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

Reply via email to