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

[George Fletcher <[e-mail]>]

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:
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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
>>
>>
>> On Mon, Jan 21, 2013 at 10:48 AM, <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>
>>     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.
>>
>>
>>     [e-mail] <mailto:[e-mail]> ??
>>     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.
>>
>>     >
>>     > From: Prabath Siriwardena <[e-mail]
>>     <mailto:[e-mail]>>
>>     > To: "[e-mail] <mailto:[e-mail]> WG" <[e-mail]
>>     <mailto:[e-mail]>>
>>     > 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 ?
>>     >
>>     > Is this behavior intentional ? or am I missing something...
>>     >
>>     > Thanks & Regards,
>>     > Prabath
>>     >
>>     > Mobile : [phone] <tel:%2B94%2071%20809%206732>
>>     >
>>     > http://blog.facilelogin.com <http://blog.facilelogin.com/>
>>     > http://RampartFAQ.com <http://rampartfaq.com/>
>>     >
>>     > _______________________________________________
>>     > OAuth mailing list
>>     > [e-mail] <mailto:[e-mail]>
>>     > https://www.ietf.org/mailman/listinfo/oauth
>>     >
>>     > _______________________________________________
>>     > OAuth mailing list
>>     > [e-mail] <mailto:[e-mail]>
>>     > https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> -- 
>> Thanks & Regards,
>> Prabath
>>
>> Mobile : [phone]
>>
>> http://blog.facilelogin.com <http://blog.facilelogin.com/>
>> http://RampartFAQ.com <http://rampartfaq.com/>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> Eve Maler http://www.xmlgrrl.com/blog
> [phone] http://www.twitter.com/xmlgrrl
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth

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