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

[Justin Richer <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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 <mailto:[e-mail]>
>>> Sent: ‎3/‎4/‎2015 6:43 PM
>>> To: Mike Jones <mailto:[e-mail]>; Hannes 
>>> Tschofenig <mailto:[e-mail]>
>>> Cc: <[e-mail]> <mailto:[e-mail]>
>>> 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] 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:[e-mail]] *On Behalf Of *Justin 
>>>> Richer
>>>> *Sent:* Wednesday, March 04, 2015 1:46 PM
>>>> *To:* Hannes Tschofenig
>>>> *Cc:* <[e-mail]>
>>>> *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
>>>>     <[e-mail] <mailto:[e-mail]>>
>>>>     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
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth