Others will hate the idea as well for other reasons I expect. If we leave introspection aside it might be a way to deal with other specs going forward.
Sent from my iPhone > On Mar 5, 2015, at 2:02 PM, Justin Richer <jric...@mit.edu> wrote: > > 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 <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
