Subject: [OAUTH-WG] Client cannot specify the token type it needs

From: Prabath Siriwardena <[email-masked]>
Date: Mon, 21 Jan 2013 08:58:26 +0530

Although token type is extensible according to the OAuth core specification
- it is fully governed by the Authorization Server.

There can be a case where a single AS supports multiple token types based
on client request.

But currently we don't have a way the client can specify (or at least
suggest) which token type it needs in the OAuth access token request ?

Is this behavior intentional ? or am I missing something...

Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

---

From: William Mills <[email-masked]>
Date: Sun, 20 Jan 2013 21:08:39 -0800 (PST)

This is true.  It's possible for the AS to vary it's behavior on scope name, but it's presumed the AS and RS have an agreement of what token type is in play.  Likely a good extension to the spec.

________________________________
 From: Prabath Siriwardena <[email-masked]>
To: "[email-masked] WG" <[email-masked]> 
Sent: Sunday, January 20, 2013 7:28 PM
Subject: [OAUTH-WG] Client cannot specify the token type it needs

Although token type is extensible according to the OAuth core specification - it is fully governed by the Authorization Server.

There can be a case where a single AS supports multiple token types based on client request.

But currently we don't have a way the client can specify (or at least suggest) which token type it needs in the OAuth access token request ?

Thanks & Regards,
Prabath

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: [email-masked]
Date: Mon, 21 Jan 2013 13:18:24 +0800

The token type shoulbe decided by resource server, which consumes access 
token.
Client just re-tell the requested token type to AS. 
Client should not specify the token type.

[email-masked] 写于 2013-01-21 13:08:39:

> This is true.  It's possible for the AS to vary it's behavior on 
> scope name, but it's presumed the AS and RS have an agreement of 
> what token type is in play.  Likely a good extension to the spec.
> 
> Although token type is extensible according to the OAuth core 
> specification - it is fully governed by the Authorization Server.
> 
> But currently we don't have a way the client can specify (or at 
> least suggest) which token type it needs in the OAuth access token 
request ?

---

From: Prabath Siriwardena <[email-masked]>
Date: Mon, 21 Jan 2013 10:59:05 +0530

Think about a distributed setup. You have single Authorization Server and
multiple Resource Servers.

Although OAuth nicely decouples AS from RS - AFAIK there is no standard
established for communication betweens AS and RS - how to declare metadata
between those.

Also there can be Resource Servers which support multiple token types. It
could vary on APIs hosted in a given RS.

Thanks & regards,
-Prabath

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: [email-masked]
Date: Mon, 21 Jan 2013 13:38:41 +0800

Well, if RS could specify token type, then Client could transfer it to AS, 

I think, but it is not a good idea for client itself to specify the token 
type. 

Prabath Siriwardena <[email-masked]> 写于 2013-01-21 13:29:05:

> Think about a distributed setup. You have single Authorization 
> Server and multiple Resource Servers.
> 
> Although OAuth nicely decouples AS from RS - AFAIK there is no 
> standard established for communication betweens AS and RS - how to 
> declare metadata between those.
> 
> Also there can be Resource Servers which support multiple token 
> types. It could vary on APIs hosted in a given RS.
> 
> Thanks & regards,
> -Prabath
> 
> The token type shoulbe decided by resource server, which consumes 
> access token. 
> > least suggest) which token type it needs in the OAuth access 
tokenrequest ?

---

From: William Mills <[email-masked]>
Date: Sun, 20 Jan 2013 21:44:45 -0800 (PST)

Not a problem for the client to request a type, but it may not get it.

________________________________
 From: "[email-masked]" <[email-masked]>
To: Prabath Siriwardena <[email-masked]> 
Cc: "[email-masked] WG" <[email-masked]>; William Mills <[email-masked]> 
Sent: Sunday, January 20, 2013 9:38 PM
Subject: Re: Re: Re: [OAUTH-WG] Client cannot specify the token type it needs

Well, if RS could specify token type,
then Client could transfer it to AS,  
I think, but it is not a good idea for
client itself to specify the token type.  

Prabath Siriwardena <[email-masked]> 写于
2013-01-21 13:29:05:

> > There can be a case where a single AS supports multiple token
types 
> > based on client request. 
tokenrequest ?

---

From: [email-masked]
Date: Mon, 21 Jan 2013 15:13:48 +0800

> Not a problem for the client to request a type, but it may not get it.
I don't object client requesting a type, but I think it is meaningful only 
when the requested type is specified by a RS,
and client just relay that request to AS.

> I think, but it is not a good idea for client itself to specify the 
> token type. 
> 
>

---

From: Prabath Siriwardena <[email-masked]>
Date: Mon, 21 Jan 2013 12:57:57 +0530

I guess that is a pattern used many scenarios. Requesting client can
suggest - but its up to the AS to honor it or not...

Thanks & regards,
-prabath

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: [email-masked]
Date: Mon, 21 Jan 2013 15:37:34 +0800

> suggest - but its up to the AS to honor it or not...

Not exactly. For example, RS supports two token types, one is bear token, 
another is holer-of-key which is assumed more secure than the first one.
RS realy wants the seconde type, but （a dishonest） client, always 
choosing the weakest, requests the first one. 
what is the meaning for client to specify the token type? 

> I don't object client requesting a type, but I think it is 
> meaningful only when the requested type is specified by a RS, 
types

---

From: Prabath Siriwardena <[email-masked]>
Date: Mon, 21 Jan 2013 13:27:25 +0530

I am not objecting that RS should define it's requirements...  and RS
should be able to do it by each resource... So ideally RS may have  away to
express that in a WADL and we need to have a standard mechanism established
for communication between RS and AS.

In WS-Trust - SP can declare it's token requirements via WS-SecurityPolicy,
in WSDL. And client reads the WSDL and identify the token requirements.
Then based on those requirements, client talks to the STS and gets the
token.

Thanks & regards,
-Prabath

On Mon, Jan 21, 2013 at 1:07 PM, <[email-masked]> wrote:

> RS realy wants the seconde type, but （a dishonest） client, always choosing
> the weakest, requests the first one.

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Eve Maler <[email-masked]>
Date: Wed, 23 Jan 2013 09:23:44 -0800

FWIW, some of us have made a proposal for exactly this type of standardized AS/RS communication:

http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00

The UMA profile refers normatively to this spec, and at that higher profile-specific level, it has an extensive set of AS configuration data that includes a way to declare token types supported. It could make sense for an RS to register its preferences for token types supported among those declared in the AS config data. Should this "preferred token type" semantic should be sedimented down to the "draft-hardjono-oauth-resource-reg" level?

	Eve

On 20 Jan 2013, at 9:29 PM, Prabath Siriwardena <[email-masked]> wrote:

> Think about a distributed setup. You have single Authorization Server and multiple Resource Servers.
> 
> Although OAuth nicely decouples AS from RS - AFAIK there is no standard established for communication betweens AS and RS - how to declare metadata between those.
> 
> Also there can be Resource Servers which support multiple token types. It could vary on APIs hosted in a given RS.
> 
> Thanks & regards,
> -Prabath
> 
> 
> The token type shoulbe decided by resource server, which consumes access token. 
> > least suggest) which token type it needs in the OAuth access token request ? 
> > 

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: George Fletcher <[email-masked]>
Date: Wed, 23 Jan 2013 13:05:48 -0500

In addition, UMA also defines a was for the RS to instruct the client on 
what to present to the AS in order to receive a token that will work at 
the RS. At the moment this flow is UMA specific but could probably be 
abstracted into a general pattern.

Also, there are really three parties that have to agree in order for the 
client to get access to the protected resource.
    a. the client -- it may only support bearer tokens and not holder-of-key
    b. the RS -- it may only allow bearer tokens from trusted clients
    c. the AS -- it may only issue bearer tokens

Developing generic negotiation amongst these parties may be overkill 
since in most cases the client know what RS it will be talking to and 
potentially even the authorizations server(s) as well.  Given that some 
pre-knowledge is probably in play, a simple solution may be to allow the 
client to register via the dynamic registration proposal the token types 
it supports and then the AS can use that data as a filtering mechanism 
when the client asks for a token.

Thanks,
George

On 1/23/13 12:23 PM, Eve Maler wrote:
> The UMA profile refers normatively to this spec, and at that higher 
> profile-specific level, it has an extensive set of AS configuration 
> data that includes a way to declare token types supported. It could 
> make sense for an RS to register its preferences for token types 
> supported among those declared in the AS config data. Should this 
> "preferred token type" semantic should be sedimented down to the 
> "draft-hardjono-oauth-resource-reg" level?
>
> Eve
>
> On 20 Jan 2013, at 9:29 PM, Prabath Siriwardena <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> On Mon, Jan 21, 2013 at 10:48 AM, <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>     [email-masked] <mailto:[email-masked]> ??
>>     2013-01-21 13:08:39:
>>
>>
>>     > From: Prabath Siriwardena <[email-masked]
>>     <mailto:[email-masked]>>
>>     > To: "[email-masked] <mailto:[email-masked]> WG" <[email-masked]
>>     <mailto:[email-masked]>>
>>     token request ?
>>     > Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>
>>     >
>>     > http://blog.facilelogin.com <http://blog.facilelogin.com/>
>>     > http://RampartFAQ.com <http://rampartfaq.com/>
>>     >
>>     > [email-masked] <mailto:[email-masked]>
>>     > [email-masked] <mailto:[email-masked]>
>> http://blog.facilelogin.com <http://blog.facilelogin.com/>
>> http://RampartFAQ.com <http://rampartfaq.com/>
>> [email-masked] <mailto:[email-masked]>

-- 
George Fletcher <http://connect.me/gffletch>

---

From: Eve Maler <[email-masked]>
Date: Wed, 23 Jan 2013 12:23:06 -0800

Nice suggestion! Good point that both the RS and the client, respectively, have ways (illustrated by a combination of dyn-client-reg and resource-set-reg) to review/indicate abilities and preferences in engaging with the AS.

	Eve

On 23 Jan 2013, at 10:05 AM, George Fletcher <[email-masked]> wrote:

> In addition, UMA also defines a was for the RS to instruct the client on what to present to the AS in order to receive a token that will work at the RS. At the moment this flow is UMA specific but could probably be abstracted into a general pattern.
> 
> Also, there are really three parties that have to agree in order for the client to get access to the protected resource.
> Developing generic negotiation amongst these parties may be overkill since in most cases the client know what RS it will be talking to and potentially even the authorizations server(s) as well.  Given that some pre-knowledge is probably in play, a simple solution may be to allow the client to register via the dynamic registration proposal the token types it supports and then the AS can use that data as a filtering mechanism when the client asks for a token.
> 
> Thanks,
> George
>