The client needs to be able to say only use a particular auth method to disallow the Authorization server from providing a weaker method to an attacker.
This is a required parameter to allow a Authorization server to support high and low LoA clients dynamically. John B. On 2013-05-09, at 2:44 PM, Phil Hunt <phil.h...@oracle.com> wrote: > Justin, > > Just to progress towards resolving this issue, what I would like to > understand is how specifying authentication type makes things simpler or more > inter-operable. I'm concerned that the logic you proposed early in the thread > is a lot more complexity. I would prefer just having the server tell the > client what authentication it MUST use. > > As an alternative, the negotiation for credential method/type could occur > during the initial developer registration of the app. As in your "blue > button" health case (did I remember that right), the initial registration JWT > would be used in the dynamic registration and allow the registration server > to observe any previously negotiated client preferences OOB of this spec. > Or, are you saying that individual instances have some need to change > authentication types on a per deployment basis independent of what the > associated authorization server wants them to use? If so what is it? > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > On 2013-05-06, at 11:56 AM, Phil Hunt wrote: > >> Justin, >> >> What you describe, though good intentioned, seems like a lot of complexity >> without getting an actual benefit. I would rather not have >> token_endpoint_auth_method at all. >> >> Think about someone writing a general purpose SCIM client or OIDC client. >> Site as uses method 1 and 2, site b supports 2,3 and 4. Site c only 5 and >> 6. So if each site is willing to negotiate authn, how has this developer's >> coding been reduced? The developer will end up having to implement all >> popular methods regardless of discovery or the ability of the client to >> select. In fact, they have to do all the logic you describe below AND >> implement all methods. >> >> I have also thought through, does it matter since it is optional? I think >> it does. If servers just ignore the param most of the time, what value is >> there? >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.com >> >> >> >> >> >> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >> >>> In spite of what John seems to think, that dependency was never there. The >>> whole discovery process is related, but separate, from registration. It >>> could happen using OIDC, it could happen with Bill Mills's LRDD link types, >>> it could happen with Nat's proposed HAL-based system, it could happen by >>> the developer going to the service provider's documentation page and >>> reading a bunch of text (which is what happens with large OAuth providers >>> today) -- it ultimately doesn't matter. >>> >>> And I think that the Dynamic Registration protocol that we have here is >>> robust against that kind of diversity. Let's take the >>> token_endpoint_auth_method parameter as an example. Let's say a client >>> shows up to a service it's just discovered -- through whatever means, we >>> don't actually care. This client either has some idea of what auth methods >>> the server supports (through a discovery mechanism) or it doesn't. If it >>> does, it will also know which methods it supports and it can pick one. If >>> it doesn't, it will still know which methods it supports and will just pick >>> one. The server will then take that information and do one of three things: >>> >>> 1) Accept what the client proposes and use that. This is of course the >>> ideal situation where everybody gets what they want, and this can be >>> brought about more often by a good discovery process. >>> 2) Reject what the client proposes with an error code >>> (invalid_client_metadata would cover this). The client then has to >>> re-register with a different value or just give up because the two systems >>> are using different auth methods that can't be reconciled. >>> 3) Ignore what the client proposes and return the server's preferred >>> method. The client can then, in turn: >>> a) Accept what the server returns and use that, if it supports it. This is >>> also ideal because everybody is happy again. >>> b) Reject what the server returns and either try the registration again >>> with another value or give up. >>> c) Ignore what the server returns and fail when doing a token request. This >>> would be a dumb thing for a dumb client to do. >>> >>> Alternatively, the client could just not mention it and have the server >>> dictate what method it will use, and the client will either accept, reject, >>> or ignore it. This process applies to every parameter in the system, from >>> something innocuous as the client's TOS uri to something as >>> security-critical as the redirect_uri (which gets its own special error >>> message). >>> >>> I think that the assumption of full automation for all clients to all >>> servers is a red herring in the OAuth world for the simple fact that the >>> API that's being accessed/protected isn't going to be universally >>> compatible anyway. I agree fully that a well-specified service discovery is >>> important and we should, as a working group, help figure out what that >>> looks like. As mentioned above, several of us already are. But I don't >>> think it's helpful to conflate the registration and discovery processes and >>> turn them into some kind of negotiation system. I think we can do a good >>> job of making it widely useful without that. >>> >>> -- Justin >>> >>> On May 5, 2013, at 1:05 PM, Phil Hunt <phil.h...@oracle.com> >>> wrote: >>> >>>> Justin, >>>> >>>> Has the assumption of a discovery service defined by OIDC been removed? >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.h...@oracle.com >>>> >>>> >>>> >>>> >>>> >>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>> >>>>> Handful of minor changes in this revision, including tightening the >>>>> language around scopes and adding an absolute-URI based mechanism for >>>>> extending token_endpoint_auth_method (no registry, still). No normative >>>>> changes beyond removing an unreachable error state. (Thanks, Nov.) Please >>>>> check the diffs, we welcome feedback. I personally think this is really >>>>> getting close to final. >>>>> >>>>> -- Justin >>>>> >>>>> On May 5, 2013, at 3:45 PM, <internet-dra...@ietf.org> >>>>> wrote: >>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the Web Authorization Protocol Working >>>>>> Group of the IETF. >>>>>> >>>>>> Title : OAuth 2.0 Dynamic Client Registration Protocol >>>>>> Author(s) : Justin Richer >>>>>> John Bradley >>>>>> Michael B. Jones >>>>>> Maciej Machulak >>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>> Pages : 25 >>>>>> Date : 2013-05-05 >>>>>> >>>>>> Abstract: >>>>>> This specification defines an endpoint and protocol for dynamic >>>>>> registration of OAuth 2.0 Clients at an Authorization Server and >>>>>> methods for the dynamically registered client to manage its >>>>>> registration. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-10 >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
