rfc9701v1.txt		rfc9701.txt
	Internet Engineering Task Force (IETF) T. Lodderstedt, Ed.		Internet Engineering Task Force (IETF) T. Lodderstedt, Ed.
	Request for Comments: 9701 yes.com AG		Request for Comments: 9701 yes.com AG
	Category: Standards Track V. Dzhuvinov		Category: Standards Track V. Dzhuvinov
	ISSN: 2070-1721 Connect2id Ltd.		ISSN: 2070-1721 Connect2id Ltd.
	November 2024		January 2025
	JSON Web Token (JWT) Response for OAuth Token Introspection		JSON Web Token (JWT) Response for OAuth Token Introspection
	Abstract		Abstract
	This specification proposes an additional JSON Web Token (JWT)		This specification proposes an additional response secured by JSON
	secured response for OAuth 2.0 Token Introspection.		Web Token (JWT) for OAuth 2.0 Token Introspection.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	Information about the current status of this document, any errata,		Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc9701.		https://www.rfc-editor.org/info/rfc9701.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2025 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	skipping to change at line 129 ¶		skipping to change at line 129 ¶
	The AS MAY additionally encrypt the token introspection response		The AS MAY additionally encrypt the token introspection response
	JWTs. If encryption is used, the AS is provisioned with encryption		JWTs. If encryption is used, the AS is provisioned with encryption
	keys and algorithms for the RS.		keys and algorithms for the RS.
	The AS MUST be able to determine whether an RS is the audience for a		The AS MUST be able to determine whether an RS is the audience for a
	particular access token and what data it is entitled to receive;		particular access token and what data it is entitled to receive;
	otherwise, the RS is not authorized to obtain data for the access		otherwise, the RS is not authorized to obtain data for the access
	token. The AS has the discretion of how to fulfill this requirement.		token. The AS has the discretion of how to fulfill this requirement.
	The AS could, for example, maintain a mapping between scope values		The AS could, for example, maintain a mapping between scope values
	and RSes.		and RSs.
	The requirements given above imply that the AS maintains credentials		The requirements given above imply that the AS maintains credentials
	and other configuration data for each RS.		and other configuration data for each RS.
	One way is by utilizing dynamic client registration [RFC7591] and		One way is by utilizing dynamic client registration [RFC7591] and
	treating every RS as an OAuth client. In this case, the AS is		treating every RS as an OAuth client. In this case, the AS is
	assumed to at least maintain a "client_id" and a		assumed to at least maintain a "client_id" and a
	"token_endpoint_auth_method" with complementary authentication method		"token_endpoint_auth_method" with complementary authentication method
	metadata, such as "jwks" or "client_secret". In cases where the AS		metadata, such as "jwks" or "client_secret". In cases where the AS
	needs to acquire consent to transmit data to an RS, the following		needs to acquire consent to transmit data to an RS, the following
	skipping to change at line 160 ¶		skipping to change at line 160 ¶
	introspection response JWTs.		introspection response JWTs.
	4. Requesting a JWT Response		4. Requesting a JWT Response
	An RS requests a JWT introspection response by sending an		An RS requests a JWT introspection response by sending an
	introspection request with an Accept HTTP header field set to		introspection request with an Accept HTTP header field set to
	"application/token-introspection+jwt".		"application/token-introspection+jwt".
	The AS MUST authenticate the caller at the token introspection		The AS MUST authenticate the caller at the token introspection
	endpoint. Authentication can utilize client authentication methods		endpoint. Authentication can utilize client authentication methods
	or a separate access token issued to the RS and identifying it as		or a separate access token that is issued to the RS and identifies
	subject.		the RS as the subject.
	The following is a non-normative example request, with the RS		The following is a non-normative example request, with the RS
	authenticating with a private key JWT:		authenticating with a private key JWT:
	POST /introspect HTTP/1.1		POST /introspect HTTP/1.1
	Host: as.example.com		Host: as.example.com
	Accept: application/token-introspection+jwt		Accept: application/token-introspection+jwt
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	token=2YotnFZFEjr1zCsicMWpAA&		token=2YotnFZFEjr1zCsicMWpAA&
	skipping to change at line 198 ¶		skipping to change at line 198 ¶
	MUST identify the resource server receiving the token		MUST identify the resource server receiving the token
	introspection response.		introspection response.
	iat		iat
	MUST be set to the time when the introspection response was		MUST be set to the time when the introspection response was
	created by the authorization server		created by the authorization server
	token_introspection		token_introspection
	A JSON object containing the members of the token introspection		A JSON object containing the members of the token introspection
	response, as specified in [RFC7662], Section 2.2. The separation		response, as specified in [RFC7662], Section 2.2. The separation
	of the introspection response members into a dedicated containing		of the introspection response members into a dedicated JSON object
	JWT claim is intended to prevent conflict and confusion with top-		containing a JWT claim is intended to prevent conflict and
	level JWT claims that may bear the same name.		confusion with top-level JWT claims that may bear the same name.
	If the access token is invalid, expired, revoked, or not intended		If the access token is invalid, expired, revoked, or not intended
	for the calling resource server (audience), the authorization		for the calling resource server (audience), the authorization
	server MUST set the value of the active member in the		server MUST set the value of the active member in the
	token_introspection claim to false and MUST NOT include other		token_introspection claim to false and MUST NOT include other
	members. Otherwise, the active member is set to true.		members. Otherwise, the active member is set to true.
	The AS SHOULD narrow down the scope value to the scopes relevant		The AS SHOULD narrow down the scope value to the scopes relevant
	to the particular RS.		to the particular RS.
	skipping to change at line 399 ¶		skipping to change at line 399 ¶
	try to exploit this and pass a JWT token introspection response as an		try to exploit this and pass a JWT token introspection response as an
	access token to the resource server. The typ ("type") JWT header		access token to the resource server. The typ ("type") JWT header
	"token-introspection+jwt" and the encapsulation of the token		"token-introspection+jwt" and the encapsulation of the token
	introspection members, such as sub and scope in the		introspection members, such as sub and scope in the
	token_introspection claim, are intended to prevent such substitution		token_introspection claim, are intended to prevent such substitution
	attacks. Resource servers MUST therefore check the typ JWT header		attacks. Resource servers MUST therefore check the typ JWT header
	value of received JWT-encoded access tokens and ensure all minimally		value of received JWT-encoded access tokens and ensure all minimally
	required claims for a valid access token are present.		required claims for a valid access token are present.
	Resource servers MUST additionally apply the countermeasures against		Resource servers MUST additionally apply the countermeasures against
	replay, as described in [RFC9700], Section 3.2.		access token replay, as described in [RFC9700].
	JWT confusion and other attacks involving JWTs are discussed in		JWT confusion and other attacks involving JWTs are discussed in
	[RFC8725].		[RFC8725].
	8.2. Token Data Leakage		8.2. Token Data Leakage
	The authorization server MUST use Transport Layer Security (TLS) 1.2		The authorization server MUST use Transport Layer Security (TLS) 1.2
	(or higher), per BCP 195 [RFC7525], in order to prevent token data		(or higher), per BCP 195 [RFC9325], in order to prevent token data
	leakage.		leakage.
	Section 2.1 of [RFC7662] permits requests to the introspection		Section 2.1 of [RFC7662] permits requests to the introspection
	endpoint to be authorized with an access token that doesn't identify		endpoint to be authorized with an access token that doesn't identify
	the caller. To prevent introspection of tokens by parties that are		the caller. To prevent introspection of tokens by parties that are
	not the intended consumer, the authorization server MUST require all		not the intended consumer, the authorization server MUST require all
	requests to the token introspection endpoint to be authenticated.		requests to the token introspection endpoint to be authenticated.
	9. Privacy Considerations		9. Privacy Considerations
	skipping to change at line 532 ¶		skipping to change at line 532 ¶
	Required parameters: N/A		Required parameters: N/A
	Optional parameters: N/A		Optional parameters: N/A
	Encoding considerations: binary. A token introspection response is		Encoding considerations: binary. A token introspection response is
	a JWT; JWT values are encoded as a series of base64url-encoded		a JWT; JWT values are encoded as a series of base64url-encoded
	values (with trailing '=' characters removed), some of which may		values (with trailing '=' characters removed), some of which may
	be the empty string, separated by period ('.') characters.		be the empty string, separated by period ('.') characters.
	Security considerations: see Section 8 of RFC 9701		Security considerations: See Section 8 of RFC 9701
	Interoperability considerations: N/A		Interoperability considerations: N/A
	Published specification: Section 4 of RFC 9701		Published specification: Section 4 of RFC 9701
	Applications that use this media type: applications that produce and		Applications that use this media type: Applications that produce and
	consume OAuth Token Introspection Responses in JWT format		consume OAuth Token Introspection Responses in JWT format
	Fragment identifier considerations: N/A		Fragment identifier considerations: N/A
	Additional information:		Additional information:
	Magic number(s): N/A		Magic number(s): N/A
	File extension(s): N/A		File extension(s): N/A
	Macintosh file type code(s): N/A		Macintosh file type code(s): N/A
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Torsten Lodderstedt (torsten@lodderstedt.net)		Torsten Lodderstedt (torsten@lodderstedt.net)
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: none		Restrictions on usage: none
	Author: Torsten Lodderstedt (torsten@lodderstedt.net)		Author: Torsten Lodderstedt (torsten@lodderstedt.net)
	Change controller: IETF		Change controller: IETF
	Provisional registration? No
	10.4. JWT Claim Registration		10.4. JWT Claim Registration
	The "token_introspection" claim has been registered in the "JSON Web		The "token_introspection" claim has been registered in the "JSON Web
	Token (JWT)" registry [IANA.JWT] in the manner described in		Token (JWT)" registry [IANA.JWT] in the manner described in
	[RFC7519].		[RFC7519].
	10.4.1. Registry Contents		10.4.1. Registry Contents
	Claim Name: token_introspection		Claim Name: token_introspection
	Claim Description: Token introspection response		Claim Description: Token introspection response
	skipping to change at line 621 ¶		skipping to change at line 619 ¶
	<https://www.rfc-editor.org/info/rfc7516>.		<https://www.rfc-editor.org/info/rfc7516>.
	[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,		[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
	DOI 10.17487/RFC7518, May 2015,		DOI 10.17487/RFC7518, May 2015,
	<https://www.rfc-editor.org/info/rfc7518>.		<https://www.rfc-editor.org/info/rfc7518>.
	[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<https://www.rfc-editor.org/info/rfc7519>.		<https://www.rfc-editor.org/info/rfc7519>.
	[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security
	(DTLS)", RFC 7525, DOI 10.17487/RFC7525, May 2015,
	<https://www.rfc-editor.org/info/rfc7525>.
	[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and		[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
	P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",		P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
	RFC 7591, DOI 10.17487/RFC7591, July 2015,		RFC 7591, DOI 10.17487/RFC7591, July 2015,
	<https://www.rfc-editor.org/info/rfc7591>.		<https://www.rfc-editor.org/info/rfc7591>.
	[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",		[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
	RFC 7662, DOI 10.17487/RFC7662, October 2015,		RFC 7662, DOI 10.17487/RFC7662, October 2015,
	<https://www.rfc-editor.org/info/rfc7662>.		<https://www.rfc-editor.org/info/rfc7662>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	skipping to change at line 650 ¶		skipping to change at line 642 ¶
	[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0		[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
	Authorization Server Metadata", RFC 8414,		Authorization Server Metadata", RFC 8414,
	DOI 10.17487/RFC8414, June 2018,		DOI 10.17487/RFC8414, June 2018,
	<https://www.rfc-editor.org/info/rfc8414>.		<https://www.rfc-editor.org/info/rfc8414>.
	[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best		[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
	Current Practices", BCP 225, RFC 8725,		Current Practices", BCP 225, RFC 8725,
	DOI 10.17487/RFC8725, February 2020,		DOI 10.17487/RFC8725, February 2020,
	<https://www.rfc-editor.org/info/rfc8725>.		<https://www.rfc-editor.org/info/rfc8725>.
			[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
			"Recommendations for Secure Use of Transport Layer
			Security (TLS) and Datagram Transport Layer Security
			(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
			2022, <https://www.rfc-editor.org/info/rfc9325>.
	[RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,		[RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
	"OAuth 2.0 Security Best Current Practice", BCP 240,		"Best Current Practice for OAuth 2.0 Security", BCP 240,
	RFC 9700, DOI 10.17487/RFC9700, November 2024,		RFC 9700, DOI 10.17487/RFC9700, January 2025,
	<https://www.rfc-editor.org/info/rfc9700>.		<https://www.rfc-editor.org/info/rfc9700>.
	11.2. Informative References		11.2. Informative References
	[IANA.OAuth.Parameters]		[IANA.OAuth.Parameters]
	IANA, "OAuth Parameters",		IANA, "OAuth Parameters",
	<http://www.iana.org/assignments/oauth-parameters>.		<http://www.iana.org/assignments/oauth-parameters>.
	Acknowledgements		Acknowledgements
End of changes. 14 change blocks.
	24 lines changed or deleted		22 lines changed or added
This html diff was produced by rfcdiff 1.48.