draft-ietf-oauth-identity-assertion-authz-grant-05.txt		draft-ietf-oauth-identity-assertion-authz-grant-06.txt
	Web Authorization Protocol A. Parecki		Web Authorization Protocol A. Parecki
	Internet-Draft Okta		Internet-Draft Okta
	Intended status: Standards Track K. McGuinness		Intended status: Standards Track K. McGuinness
	Expires: 3 May 2027 Independent		Expires: 4 May 2027 Independent
	B. Campbell		B. Campbell
	Ping Identity		Ping Identity
	30 October 2026		31 October 2026
	Identity Assertion JWT Authorization Grant		Identity Assertion JWT Authorization Grant
	draft-ietf-oauth-identity-assertion-authz-grant-05		draft-ietf-oauth-identity-assertion-authz-grant-06
	Abstract		Abstract
	This specification provides a mechanism for an application to use an		This specification provides a mechanism for an application to use an
	identity assertion to obtain an access token for a third-party API by		identity assertion to obtain an access token for a third-party API by
	coordinating through an identity provider that the downstream		coordinating through an identity provider that the downstream
	Resource Authorization Server already trusts for single sign-on		Resource Authorization Server already trusts for single sign-on
	(SSO), using OAuth 2.0 Token Exchange (RFC 8693) and the JWT Profile		(SSO), using OAuth 2.0 Token Exchange (RFC 8693) and the JWT Profile
	for OAuth 2.0 Authorization Grants (RFC 7523). This pattern is		for OAuth 2.0 Authorization Grants (RFC 7523). This pattern is
	informally referred to as Cross-App Access (XAA).		informally referred to as Cross-App Access (XAA).
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	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 May 2027.		This Internet-Draft will expire on 4 May 2027.
	Copyright Notice		Copyright Notice
	Copyright (c) 2026 IETF Trust and the persons identified as the		Copyright (c) 2026 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 4, line 10 ¶		skipping to change at page 4, line 10 ¶
	A.2. Customer Identity for Developer SaaS Components . . . . . 65		A.2. Customer Identity for Developer SaaS Components . . . . . 65
	A.2.1. Preconditions . . . . . . . . . . . . . . . . . . . . 65		A.2.1. Preconditions . . . . . . . . . . . . . . . . . . . . 65
	A.3. Email and Calendaring Applications . . . . . . . . . . . 66		A.3. Email and Calendaring Applications . . . . . . . . . . . 66
	A.3.1. Preconditions . . . . . . . . . . . . . . . . . . . . 67		A.3.1. Preconditions . . . . . . . . . . . . . . . . . . . . 67
	A.4. AI Agent using External Tools . . . . . . . . . . . . . . 67		A.4. AI Agent using External Tools . . . . . . . . . . . . . . 67
	A.4.1. Preconditions . . . . . . . . . . . . . . . . . . . . 67		A.4.1. Preconditions . . . . . . . . . . . . . . . . . . . . 67
	A.4.2. Example Sequence . . . . . . . . . . . . . . . . . . 68		A.4.2. Example Sequence . . . . . . . . . . . . . . . . . . 68
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 76		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 76
	Document History . . . . . . . . . . . . . . . . . . . . . . . . 76		Document History . . . . . . . . . . . . . . . . . . . . . . . . 76
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
	1. Introduction		1. Introduction
	In many deployments, applications are configured for single sign-on		In many deployments, applications are configured for single sign-on
	to a common identity provider (IdP) using OpenID Connect or SAML.		to a common identity provider (IdP) using OpenID Connect or SAML.
	This enables users to access multiple applications using a single		This enables users to access multiple applications using a single
	account at the IdP, and enables the operator of that IdP to manage		account at the IdP, and enables the operator of that IdP to manage
	which users can access which applications and enforce policy for		which users can access which applications and enforce policy for
	access to those applications. Enterprise workforce identity		access to those applications. Enterprise workforce identity
	providers are one common example, but the same trust pattern can also		providers are one common example, but the same trust pattern can also
	skipping to change at page 30, line 35 ¶		skipping to change at page 30, line 35 ¶
	]		]
	}		}
	4.3.4.3. Error Response		4.3.4.3. Error Response
	On error, the IdP Authorization Server returns an OAuth 2.0 Token		On error, the IdP Authorization Server returns an OAuth 2.0 Token
	Error response as defined in Section 5.2 of [RFC6749]. Any OAuth		Error response as defined in Section 5.2 of [RFC6749]. Any OAuth
	error code MAY be returned; this specification profiles the following		error code MAY be returned; this specification profiles the following
	codes for interoperability:		codes for interoperability:
	* invalid_grant: the subject token failed validation (for example		* invalid_request: the subject token failed validation (for example
	expired, malformed, audience mismatch, or a Refresh Token is		expired, malformed, audience mismatch, or a Refresh Token is
	expired or revoked). A re-issued subject token may resolve the		expired or revoked), as required by Section 2.2.2 of [RFC8693]. A
	error.		Client that receives invalid_request for a request that previously
			succeeded can obtain a new subject token and retry.
	{		{
	"error": "invalid_grant",		"error": "invalid_request",
	"error_description": "Audience validation failed"		"error_description": "Audience validation failed"
	}		}
	* access_denied: the subject token is valid but the Client or End-		* access_denied: the subject token is valid but the Client or End-
	User is not authorized to obtain an ID-JAG for the target Resource		User is not authorized to obtain an ID-JAG for the target Resource
	Authorization Server. A re-issued subject token will not resolve		Authorization Server. A re-issued subject token will not resolve
	the error. Remediation is defined by the IdP Authorization Server		the error. Remediation is defined by the IdP Authorization Server
	operator's app assignment, access-request, or entitlement process,		operator's app assignment, access-request, or entitlement process,
	such as an Identity Governance and Administration (IGA) workflow.		such as an Identity Governance and Administration (IGA) workflow.
			This profile uses access_denied here rather than invalid_target
			(Section 2.2.2 of [RFC8693]), so that the Client can tell a target
			it is not allowed to use from one the IdP Authorization Server
			does not recognize.
	{		{
	"error": "access_denied",		"error": "access_denied",
	"error_description": "Client is not authorized to access the target Resource Authorization Server"		"error_description": "Client is not authorized to access the target Resource Authorization Server"
	}		}
	* invalid_target: the audience does not identify a Resource		* invalid_target: the audience does not identify a Resource
	Authorization Server with which the IdP Authorization Server has a		Authorization Server with which the IdP Authorization Server has a
	trust relationship, or a requested resource is not governed by		trust relationship, or a requested resource is not governed by
	that Resource Authorization Server (Section 4.3). A re-issued		that Resource Authorization Server (Section 4.3). A re-issued
	skipping to change at page 76, line 46 ¶		skipping to change at page 76, line 46 ¶
	contributions and reviews of this specification: Kamron		contributions and reviews of this specification: Kamron
	Batmanghelich, Paul Carleton, Sofia Desenberg, Meghna Dubey, George		Batmanghelich, Paul Carleton, Sofia Desenberg, Meghna Dubey, George
	Fletcher, Bingrong He, Pieter Kasselman, Aaron Jeongwoo Kim, Kai		Fletcher, Bingrong He, Pieter Kasselman, Aaron Jeongwoo Kim, Kai
	Lehmann, David Lozano, Kaixuan Luo, Ken McCracken, Anuj Mistry, Dean		Lehmann, David Lozano, Kaixuan Luo, Ken McCracken, Anuj Mistry, Dean
	H. Saxe, Kenneth Sinder, Filip Skokan, Phil Whipps.		H. Saxe, Kenneth Sinder, Filip Skokan, Phil Whipps.
	Document History		Document History
	[[ To be removed from the final specification ]]		[[ To be removed from the final specification ]]
			-06
			* Changed the IdP Authorization Server error for a subject token
			that fails validation from invalid_grant to invalid_request, as
			required by Section 2.2.2 of RFC 8693
			* Explained why access_denied is used rather than invalid_target
			when the Client or End-User is not authorized for the target
	-05		-05
	* Added invalid_target handling and resource governance checks for		* Added invalid_target handling and resource governance checks for
	the resource parameter and claim		the resource parameter and claim
	* Added security considerations on Authorization Server and		* Added security considerations on Authorization Server and
	Protected Resource Metadata validation		Protected Resource Metadata validation
	* Added mTLS certificate binding as an alternative sender-		* Added mTLS certificate binding as an alternative sender-
	constraining mechanism for the ID-JAG, alongside DPoP		constraining mechanism for the ID-JAG, alongside DPoP
	skipping to change at page 77, line 40 ¶		skipping to change at page 77, line 48 ¶
	Server, and added a Subject Identifier Mapping section		Server, and added a Subject Identifier Mapping section
	* Clarified that Token Exchange scope values are not OpenID Connect		* Clarified that Token Exchange scope values are not OpenID Connect
	scopes		scopes
	* Specified how the Resource Authorization Server finds and		* Specified how the Resource Authorization Server finds and
	validates ID-JAG signing keys		validates ID-JAG signing keys
	* Added id_jag_signing_alg_values_supported IdP metadata parameter		* Added id_jag_signing_alg_values_supported IdP metadata parameter
			* Specified that IdP metadata is located per RFC 8414
	* Clarified ID-JAG reuse limits and when the Client should request a		* Clarified ID-JAG reuse limits and when the Client should request a
	new ID-JAG		new ID-JAG
			* Required the IdP to authenticate the Client in the Token Exchange
			request
	* Limited the Token Exchange request to a single audience value, and		* Limited the Token Exchange request to a single audience value, and
	profiled invalid_target for an unrecognized audience or a resource		profiled invalid_target for an unrecognized audience or a resource
	not governed by it		not governed by it
	* Defined resource identifier comparison, made the IdP resource		* Defined resource identifier comparison, made the IdP resource
	governance check a SHOULD, and required the access token to be		governance check a SHOULD, and required the access token to be
	restricted to the resources in the ID-JAG resource claim		restricted to the resources in the ID-JAG resource claim
	* Moved RFC 9728 to normative references		* Moved RFC 9728 to normative references
	* Clarified how the IdP validates a Refresh Token used as the		* Clarified how the IdP validates a Refresh Token used as the
	subject token, and when the RFC 6749 scope comparison applies		subject token, and when the RFC 6749 scope comparison applies
	* Required the jwt-dpop grant type for DPoP-bound ID-JAGs, and		* Required the jwt-dpop grant type for DPoP-bound ID-JAGs, and
	required the Resource Authorization Server to reject an ID-JAG		required the Resource Authorization Server to reject an ID-JAG
	with an unsupported cnf confirmation method		with an unsupported cnf confirmation method
			* Allowed a key-bound ID-JAG to be used in place of client
			authentication at the Resource Authorization Server
	* Fixed the tenant claims used in the client ID and subject		* Fixed the tenant claims used in the client ID and subject
	identifier uniqueness rules		identifier uniqueness rules
			* Added a tenant context check at the Resource Authorization Server
			* Added Privacy Considerations
			* Updated the email and calendaring use case to use a Client ID
			Metadata Document
	* Fixed examples (RS256 signatures, Cache-Control headers, mTLS		* Fixed examples (RS256 signatures, Cache-Control headers, mTLS
	client_id, consistent iss and exp values)		client_id, consistent iss and exp values)
	* Corrected cited section numbers, removed citations from the		* Corrected cited section numbers, removed citations from the
	abstract, and removed an unused reference		abstract, and removed an unused reference
	* Editorial clarifications and typo fixes		* Editorial clarifications and typo fixes
	-04		-04
End of changes. 15 change blocks.
	9 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.49. The latest version is available from https://github.com/ietf-tools/rfcdiff