Yes, all of these all seem like the right set of use cases. I'm not sure if I'll have much time to devote to them over the next few months though.
--David On Mon, Aug 2, 2010 at 2:14 PM, William Mills <[email protected]> wrote: > 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: [email protected] [mailto:[email protected]] > > On Behalf Of Marius Scurtescu > > Sent: Monday, August 02, 2010 1:47 PM > > To: Torsten Lodderstedt > > Cc: OAuth WG ([email protected]) > > 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 > > <[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 > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
