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 <gffle...@aol.com> 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 <prab...@wso2.com> 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, <zhou.suj...@zte.com.cn> 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.
>>>
>>>
>>> oauth-boun...@ietf.org 写于 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 <prab...@wso2.com>
>>> > To: "oauth@ietf.org WG" <oauth@ietf.org>
>>> > 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 : +94 71 809 6732
>>> >
>>> > http://blog.facilelogin.com
>>> > http://RampartFAQ.com
>>> >
>>> > _______________________________________________
>>> > 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
>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Prabath
>>>
>>> Mobile : +94 71 809 6732
>>>
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> Eve Maler http://www.xmlgrrl.com/blog
>> +1 425 345 6756 http://www.twitter.com/xmlgrrl
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
> <XeC.png>
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
