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

Phil Hunt <phil.hunt@oracle.com> Thu, 28 February 2013 16:29 UTC

Return-Path: <phil.hunt@oracle.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 DADCD21F8C0C for <oauth@ietfa.amsl.com>; Thu, 28 Feb 2013 08:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.517
X-Spam-Level:
X-Spam-Status: No, score=-5.517 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
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 fanGIlsBD5cd for <oauth@ietfa.amsl.com>; Thu, 28 Feb 2013 08:29:44 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 900EA21F8C09 for <oauth@ietf.org>; Thu, 28 Feb 2013 08:29:43 -0800 (PST)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SGTbYU006116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Feb 2013 16:29:38 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SGTaqY012856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 16:29:36 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SGTaQn004001; Thu, 28 Feb 2013 10:29:36 -0600
Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 08:29:36 -0800
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> <C75E4871-E907-4EF7-BAF0-9D1A172D581B@ve7jtb.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <C75E4871-E907-4EF7-BAF0-9D1A172D581B@ve7jtb.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <117150EA-E7D6-47EF-A8DB-BF07962B6E11@oracle.com>
X-Mailer: iPhone Mail (10B146)
From: Phil Hunt <phil.hunt@oracle.com>
Date: Thu, 28 Feb 2013 08:29:34 -0800
To: John Bradley <ve7jtb@ve7jtb.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
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 16:29:46 -0000

Personally I am starting to feel strongly that access tokens should be highly contextual and therefore tightly bound to specific resources. 

It seems to me trust will get incredibly complex if we start federating access tokens. My belief is that uma needs to still chain to local authorization servers and should never expect a federated token to be accepted directly. 

I hope to blog on this in more detail. But i wanted to express concerns about trust with federated authorization vs federated authn. 

Scope is just the tip of the iceberg. 

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