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