Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens

Torsten Lodderstedt <> Sun, 07 February 2021 12:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C8B53A0BA0 for <>; Sun, 7 Feb 2021 04:14:11 -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 chV0q6J4UBhk for <>; Sun, 7 Feb 2021 04:14:09 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EACFA3A0B16 for <>; Sun, 7 Feb 2021 04:14:08 -0800 (PST)
Received: by with SMTP id m13so13661571wro.12 for <>; Sun, 07 Feb 2021 04:14:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qlYWycpIDICyQ+t9FQK9PuVBND9gjdZsQDu+4ItxEuo=; b=q1hH/P7XID/ovLZAGfzLyEQA7DyC0w2Xf+ANE4Iqdzj3n2fjyApEtKmXKTJ9RZW6sD 1bhYkXLct2Cec/jcombFP/+48ob7skT8nH6Bod4X9yiUTvhpw0S2qR9keP/zYwqNh3Lc Wb0gezFQ0n05EfekErDPo1MJ1sIsRww81xaUjurImG3jqUP6m9Ja8j4TnDmd7F1nx2A+ KBxmH7iaGSftQ7GlJy0y+pSvgEX7kfTgidQ4NjvFGsvSoIy2YOFy0d+VmQW9pDnhrTA1 UnDJ18ryKVnqjVkt4eF6wgcR1Isr/9Monj0CcomkYlbzb3hryCTBE2OacJ346HA99+uJ xXRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qlYWycpIDICyQ+t9FQK9PuVBND9gjdZsQDu+4ItxEuo=; b=CI5pBEYqzC9mwM494NYVPHkFWFztWJu1Lt0o6OMU04iTjKb1eOXR3ljWx4i9bGf1rm +AAP72dsiP6038zYpJlZcE4Hy/fcUQrfTx0NjV6Up9DqNsPqmH5uycbHEdvLgJUpvxEw LEsn4yX0aj+u+2BPQOeWsMdBHwVV1rt6MiG9LJMTxakY0nAOs7Pbc3qLhCOIsYJmVawK nMjFy/br3ub1thTkyYeAvVgffJ6xG7iHJ8Ml1UsgT5PZiADcQH85gFGypVesOMz6FAHx fMCrE2kXIyC4PddJ8p0p9YKiRV/s3u18lqPO6bN81SMOwenMAR0KLA1yS0CFaw0BThwL tPLQ==
X-Gm-Message-State: AOAM5321NIYsU244koyLKXNDAH7F1B0chUHZ7jaKbVJI3lp0oMEWyAjr CjfgG6+KglFM1zDiG2AcQp+G7w==
X-Google-Smtp-Source: ABdhPJwoKwFBrZpLbuZrwRDafiystcxZJ7DNg9gJJj/FTvxWERnMRfDw8QwzE/t7RLwq8ZVRVJrhPQ==
X-Received: by 2002:a05:6000:1565:: with SMTP id 5mr15046531wrz.109.1612700047131; Sun, 07 Feb 2021 04:14:07 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id g14sm22797706wru.45.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Feb 2021 04:14:06 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Torsten Lodderstedt <>
In-Reply-To: <>
Date: Sun, 07 Feb 2021 13:14:05 +0100
Cc: oauth <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Andrii Deinega <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens
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: Sun, 07 Feb 2021 12:14:12 -0000

Hi Andrii,

thanks for your post. 

The draft is intended to provide AS and RS with a solution to exchange signed (and optionally encrypted) token introspection responses in order to provide stronger assurance among those parties. This is important in use cases where the RS acts upon the introspection response data and wants the AS to take liability re the data quality. 

I’m not sure whether there are similar use cases if a client introspects a refresh token. What is your use case?

best regards,

> Am 07.02.2021 um 08:41 schrieb Andrii Deinega <>:
> Hi WG,
> draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 Token Introspection [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token." which is true. Although, according to RFC7662, the introspection endpoint allows to introspect a refresh token as well. Hence, the question I have is how will a token introspection response look like when the caller provides a refresh token and sets the "Accept" HTTP header to "application/token-introspection+jwt"?
> I expect there will be no differences, right?
> If so, I suggest to
> 	• replace "a resource server" by "the caller" in section 4 (Requesting a JWT Response)
> 	• change "If the access token is invalid, expired, revoked" by "If a given token is invalid, expired, revoked" in section 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when it asked to introspect the refresh token in general and additionally, what should happen in the same case based on the type of the caller from the AS's point of view.
> Regards,
> Andrii