There's also this means of providing identifying instance information for a single client registration:
http://tools.ietf.org/html/draft-richer-oauth-instance-00 This is solving a different need and can be used in tandem with, or in lieu of, the dynamic registration per-client, depending on your use case. Sometimes you're happy with just one registered client_id but want to track multiple copies of it getting tokens -- that's what this extension is for. -- Justin On Oct 20, 2012, at 9:37 PM, Nat Sakimura wrote: On the instance identification purpose, it may be interesting to generate a key-pair and register the public key out of it to the server, similar to what we do in the case of Self-Issued OP in OpenID Connect. So, the app will have the client_id, which is pre-provisioned to the same app as a "class", and the app, when first registering itself to the server will generate the "instance id" which is tied to the secret key that is typically stored in key-chain or similar devices. Note that the key generation has to be done for each server or server groups as otherwise it will become trivial to track the user across. Nat On Sat, Oct 20, 2012 at 3:35 AM, Phil Hunt <phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote: I agree with your assessment here. Phil @independentid www.independentid.com<http://www.independentid.com/> phil.h...@oracle.com<mailto: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<mailto: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<http://www.independentid.com/> phil.h...@oracle.com<mailto: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<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<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<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 -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ 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
