Diff: rfc9207.original.xml

	rfc9207.original.xml	rfc9207.xml

	<?xml version="1.0" encoding="utf-8"?>	<?xml version="1.0" encoding="UTF-8"?>

		<!-- draft submitted in xml v3 -->

		<!DOCTYPE rfc [
		<!ENTITY nbsp " ">
		<!ENTITY zwsp "">
		<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
		]>

	<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process or - mmark.miek.nl" -->	<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process or - mmark.miek.nl" -->

	<rfc version="3" ipr="trust200902" docName="draft-ietf-oauth-iss-auth-resp-05" s
	ubmissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/20	<rfc version="3" ipr="trust200902" docName="draft-ietf-oauth-iss-auth-resp-05" n
	01/XInclude" consensus="true">	umber="9207"
		submissionType="IETF" category="std" consensus="true" updates="" obsoletes="" to
		cInclude="true" sortRefs="true" symRefs="true" xml:lang="en" xmlns:xi="http://ww
		w.w3.org/2001/XInclude">

	<front>	<front>

	<title abbrev="oauth-iss-auth-resp">OAuth 2.0 Authorization Server Issuer Identi	<title abbrev="OAuth 2.0 Auth Server ID">OAuth 2.0 Authorization Server Issuer
	fication</title><seriesInfo value="draft-ietf-oauth-iss-auth-resp-05" stream="IE	Identification</title>
	TF" status="standard" name="Internet-Draft"></seriesInfo>	<seriesInfo name="RFC" value="9207"/>
	<author initials="K." surname="Meyer zu Selhausen" fullname="Karsten Meyer zu Se lhausen"><organization>Hackmanit</organization><address><postal><street></street >	<author initials="K." surname="Meyer zu Selhausen" fullname="Karsten Meyer zu Se lhausen"><organization>Hackmanit</organization><address><postal><street></street >
	</postal><email>karsten.meyerzuselhausen@hackmanit.de</email>	</postal><email>karsten.meyerzuselhausen@hackmanit.de</email>
	</address></author>	</address></author>
	<author initials="D." surname="Fett" fullname="Daniel Fett"><organization>yes.co m</organization><address><postal><street></street>	<author initials="D." surname="Fett" fullname="Daniel Fett"><organization>yes.co m</organization><address><postal><street></street>
	</postal><email>mail@danielfett.de</email>	</postal><email>mail@danielfett.de</email>
	</address></author>	</address></author>

	<date/>	<date year="2022" month="February" />
	<area>Security</area>	<area>Security</area>
	<workgroup>Web Authorization Protocol</workgroup>	<workgroup>Web Authorization Protocol</workgroup>
	<keyword>security</keyword>	<keyword>security</keyword>
	<keyword>oauth2</keyword>	<keyword>oauth2</keyword>

	<abstract>	<abstract>

	<t>This document specifies a new parameter <tt>iss</tt> that is used to explicit ly include the issuer identifier of the authorization server in the authorizatio n response of an OAuth authorization flow. The <tt>iss</tt> parameter serves as an effective countermeasure to "mix-up attacks".</t>	<t>This document specifies a new parameter called <tt>iss</tt>. This parameter i s used to explicitly include the issuer identifier of the authorization server i n the authorization response of an OAuth authorization flow. The <tt>iss</tt> pa rameter serves as an effective countermeasure to "mix-up attacks".</t>
	</abstract>	</abstract>

	</front>	</front>

	<middle>	<middle>

	<section anchor="Introduction"><name>Introduction</name>	<section anchor="Introduction"><name>Introduction</name>

	<t>The OAuth authorization framework <xref target="RFC6749"></xref> allows clien	<t>The OAuth 2.0 Authorization Framework <xref target="RFC6749"></xref> allows c
	ts to interact with multiple independent authorization servers under the control	lients to interact with multiple independent authorization servers under the con
	of separate entities.	trol of separate entities.
	Some OAuth grant types utilize the resource owner's user-agent to deliver the au	Some OAuth grant types utilize the resource owner's user agent to deliver the au
	thorization server's response to the OAuth client. One example of this pattern i	thorization server's response to the OAuth client. One example of this pattern i
	s the authorization response of the authorization code grant.</t>	s the authorization response of the authorization code grant.</t>
	<t>The authorization response as specified in Section 4.1.2 of <xref target="RFC	<t>The authorization response as specified in <xref target="RFC6749" section="4.
	6749"></xref> does not contain any information about the identity of the authori	1.2" sectionFormat="of"></xref> does not contain any information about the ident
	zation server which issued the response.	ity of the authorization server that issued the response.
	Therefore, clients receiving a response from the resource owner's user-agent can	Therefore, clients receiving a response from the resource owner's user agent can
	not be sure who initially issued the response and the secrets contained therein.	not be sure who initially issued the response and the secrets contained therein.
	The lack of certainty about the origin of the response enables a class of attac	The lack of certainty about the origin of the response enables a class of attac
	ks called "mix-up attacks".</t>	ks called "mix-up attacks".</t>
	<t>Mix-up attacks are a potential threat to all OAuth clients that interact with	<t>Mix-up attacks are a potential threat to all OAuth clients that interact with
	multiple authorization servers. When at least one of these authorization server	multiple authorization servers. When at least one of these authorization server
	s is under an attacker's control, the attacker can launch a mix-up attack to acq	s is under an attacker's control, the attacker can launch a mix-up attack to acq
	uire authorization codes or access tokens issued by any one of the other authori	uire authorization codes or access tokens issued by any one of the other authori
	zation servers. There are multiple ways in which an attacker can gain control ov	zation servers. There are multiple ways in which an attacker can gain control ov
	er an authorization server supported by the client: For instance, an authorizati	er an authorization server supported by the client; for instance, an authorizati
	on server could become compromised, or the attacker could register their own aut	on server could become compromised, or the attacker could register their own aut
	horization server, for example, using dynamic client registration (<xref target=	horization server, for example, using dynamic client registration <xref target="
	"RFC7591"></xref>).</t>	RFC7591"></xref>.</t>
	<t>OAuth clients that interact with only one authorization server are not vulner	<t>OAuth clients that interact with only one authorization server are not vulner
	able to mix-up attacks. However, when such clients decide to add support for a s	able to mix-up attacks. However, when such clients decide to add support for a s
	econd authorization server in the future they become vulnerable and need to appl	econd authorization server in the future, they become vulnerable and need to app
	y countermeasures to mix-up attacks.</t>	ly countermeasures to mix-up attacks.</t>

	<t>Mix-up attacks aim to steal an authorization code or access token by tricking the client into sending the authorization code or access token to the attacker instead of the honest authorization or resource server. This marks a severe thre at to the confidentiality and integrity of resources whose access is managed wit h OAuth.	<t>Mix-up attacks aim to steal an authorization code or access token by tricking the client into sending the authorization code or access token to the attacker instead of the honest authorization or resource server. This marks a severe thre at to the confidentiality and integrity of resources whose access is managed wit h OAuth.

	A detailed description and different variants of the mix-up attack class can be	A detailed description and different variants of the mix-up attack class can be
	found in Section 4.4 of the OAuth Security Best Current Practice <xref target="I	found in Section <xref target="I-D.ietf-oauth-security-topics" sectionFormat="ba
	-D.ietf-oauth-security-topics"></xref> as well as in the original research first	re" section="4.4"/> of "OAuth 2.0 Security Best Current Practice" <xref target="
	highlighting this attack class, "On the security of modern Single Sign-On	I-D.ietf-oauth-security-topics"/> as well as in the original research first high
	Protocols: Second-Order Vulnerabilities in OpenID Connect" <xref target="ar	lighting this attack class, "On the security of modern Single Sign-On Protocols:
	Xiv.1508.04324"></xref> and "A Comprehensive Formal Security Analysis of OA	Second-Order Vulnerabilities in OpenID Connect" <xref target="arXiv.1508.04324"
	uth 2.0" <xref target="arXiv.1601.01229"></xref>.</t>	/> and "A Comprehensive Formal Security Analysis of OAuth 2.0" <xref target="arX
		iv.1601.01229"/>.</t>

	<t>This document defines a new parameter in the authorization response called <t t>iss</tt>. The <tt>iss</tt> parameter allows the authorization server to includ e its identity in the authorization response explicitly. The client can compare the value of the <tt>iss</tt> parameter to the issuer identifier of the authoriz ation server (e.g., retrieved from its metadata) it believes it is interacting w ith. The <tt>iss</tt> parameter gives the client certainty about the authorizati on server's identity and enables it to send credentials such as authorization co des and access tokens only to the intended recipients.</t>	<t>This document defines a new parameter in the authorization response called <t t>iss</tt>. The <tt>iss</tt> parameter allows the authorization server to includ e its identity in the authorization response explicitly. The client can compare the value of the <tt>iss</tt> parameter to the issuer identifier of the authoriz ation server (e.g., retrieved from its metadata) it believes it is interacting w ith. The <tt>iss</tt> parameter gives the client certainty about the authorizati on server's identity and enables it to send credentials such as authorization co des and access tokens only to the intended recipients.</t>
	<t>The effectiveness of the <tt>iss</tt> parameter against mix-up attacks was an alyzed and formally proven in "A Comprehensive Formal Security Analysis of OAuth 2.0" <xref target="arXiv.1601.01229"></xref>.</t>	<t>The effectiveness of the <tt>iss</tt> parameter against mix-up attacks was an alyzed and formally proven in "A Comprehensive Formal Security Analysis of OAuth 2.0" <xref target="arXiv.1601.01229"></xref>.</t>

	<section anchor="conventions-and-terminology"><name>Conventions and Terminology< /name>	<section anchor="conventions-and-terminology"><name>Conventions and Terminology< /name>

	<t>The key words "MUST", "MUST NOT", "REQUIRED", &	<t>
	quot;SHALL", "SHALL	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"NOT RECOMMENDED",	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	"MAY", and "OPTIONAL" in this document are to be interpreted	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	as	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref	be interpreted as
	> when, and only when, they	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	appear in all capitals, as shown here.</t>	when, and only when, they appear in all capitals, as shown here.
	<t>This specification uses the terms "access token", "authorizati	</t>
	on code", "authorization code grant", "authorization server&
	quot;, "resource server", "authorization response", "gr	<t>This specification uses the terms "access token", "authorizati
	ant type", and "client" defined by the OAuth 2.0 Authorization Fr	on code", "authorization code grant", "authorization server&
	amework <xref target="RFC6749"></xref> and the term "issuer identifier&quot	quot;, "resource server", "authorization response", "gr
	; defined by OAuth 2.0 Authorization Server Metadata <xref target="RFC8414"></xr	ant type", and "client" defined by the OAuth 2.0 Authorization Fr
	ef>.</t>	amework <xref target="RFC6749" format="default"/>. The term "issuer identif
		ier" is defined by OAuth 2.0 Authorization Server Metadata <xref target="RF
		C8414" format="default"/>.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="iss_parameter"><name>Response Parameter <tt>iss</tt></name>	<section anchor="iss_parameter"><name>Response Parameter <tt>iss</tt></name>

	<t>In authorization responses to the client, including error responses, an autho	<t>In authorization responses to the client, including error responses, an autho
	rization server supporting this specification MUST indicate its identity by incl	rization server supporting this specification <bcp14>MUST</bcp14> indicate its i
	uding the <tt>iss</tt> parameter in the response.</t>	dentity by including the <tt>iss</tt> parameter in the response.</t>
	<t>The <tt>iss</tt> parameter value is the issuer identifier of the authorizatio	<t>The <tt>iss</tt> parameter value is the issuer identifier of the authorizatio
	n server which created the authorization response, as defined in <xref target="R	n server that created the authorization response, as defined in <xref target="RF
	FC8414"></xref>. Its value MUST be a URL that uses the "https" scheme	C8414"></xref>. Its value <bcp14>MUST</bcp14> be a URL that uses the "https
	without any query or fragment components.</t>	" scheme without any query or fragment components.</t>

	<section anchor="example-authorization-response"><name>Example Authorization Res ponse</name>	<section anchor="example-authorization-response"><name>Example Authorization Res ponse</name>
	<t>The following example shows an authorization response from the authorization server whose issuer identifier is <tt>https://honest.as.example</tt> (extra line breaks and indentation are for display purposes only):</t>	<t>The following example shows an authorization response from the authorization server whose issuer identifier is <tt>https://honest.as.example</tt> (extra line breaks and indentation are for display purposes only):</t>


	<sourcecode type="http">HTTP/1.1 302 Found	<sourcecode type="http-message">HTTP/1.1 302 Found
	Location: https://client.example/cb?	Location: https://client.example/cb?
	code=x1848ZT64p4IirMPT0R-X3141MFPTuBX-VFL_cvaplMH58	code=x1848ZT64p4IirMPT0R-X3141MFPTuBX-VFL_cvaplMH58
	&state=ZWVlNDBlYzA1NjdkMDNhYjg3ZjUxZjAyNGQzMTM2NzI	&state=ZWVlNDBlYzA1NjdkMDNhYjg3ZjUxZjAyNGQzMTM2NzI
	&iss=https%3A%2F%2Fhonest.as.example	&iss=https%3A%2F%2Fhonest.as.example
	</sourcecode>	</sourcecode>
	</section>	</section>

	<section anchor="example-error-response"><name>Example Error Response</name>	<section anchor="example-error-response"><name>Example Error Response</name>
	<t>The following example shows an error response from the same authorization ser ver (extra line breaks and indentation are for display purposes only):</t>	<t>The following example shows an error response from the same authorization ser ver (extra line breaks and indentation are for display purposes only):</t>


	<sourcecode type="http">HTTP/1.1 302 Found	<sourcecode type="http-message">HTTP/1.1 302 Found
	Location: https://client.example/cb?	Location: https://client.example/cb?
	error=access_denied	error=access_denied
	&state=N2JjNGJhY2JiZjRhYzA3MGJkMzNmMDE5OWJhZmJhZjA	&state=N2JjNGJhY2JiZjRhYzA3MGJkMzNmMDE5OWJhZmJhZjA
	&iss=https%3A%2F%2Fhonest.as.example	&iss=https%3A%2F%2Fhonest.as.example
	</sourcecode>	</sourcecode>
	</section>	</section>


	<section anchor="providing_iss_parameter"><name>Providing the Issuer Identifier	<section anchor="providing_iss_parameter"><name>Providing the Issuer Identifier<
	<tt>iss</tt></name>	/name>
	<t>Authorization servers supporting this specification MUST provide their issuer	<t>Authorization servers supporting this specification <bcp14>MUST</bcp14> provi
	identifier to enable clients to validate the <tt>iss</tt> parameter effectively	de their issuer identifier to enable clients to validate the <tt>iss</tt> parame
	.</t>	ter effectively.</t>

	<t>For authorization servers publishing metadata according to <xref target="RFC8 414"></xref>, the following rules apply:</t>	<t>For authorization servers publishing metadata according to <xref target="RFC8 414"></xref>, the following rules apply:</t>

	<ul>	<ul>

	<li><t>The issuer identifier included in the server's metadata value <tt>issuer< /tt> MUST be identical to the <tt>iss</tt> parameter's value.</t>	<li><t>The issuer identifier included in the server's metadata value <tt>issuer< /tt> <bcp14>MUST</bcp14> be identical to the <tt>iss</tt> parameter's value.</t>
	</li>	</li>

	<li><t>The server MUST indicate its support for the <tt>iss</tt> parameter by se tting the metadata parameter <tt>authorization_response_iss_parameter_supported< /tt>, defined in <xref target="as_metadata"></xref>, to <tt>true</tt>.</t>	<li><t>The server <bcp14>MUST</bcp14> indicate its support for the <tt>iss</tt> parameter by setting the metadata parameter <tt>authorization_response_iss_param eter_supported</tt>, defined in <xref target="as_metadata"></xref>, to <tt>true< /tt>.</t>
	</li>	</li>
	</ul>	</ul>

	<t>Authorization servers MAY additionally provide the issuer identifier to clien ts by any other mechanism which is outside of the scope of this specification.</ t>	<t>Authorization servers <bcp14>MAY</bcp14> additionally provide the issuer iden tifier to clients by any other mechanism, which is outside of the scope of this specification.</t>
	</section>	</section>


	<section anchor="iss_parameter_validation"><name>Validation of the Issuer Identi	<section anchor="iss_parameter_validation"><name>Validating the Issuer Identifie
	fier <tt>iss</tt></name>	r</name>
	<t>Clients that support this specification MUST extract the value of the <tt>iss	<t>Clients that support this specification <bcp14>MUST</bcp14> extract the value
	</tt> parameter from authorization responses they receive if the parameter is pr	of the <tt>iss</tt> parameter from authorization responses they receive if the
	esent. Clients MUST then decode the value from its "application/x-www-form-	parameter is present. Clients <bcp14>MUST</bcp14> then decode the value from its
	urlencoded" form according to <xref target="RFC6749"></xref>, Appendix B, a	"application/x-www-form-urlencoded" form according to <xref target="R
	nd compare the result to the issuer identifier of the authorization server where	FC6749" sectionFormat="of" section="B"></xref> and compare the result to the iss
	the authorization request was sent to. This comparison MUST use simple string c	uer identifier of the authorization server where the authorization request was s
	omparison as defined in Section 6.2.1 of <xref target="RFC3986"></xref>. If the	ent to. This comparison <bcp14>MUST</bcp14> use simple string comparison as defi
	value does not match the expected issuer identifier, clients MUST reject the aut	ned in <xref target="RFC3986" sectionFormat="of" section="6.2.1"></xref>. If the
	horization response and MUST NOT proceed with the authorization grant. For error	value does not match the expected issuer identifier, clients <bcp14>MUST</bcp14
	responses, clients MUST NOT assume that the error originates from the intended	> reject the authorization response and <bcp14>MUST NOT</bcp14> proceed with the
	authorization server.</t>	authorization grant. For error responses, clients <bcp14>MUST NOT</bcp14> assum
	<t>More precisely, clients that interact with authorization servers supporting O	e that the error originates from the intended authorization server.</t>
	Auth metadata <xref target="RFC8414"></xref> MUST compare the <tt>iss</tt> param	<t>More precisely, clients that interact with authorization servers supporting O
	eter value to the <tt>issuer</tt> value in the server's metadata document. If OA	Auth metadata <xref target="RFC8414"></xref> <bcp14>MUST</bcp14> compare the <tt
	uth metadata is not used, clients MUST use deployment-specific ways, for example	>iss</tt> parameter value to the <tt>issuer</tt> value in the server's metadata
	a static configuration, to decide if the returned <tt>iss</tt> value is the exp	document. If OAuth metadata is not used, clients <bcp14>MUST</bcp14> use deploym
	ected value in the current flow (see also <xref target="security_considerations"	ent-specific ways (for example, a static configuration) to decide if the returne
	></xref>).</t>	d <tt>iss</tt> value is the expected value in the current flow (see also <xref t
	<t>If clients interact with both authorization servers supporting this specifica	arget="security_considerations"></xref>).</t>
	tion and authorization servers not supporting this specification, clients MUST r
	etain state about whether each	<t>If clients interact with both authorization servers supporting this specifica
	authorization server supports the <tt>iss</tt> parameter. Clients MUST reject au	tion and authorization servers not supporting this specification,
	thorization responses without the <tt>iss</tt> parameter from authorization serv	clients <bcp14>MUST</bcp14> retain state about whether each
	ers which do support the parameter according to the client's configuration. Clie	authorization server supports the <tt>iss</tt> parameter.
	nts SHOULD discard authorization responses with the <tt>iss</tt> parameter from
	authorization servers which do not indicate their support for the parameter. How	Clients <bcp14>MUST</bcp14> reject authorization responses without the <tt>iss</
	ever, there might be legitimate authorization servers that provide the <tt>iss</	tt> parameter from authorization servers that do support the parameter according
	tt> parameter without indicating their support in their metadata. Local policy o	to the client's configuration. Clients <bcp14>SHOULD</bcp14> discard authorizat
	r configuration can determine whether to accept such responses and specific guid	ion responses with the <tt>iss</tt> parameter from authorization servers that do
	ance is out of scope for this specification.</t>	not indicate their support for the parameter. However, there might be legitimat
	<t>In general, clients that support this specification MAY accept authorization	e authorization servers that provide the <tt>iss</tt> parameter without indicati
	responses that do not contain the <tt>iss</tt> parameter or reject them and excl	ng their support in their metadata. Local policy or configuration can determine
	usively support authorization servers which provide the <tt>iss</tt> parameter i	whether to accept such responses, and specific guidance is out of scope for this
	n the authorization response. Local policy or configuration can determine when t	specification.</t>
	o accept such responses and specific guidance is out of scope for this specifica	<t>In general, clients that support this specification <bcp14>MAY</bcp14> accept
	tion.</t>	authorization responses that do not contain the <tt>iss</tt> parameter or rejec
	<t>In OpenID Connect <xref target="OIDC.Core"></xref> flows where an ID Token is	t them and exclusively support authorization servers that provide the <tt>iss</t
	returned from the authorization endpoint, the value in the <tt>iss</tt> paramet	t> parameter in the authorization response. Local policy or configuration can de
	er MUST always be identical to the <tt>iss</tt> claim in the ID Token.</t>	termine when to accept such responses, and specific guidance is out of scope for
	<t>Section 4.1.2 of <xref target="RFC6749"></xref> already mandates that clients	this specification.</t>
	that do not support this specification MUST ignore the unrecognized <tt>iss</tt	<t>In OpenID Connect <xref target="OIDC.Core"></xref> flows where an ID Token is
	> parameter.</t>	returned from the authorization endpoint, the value in the <tt>iss</tt> paramet
	<t>Note: The "JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)&	er <bcp14>MUST</bcp14> always be identical to the <tt>iss</tt> claim in the ID T
	quot; <xref target="JARM"></xref> defines a mechanism that conveys all authoriza	oken.</t>
	tion response parameters in a JWT. This JWT contains an <tt>iss</tt> claim that
	provides the same protection if it is validated as described in <xref target="is	<t><xref target="RFC6749" sectionFormat="of" section="4.1.2"></xref> already man
	s_parameter_validation"></xref>. Therefore, an additional <tt>iss</tt> parameter	dates that clients that do not support this specification <bcp14>MUST</bcp14> ig
	outside the JWT is not necessary when JARM is used.</t>	nore the unrecognized <tt>iss</tt> parameter.</t>

		<aside>
		<t>Note: The "JWT Secured Authorization Response Mode for OAuth 2.0 (JARM
		)" <xref target="JARM"></xref> defines a mechanism that conveys all authori
		zation response parameters in a JSON Web Token (JWT). This JWT contains an <tt>i
		ss</tt> claim that provides the same protection if it is validated as described
		in <xref target="iss_parameter_validation"></xref>. Therefore, an additional <tt
		>iss</tt> parameter outside the JWT is not necessary when JARM is used.</t>
		</aside>

	</section>	</section>
	</section>	</section>

	<section anchor="as_metadata"><name>Authorization Server Metadata</name>	<section anchor="as_metadata"><name>Authorization Server Metadata</name>
	<t>The following parameter for the authorization server metadata <xref target="R FC8414"></xref> is introduced to signal the authorization server's support for t his specification:</t>	<t>The following parameter for the authorization server metadata <xref target="R FC8414"></xref> is introduced to signal the authorization server's support for t his specification:</t>

	<dl>	<dl>

	<dt><tt>authorization_response_iss_parameter_supported</tt></dt>	<dt><tt>authorization_response_iss_parameter_supported</tt>:</dt>
	<dd><t>Boolean parameter indicating whether the authorization server provides th e <tt>iss</tt> parameter in the authorization response as defined in <xref targe t="iss_parameter"></xref>. If omitted, the default value is false.</t>	<dd><t>Boolean parameter indicating whether the authorization server provides th e <tt>iss</tt> parameter in the authorization response as defined in <xref targe t="iss_parameter"></xref>. If omitted, the default value is false.</t>
	</dd>	</dd>
	</dl>	</dl>
	</section>	</section>

	<section anchor="security_considerations"><name>Security Considerations</name>	<section anchor="security_considerations"><name>Security Considerations</name>

	<t>Clients MUST validate the <tt>iss</tt> parameter precisely as described in <x	<t>Clients <bcp14>MUST</bcp14> validate the <tt>iss</tt> parameter precisely as
	ref target="iss_parameter_validation"></xref> and MUST NOT allow multiple author	described in <xref target="iss_parameter_validation"></xref> and <bcp14>MUST NOT
	ization servers to use the same issuer identifier. In particular, when authoriza	</bcp14> allow multiple authorization servers to use the same issuer identifier.
	tion server details can be manually configured in the client, the client MUST en	In particular, when authorization server details can be manually configured in
	sure that the accepted <tt>iss</tt> values are unique for each authorization ser	the client, the client <bcp14>MUST</bcp14> ensure that the accepted <tt>iss</tt>
	ver.</t>	values are unique for each authorization server.</t>
	<t>The <tt>iss</tt> parameter enables a client to decide if an authorization ser	<t>The <tt>iss</tt> parameter enables a client to decide if an authorization ser
	ver "expects" to be used in an OAuth flow together with a certain toke	ver "expects" to be used in an OAuth flow together with a certain toke
	n endpoint and potentially other endpoints, like the userinfo endpoint (<xref ta	n endpoint and potentially other endpoints, like the userinfo endpoint <xref tar
	rget="OIDC.Core"></xref>). When OAuth metadata is used, the <tt>iss</tt> paramet	get="OIDC.Core"></xref>. When OAuth metadata is used, the <tt>iss</tt> parameter
	er identifies the issuer and therefore the respective OAuth metadata document wh	identifies the issuer and therefore the respective OAuth metadata document that
	ich points to the other endpoints. When OAuth metadata is not used, the client c	points to the other endpoints. When OAuth metadata is not used, the client can
	an use, for example, a statically configured expected <tt>iss</tt> value for eac	use, for example, a statically configured expected <tt>iss</tt> value for each c
	h configured authorization server.</t>	onfigured authorization server.</t>
	<t>The issuer identifier contained in the authorization response is not cryptogr	<t>The issuer identifier contained in the authorization response is not cryptogr
	aphically protected against tampering. In general, mechanisms such as JWTs (as s	aphically protected against tampering. In general, mechanisms such as JWTs (as s
	pecified in JARM <xref target="JARM"></xref>) could be used to protect the integ	pecified in <xref target="JARM"></xref>) could be used to protect the integrity
	rity of the authorization response. However, in mix-up attacks, the client gener	of the authorization response. However, in mix-up attacks, the client generally
	ally receives the authorization response from an uncompromised authorization ser	receives the authorization response from an uncompromised authorization server.
	ver. If an attacker can tamper this authorization response before it is received	If an attacker can tamper with this authorization response before it is received
	by the client, the attacker would also have direct access to the authorization	by the client, the attacker would also have direct access to the authorization
	code. The attacker does not need to execute a mix-up attack to steal the authori	code. The attacker does not need to execute a mix-up attack to steal the authori
	zation code. Therefore, integrity protection for the authorization response is n	zation code. Therefore, integrity protection for the authorization response is n
	ot necessary to defend against mix-up attacks.</t>	ot necessary to defend against mix-up attacks.</t>
	<t>There are also alternative countermeasures to mix-up attacks. When an authori	<t>There are also alternative countermeasures to mix-up attacks. When an authori
	zation response already includes an authorization server's issuer identifier by	zation response already includes an authorization server's issuer identifier by
	other means, and this identifier is checked as laid out in <xref target="iss_par	other means and this identifier is checked as laid out in <xref target="iss_para
	ameter_validation"></xref>, the use and verification of the <tt>iss</tt> paramet	meter_validation"></xref>, the use and verification of the <tt>iss</tt> paramete
	er is not necessary and MAY be omitted. This is the case when OpenID Connect res	r is not necessary and <bcp14>MAY</bcp14> be omitted.
	ponse types that return an ID token from the authorization endpoint (e.g., <tt>r	For example, this is the case when OpenID Connect response types that return an
	esponse_type=code id_token</tt>) or JARM response mode are used, for example. Ho	ID Token from the authorization endpoint (e.g., <tt>response_type=code id_token<
	wever, if a client receives an authorization response that contains multiple iss	/tt>) or <xref target="JARM"></xref> are used.
	uer identifiers, the client MUST reject the response if these issuer identifiers	However, if a client receives an authorization response that contains multiple i
	do not match. The details of alternative countermeasures are outside of the sco	ssuer identifiers, the client <bcp14>MUST</bcp14> reject the response if these i
	pe of this specification.</t>	ssuer identifiers do not match. The details of alternative countermeasures are o
	<t>Mix-up attacks are only relevant to clients that interact with multiple autho	utside of the scope of this specification.</t>
	rization servers. However, clients interacting with only one authorization serve	<t>Mix-up attacks are only relevant to clients that interact with multiple autho
	r might add support for a second authorization server in the future. By supporti	rization servers. However, clients interacting with only one authorization serve
	ng multiple authorization servers they become vulnerable to mix-up attacks and n	r might add support for a second authorization server in the future. By supporti
	eed to apply countermeasures.</t>	ng multiple authorization servers, they become vulnerable to mix-up attacks and
		need to apply countermeasures.</t>
	</section>	</section>

	<section anchor="iana_considerations"><name>IANA Considerations</name>	<section anchor="iana_considerations"><name>IANA Considerations</name>

	<section anchor="oauth-authorization-server-metadata"><name>OAuth Authorization Server Metadata</name>	<section anchor="oauth-authorization-server-metadata"><name>OAuth Authorization Server Metadata</name>

	<t>This specification adds the following values to the IANA "OAuth Authoriz ation Server Metadata" registry of <xref target="IANA.OAuth.Parameters"></x ref> established by <xref target="RFC8414"></xref>.</t>	<t>IANA has registered the following values in the "OAuth Authorization Ser ver Metadata" registry of <xref target="IANA.OAuth.Parameters"></xref> esta blished by <xref target="RFC8414"></xref>.</t>


	<dl spacing="compact">	<dl newline="false" spacing="compact">
	<dt>Metadata Name:</dt>	<dt>Metadata Name:</dt>

	<dd><t><tt>authorization_response_iss_parameter_supported</tt></t>	<dd><tt>authorization_response_iss_parameter_supported</tt>
	</dd>	</dd>
	<dt>Metadata Description:</dt>	<dt>Metadata Description:</dt>

	<dd><t>Boolean value indicating whether the authorization server provides the <t t>iss</tt> parameter in the authorization response.</t>	<dd>Boolean value indicating whether the authorization server provides the <tt>i ss</tt> parameter in the authorization response.
	</dd>	</dd>
	<dt>Change Controller:</dt>	<dt>Change Controller:</dt>

	<dd><t>IETF</t>	<dd>IETF
	</dd>	</dd>
	<dt>Specification Document(s):</dt>	<dt>Specification Document(s):</dt>

	<dd><t><xref target="as_metadata"></xref> of [[ this document ]]</t>	<dd><xref target="as_metadata"></xref> of RFC 9207
	</dd>	</dd>
	</dl>	</dl>
	</section>	</section>

	<section anchor="oauth-parameters-registration"><name>OAuth Parameters Registrat ion</name>	<section anchor="oauth-parameters-registration"><name>OAuth Parameters Registrat ion</name>

	<t>This specification updates the <tt>iss</tt> entry in the IANA "OAuth Par ameters" registry of <xref target="IANA.OAuth.Parameters"></xref> establish ed by <xref target="RFC6749"></xref>.</t>	<t>IANA has updated the <tt>iss</tt> entry to appear as follows in the "OAu th Parameters" registry of <xref target="IANA.OAuth.Parameters"></xref> est ablished by <xref target="RFC6749"></xref>.</t>


	<dl spacing="compact">	<dl newline="false" spacing="compact">
	<dt>Parameter name:</dt>	<dt>Parameter name:</dt>

	<dd><t><tt>iss</tt></t>	<dd><tt>iss</tt>
	</dd>	</dd>
	<dt>Parameter usage location:</dt>	<dt>Parameter usage location:</dt>

	<dd><t>authorization request, authorization response</t>	<dd>authorization request, authorization response
	</dd>	</dd>
	<dt>Change Controller:</dt>	<dt>Change Controller:</dt>

	<dd><t>IETF</t>	<dd>IETF
	</dd>	</dd>
	<dt>Specification Document(s):</dt>	<dt>Specification Document(s):</dt>

	<dd><t><xref target="iss_parameter"></xref> of [[ this document ]], <xref target ="RFC9101"></xref>, and Section 4.1.1 of <xref target="RFC7519"></xref>.</t>	<dd><xref target="iss_parameter"></xref> of RFC 9207, <xref target="RFC9101"></x ref>, and <xref target="RFC7519" sectionFormat="of" section="4.1.1"></xref>.
	</dd>	</dd>
	</dl>	</dl>
	</section>	</section>
	</section>	</section>

	</middle>	</middle>

	<back>	<back>


		<displayreference target="I-D.ietf-oauth-security-topics" to="OAUTH-SECURITY-TOP
		ICS"/>
		<references><name>References</name>
	<references><name>Normative References</name>	<references><name>Normative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8414. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8414. xml"/>
	</references>	</references>
	<references><name>Informative References</name>	<references><name>Informative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9101. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9101. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519. xml"/>


		<!-- [I-D.ietf-oauth-security-topics] IESG state I-D Exists -->

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i etf-oauth-security-topics.xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i etf-oauth-security-topics.xml"/>


	<reference anchor="arXiv.1601.01229" target="https://arxiv.org/abs/1601.01229">	<reference anchor="arXiv.1601.01229" target="https://arxiv.org/abs/1601.01229">
	<front>	<front>
	<title>A Comprehensive Formal Security Analysis of OAuth 2.0</title>	<title>A Comprehensive Formal Security Analysis of OAuth 2.0</title>
	<author fullname="Daniel Fett" initials="D." surname="Fett">	<author fullname="Daniel Fett" initials="D." surname="Fett">
	<organization>University of Trier</organization>	<organization>University of Trier</organization>
	</author>	</author>
	<author fullname="Ralf Kuesters" initials="R." surname="Kuesters">	<author fullname="Ralf Kuesters" initials="R." surname="Kuesters">
	<organization>University of Trier</organization>	<organization>University of Trier</organization>
	</author>	</author>
	<author fullname="Guido Schmitz" initials="G." surname="Schmitz">	<author fullname="Guido Schmitz" initials="G." surname="Schmitz">
	<organization>University of Trier</organization>	<organization>University of Trier</organization>
	</author>	</author>

	<date year="2016" month="Jan" day="6"></date>	<date year="2016" month="January"></date>
	</front>	</front>

		<seriesInfo name="DOI" value="10.1145/2976749.2978385"/>
	</reference>	</reference>


	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7591. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7591. xml"/>


	<reference anchor="IANA.OAuth.Parameters" target="https://www.iana.org/assignmen ts/oauth-parameters">	<reference anchor="IANA.OAuth.Parameters" target="https://www.iana.org/assignmen ts/oauth-parameters">
	<front>	<front>
	<title>OAuth Parameters</title>	<title>OAuth Parameters</title>
	<author>	<author>
	<organization>IANA</organization>	<organization>IANA</organization>
	</author>	</author>
	<date></date>	<date></date>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="OIDC.Core" target="https://openid.net/specs/openid-connect-co re-1_0.html">	<reference anchor="OIDC.Core" target="https://openid.net/specs/openid-connect-co re-1_0.html">
	<front>	<front>
	<title>OpenID Connect Core 1.0 incorporating errata set 1</title>	<title>OpenID Connect Core 1.0 incorporating errata set 1</title>
	<author fullname="Nat Sakimura" initials="N." surname="Sakimura">	<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	<organization>NRI</organization>	<organization>NRI</organization>
	</author>	</author>
	<author fullname="John Bradley" initials="J." surname="Bradley">	<author fullname="John Bradley" initials="J." surname="Bradley">
	<organization>Ping Identity</organization>	<organization>Ping Identity</organization>
	</author>	</author>
	<author fullname="Mike Jones" initials="M." surname="Jones">	<author fullname="Mike Jones" initials="M." surname="Jones">
	<organization>Microsoft</organization>	<organization>Microsoft</organization>
	</author>	</author>
	<author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">	<author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
	<organization>Google</organization>	<organization>Google</organization>
	</author>	</author>
	<author fullname="Chuck Mortimore" initials="C." surname="Mortimore">	<author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
	<organization>Salesforce</organization>	<organization>Salesforce</organization>
	</author>	</author>

	<date year="2014" month="Nov" day="8"></date>	<date year="2014" month="Nov"></date>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="JARM" target="https://openid.net/specs/openid-financial-api-j arm.html">	<reference anchor="JARM" target="https://openid.net/specs/openid-financial-api-j arm.html">
	<front>	<front>
	<title>Financial-grade API: JWT Secured Authorization Response Mode for OAut h 2.0 (JARM)</title>	<title>Financial-grade API: JWT Secured Authorization Response Mode for OAut h 2.0 (JARM)</title>
	<author fullname="Torsten Lodderstedt" initials="T." surname="Lodderstedt">	<author fullname="Torsten Lodderstedt" initials="T." surname="Lodderstedt">
	<organization>Yes</organization>	<organization>Yes</organization>
	</author>	</author>
	<author fullname="Brian Campbell" initials="B." surname="Campbell">	<author fullname="Brian Campbell" initials="B." surname="Campbell">
	<organization>Ping</organization>	<organization>Ping</organization>
	</author>	</author>

	<date year="2018" month="Oct" day="17"></date>	<date year="2018" month="Oct"></date>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="arXiv.1508.04324" target="https://arxiv.org/abs/1508.04324">	<reference anchor="arXiv.1508.04324" target="https://arxiv.org/abs/1508.04324">
	<front>	<front>
	<title>On the security of modern Single Sign-On Protocols: Second-Order Vuln erabilities in OpenID Connect</title>	<title>On the security of modern Single Sign-On Protocols: Second-Order Vuln erabilities in OpenID Connect</title>
	<author fullname="Christian Mainka" initials="C." surname="Mainka">	<author fullname="Christian Mainka" initials="C." surname="Mainka">
	<organization>Ruhr University Bochum</organization>	<organization>Ruhr University Bochum</organization>
	</author>	</author>
	<author fullname="Vladislav Mladenov" initials="V." surname="Mladenov">	<author fullname="Vladislav Mladenov" initials="V." surname="Mladenov">
	<organization>Ruhr University Bochum</organization>	<organization>Ruhr University Bochum</organization>
	</author>	</author>
	<author fullname="Jörg Schwenk" initials="J." surname="Schwenk">	<author fullname="Jörg Schwenk" initials="J." surname="Schwenk">
	<organization>Ruhr University Bochum</organization>	<organization>Ruhr University Bochum</organization>
	</author>	</author>

	<date year="2015" month="Aug" day="18"></date>	<date year="2015" month="August"></date>
	</front>	</front>
	</reference>	</reference>
	</references>	</references>

		</references>
	<section anchor="Acknowledgements"><name>Acknowledgements</name>	<section numbered="false" anchor="Acknowledgements"><name>Acknowledgements</name
		>
	<t>We would like to thank	<t>We would like to thank

	Brian Campbell,	<contact fullname="Brian Campbell"/>,
	Roman Danyliw,	<contact fullname="Roman Danyliw"/>,
	Vladimir Dzhuvinov,	<contact fullname="Vladimir Dzhuvinov"/>,
	Joseph Heenan,	<contact fullname="Joseph Heenan"/>,
	Takahiko Kawasaki,	<contact fullname="Takahiko Kawasaki"/>,
	Torsten Lodderstedt,	<contact fullname="Torsten Lodderstedt"/>,
	Christian Mainka,	<contact fullname="Christian Mainka"/>,
	Vladislav Mladenov,	<contact fullname="Vladislav Mladenov"/>,
	Warren Parad,	<contact fullname="Warren Parad"/>,
	Aaron Parecki,	<contact fullname="Aaron Parecki"/>,
	and	and

	Rifaat Shekh-Yusef	<contact fullname="Rifaat Shekh-Yusef"/>
	for their valuable feedback on this document.</t>	for their valuable feedback on this document.</t>
	</section>	</section>


	<section anchor="document-history"><name>Document History</name>

	<artwork>[[ To be removed from the final specification ]]

	-05 [[ Working Group Draft ]]
	* Changed reference to OAuth Security Best Current Practices from normative to
	informative

	-04 [[ Working Group Draft ]]
	* Incorporated feedback from Lars Eggert
	* Incorporated feedback from Francesca Palombini (IANA registrations)
	* Incorporated feedback from Benjamin Kaduk

	-03 [[ Working Group Draft ]]
	* Incorporated feedback from AD review
	* Incorporated feedback from artart and secdir reviews

	-02 [[ Working Group Draft ]]
	* Incorporated feedback from shepherd review
	* Changed SHOULD to MUST (clients MUST store which AS support `iss` parameter)
	* Added note for clients receiving unexpected `iss` parameter
	* Editorial changes

	-01 [[ Working Group Draft ]]
	* Incorporated WG feedback
	* Changed title of the draft to make it shorter
	* Clarified mix-up attacks in introduction
	* Improved note on JARM in validation section

	-00 [[ Working Group Draft ]]
	* Working group draft

	-02
	* Incorporated WG feedback
	* Clarifications for unique issuer identifier
	* Clarifications when multiple issuer identifier could be present
	* Added note that iss parameter MUST NOT be used with JARM
	* Added note on error responses and example for error response
	* Editorial changes

	-01

	* Incorporated first WG feedback
	* Clarifications for use with OIDC
	* Added note that clients supporting just one AS are not vulnerable
	* Renamed metadata parameter
	* Various editorial changes

	-00

	* initial draft
	</artwork>
	</section>

	</back>	</back>

	</rfc>	</rfc>

End of changes. 47 change blocks.
	249 lines changed or deleted	240 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/