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
