Re: [OAUTH-WG] JWT - scope claim missing

Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 28 February 2013 17:56 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 04A8C21F8835 for <oauth@ietfa.amsl.com>; Thu, 28 Feb 2013 09:56:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.533
X-Spam-Level:
X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 fhVjXKSkEqD2 for <oauth@ietfa.amsl.com>; Thu, 28 Feb 2013 09:56:50 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 06E1221F8801 for <oauth@ietf.org>; Thu, 28 Feb 2013 09:56:50 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MW5VH-1ULvTM06kz-00XLiq for <oauth@ietf.org>; Thu, 28 Feb 2013 18:56:49 +0100
Received: (qmail invoked by alias); 28 Feb 2013 17:56:48 -0000
Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp019) with SMTP; 28 Feb 2013 18:56:48 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/qA+AIv83qY78549ETKXbQ4F8uymmYECbhMvKtk5 L82/hJjvJF9nDv
Message-ID: <512F9A5C.1070900@gmx.net>
Date: Thu, 28 Feb 2013 19:56:44 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Phil Hunt <phil.hunt@oracle.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> <C75E4871-E907-4EF7-BAF0-9D1A172D581B@ve7jtb.com> <CA6A6425-D0CE-469F-B51E-9F296DA8041C@oracle.com> <EAD4F55D-7A02-4209-BB15-21BA5AB512AC@ve7jtb.com> <1BDBAFF3-6B2D-45EE-8A7E-B0B2572C8A01@oracle.com>
In-Reply-To: <1BDBAFF3-6B2D-45EE-8A7E-B0B2572C8A01@oracle.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] JWT - scope claim missing
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: Thu, 28 Feb 2013 17:56:51 -0000

I guess we first have to agree whether there is a security benefit of 
communicating the scope from the AS to the RS (in a way that it cannot 
be modified by the client or any other party).

The scope indicates permissions (for example, whether the resource owner 
allowed read access to a certain resource or write access).

Do you agree that there is a security benefit (or to put it the other 
way around: do you see the security vulnerability if this information is 
not communicated to the RS and checked against what the resource owner 
accepted?

Then, a secondary question is what the right mechanism is.

Ciao
Hannes


On 02/28/2013 07:29 PM, Phil Hunt wrote:
> What people are doing now is often issuing saml like assertions. Thats not necessarily indicating intent. It just indicates transition.
>
> Phil
>
> Sent from my phone.
>
> On 2013-02-28, at 9:07, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
>> I am not advocating anything, only sting what people are doing now.
>>
>> How authorization is communicated between the AS and RS via a token that is opaque to the client is out of scope fro OAuth core, it might be magic pixy dust.
>>
>> This has lead to a number of ways people are doing it.
>>
>> JWT along with  JOSE provide a container to get some claims from the AS to the RS though the JWT is not specific to this and is used in the assertions profile and other specs for many things other than access tokens.
>>
>> Yes a profile of JWT for an access token as an access token is needed, Yes further profiling is required for a JWT access token using MAC.
>>
>> The format of the authorization claims is not tightly bound to MAC and might be used with other bearer JWT tokens.
>>
>> I don't know that there will be only one way to communicate those claims because different sorts of implementations need different information for the RS to act on.
>> Recommendations are fine but defining a field called scope and passing on exactly the scopes the client was granted is not going to work for everyone for lots of good reasons.
>>
>> John B.
>> On 2013-02-28, at 8:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
>>
>>> Are you advocating TWO systems? That seems like a bad choice.
>>>
>>> I would rather fix scope than go to a two system approach.
>>>
>>> Phil
>>>
>>> Sent from my phone.
>>>
>>> On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>>
>>>> While scope is one method that a AS could communicate authorization to a RS, it is not the only or perhaps even the most likely one.
>>>> Using scope requires a relatively tight binding between the RS and AS,  UMA uses a different mechanism that describes finer grained operations.
>>>> The AS may include roles, user, or other more abstract claims that the the client may (god help them) pass on to EXCML for processing.
>>>>
>>>> While having a scopes claim is possible, like any other claim it is not part of the JWT core security processing claims, and needs to be defined by extension.
>>>>
>>>> John B.
>>>> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>>>
>>>>> Hi Mike,
>>>>>
>>>>> when I worked on the MAC specification I noticed that the JWT does not have a claim for the scope. I believe that this would be needed to allow the resource server to verify whether the scope the authorization server authorized is indeed what the client is asking for.
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>