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> wrote: > 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 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 listOAuth@ietf.orghttps://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 > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
