Re: [OAUTH-WG] Dynamic registration of client application instances
Thanks for the response. I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject. What is the best place to follow this discussion? This mailing list? Thanks Pedro On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt phil.h...@oracle.com wrote: Pedro, AFAIK this is still a TODO within the current charter. Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-10-18, at 9:06 AM, Pedro Felix wrote: Hi, Where can I find more information about the dynamic registration of client application instances? The idea is that each installed application instance has a different id, eventually related to the general application id. It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address). Thanks Pedro ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic registration of client application instances
I have a native app scenario where - There are multiple app instances - The same user user can have multiple app instances (phone, tablet) - I would want to use confidential clients - the native app instance dynamically receives the client_secret - There should be a way to limit the number of app instances that are created. For instance, one could associate an app instance to the user's email. Namely, I would like to explore the idea that an app instance is something that is simultaneous associated with the client app but also to the user (resource owner). Thanks Pedro On Fri, Oct 19, 2012 at 3:53 PM, Maciej Machulak maciej.machu...@cloudidentity.co.uk wrote: Hi Pedro, With reference to your question posted on the OAUTH WG regarding dynamic registration of OAuth clients, could you please provide us with the description of your use case. We've implemented dynamic registration on one of our systems based on the specification that we've co-authored ( http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00). It would be great to learn more about what you're trying to achieve and if we can help. Thanks, Maciej ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic registration of client application instances
The client instance registration was something that we discussed and put into the openID Connect dynamic client registration but has not yet been put back into the UMA draft. http://openid.bitbucket.org/openid-connect-registration-1_0.html The basic idea is that you can bake a access token into client code and that client then uses that to get a unique clientID and secret/register public key. There was a long discussion about this at a IIW about a year ago. In some of the native apps projects I am looking at that are not openID connect related we are looking at doing the same thing to differentiate instances of clients. John B. On 2012-10-19, at 11:47 AM, Pedro Felix pmhsfe...@gmail.com wrote: Thanks for the response. I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject. What is the best place to follow this discussion? This mailing list? Thanks Pedro On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt phil.h...@oracle.com wrote: Pedro, AFAIK this is still a TODO within the current charter. Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-10-18, at 9:06 AM, Pedro Felix wrote: Hi, Where can I find more information about the dynamic registration of client application instances? The idea is that each installed application instance has a different id, eventually related to the general application id. It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address). Thanks Pedro ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic registration of client application instances
And what if the client instance is also connected to some verifiable user attribute, such as an email? Is this a bad idea? Pedro On Fri, Oct 19, 2012 at 4:24 PM, John Bradley ve7...@ve7jtb.com wrote: The client instance registration was something that we discussed and put into the openID Connect dynamic client registration but has not yet been put back into the UMA draft. http://openid.bitbucket.org/openid-connect-registration-1_0.html The basic idea is that you can bake a access token into client code and that client then uses that to get a unique clientID and secret/register public key. There was a long discussion about this at a IIW about a year ago. In some of the native apps projects I am looking at that are not openID connect related we are looking at doing the same thing to differentiate instances of clients. John B. On 2012-10-19, at 11:47 AM, Pedro Felix pmhsfe...@gmail.com wrote: Thanks for the response. I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject. What is the best place to follow this discussion? This mailing list? Thanks Pedro On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt phil.h...@oracle.com wrote: Pedro, AFAIK this is still a TODO within the current charter. Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-10-18, at 9:06 AM, Pedro Felix wrote: Hi, Where can I find more information about the dynamic registration of client application instances? The idea is that each installed application instance has a different id, eventually related to the general application id. It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address). Thanks Pedro ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic registration of client application instances
Pedro - the best way to move this forward is to make a proposal or describe some use-cases. My own guess is that we also need a broader discussion of different client-types and their deployment models. For example, there are clients that are delivered through a secured process to tablets or devices or desktops. Another category of clients are services hosted by an application server, these have quite different characteristics as well. - prateek - Thanks for the response. I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject. What is the best place to follow this discussion? This mailing list? Thanks Pedro On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt phil.h...@oracle.com mailto:phil.h...@oracle.com wrote: Pedro, AFAIK this is still a TODO within the current charter. Phil @independentid www.independentid.com http://www.independentid.com phil.h...@oracle.com mailto:phil.h...@oracle.com On 2012-10-18, at 9:06 AM, Pedro Felix wrote: Hi, Where can I find more information about the dynamic registration of client application instances? The idea is that each installed application instance has a different id, eventually related to the general application id. It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address). Thanks Pedro ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic registration of client application instances
I think it's an interesting idea... I'm just not sure how to tie the dynamic client registration to a verified user email address. To get a verified email address, most OAuth2 flows require the client_id to be already provisioned. I do agree that from the AS/OP perspective, we don't want to allow unlimited client registrations. This could be it's own form of DoS attack. I suppose if the client has a verifiable token containing the user attributes, that could be passed optionally to the dynamic client registration flow. How the client got the verifiable token could be left out of scope. There are probably other ways to protect against abuse and they will likely be different from OP to OP for a while, until some best practices are established. Thanks, George On 10/19/12 12:00 PM, Pedro Felix wrote: And what if the client instance is also connected to some verifiable user attribute, such as an email? Is this a bad idea? Pedro On Fri, Oct 19, 2012 at 4:24 PM, John Bradley ve7...@ve7jtb.com mailto:ve7...@ve7jtb.com wrote: The client instance registration was something that we discussed and put into the openID Connect dynamic client registration but has not yet been put back into the UMA draft. http://openid.bitbucket.org/openid-connect-registration-1_0.html The basic idea is that you can bake a access token into client code and that client then uses that to get a unique clientID and secret/register public key. There was a long discussion about this at a IIW about a year ago. In some of the native apps projects I am looking at that are not openID connect related we are looking at doing the same thing to differentiate instances of clients. John B. On 2012-10-19, at 11:47 AM, Pedro Felix pmhsfe...@gmail.com mailto:pmhsfe...@gmail.com wrote: Thanks for the response. I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject. What is the best place to follow this discussion? This mailing list? Thanks Pedro On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt phil.h...@oracle.com mailto:phil.h...@oracle.com wrote: Pedro, AFAIK this is still a TODO within the current charter. Phil @independentid www.independentid.com http://www.independentid.com/ phil.h...@oracle.com mailto:phil.h...@oracle.com On 2012-10-18, at 9:06 AM, Pedro Felix wrote: Hi, Where can I find more information about the dynamic registration of client application instances? The idea is that each installed application instance has a different id, eventually related to the general application id. It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address). Thanks Pedro ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic registration of client application instances
Consider that the issues comes from 2 angles: 1. The desire to distinguish between instances of a client app (e.g. on mobile phones) 2. The desire for the client to register with particular instances of a resource service. The objective: to establish a unique credential that binds a particular client instance (or set of clients) with a particular resource service provider. I note that, per John's suggestion, this is something like what OpenID Connect attempted to solve with their dynamic registration draft. As further input, during the review of the OAuth Threat Model, there was significant inquires and discussion about how to assess the legitimacy or authenticity of a piece of client software. Though we didn't solve it, there was a lot of requests for finding a way to authenticate client software as simply being the one made by its developer. Therefore, I think there is requirement to be able to authenticate software (at some level) that is part of the dynamic registration process. I think there is a few of steps in dynamic registration. 1. A method to authenticate the software. Is it signed by its publisher? If the resource being accessed is developed by a single publisher, has the client been registered with the publisher? Hypothetical examples of this might be clients designed to work with MS Exchange, or Oracle CRM. 2. Optionally establishing a means to distinguish one client instance from another. 3. Dynamically issuing the client with a credential (which may or may not be instance specific) to use with a particular instance of a resource authorization server. Regarding step 1, I note that in the case OpenID Connect, there is no single place to even register a client as there is with proprietary APIs. Not sure if software signing can work here. The same problem will emerge with any standards based API (e.g. such as SCIM). This is why I think dynamic registration is of broad interest in the standards community beyond just OpenID. Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-10-19, at 9:40 AM, George Fletcher wrote: I think it's an interesting idea... I'm just not sure how to tie the dynamic client registration to a verified user email address. To get a verified email address, most OAuth2 flows require the client_id to be already provisioned. I do agree that from the AS/OP perspective, we don't want to allow unlimited client registrations. This could be it's own form of DoS attack. I suppose if the client has a verifiable token containing the user attributes, that could be passed optionally to the dynamic client registration flow. How the client got the verifiable token could be left out of scope. There are probably other ways to protect against abuse and they will likely be different from OP to OP for a while, until some best practices are established. Thanks, George On 10/19/12 12:00 PM, Pedro Felix wrote: And what if the client instance is also connected to some verifiable user attribute, such as an email? Is this a bad idea? Pedro On Fri, Oct 19, 2012 at 4:24 PM, John Bradley ve7...@ve7jtb.com wrote: The client instance registration was something that we discussed and put into the openID Connect dynamic client registration but has not yet been put back into the UMA draft. http://openid.bitbucket.org/openid-connect-registration-1_0.html The basic idea is that you can bake a access token into client code and that client then uses that to get a unique clientID and secret/register public key. There was a long discussion about this at a IIW about a year ago. In some of the native apps projects I am looking at that are not openID connect related we are looking at doing the same thing to differentiate instances of clients. John B. On 2012-10-19, at 11:47 AM, Pedro Felix pmhsfe...@gmail.com wrote: Thanks for the response. I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject. What is the best place to follow this discussion? This mailing list? Thanks Pedro On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt phil.h...@oracle.com wrote: Pedro, AFAIK this is still a TODO within the current charter. Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-10-18, at 9:06 AM, Pedro Felix wrote: Hi, Where can I find more information about the dynamic registration of client application instances? The idea is that each installed application instance has a different id, eventually related to the general application id. It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address). Thanks Pedro ___ OAuth mailing list
Re: [OAUTH-WG] Dynamic registration of client application instances
It would be nice if software signing could work, however verifying that over a network connection without some sort of OS level TPM seems overly ambitious. We were not trying to solve that problem with connect, only find a way that we could provision a secret for native apps. Certainly the registration token can be stolen and faked by a rogue app. However with a good app it lets you get a unique client secret for the app or register a public key (something perhaps useful for Proof of possession tokens as well) For web server clients this is not a big deal because registration is a one tie thing. For native apps on phones etc having every one with the same clientID and password is not a good thing. John B. On 2012-10-19, at 2:39 PM, Phil Hunt phil.h...@oracle.com wrote: Consider that the issues comes from 2 angles: 1. The desire to distinguish between instances of a client app (e.g. on mobile phones) 2. The desire for the client to register with particular instances of a resource service. The objective: to establish a unique credential that binds a particular client instance (or set of clients) with a particular resource service provider. I note that, per John's suggestion, this is something like what OpenID Connect attempted to solve with their dynamic registration draft. As further input, during the review of the OAuth Threat Model, there was significant inquires and discussion about how to assess the legitimacy or authenticity of a piece of client software. Though we didn't solve it, there was a lot of requests for finding a way to authenticate client software as simply being the one made by its developer. Therefore, I think there is requirement to be able to authenticate software (at some level) that is part of the dynamic registration process. I think there is a few of steps in dynamic registration. 1. A method to authenticate the software. Is it signed by its publisher? If the resource being accessed is developed by a single publisher, has the client been registered with the publisher? Hypothetical examples of this might be clients designed to work with MS Exchange, or Oracle CRM. 2. Optionally establishing a means to distinguish one client instance from another. 3. Dynamically issuing the client with a credential (which may or may not be instance specific) to use with a particular instance of a resource authorization server. Regarding step 1, I note that in the case OpenID Connect, there is no single place to even register a client as there is with proprietary APIs. Not sure if software signing can work here. The same problem will emerge with any standards based API (e.g. such as SCIM). This is why I think dynamic registration is of broad interest in the standards community beyond just OpenID. Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-10-19, at 9:40 AM, George Fletcher wrote: I think it's an interesting idea... I'm just not sure how to tie the dynamic client registration to a verified user email address. To get a verified email address, most OAuth2 flows require the client_id to be already provisioned. I do agree that from the AS/OP perspective, we don't want to allow unlimited client registrations. This could be it's own form of DoS attack. I suppose if the client has a verifiable token containing the user attributes, that could be passed optionally to the dynamic client registration flow. How the client got the verifiable token could be left out of scope. There are probably other ways to protect against abuse and they will likely be different from OP to OP for a while, until some best practices are established. Thanks, George On 10/19/12 12:00 PM, Pedro Felix wrote: And what if the client instance is also connected to some verifiable user attribute, such as an email? Is this a bad idea? Pedro On Fri, Oct 19, 2012 at 4:24 PM, John Bradley ve7...@ve7jtb.com wrote: The client instance registration was something that we discussed and put into the openID Connect dynamic client registration but has not yet been put back into the UMA draft. http://openid.bitbucket.org/openid-connect-registration-1_0.html The basic idea is that you can bake a access token into client code and that client then uses that to get a unique clientID and secret/register public key. There was a long discussion about this at a IIW about a year ago. In some of the native apps projects I am looking at that are not openID connect related we are looking at doing the same thing to differentiate instances of clients. John B. On 2012-10-19, at 11:47 AM, Pedro Felix pmhsfe...@gmail.com wrote: Thanks for the response. I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject. What is the best place to follow
Re: [OAUTH-WG] Dynamic registration of client application instances
I agree with your assessment here. Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-10-19, at 11:12 AM, John Bradley wrote: It would be nice if software signing could work, however verifying that over a network connection without some sort of OS level TPM seems overly ambitious. We were not trying to solve that problem with connect, only find a way that we could provision a secret for native apps. Certainly the registration token can be stolen and faked by a rogue app. However with a good app it lets you get a unique client secret for the app or register a public key (something perhaps useful for Proof of possession tokens as well) For web server clients this is not a big deal because registration is a one tie thing. For native apps on phones etc having every one with the same clientID and password is not a good thing. John B. On 2012-10-19, at 2:39 PM, Phil Hunt phil.h...@oracle.com wrote: Consider that the issues comes from 2 angles: 1. The desire to distinguish between instances of a client app (e.g. on mobile phones) 2. The desire for the client to register with particular instances of a resource service. The objective: to establish a unique credential that binds a particular client instance (or set of clients) with a particular resource service provider. I note that, per John's suggestion, this is something like what OpenID Connect attempted to solve with their dynamic registration draft. As further input, during the review of the OAuth Threat Model, there was significant inquires and discussion about how to assess the legitimacy or authenticity of a piece of client software. Though we didn't solve it, there was a lot of requests for finding a way to authenticate client software as simply being the one made by its developer. Therefore, I think there is requirement to be able to authenticate software (at some level) that is part of the dynamic registration process. I think there is a few of steps in dynamic registration. 1. A method to authenticate the software. Is it signed by its publisher? If the resource being accessed is developed by a single publisher, has the client been registered with the publisher? Hypothetical examples of this might be clients designed to work with MS Exchange, or Oracle CRM. 2. Optionally establishing a means to distinguish one client instance from another. 3. Dynamically issuing the client with a credential (which may or may not be instance specific) to use with a particular instance of a resource authorization server. Regarding step 1, I note that in the case OpenID Connect, there is no single place to even register a client as there is with proprietary APIs. Not sure if software signing can work here. The same problem will emerge with any standards based API (e.g. such as SCIM). This is why I think dynamic registration is of broad interest in the standards community beyond just OpenID. Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-10-19, at 9:40 AM, George Fletcher wrote: I think it's an interesting idea... I'm just not sure how to tie the dynamic client registration to a verified user email address. To get a verified email address, most OAuth2 flows require the client_id to be already provisioned. I do agree that from the AS/OP perspective, we don't want to allow unlimited client registrations. This could be it's own form of DoS attack. I suppose if the client has a verifiable token containing the user attributes, that could be passed optionally to the dynamic client registration flow. How the client got the verifiable token could be left out of scope. There are probably other ways to protect against abuse and they will likely be different from OP to OP for a while, until some best practices are established. Thanks, George On 10/19/12 12:00 PM, Pedro Felix wrote: And what if the client instance is also connected to some verifiable user attribute, such as an email? Is this a bad idea? Pedro On Fri, Oct 19, 2012 at 4:24 PM, John Bradley ve7...@ve7jtb.com wrote: The client instance registration was something that we discussed and put into the openID Connect dynamic client registration but has not yet been put back into the UMA draft. http://openid.bitbucket.org/openid-connect-registration-1_0.html The basic idea is that you can bake a access token into client code and that client then uses that to get a unique clientID and secret/register public key. There was a long discussion about this at a IIW about a year ago. In some of the native apps projects I am looking at that are not openID connect related we are looking at doing the same thing to differentiate instances of clients. John B. On 2012-10-19, at 11:47 AM, Pedro Felix pmhsfe...@gmail.com wrote: Thanks for the response. I know that this area is
Re: [OAUTH-WG] Agenda for Atlanta Meeting
On those lines, I've been asked to sign up as co-editor for the dynamic client registration document, and I'd be OK with that. There are a lot of little side documents that I'd like to see finalized (XML encoding, instance, UX, dynamic reg, chained auth, MAC). We can discuss details at either IIW or IETF -- but it's something that I'd definitely like to help see through how I can. -- Justin On Oct 10, 2012, at 4:52 AM, Hannes Tschofenig wrote: Hi Justin, Hi Torsten, We will take care of appropriate time management and agenda topics that have not seen enough presentation on the list will be postponed. In fact, I am concerned about the progress with the use cases document and the dynamic client registration work. I have notified the authors of my concerns privately already. Ciao Hannes On 10/10/2012 08:09 AM, Torsten Lodderstedt wrote: +1 Richer, Justin P. jric...@mitre.org schrieb: Good for me, AS LONG AS we make absolutely SURE that we leave plenty of time for #8 on the agenda, to the point of cutting off and tabling other discussions ahead of time. There are a lot of ancillary documents in various states of use/neglect that shouldn't be left aside by the WG, and this is a good venue for all of that. -- Justin On Oct 7, 2012, at 12:08 PM, Zeltsan, Zachary (Zachary) wrote: +1 Zachary -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt Sent: Saturday, October 06, 2012 2:54 PM To: Torsten Lodderstedt Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting +1 Phil On 2012-10-06, at 10:07, Torsten Lodderstedt tors...@lodderstedt.net wrote: fine for me Am 05.10.2012 10:03, schrieb Hannes Tschofenig: Hi all, here is an agenda proposal for the Atlanta IETF meeting: (The indicated names are proposals.) -- Agenda: 1. Status Update, Agenda Bashing (Chairs) 2. Token Revocation (Thorsten) 3. Assertions (Brian + Mike) 4. OAuth Use Cases (Zachary) 5. JWT (Mike) 6. Security (Phil) 7. Dynamic Client Registration (Thomas) 8. Roadmap -- In the last item we would like to discuss the bigger picture of how to get OAuth 2.0 deployment improved. There are at least 2 parts to this, namely (a) what other specifications do we need to work on, and (b) how do we improve interoperability. Let us know whether you think that this fits your needs. Ciao Hannes Derek PS: I am hoping to see daft updates of the WG items soon. OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Agenda for Atlanta Meeting
I will be at iiw on tues/wed. Phil On 2012-10-19, at 12:10, Richer, Justin P. jric...@mitre.org wrote: On those lines, I've been asked to sign up as co-editor for the dynamic client registration document, and I'd be OK with that. There are a lot of little side documents that I'd like to see finalized (XML encoding, instance, UX, dynamic reg, chained auth, MAC). We can discuss details at either IIW or IETF -- but it's something that I'd definitely like to help see through how I can. -- Justin On Oct 10, 2012, at 4:52 AM, Hannes Tschofenig wrote: Hi Justin, Hi Torsten, We will take care of appropriate time management and agenda topics that have not seen enough presentation on the list will be postponed. In fact, I am concerned about the progress with the use cases document and the dynamic client registration work. I have notified the authors of my concerns privately already. Ciao Hannes On 10/10/2012 08:09 AM, Torsten Lodderstedt wrote: +1 Richer, Justin P. jric...@mitre.org schrieb: Good for me, AS LONG AS we make absolutely SURE that we leave plenty of time for #8 on the agenda, to the point of cutting off and tabling other discussions ahead of time. There are a lot of ancillary documents in various states of use/neglect that shouldn't be left aside by the WG, and this is a good venue for all of that. -- Justin On Oct 7, 2012, at 12:08 PM, Zeltsan, Zachary (Zachary) wrote: +1 Zachary -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt Sent: Saturday, October 06, 2012 2:54 PM To: Torsten Lodderstedt Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting +1 Phil On 2012-10-06, at 10:07, Torsten Lodderstedt tors...@lodderstedt.net wrote: fine for me Am 05.10.2012 10:03, schrieb Hannes Tschofenig: Hi all, here is an agenda proposal for the Atlanta IETF meeting: (The indicated names are proposals.) -- Agenda: 1. Status Update, Agenda Bashing (Chairs) 2. Token Revocation (Thorsten) 3. Assertions (Brian + Mike) 4. OAuth Use Cases (Zachary) 5. JWT (Mike) 6. Security (Phil) 7. Dynamic Client Registration (Thomas) 8. Roadmap -- In the last item we would like to discuss the bigger picture of how to get OAuth 2.0 deployment improved. There are at least 2 parts to this, namely (a) what other specifications do we need to work on, and (b) how do we improve interoperability. Let us know whether you think that this fits your needs. Ciao Hannes Derek PS: I am hoping to see daft updates of the WG items soon. OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
