Client discovery can be useful for presenting a nicer user experience in token management for example, displaying a favicon for example to help identify the tokens listed for revocation.
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] > On Behalf Of Marius Scurtescu > Sent: Monday, August 02, 2010 1:47 PM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth Discovery Requirements > > 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 > <tors...@lodderstedt.net> 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 > > 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
