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
