Part of my argument for leaving this parameter in is exactly the use case that you're saying: the client doesn't tell the server anything but the server tells the client what it must use to authenticate. That's already possible using what's there. But I'm loathe to pull out this particular piece of metadata as non-parallel and separate from the rest of the parameters.
The whole negotiation for this or any other parameter can happen at least partially out of band, for instance as part of the discovery process. In Blue Button+ (reference for others, here: http://blue-button.github.io/blue-button-plus-pull/), you could either pre-register it or you could do it per-instance. You'd probably pre-register this parameter in most cases though because the nature of the app's capabilities won't really change. What I think this parameter gives you is a *chance* for things to go right or stop early before they go horribly wrong later in the process where the stakes are higher. All of the if-then steps I listed out below still exist if the client can't tell its preferred auth method to the server in-band during registration, the decisions just happen at a different times where it's harder to recover programmatically. And since it's an optional parameter on both sides, people who don't want to deal with the logic to process it don't have to do anything with it. -- Justin On May 9, 2013, 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
