Subject: [OAUTH-WG] OAuth Discovery Requirements

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 02 Aug 2010 22:20:19 +0200

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.

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 2 Aug 2010 13:47:13 -0700

Does anyone see value in client discovery?

A client starts a transaction with an authz server without doing any
registration beforehand. Based on the client id (which can be a URL or
a domain name) the authz server can discover information about the
client, information that normally is provided during registration:
client name, description, logo, redirect URI.

The client can self assert all this information as well, but with
discovery the authz server at least is confident the client controls
the domain where the redirect URI is.

There is no client secret issued in this case, that could be a
separate call, but the discovery info could include a public key to be
used with signatures.

Marius

On Mon, Aug 2, 2010 at 1:20 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> 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
> 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
> The authz server URI obtained in step 1 is used to gather the following data
> from the authz server:
> 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.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: William Mills <[email-masked]>
Date: Mon, 2 Aug 2010 14:14:40 -0700

Client discovery can be useful for presenting a nicer user experience in token management for example, displaying a favicon for example to help identify the tokens listed for revocation.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Marius Scurtescu
> Sent: Monday, August 02, 2010 1:47 PM
> To: Torsten Lodderstedt
> Cc: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] OAuth Discovery Requirements
> 
> A client starts a transaction with an authz server without 
> doing any registration beforehand. Based on the client id 
> (which can be a URL or a domain name) the authz server can 
> discover information about the client, information that 
> normally is provided during registration:
> The client can self assert all this information as well, but 
> with discovery the authz server at least is confident the 
> client controls the domain where the redirect URI is.
> 
> There is no client secret issued in this case, that could be 
> a separate call, but the discovery info could include a 
> public key to be used with signatures.
> 
> Marius
> 
> 
> 
> > 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
> > order to gather this information and whether there will be 
> any levels 
> > of indirections (e.g. from resource to resource server).
> >
> > The authz server URI obtained in step 1 is used to gather the 
> > following data from the authz server:
> > 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.
> >
> >
> >

---

From: David Recordon <[email-masked]>
Date: Mon, 2 Aug 2010 14:35:49 -0700

Yes, all of these all seem like the right set of use cases. I'm not sure if
I'll have much time to devote to them over the next few months though.

--David

On Mon, Aug 2, 2010 at 2:14 PM, William Mills <[email-masked]> wrote:

> Client discovery can be useful for presenting a nicer user experience in
> token management for example, displaying a favicon for example to help
> identify the tokens listed for revocation.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 4 Aug 2010 09:39:09 +0200

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 <[email-masked]>:

> 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
> 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).
> 
> The authz server URI obtained in step 1 is used to gather the following data from the authz server:
> 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.
> 
> 
>

---

From: William Mills <[email-masked]>
Date: Wed, 4 Aug 2010 09:05:02 -0700

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

> On Behalf Of Torsten Lodderstedt
> Sent: Wednesday, August 04, 2010 12:39 AM
> To: Torsten Lodderstedt
> 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).
> 
> > 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
> > 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).
> > 
> > The authz server URI obtained in step 1 is used to gather 
> the following data from the authz server:
> > The client stores the authz server's discovery URL along 
> with the token(s) it obtains for further use.
> > 
> appreciate if we could have a discussion towards a consensus 
> about discovery requirements.
> > 
> > regards,
> > Torsten.
> > 
> > 
> >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 04 Aug 2010 19:01:43 +0200

I'm not familiar with SASL. So out of curiosity: What is the relation 
between HTTP WWW-Authenticate headers and SASL?

regards,
Torsten.

---

From: William Mills <[email-masked]>
Date: Wed, 4 Aug 2010 12:09:49 -0500

Only in my head.  But I do want to use a consistent definition for discovery within SASL.  

> From: Torsten Lodderstedt [mailto:[email-masked]] 
> Sent: Wednesday, August 04, 2010 10:02 AM
> To: William Mills
> I'm not familiar with SASL. So out of curiosity: What is the 
> relation between HTTP WWW-Authenticate headers and SASL?
> 
> regards,
> Torsten.
> 
> > 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
> >
> >    
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Torsten Lodderstedt
> >> 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).
> >>
> >> respective authorization server for the purpose of 
> obtaining access 
> >> tokens.
> >>      
> >> 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
> there will 
> >> be any levels of indirections (e.g. from resource to resource 
> >> server).
> >>      
> >> appreciate if we could have a discussion towards a consensus about 
> >> discovery requirements.
> >>      
> >>> regards,
> >>> Torsten.
> >>>
> >>>
> >>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 4 Aug 2010 15:39:38 -0700

Yes.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of William Mills
> Sent: Wednesday, August 04, 2010 9:05 AM
> To: Torsten Lodderstedt
> 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
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Torsten Lodderstedt
> > described in my original posting independent of "functional" requests.
> > (2) Discovery for unauthorized requests (WWW-Authenticate header).
> >
> > 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.
> > >
> > processed in order to gather this information and whether there will
> > be any levels of indirections (e.g. from resource to resource server).
> > >

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 10 Aug 2010 15:45:36 -0400

+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