+1
(1) is crystal-clear and is a must, as far as I am concerned. (2) would
definitely help as a catch-all for unauthorized requests.
Igor
Torsten Lodderstedt wrote:
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
