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

Justin Richer <> Thu, 05 March 2015 13:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3A4511A1A02 for <>; Thu, 5 Mar 2015 05:02:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Q3szx-Wjyfa for <>; Thu, 5 Mar 2015 05:02:39 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D99CC1A0387 for <>; Thu, 5 Mar 2015 05:02:38 -0800 (PST)
X-AuditID: 12074423-f79066d0000058b8-04-54f853ecc4fc
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 93.8F.22712.CE358F45; Thu, 5 Mar 2015 08:02:36 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t25D2ZvE022322; Thu, 5 Mar 2015 08:02:35 -0500
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t25D2XKa031392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Mar 2015 08:02:34 -0500
Message-ID: <>
Date: Thu, 05 Mar 2015 08:02:26 -0500
From: Justin Richer <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: John Bradley <>
References: <> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------030502010202000208050302"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixG6novsm+EeIwZ9z0hZLd95jtdg77ROL xcm3r9gsVt/9y+bA4rF40342jyVLfjJ5tO74y+5x+/ZGlgCWKC6blNSczLLUIn27BK6M/we2 shTc+MhU8brVq4Gx8wVjFyMnh4SAiUTj+b1MELaYxIV769m6GLk4hAQWM0l03O2FcjYwSsza cAHKucUksW7nP3aQFl4BNYkFW46DjWIRUJXY8G4xM4jNBmRPX9MCNlZUIEqi5083G0S9oMTJ mU9YQGwRARWJffseMYIMZRaYxCixeM1mVpCEsECAxIptJ1khtj1nkrj24zrYVE4BO4n3l04A TWUH6giTmF49gVFgFpKxs+ASIFFmATOJeZsfMkPY8hLNW2cD2RxAtprEslYlZOEFjGyrGGVT cqt0cxMzc4pTk3WLkxPz8lKLdM30cjNL9FJTSjcxguPCRXkH45+DSocYBTgYlXh4Z2z8HiLE mlhWXJl7iFGSg0lJlDfY+EeIEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHefC2gHG9KYmVValE+ TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBG9JEFCjYFFqempFWmZOCUKaiYMTZDgP 0HBFkBre4oLE3OLMdIj8KUZFKXHeHJCEAEgiozQPrheWtl4xigO9IsybBVLFA0x5cN2vgAYz AQ3WEgMbXJKIkJJqYHR579f2T+h/rNGOFVIZ7Guqfog9KD1kGLWsuuOD9G2rqk9vLO7HL0nI 9fDKtxZznn3GVOfG5SXFMQWds5qfvFPpOch+VvuBYkdxodrfLyJN3zcek65JuWdVNUvqbHz7 9w/PHaaYyD6N99x+58nmozef/Z67QE9zf10Tj0fPy+NNJ4R4065t267EUpyRaKjFXFScCADC N5O9NgMAAA==
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Mar 2015 13:02:44 -0000

And you're right that I *really* don't like this because it breaks 
existing implementations somewhat arbitrarily. Mike had suggested 
something similar.

  -- Justin

On 3/5/2015 7:48 AM, John Bradley wrote:
> A middle ground,  that perhaps no one will like is registering 
> application specific claims in the JWT registry,  but pretending them 
> with a app namespace.
> Eg
> Int:active
> That prevents people from stepping on each other with short names, 
>  and gives a central place to look them up,  without requiring all all 
> alls to understand all claims.
> John B.
> Sent from my iPhone
> On Mar 5, 2015, at 1:25 PM, Justin Richer < 
> <>> wrote:
>> I'm OK with a separate registry, my only question is whether or not 
>> there's a way to correlate and coordinate the values of the two 
>> registries. The concern with importing the JWT claims directly into 
>> introspection's response was that we'd potentially be stepping on an 
>> existing namespace. In practice, I don't think that's a concern, but 
>> I can see the argument. If we establish an introspection response 
>> registry, how do we continue to deconflict with the JWT registry?
>>  -- Justin
>> On 3/5/2015 2:36 AM, Mike Jones wrote:
>>> It sounds to me like you're making a good argument for this spec to 
>>> have its own registry. Registries are easy to establish and use.
>>> ------------------------------------------------------------------------
>>> From: Justin Richer <>
>>> Sent: ‎3/‎4/‎2015 6:43 PM
>>> To: Mike Jones <>; Hannes 
>>> Tschofenig <>
>>> Cc: <> <>
>>> Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token 
>>> Introspection "Claims"
>>> 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]
>>> [2] 
>>> 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 [] *On Behalf Of *Justin 
>>>> Richer
>>>> *Sent:* Wednesday, March 04, 2015 1:46 PM
>>>> *To:* Hannes Tschofenig
>>>> *Cc:* <>
>>>> *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
>>>>     < <>>
>>>>     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
>>>> 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 mailing list
>> <>