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 >>> > 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
