Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Torsten Lodderstedt <> Mon, 02 March 2020 14:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF6DA3A0036 for <>; Mon, 2 Mar 2020 06:04:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 DfOu7jlMKucb for <>; Mon, 2 Mar 2020 06:04:55 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABDAD3A002F for <>; Mon, 2 Mar 2020 06:04:54 -0800 (PST)
Received: by with SMTP id y17so12757602wrn.6 for <>; Mon, 02 Mar 2020 06:04:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Ml3WTPXzL7jQdFoEtEhJmd1tJ4/Gt3E1KrbNJGswh20=; b=si2JzyNnD8TXxqaT5LwN4IHFSUi+INpn6WpK8ciwnEhHmfWhx4xNwUZ3Clf5/iEpEG /EoH2fX303U9qnq+yzKjnmhC0PezRYctFRxvv0/tdwGm4vtOLaMUm/9SVm/ASsVYwh0Q Wp/dhqD5gGgw4igjhphu9nZp/Uk6O/UXTTPZ0m9xgx3Dd4/VXsT87NzQvQK9yv8kK7Te MreNiDEDLwFmgjcB/eb/7fWgLg5EJAIefQE6+2zI83TO0Pke+/81dIpVCYcSoVRXiY8u MbImslyHwjCL55GAQ1zyy4IjyKDjl7oU+G+kAGwpicmnMg9Z933kyrn1tO9XGkEeKLg0 QWcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Ml3WTPXzL7jQdFoEtEhJmd1tJ4/Gt3E1KrbNJGswh20=; b=P8nLEQHsAuPo8wxGTjl1RZXJBNwjvsLTaAgvHgJYob2M+FtZfKl91OhlUcLT6EkOH1 d6SDHmCIGlcfZUApkS/NIehAk/Meb9vY0Qb8Q6nJrIzsB5odcnfIIgFWzSKeoM2f66Td sFdkqeRZixh5QdU9M8Vfg9nSibX7EoWfI3eI4sWf3a4P11oEV3ji/3Z5eA1nq95GxOlr mtnc/Fdxwbj0bkbnXjyVezGrHTURTXoJp8hRgH5FzyeS3iswA9O5NkPbaxnOvgiIsgnX rDIxvChqmwRbCZCqPvyO1U7rHJZM/VG+K7SkafZi1sm7qEuJfpmWpF+q4DC+AzvpffWB TXIw==
X-Gm-Message-State: APjAAAV9UYJdhkW1IMJ031eIaYhO14FH8E+Vhv81RZNQo52nJVWLT/04 NS4dNQzPxAWmxqpQXWEnqgLs5iOkXkduZw==
X-Google-Smtp-Source: APXvYqxVDWRzv2+isV0MgpanfMUR6yMldIKm9zF6CjRiU83aw0ehhVtwE1zPL4RLzUFkUeV7SwTGeA==
X-Received: by 2002:a5d:4408:: with SMTP id z8mr22481022wrq.321.1583157892992; Mon, 02 Mar 2020 06:04:52 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id o11sm16621481wrn.6.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2020 06:04:52 -0800 (PST)
From: Torsten Lodderstedt <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_19C984C7-D876-4E87-A22A-07BA80A0AFA8"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Mon, 02 Mar 2020 15:04:51 +0100
In-Reply-To: <>
Cc: oauth <>
To: Filip Skokan <>, Takahiko Kawasaki <>
References: <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection
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: Mon, 02 Mar 2020 14:04:57 -0000

Hi Filip, Hi Taka,

iat: We might add a structure (e.g. "underlying_access_token") to be able to convey “iat" for both the underlying access token as well as the JWT-formatted introspection response to the RS. I’m not really convinced we need to add this additional complexity since, in my experience, applications use “exp” for validity checks. I consequently would argue that overloading “iat” for the AS attesting the instant when it created the JWT formatted introspection response is acceptable. No strong argument, just an explanation, why we didn't change it so far.

jti: This is getting more difficult for the “jti”. If the “jti” of the JWT-formatted introspection response is in the root level, and the “jti" of the underlying access token goes into a container, the RS developer need to dig into this container to implement replay detection with respect to the underlying access tokens. 

I’m concerned RS developers will just use the top level “jti" for replay detection, which does not make any sense as this “jti" is freshly assigned with every introspection response. 

I look forward to getting your advice. 

best regards,

> On 2. Mar 2020, at 08:25, Filip Skokan <> wrote:
> Perhaps we should consider leaving the root level JWT claims as-is per JWT and push the introspection response unmodified as if it was regular json response to a JWT claim called "introspection". Since regular introspection uses the same claim names as JWT this would get around all the conflicts.
> Last time i brought it up the authors didn't want to consider it because of existing implementations.
> S pozdravem,
> Filip Skokan
> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki <> wrote:
> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the same concerns in this mailing list about 6 months ago (on Sep. 4, 2019). RFC 8707 didn't exist then, though.
> Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05
> A JWT puts both (a) information about itself and (b) other data in its payload part. When the "other data" have the same claim names as are used to express information about the JWT itself, conflicts happen.
> Also, it should be noted that Ben pointed out in other thread that the requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which says "jti" is a unique identifier for the access token that MUST be stable for all introspection calls, contradicts the definition of "jti", which should be unique for each JWT.
> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
> draft-ietf-oauth-jwt-introspection-response needs to be modified to solve the conflicts.
> Taka
> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki <> wrote:
> Hello,
> I'm wondering if the following conflicts in "JWT Response for OAuth Token Introspection" (draft 8) have already been pointed out.
> RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an introspection response hold the values of the 'resource' request parameters, whereas "JWT Response for OAuth Token Introspection" says that 'aud' MUST identify the resource server receiving the token introspection response. The definitions conflict.
> RFC 7662 (OAuth 2.0 Token Introspection) requires that 'iat' in an introspection response indicate when the access/refresh token was issued, whereas "JWT Response for OAuth Token Introspection" says that 'iat' indicates when the introspection response in JWT format was issued. The definitions conflict.
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
> _______________________________________________
> OAuth mailing list
> _______________________________________________
> OAuth mailing list