I'm assuming that the WWW-Authenticate style will also be supported (because I'm going to try to make sure it gets added). I specifically want this for SASL discovery.
-bill > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] > On Behalf Of Torsten Lodderstedt > Sent: Wednesday, August 04, 2010 12:39 AM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth Discovery Requirements > > Would it make sense to support two scenarios? (1) Discovery > as described in my original posting independent of > "functional" requests. (2) Discovery for unauthorized > requests (WWW-Authenticate header). > > The later might be a lightweight variant of the first scenario. > > regards, > Torsten. > > > > Am 02.08.2010 um 22:20 schrieb Torsten Lodderstedt > <tors...@lodderstedt.net>: > > > 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
