draft-parecki-oauth-global-token-revocation-02.txt		draft-parecki-oauth-global-token-revocation-03.txt
	Web Authorization Protocol A. Parecki		Web Authorization Protocol A. Parecki
	Internet-Draft Okta		Internet-Draft Okta
	Intended status: Standards Track 2 March 2024		Intended status: Standards Track 21 March 2024
	Expires: 3 September 2024		Expires: 22 September 2024
	Global Token Revocation		Global Token Revocation
	draft-parecki-oauth-global-token-revocation-02		draft-parecki-oauth-global-token-revocation-03
	Abstract		Abstract
	Global Token Revocation enables parties such as a security incident		Global Token Revocation enables parties such as a security incident
	management tool or an external Identity Provider to send a request to		management tool or an external Identity Provider to send a request to
	an Authorization Server to indicate that it should revoke all of the		an Authorization Server to indicate that it should revoke all of the
	user's existing tokens and require that the user re-authenticates		user's existing tokens and require that the user re-authenticates
	before issuing new tokens.		before issuing new tokens.
	About This Document		About This Document
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	The latest revision of this draft can be found at		The latest revision of this draft can be found at
	https://aaronpk.github.io/global-token-revocation/draft-parecki-		https://drafts.aaronpk.com/global-token-revocation/draft-parecki-
	oauth-global-token-revocation.html. Status information for this		oauth-global-token-revocation.html. Status information for this
	document may be found at https://datatracker.ietf.org/doc/draft-		document may be found at https://datatracker.ietf.org/doc/draft-
	parecki-oauth-global-token-revocation/.		parecki-oauth-global-token-revocation/.
	Discussion of this document takes place on the Web Authorization		Discussion of this document takes place on the Web Authorization
	Protocol Working Group mailing list (mailto:oauth@ietf.org), which is		Protocol Working Group mailing list (mailto:oauth@ietf.org), which is
	archived at https://mailarchive.ietf.org/arch/browse/oauth/.		archived at https://mailarchive.ietf.org/arch/browse/oauth/.
	Subscribe at https://www.ietf.org/mailman/listinfo/oauth/.		Subscribe at https://www.ietf.org/mailman/listinfo/oauth/.
	Source for this draft and an issue tracker can be found at		Source for this draft and an issue tracker can be found at
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 3 September 2024.		This Internet-Draft will expire on 22 September 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 42 ¶		skipping to change at page 2, line 42 ¶
	3. Token Revocation . . . . . . . . . . . . . . . . . . . . . . 4		3. Token Revocation . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Revocation Endpoint . . . . . . . . . . . . . . . . . . . 4		3.1. Revocation Endpoint . . . . . . . . . . . . . . . . . . . 4
	3.2. Revocation Request . . . . . . . . . . . . . . . . . . . 4		3.2. Revocation Request . . . . . . . . . . . . . . . . . . . 4
	3.3. Revocation Expectations . . . . . . . . . . . . . . . . . 6		3.3. Revocation Expectations . . . . . . . . . . . . . . . . . 6
	3.4. Revocation Response . . . . . . . . . . . . . . . . . . . 6		3.4. Revocation Response . . . . . . . . . . . . . . . . . . . 6
	3.4.1. Successful Response . . . . . . . . . . . . . . . . . 6		3.4.1. Successful Response . . . . . . . . . . . . . . . . . 6
	3.4.2. Error Response . . . . . . . . . . . . . . . . . . . 6		3.4.2. Error Response . . . . . . . . . . . . . . . . . . . 6
	4. Revocation of Access Tokens . . . . . . . . . . . . . . . . . 7		4. Revocation of Access Tokens . . . . . . . . . . . . . . . . . 7
	5. Authorization Server Metadata . . . . . . . . . . . . . . . . 7		5. Authorization Server Metadata . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6.1. Enumeration of User Accounts . . . . . . . . . . . . . . 8		6.1. Authentication of Revocation Request . . . . . . . . . . 8
			6.2. Enumeration of User Accounts . . . . . . . . . . . . . . 8
			6.3. Malicious Authorization Server . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7.1. OAuth Authorization Server Metadata . . . . . . . . . . . 9		7.1. OAuth Authorization Server Metadata . . . . . . . . . . . 9
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix A. Relationship to Related Specifications . . . . . . . 10		Appendix A. Relationship to Related Specifications . . . . . . . 11
	A.1. RFC7009: Token Revocation . . . . . . . . . . . . . . . . 10		A.1. RFC7009: Token Revocation . . . . . . . . . . . . . . . . 11
	A.2. OpenID Connect Front-Channel Logout . . . . . . . . . . . 11		A.2. OpenID Connect Front-Channel Logout . . . . . . . . . . . 11
	A.3. OpenID Connect Back-Channel Logout . . . . . . . . . . . 11		A.3. OpenID Connect Back-Channel Logout . . . . . . . . . . . 12
	A.4. Shared Signals Framework . . . . . . . . . . . . . . . . 12		A.4. Shared Signals Framework . . . . . . . . . . . . . . . . 12
			Appendix B. Document History . . . . . . . . . . . . . . . . . . 13
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 12		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	An OAuth Authorization Server issues tokens in response to a user		An OAuth Authorization Server issues tokens in response to a user
	authorizing a client. A party external to the OAuth Authorization		authorizing a client. A party external to the OAuth Authorization
	Server may wish to instruct the Authorization Server to revoke all		Server may wish to instruct the Authorization Server to revoke all
	tokens belonging to a particular user, and prevent the server from		tokens belonging to a particular user, and prevent the server from
	issuing new tokens until the user re-authenticates.		issuing new tokens until the user re-authenticates.
	For example, a security incident management tool may detect anomalous		For example, a security incident management tool may detect anomalous
	skipping to change at page 5, line 23 ¶		skipping to change at page 5, line 23 ¶
	The following example requests that all tokens for a user identified		The following example requests that all tokens for a user identified
	by an email address be revoked:		by an email address be revoked:
	POST /global-token-revocation		POST /global-token-revocation
	Host: example.com		Host: example.com
	Content-Type: application/json		Content-Type: application/json
	Authorization: Bearer f5641763544a7b24b08e4f74045		Authorization: Bearer f5641763544a7b24b08e4f74045
	{		{
	"subject": {		"sub_id": {
	"format": "email",		"format": "email",
	"email": "user@example.com"		"email": "user@example.com"
	}		}
	}		}
	If the user identifier at the authorization server is known by the		If the user identifier at the authorization server is known by the
	system making the revocation request, the request can use the "Opaque		system making the revocation request, the request can use the "Opaque
	Identifer" format to provide the user identifier:		Identifer" format to provide the user identifier:
	POST /global-token-revocation		POST /global-token-revocation
	Host: example.com		Host: example.com
	Content-Type: application/json		Content-Type: application/json
	Authorization: Bearer f5641763544a7b24b08e4f74045		Authorization: Bearer f5641763544a7b24b08e4f74045
	{		{
	"subject": {		"sub_id": {
	"format": "opaque",		"format": "opaque",
	"id": "e193177dfdc52e3dd03f78c"		"id": "e193177dfdc52e3dd03f78c"
	}		}
	}		}
	If it is expected that the authorization server knows about the user		If it is expected that the authorization server knows about the user
	identifier at the IdP, the request can use the "Issuer and Subject		identifier at the IdP, the request can use the "Issuer and Subject
	Identifier" format:		Identifier" format:
	POST /global-token-revocation		POST /global-token-revocation
	Host: example.com		Host: example.com
	Content-Type: application/json		Content-Type: application/json
	Authorization: Bearer f5641763544a7b24b08e4f74045		Authorization: Bearer f5641763544a7b24b08e4f74045
	{		{
	"subject": {		"sub_id": {
	"format": "iss_sub",		"format": "iss_sub",
	"iss": "https://issuer.example.com/",		"iss": "https://issuer.example.com/",
	"sub": "af19c476f1dc4470fa3d0d9a25"		"sub": "af19c476f1dc4470fa3d0d9a25"
	}		}
	}		}
	3.3. Revocation Expectations		3.3. Revocation Expectations
	Upon receiving a revocation request, authorizing the request, and		Upon receiving a revocation request, authorizing the request, and
	validating the identified user, the Authorization Server:		validating the identified user, the Authorization Server:
	* MUST revoke all active refresh tokens		* MUST revoke all active refresh tokens
	* SHOULD invalidate all access tokens, although it is recognized		* SHOULD invalidate all access tokens, although it is recognized
	that it might not be technically feasible to invalidate access		that it might not be technically feasible to invalidate access
	tokens (see Section 4 below)		tokens (see Section 4 below)
	* MUST NOT issue new access tokens or refresh tokens without re-		* MUST re-authenticate the user before issuing new access tokens or
	authenticating the user		refresh tokens
	3.4. Revocation Response		3.4. Revocation Response
	This specification indicates success and error conditions by using		This specification indicates success and error conditions by using
	HTTP response codes, and does not define the response body format or		HTTP response codes, and does not define the response body format or
	content.		content.
	3.4.1. Successful Response		3.4.1. Successful Response
	To indicate that the request was successful and revocation of the		To indicate that the request was successful and revocation of the
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 28 ¶
	authorization decision of the client requesting access to a protected		authorization decision of the client requesting access to a protected
	resource. A system design may, however, instead use access tokens		resource. A system design may, however, instead use access tokens
	that are handles (also known as "reference tokens") referring to		that are handles (also known as "reference tokens") referring to
	authorization data stored at the authorization server.		authorization data stored at the authorization server.
	While these are not the only options, they illustrate the		While these are not the only options, they illustrate the
	implications for revocation. In the latter case of reference tokens,		implications for revocation. In the latter case of reference tokens,
	the authorization server is able to revoke an access token by		the authorization server is able to revoke an access token by
	removing it from storage. In the former case, without storing		removing it from storage. In the former case, without storing
	tokens, it may be impossible to revoke tokens without taking		tokens, it may be impossible to revoke tokens without taking
	additional measures.		additional measures. One such measure is to use
			[I-D.ietf-oauth-status-list] to maintain a distributed and easily-
			compressed list of token revocation statuses.
	For this reason, revocation of access tokens is optional in this		For this reason, revocation of access tokens is optional in this
	specification, since it may pose too significant of a burden for		specification, since it may pose too significant of a burden for
	implementers. It is not required to revoke access tokens to be able		implementers. It is not required to revoke access tokens to be able
	to return a success code to the caller.		to return a success code to the caller.
	5. Authorization Server Metadata		5. Authorization Server Metadata
	The following authorization server metadata parameters [RFC8414] are		The following authorization server metadata parameters [RFC8414] are
	introduced to signal the server's capability and policy with respect		introduced to signal the server's capability and policy with respect
	skipping to change at page 8, line 4 ¶		skipping to change at page 7, line 47 ¶
	5. Authorization Server Metadata		5. Authorization Server Metadata
	The following authorization server metadata parameters [RFC8414] are		The following authorization server metadata parameters [RFC8414] are
	introduced to signal the server's capability and policy with respect		introduced to signal the server's capability and policy with respect
	to Global Token Revocation.		to Global Token Revocation.
	"global_token_revocation_endpoint": The URL of the authorization		"global_token_revocation_endpoint": The URL of the authorization
	server's global token revocation endpoint.		server's global token revocation endpoint.
	"global_token_revocation_endpoint_auth_methods_supported": OPTIONAL.		"global_token_revocation_endpoint_auth_methods_supported": OPTIONAL.
	JSON array containing a list of client authentication methods		JSON array containing a list of client authentication methods
	supported by this introspection endpoint. The valid client		supported by this introspection endpoint. The valid client
	authentication method values are those registered in the IANA		authentication method values are those registered in the IANA
	"OAuth Token Endpoint Authentication Methods" registry		"OAuth Token Endpoint Authentication Methods" registry
	[IANA.oauth-parameters] or those registered in the IANA "OAuth		[IANA.oauth-parameters] or those registered in the IANA "OAuth
	Access Token Types" registry [IANA.oauth-parameters]. (These		Access Token Types" registry [IANA.oauth-parameters]. (These
	values are and will remain distinct, due to Section 7.2.) If		values are and will remain distinct, due to Section 7.2.) If
	omitted, the set of supported authentication methods MUST be		omitted, the set of supported authentication methods MUST be
	determined by other means.		determined by other means.
	6. Security Considerations		6. Security Considerations
	6.1. Enumeration of User Accounts		6.1. Authentication of Revocation Request
			While Section 3.2 requires that the revocation request is an
			authenticated request, the specifics of the authentication are out of
			scope of this specification.
			Since the revocation request ultimately has wide-reaching effects (a
			user is expected to be logged out of all devices), this presents a
			new Denial of Service attack vector. As such, the authentication
			used for this request SHOULD be narrowly scoped to avoid granting
			unnecessary privileges to the caller.
			For example, if using OAuth Bearer Tokens, the token SHOULD be issued
			with a single scope that enables it to perform the revocation
			request, and no other type of token issued should include this scope.
			If the authorization server is multi-tenant (supports multiple
			customers) through different identity providers, each identity
			provider SHOULD use its own scoped credential that is only authorized
			to revoke tokens for users within the same tenant.
			6.2. Enumeration of User Accounts
	Typically, an API that accepts a user identifier and returns		Typically, an API that accepts a user identifier and returns
	different statuses depending on whether the user exists would provide		different statuses depending on whether the user exists would provide
	an attack vector allowing enumeration of user accounts. This		an attack vector allowing enumeration of user accounts. This
	specification does require a "User Not Found" response, so would		specification does require a "User Not Found" response, so would
	normally fall under this category. However, requests to the endpoint		normally fall under this category. However, requests to the endpoint
	defined by this specification are required to be authenticated, so		defined by this specification are required to be authenticated, so
	this is not considered a public endpoint.		this is not considered a public endpoint.
	If the tool making the request is compromised, and the attacker can		If the tool making the request is compromised, and the attacker can
	impersonate the requests from this tool (either by coercing the tool		impersonate the requests from this tool (either by coercing the tool
	to make the request, or by extracting the credentials), then the		to make the request, or by extracting the credentials), then the
	attacker would be able to enumerate user accounts. However, since		attacker would be able to enumerate user accounts. However, since
	the request is not just testing the presence of a user account, but		the request is not just testing the presence of a user account, but
	actually revoking the tokens associated with the user if successful,		actually revoking the tokens associated with the user if successful,
	this would likely be easily visible in any audit logs as many users		this would likely be easily visible in any audit logs as many users'
	tokens would be revoked in a short period of time.		tokens would be revoked in a short period of time.
	To mitigate some of the concerns of providing such a powerful API		To mitigate some of the concerns of providing such a powerful API
	endpoint, the users that a particular client can request revocation		endpoint, the users that a particular client can request revocation
	for SHOULD be limited, and the authentication of the request SHOULD		for SHOULD be limited, and the authentication of the request SHOULD
	be used to scope the possible user revocation list to only users		be used to scope the possible user revocation list to only users
	authorized to the client.		authorized to the client as described in Section 6.1.
	For example, a multi-tenant identity provider that uses different		For example, a multi-tenant identity provider that uses different
	signing keys for users assciated with different tenants, can also use		signing keys for users associated with different tenants, can also
	the same signing keys to authenticate revocation requests, such as		use the same signing keys to authenticate revocation requests, such
	creating a JWT to use as client authentication as described in		as creating a JWT to use as client authentication as described in
	[RFC7523]. This enables the authorization server receiving the		[RFC7523]. This enables the authorization server receiving the
	request to only accept revocation requests for users that are		request to only accept revocation requests for users that are
	associated with the particular tenant at the identity provider.		associated with the particular tenant at the identity provider.
			6.3. Malicious Authorization Server
			From the point of view of an identity provider that supports
			integrations with multiple downstream applications, there is an
			opportunity for a downstream application to maliciously set up a
			Global Token Revocation endpoint to harvest user identifiers and
			authentication of the revocation requests.
			Similarly as described in Section 6.1 above, each integration SHOULD
			be using separate authentication credentials, and each credential
			SHOULD be scoped as narrowly as possible, such that a malicious
			server that receives this authentication cannot replay it anywhere
			else to perform any actions on other systems.
	7. IANA Considerations		7. IANA Considerations
	7.1. OAuth Authorization Server Metadata		7.1. OAuth Authorization Server Metadata
	IANA has (TBD) registered the following values in the IANA "OAuth		IANA has (TBD) registered the following values in the IANA "OAuth
	Authorization Server Metadata" registry of [IANA.oauth-parameters]		Authorization Server Metadata" registry of [IANA.oauth-parameters]
	established by [RFC8414].		established by [RFC8414].
	*Metadata Name*: global_token_revocation_endpoint		*Metadata Name*: global_token_revocation_endpoint
	skipping to change at page 10, line 17 ¶		skipping to change at page 10, line 44 ¶
	DOI 10.17487/RFC8414, June 2018,		DOI 10.17487/RFC8414, June 2018,
	<https://www.rfc-editor.org/rfc/rfc8414>.		<https://www.rfc-editor.org/rfc/rfc8414>.
	[RFC9493] Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject		[RFC9493] Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject
	Identifiers for Security Event Tokens", RFC 9493,		Identifiers for Security Event Tokens", RFC 9493,
	DOI 10.17487/RFC9493, December 2023,		DOI 10.17487/RFC9493, December 2023,
	<https://www.rfc-editor.org/rfc/rfc9493>.		<https://www.rfc-editor.org/rfc/rfc9493>.
	8.2. Informative References		8.2. Informative References
			[I-D.ietf-oauth-status-list]
			Looker, T., Bastian, P., and C. Bormann, "Token Status
			List", Work in Progress, Internet-Draft, draft-ietf-oauth-
			status-list-02, 3 March 2024,
			<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
			status-list-02>.
	[OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and		[OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
	C. Mortimore, "OpenID Connect Core 1.0", November 2014,		C. Mortimore, "OpenID Connect Core 1.0", November 2014,
	<https://openid.net/specs/openid-connect-core-1_0.html>.		<https://openid.net/specs/openid-connect-core-1_0.html>.
	[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization		[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
	Framework: Bearer Token Usage", RFC 6750,		Framework: Bearer Token Usage", RFC 6750,
	DOI 10.17487/RFC6750, October 2012,		DOI 10.17487/RFC6750, October 2012,
	<https://www.rfc-editor.org/rfc/rfc6750>.		<https://www.rfc-editor.org/rfc/rfc6750>.
	[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth		[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
	skipping to change at page 12, line 21 ¶		skipping to change at page 13, line 7 ¶
	The Shared Signals Framework at the OpenID Foundation provides two		The Shared Signals Framework at the OpenID Foundation provides two
	specifications that have functionality related to session and token		specifications that have functionality related to session and token
	revocation.		revocation.
	Continuous Access Evaluation Profile (CAEP)		Continuous Access Evaluation Profile (CAEP)
	(https://openid.net/specs/openid-caep-specification-1_0.html) defines		(https://openid.net/specs/openid-caep-specification-1_0.html) defines
	several event types that can be sent between cooperating parties. In		several event types that can be sent between cooperating parties. In
	particular, the "Session Revoked" event can be sent from an identity		particular, the "Session Revoked" event can be sent from an identity
	provider to an authorization server when the user's session at the		provider to an authorization server when the user's session at the
	identity provider was revoked. The main difference between this and		identity provider was revoked. The main difference between this and
	the Global Token Revocation request is that teh CAEP event is a		the Global Token Revocation request is that the CAEP event is a
	signal that may or may not be acted upon by the receiver, whereas the		signal that may or may not be acted upon by the receiver, whereas the
	Global Token Revocation request is a command that has a defined list		Global Token Revocation request is a command that has a defined list
	of expected outcomes.		of expected outcomes.
	Risk Incident Sharing and Coordination (RISC)		Risk Incident Sharing and Coordination (RISC)
	(https://openid.net/specs/openid-risc-profile-specification-1_0.html)		(https://openid.net/specs/openid-risc-profile-specification-1_0.html)
	defines events that have somewhat stronger defined meanings compared		defines events that have somewhat stronger defined meanings compared
	to CAEP. In particular, the "Account Disabled" event has clear		to CAEP. In particular, the "Account Disabled" event has clear
	meaning and strongly implies that a receiver should also disable the		meaning and strongly implies that a receiver should also disable the
	specified account. However, RISC also has a mechanism for a user to		specified account. However, RISC also has a mechanism for a user to
	skipping to change at page 12, line 45 ¶		skipping to change at page 13, line 31 ¶
	Lastly, it is more complex to set up a receiver for CAEP and RISC		Lastly, it is more complex to set up a receiver for CAEP and RISC
	events compared to a receiver for the Global Token Revocation		events compared to a receiver for the Global Token Revocation
	request, so if the receiver is only interested in supporting the		request, so if the receiver is only interested in supporting the
	revocation use cases, it is much simpler to support the single POST		revocation use cases, it is much simpler to support the single POST
	request described in this draft.		request described in this draft.
	Appendix B. Document History		Appendix B. Document History
	(( To be removed from the final specification ))		(( To be removed from the final specification ))
			-03
			* Renamed property from subject to sub_id for consistency with JWT
			claim name defined in RFC9493
			* Added reference to draft-ietf-oauth-status-list
			* Added additional security considerations for authentication of the
			revocation request and malicious authorization servers
	-02		-02
	* Added security consideration around enumeration of user accounts		* Added security consideration around enumeration of user accounts
	* Added an appendix describing the differences between this and		* Added an appendix describing the differences between this and
	related logout specifications		related logout specifications
	-01		-01
	* Clarified revocation expectations
			* Clarified revocation expectations
	* Better definition of endpoint		* Better definition of endpoint
	* Added section defining endpoint in Authorization Server Metadata		* Added section defining endpoint in Authorization Server Metadata
	-00		-00
	* Initial Draft		* Initial Draft
	Acknowledgments		Acknowledgments
	The authors would like to thank the following people for their		The authors would like to thank the following people for their
	contributions and reviews of this specification: George Fletcher,		contributions and reviews of this specification: Apoorva Deshpande,
	Karl McGuinness, Mike Jones.		George Fletcher, Karl McGuinness, Mike Jones.
	Author's Address		Author's Address
	Aaron Parecki		Aaron Parecki
	Okta		Okta
	Email: aaron@parecki.com		Email: aaron@parecki.com
	URI: https://aaronparecki.com		URI: https://aaronparecki.com
End of changes. 26 change blocks.
	32 lines changed or deleted		86 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/