Yes.
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of William Mills > Sent: Wednesday, August 04, 2010 9:05 AM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth Discovery Requirements > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
