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
