Only in my head. But I do want to use a consistent definition for discovery within SASL.
> -----Original Message----- > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Wednesday, August 04, 2010 10:02 AM > To: William Mills > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth Discovery Requirements > > I'm not familiar with SASL. So out of curiosity: What is the > relation between HTTP WWW-Authenticate headers and SASL? > > regards, > Torsten. > > Am 04.08.2010 18:05, schrieb William Mills: > > 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
