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

[Eve Maler <[e-mail]>]

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 <[e-mail]> 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.
>    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]> 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]> 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] 写于 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]>
>>> > To: "[e-mail] WG" <[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] 
>>> > 
>>> > http://blog.facilelogin.com
>>> > http://RampartFAQ.com 
>>> > 
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>> > 
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> 
>>> -- 
>>> Thanks & Regards,
>>> Prabath
>>> 
>>> Mobile : [phone] 
>>> 
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>> _______________________________________________
>>> OAuth mailing list
>>> [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
> 
> -- 
> <XeC.png>


Eve Maler                                  http://www.xmlgrrl.com/blog
[phone]                         http://www.twitter.com/xmlgrrl