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

Eve Maler <eve@xmlgrrl.com> Wed, 23 January 2013 20:23 UTC

Return-Path: <eve@xmlgrrl.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A6421F866E for <oauth@ietfa.amsl.com>; Wed, 23 Jan 2013 12:23:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.047
X-Spam-Level:
X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdFJclq9E53T for <oauth@ietfa.amsl.com>; Wed, 23 Jan 2013 12:23:11 -0800 (PST)
Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8394321F8542 for <oauth@ietf.org>; Wed, 23 Jan 2013 12:23:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 549D39AA17C; Wed, 23 Jan 2013 12:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at promanage-inc.com
Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7moGDXlJQg-o; Wed, 23 Jan 2013 12:23:06 -0800 (PST)
Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id D4E529AA15B; Wed, 23 Jan 2013 12:23:06 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_863224A2-1BA7-409F-9460-BA929BF04B70"
From: Eve Maler <eve@xmlgrrl.com>
In-Reply-To: <5100267C.1010400@aol.com>
Date: Wed, 23 Jan 2013 12:23:06 -0800
Message-Id: <AF195E86-F948-4EC3-9D5A-5FBCEDE010A1@xmlgrrl.com>
References: <1358744919.12881.YahooMailNeo@web31811.mail.mud.yahoo.com> <OFCCDF8F10.8CEE85DE-ON48257AFA.001CFDB1-48257AFA.001D2C4E@zte.com.cn> <CAJV9qO-D=9-Dbi8Rp8fdXYSYOMeNhfVbSmk2_u3z=Vy3tiyzLw@mail.gmail.com> <9034B9E7-B35F-4647-AF59-0DD222A3C60C@xmlgrrl.com> <5100267C.1010400@aol.com>
To: George Fletcher <gffletch@aol.com>
X-Mailer: Apple Mail (2.1499)
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jan 2013 20:23:12 -0000

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 <gffletch@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 <prabath@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.sujing@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-bounces@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 <prabath@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