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

Benjamin Kaduk <> Mon, 09 March 2020 03:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 421323A0F20 for <>; Sun, 8 Mar 2020 20:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0nmDsHxpLkOl for <>; Sun, 8 Mar 2020 20:12:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 585BB3A0F1D for <>; Sun, 8 Mar 2020 20:12:32 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 0293COuh017914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 8 Mar 2020 23:12:26 -0400
Date: Sun, 08 Mar 2020 20:12:23 -0700
From: Benjamin Kaduk <>
To: Torsten Lodderstedt <>
Cc: oauth <>, Filip Skokan <>, Justin Richer <>, Takahiko Kawasaki <>, Vladimir Dzhuvinov <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
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, 09 Mar 2020 03:12:34 -0000

Hi Torsten,

Sorry for the delayed response, but since I was explicitly listed in the
"To:" field I expect the response is still of interest.
On Wed, Mar 04, 2020 at 05:19:13PM +0100, Torsten Lodderstedt wrote:
> Hi all, 
> based on the recent feedback, Vladimir and I propose the following changes to draft-ietf-oauth-jwt-introspection-response: 
> - the token data are encapsulated in a container element “_token_data”
> - beyond this, the top-level container only contains meta data pertinent to the JWT representing the signed (encrypted) introspection response
> - we need to add text to the spec to point out that replay detection must be based on the jti in the “_token_data” container not the top level claim

I think this sort of thing will resolve the fundamental issues quite well.
(I want to say I had listed it as a potential option some months ago, but
don't have the time to go look in the archives and check.)

I see there's still some discussion ongoing about specifics, which is fine;
I expect we will still end up in a good place.