Does anyone see value in client discovery? A client starts a transaction with an authz server without doing any registration beforehand. Based on the client id (which can be a URL or a domain name) the authz server can discover information about the client, information that normally is provided during registration: client name, description, logo, redirect URI.
The client can self assert all this information as well, but with discovery the authz server at least is confident the client controls the domain where the redirect URI is. There is no client secret issued in this case, that could be a separate call, but the discovery info could include a public key to be used with signatures. Marius On Mon, Aug 2, 2010 at 1:20 PM, Torsten Lodderstedt <[email protected]> wrote: > In the WG meeting at Maastricht, I have been asked to write down my > requirements regarding Discovery. And here they are: > > Assumptions: Discovery allows a compliant client to automatically obtain all > deployment specific data required to securely access a particular resource > servers as well as its respective authorization server for the purpose of > obtaining access tokens. > > Starting point of the discovery process is a resource URL. This URL can be > hard-coded into the client, bundled with the applications resources or > manually configured by the end-user at runtime. > > 1) Client -> Resource > The client uses the resource URL to obtain resource-specific data, such as > a) one URI refering to its authorization server > b) a definition of all scopes of the resource > c) additional data, e.g. supported signature methods and algorithms > > I do not make any assumption about how many requests are processed in order > to gather this information and whether there will be any levels of > indirections (e.g. from resource to resource server). > > 2) Client -> Authz Server > The authz server URI obtained in step 1 is used to gather the following data > from the authz server: > a) endpoint URLs (end-user authorization, tokens, ...) > b) information about the server's capabilities, e.g. the supported response > (end-user authorization endpoint) and grant types (tokens endpoint) > > The client stores the authz server's discovery URL along with the token(s) > it obtains for further use. > > And that's it from my point of view. I would very much appreciate if we > could have a discussion towards a consensus about discovery requirements. > > regards, > Torsten. > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
