Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"
Justin Richer <jricher@mit.edu> Thu, 05 March 2015 13:02 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 3A4511A1A02 for <oauth@ietfa.amsl.com>; Thu, 5 Mar 2015 05:02:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q3szx-Wjyfa for <oauth@ietfa.amsl.com>; Thu, 5 Mar 2015 05:02:39 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99CC1A0387 for <oauth@ietf.org>; Thu, 5 Mar 2015 05:02:38 -0800 (PST)
X-AuditID: 12074423-f79066d0000058b8-04-54f853ecc4fc
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 93.8F.22712.CE358F45; Thu, 5 Mar 2015 08:02:36 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t25D2ZvE022322; Thu, 5 Mar 2015 08:02:35 -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 t25D2XKa031392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Mar 2015 08:02:34 -0500
Message-ID: <54F853E2.9030405@mit.edu>
Date: Thu, 05 Mar 2015 08:02:26 -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: John Bradley <ve7jtb@ve7jtb.com>
References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F84B3D.1090401@mit.edu> <9B6A57FD-4D82-4475-B2BE-6EC87D235754@ve7jtb.com>
In-Reply-To: <9B6A57FD-4D82-4475-B2BE-6EC87D235754@ve7jtb.com>
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: <http://mailarchive.ietf.org/arch/msg/oauth/gCUwOCaOuWPFJbvFQ6LJxSpnBqo>
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 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 <jricher@mit.edu > <mailto:jricher@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 <mailto:jricher@mit.edu> >>> Sent: 3/4/2015 6:43 PM >>> To: Mike Jones <mailto:Michael.Jones@microsoft.com>; Hannes >>> Tschofenig <mailto:hannes.tschofenig@gmx.net> >>> Cc: <oauth@ietf.org> <mailto: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-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 >>>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Alignment of JWT Claims and Token Intr… Hannes Tschofenig
- Re: [OAUTH-WG] Alignment of JWT Claims and Token … Justin Richer
- Re: [OAUTH-WG] Alignment of JWT Claims and Token … Anthony Nadalin
- Re: [OAUTH-WG] Alignment of JWT Claims and Token … Mike Jones
- Re: [OAUTH-WG] Alignment of JWT Claims and Token … Justin Richer
- Re: [OAUTH-WG] Alignment of JWT Claims and Token … Mike Jones
- Re: [OAUTH-WG] Alignment of JWT Claims and Token … Hannes Tschofenig
- Re: [OAUTH-WG] Alignment of JWT Claims and Token … Justin Richer
- Re: [OAUTH-WG] Alignment of JWT Claims and Token … Justin Richer
- Re: [OAUTH-WG] Alignment of JWT Claims and Token … Hannes Tschofenig
- Re: [OAUTH-WG] Alignment of JWT Claims and Token … John Bradley
- Re: [OAUTH-WG] Alignment of JWT Claims and Token … Justin Richer
- Re: [OAUTH-WG] Alignment of JWT Claims and Token … Justin Richer
- Re: [OAUTH-WG] Alignment of JWT Claims and Token … John Bradley
- [OAUTH-WG] Returning tokens directly to a human u… Sergey Beryozkin
- [OAUTH-WG] Using refresh tokens to authenticate t… Sergey Beryozkin
- Re: [OAUTH-WG] Returning tokens directly to a hum… Dick Hardt
- Re: [OAUTH-WG] Returning tokens directly to a hum… Justin Richer
- Re: [OAUTH-WG] Returning tokens directly to a hum… Sergey Beryozkin
- Re: [OAUTH-WG] Returning tokens directly to a hum… Sergey Beryozkin
- Re: [OAUTH-WG] Returning tokens directly to a hum… Justin Richer
- Re: [OAUTH-WG] Returning tokens directly to a hum… Sergey Beryozkin