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