Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt

Travis Spencer <> Thu, 26 September 2019 09:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D030120859 for <>; Thu, 26 Sep 2019 02:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hQ7PNVhuHYuz for <>; Thu, 26 Sep 2019 02:26:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A9BF12012C for <>; Thu, 26 Sep 2019 02:26:44 -0700 (PDT)
Received: by with SMTP id 206so76262ybc.8 for <>; Thu, 26 Sep 2019 02:26:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4muyA02jbXlFL8XCNjRLfDUB6TrQcHWfVyTfpCouAeQ=; b=DMpPnM3mADRCreQWy153E0RG6wJBkg7s9sMdni+DvZ1h3jAlAwATBUw95v/Tvm/fB+ ENie4WM3oNm7+rrLrxQ0bTpUoS4lf0vmMQFkyzq82ytYxdTO5hxuQQ82+wb1DUt6Rp+1 bfjKzVnsKsYDLJQc7Np4+/ibcrTWTqE4l8nsfW0kyfWtfhvQgSIDESIYGVYybxUdj7/a Q6s2objI7uR8ng1SUo8zjcJgMoucNvETHjG4aKjqJVj5/UdvcpTwewE5qmI6A+cX1VRS FQSQ4b7PWJdDWjvPf/x7ZHIXpuOHz9g2OEFlnpIUkpW/lbxnM/ZiSfjBStoH4vVAZKHn 3iEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4muyA02jbXlFL8XCNjRLfDUB6TrQcHWfVyTfpCouAeQ=; b=cwMaznNd3vBw9BsC9ccosDHVhPzndfVTJ5qSpXukNphb/7by77hizkYuO7IxTR2+HK iJ0RVO1QctLbdAM6z9wDSm0tIU08X6Zlqv+r28MeloRFUKIKnq+gx2QA8v7p9UU4pcav rKlfRqmOjNmJ79IZPg0N5SMKpdJTeMPNk8eP1dxXFhxbEyBhFg6WZgXf9mfQVnQDK81w w5ZgK0nRBYxLssOFZrzB9W0AdCixwEFY0GPVN/qnnsHbjYqDwGWfX3aIZKODG6WxhNr3 xKTr/ZrYJdt9iKNJR19G0Bz0rWLj5bc/ZAXilajxdxZBxie4Qh9N0d9aANtqtGmUo1ES xhLQ==
X-Gm-Message-State: APjAAAV0l/sV+cjZRzaCrctTGkPZNBSHolGtVCTiEN2KDr9ha23bjIFG mxyQcHOYP90C5TI5mZ5BErcw04x/40r5kLSSz3BknJ0j05gZbw==
X-Google-Smtp-Source: APXvYqzAd0+/AXIQSiLrb3cy1u409whIoMKa1nTILY3ZSAsXiA3m6kNB/eXB8ee4kkwUiDnBQSAB3vI8GihAHj/vbT0=
X-Received: by 2002:a25:6b44:: with SMTP id o4mr1172979ybm.369.1569490002940; Thu, 26 Sep 2019 02:26:42 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Travis Spencer <>
Date: Thu, 26 Sep 2019 11:26:31 +0200
Message-ID: <>
To: oauth <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Sep 2019 09:26:46 -0000

Some feedback on this draft compared to the last one that I read:

* The acronym RS and the term "resource server" are used
inconsistently. It would read better IMO if the acronym was always
used after being defined or if resource server was always spelled out.
Same for AS, but less so. Maybe this is just me, so take it as you

* In section 3, is it saying that JWE is MTI? From the end of section
5, it seems not. If so, this statement should be clarified IMO:

> To support encrypted token introspection response JWTs, the authorization server MUST also be provided with the respective resource server encryption keys and algorithms.

Maybe just change it to "If the AS supports encrypted token
introspection response JWTs..."

* Instead of issuing an expired JWT (or in addition) I think it should
be valid for the AS to reply with a 201, no content. For this reason,
I think that section 5 should be updated thusly:

> If the access token is invalid, expired, has been revoked, or is not intended to be consumed by the calling resource server (audience), the authorization server MUST set the value of the response claim
"active" to "false" if it chooses to issue a JWT. Otherwise, this
claim is set to "true". If it does not issue a JWT, the AS MUST reply
with an HTTP 204, no content, status code. If it does include a JWT
with an "active" claim of "false", the AS MAY reply with an HTTP 204,
no content, status code.

The rational is that the AS may not want to exert effort to make a
signed/encrypted JWT that is expired. Not having the token is usually
as good or better than having an expired one.

* This statement makes the audience sound too narrow IMO:

> The value of the "aud" claims MUST identify the resource server receiving the token introspection response.

Because the AS's policy may stipulate that the audience could be
others in addition to the RS some wording should be added like "the
'aud' claim MUST identify the resource server receiving the token
introspection response and MAY contain other values based on its

* The "M" in email in section 5 should not be capitalized IINM.

* In section 5, this is very broad.

> The AS determines based on the RS-specific policy what claims about the resource owner to return in the token introspection response. The AS MUST ensure that the release of any privacy-sensitive data is legally based.

So, an AS must follow the law? Is that all that it's saying? Section 9
seems to restate this point. Is conformance to the law really up to
this doc to stipulate? If the AS breaks the law, it don't conform to
the protocol. This seems very meta.

* 1st in section 9 should be spelled out as "first" and IINM it should
be "first-party" since it's being used as an adjective.

* Last but certainly not least is the restriction that the current
version places on disallowing of the introspection JWT response as an
access token. This is done in numerous places (the note in section 5,
8.1, etc.). I understand that there are some objection to this usage,
but we have had this protocol deployed for years, and it's running in
dozens of customer's facilities. This will break real applications of
this specification without a clear alternative. As we discussed in
London last year at the IETF meeting, token exchange isn't a viable
alternative (even still in its current draft form to the best of my
knowledge). Without a workable alternative to move to, I emphatically
but humbly request that this specification remove this restriction.

On Fri, Sep 20, 2019 at 2:28 PM <> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>         Title           : JWT Response for OAuth Token Introspection
>         Authors         : Torsten Lodderstedt
>                           Vladimir Dzhuvinov
>         Filename        : draft-ietf-oauth-jwt-introspection-response-08.txt
>         Pages           : 18
>         Date            : 2019-09-20
> Abstract:
>    This specification proposes an additional JSON Web Token (JWT)
>    secured response for OAuth 2.0 Token Introspection.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> OAuth mailing list