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 <jric...@mit.edu> 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: <oauth@ietf.org> >> 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:oauth-boun...@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.tschofe...@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 >>> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > 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
