Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

Justin Richer <jricher@mit.edu> Thu, 05 March 2015 02:43 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E4E1AD1A3 for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2015 18:43:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7j_BYK5C7uq for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2015 18:43:14 -0800 (PST)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70AED1AD190 for <oauth@ietf.org>; Wed, 4 Mar 2015 18:43:14 -0800 (PST)
X-AuditID: 1209190e-f79bb6d0000030e8-9e-54f7c2c0f882
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 51.3C.12520.0C2C7F45; Wed, 4 Mar 2015 21:43:12 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t252hBpv011064; Wed, 4 Mar 2015 21:43:12 -0500
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t252hAu7022006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2015 21:43:11 -0500
Message-ID: <54F7C2B7.7090304@mit.edu>
Date: Wed, 04 Mar 2015 21:43:03 -0500
From: Justin Richer <jricher@mit.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Mike Jones <Michael.Jones@microsoft.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>
References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------030005090508000404060607"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixG6nrnvg0PcQg74GY4ulO++xWuyd9onF 4uTbV2wOzB6LN+1n81iy5CeTR+uOv+wBzFFcNimpOZllqUX6dglcGcdnnmQu2DuJqWL1/H9s DYznDjN2MXJySAiYSBz99IMJwhaTuHBvPVsXIxeHkMBiJolze16xQDgbGCU2PWxkh3BuMUn8 vTaZDaSFV0BN4mH3S2YQm0VAVeLCh04wmw3Inr6mBWysqECURM+fbqh6QYmTM5+wgNgiAikS F5oXgdUwC6hL9P5eyQpiCwsESKzYdpIVYtkqRoknP16xgyQ4BRIlbt3fwgbRECYxc30L0wRG gVlI5s5CkoKwzSTmbX7IDGHLSzRvnQ1kcwDZahLLWpWQhRcwsq1ilE3JrdLNTczMKU5N1i1O TszLSy3SNdbLzSzRS00p3cQIigVOSb4djF8PKh1iFOBgVOLh/bD5e4gQa2JZcWXuIUZJDiYl Ud6NjUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrwPpwPleFMSK6tSi/JhUtIcLErivJt+8IUI CaQnlqRmp6YWpBbBZGU4OJQkeFsOAjUKFqWmp1akZeaUIKSZODhBhvMADW8FqeEtLkjMLc5M h8ifYlSUEud9AJIQAElklObB9cJS1StGcaBXhHlFgYlLiAeY5uC6XwENZgIafEvxC8jgkkSE lFQDY5TIv6hn+zQUXX5HHTF6ldIlLO50ZO/irdOWKkjlLDdj9n4XtFJ+Vkag5NKdW9KupE+R 6T+277rpM9/cGxK/jD6mpkyyuKJiUe6XNXNCaEr43ZD1sxW2nN9hc9bxV2ZIzxTJ3tl7GQvu eRcukO6K3Jfbxf72v0r3tJ4f1kWvdNp0K3Jq1P7/VGIpzkg01GIuKk4EAJ5GB58wAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/zAYkxjUMWs4IuIL2S0jZXrGFt7k>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 05 Mar 2015 02:43:19 -0000

I'm actually fine with keeping the introspection-specific elements out 
of the registry (see my note on "active" and how it doesn't fit in JWT 
below), but I do not want to give up the short names. The short names 
are already in production, especially "active", which is well understood 
and used in practice today, and has been for years[1]. Changing this 
would fundamentally break all existing implementations for no good 
reason. I'm slightly more OK with changing "user_id" to "username", 
since that's not as widely deployed to my knowledge (other implementers, 
please pipe up if I'm mistaken), and I'm well familiar with 
"preffered_username" in OIDC because I'm the one that put it in there 
[2]. :) While I prefer to leave it be at this stage, I think this is a 
less destructive change than "active", "scope", or "client_id" would be.

For background to my stance regarding the registry: several revisions 
(and years) ago, the introspection draft re-defined several fields that 
overlapped with JWT and we were asked to correlate the two. Originally, 
we simply had a pointer to re-use the JWT claims as defined, and stacked 
our own claims on top. Later, we were asked to outright merge them, 
which is what we have right now. If the WG wants to back off that last 
change to the middle state -- where we re-use the JWT registry but don't 
write to it -- I'm very happy with that result and can work that (back) 
into the next draft.

Though it does point out something strange about the standards process 
that we're running into here: JWT needed a place to register bits of 
metadata about a token, so it created one. This became the "JWT 
registry", and now it's got hangings of being "JWT-specific". When 
introspection came along with a need to talk about much the same kind of 
information, it makes sense to re-use the existing items but also that 
there would be things that are introspection-specific.

  -- Justin

[1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03
[2] https://bitbucket.org/openid/connect/issue/584/messages-username-claim

On 3/4/2015 6:28 PM, Mike Jones wrote:
>
> I have severe concerns with this approach.  It’s not appropriate to 
> register arbitrary JSON object member names as JWT claim names – 
> especially when the JSON object member names are not even being used 
> as JWT claim names. *Please do not do this*, as it would needlessly 
> pollute the JWT claim name namespace with registered names that are 
> application specific.
>
> Secondarily, I have concerns about these names and suggestions for how 
> to address them.
>
> “active” – This claim is not presently adequately defined.  And its 
> definition will of necessity be specific to the introspection 
> application.  Therefore, it should not be registered as a general JWT 
> claim name.  A name I would be comfortable with for this concept would 
> be urn:ietf:params:oauth:introspection:active, since it makes it clear 
> what application the name is used with.
>
> “user_id” – The concept you’re describing is almost universally called 
> “username”.  User ID is typically the numeric account identifier 
> (carried in the “sub” claim in a JWT), and so is not the right name 
> for this.  Compare it to the preferred_username claim in OpenID 
> Connect.  Please change this either to “username” or 
> urn:ietf:params:oauth:introspection:username.
>
> “token_type” – While this is well-defined, the usage is fairly 
> specific to this application.  Again, adding the 
> urn:ietf:params:oauth:introspection: name prefix would address this issue.
>
> If you give up registering these names in the JWT Claims registry, I’m 
> OK with you using short names.  But if you want them to live alongside 
> other JWT claim names, please include the 
> urn:ietf:params:oauth:introspection: in lieu of registration.
>
> Thank you,
>
> -- Mike
>
> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Richer
> *Sent:* Wednesday, March 04, 2015 1:46 PM
> *To:* Hannes Tschofenig
> *Cc:* <oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] Alignment of JWT Claims and Token 
> Introspection "Claims"
>
> Hi Hannes, thanks for the feedback. Responses inline.
>
>     On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig
>     <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>
>     Hi Justin, Hi all,
>
>     in OAuth we provide two ways for a resource server to make an
>     authorization decision.
>
>     1) The resource server receives a self-contained token that
>     contains all
>     the necessary information to make a local authorization decision. With
>     the JWT we have created such a standardized information and data
>     model.
>
>     2) With an access request from a client the resource server asks the
>     authorization server for "help". The authorization server provides
>     information that help make the authorization decision. This is the
>     token
>     introspection approach.
>
>     I believe the two approaches need to be aligned with regard to the
>     information and the data model. Since both documents already use
>     JSON as
>     a way to encode information (=data model) and almost have an identical
>     information model (the data that is being passed around).
>
>     What needs to be done?
>
>     * Use the term 'claims' in both documents.
>     * Use the same registry (i.e., the registry established with the JWT).
>     * Register the newly defined claims from the token introspection
>     document in the claims registry.
>
> We’ve already done this in the latest draft. Or at least, that’s the 
> intent of the current text — the registry is referenced and the new 
> claims are registered. Can you specifically point to places where this 
> needs to be improved upon?
>
>
>
> Then, I have a few comments on the new claims that are proposed:
>
> Here is the definition of the 'active' claim:
>
>   active
>      REQUIRED.  Boolean indicator of whether or not the presented token
>      is currently active.  The authorization server determines whether
>      and when a given token is in an active state.
>
> This claim is not well-defined. You need to explain what "active" means.
> It could, for example, mean that the token is not yet expired. Then,
> there is of course the question why you are not returning the 'exp'
> claim together with the 'nbf' claim.
>
> The definition of “active” is really up to the authorization server, 
> and I’ve yet to hear from an actual implementor who’s confused by this 
> definition. When you’re the one issuing the tokens, you know what an 
> “active” token means to you. Still, perhaps we can be even more 
> explicit, such as:
>
>     active
>
>       REQUIRED. Boolean indicator of whether or not the presented
>     token is currently active. The specifics of a token’s active state
>     will vary depending on the implementation of the authorization
>     server, but generally this will indicate that a given token has
>     been issued by this authorization server, has not been revoked by
>     the resource owner, and is within its given time window of
>     validity (e.g. not expired).
>
> Also, this is one of the places where the overlap between JWT and 
> introspection claims don’t make sense. It doesn’t make any sense for a 
> JWT to carry an “active” claim at all. Why would you have a JWT claim 
> to be anything but active? We should register it with the JWT registry 
> to avoid name collisions, but there’s nothing in the JWT registry that 
> says “don’t use this inside of a JWT”. Do you have any advice on how 
> to address this?
>
>
>
>
> client_id: What is the resource server going to do with the client_id?
> What authorization decision could it make?
>
> Whatever it wants to. If an RS can figure out something from the 
> client_id, why not let it? The client_id is a piece of information 
> about the context of the issuance of the token, and a common enough 
> OAuth value for decision making.
>
>
>
> I have a couple of reactions when I read the 'user_id' claim:
>  - I believe the inclusion of a user id field in the response could
> lead to further confusion regarding OAuth access token usage for
> authentication.
>
> This isn’t any different from having a userinfo-endpoint equivalent 
> (like social graph or twitter API) and it’s got the same trouble.
>
>
>
>
>  - Since you define it as a human readable identifier I am wondering
> whether you want to say something about the usage. Here it seems that it
> might be used for displaying something on a webpage rather than making
> an authorization decision but I might well be wrong.
>
> We added in “user_id” to our implementation due to developer demand — 
> they wanted a username associated with the return value, but to leave 
> the “sub” value the same as that defined by OpenID Connect. Note that 
> this is in an environment where the username is a known quantity, and 
> they’re not trying to do cross-domain authentication. They just want 
> to know whose token this was so they can figure out whose data to 
> return. It’s not used for display, but I tried to make the definition 
> in contrast to the machine-facing “sub” value.
>
>
>
>
>  - I am missing a discussion about the privacy implications of it.
> While there is a privacy consideration section I am wondering what
> controls the release of this sensitive information from the
> authorization server to the resource server. While in some cases the two
> parties might belong to the same organization but in other cases that
> may not necessarily be true.
>
> You’re correct, this is currently missing and I’ll add that in.
>
>
>
>
>  - In terms of the information exchanged about the user I am curious
> about the usefulness of including other information as well, such as the
> info that is included in an id token (see
> http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this
> has nothing to do with the ID token concept and the information carried
> within it then I would add that remark.
>
> You could introspect an ID token if you wanted to, but it’s usually 
> easier to just parse it yourself because it’s self-contained. The ID 
> Token also extends JWT, so there’s nothing stopping you from returning 
> those claims as well. However, note that the audience of the ID token 
> is the OAuth *client* whereas the targeted user of the introspection 
> endpoint is the *protected resource*. The PR isn’t going to see the ID 
> Token most of the time, and the client’s not going to need to (or be 
> able to) introspect its tokens most of the time, so in practice 
> there’s not really any overlap.
>
>  — Justin
>
>
>
>
> Ciao
> Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>