wdiff rfc9207.original.xml rfc9207.xml

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

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

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

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

<rfc version="3" ipr="trust200902" docName="draft-ietf-oauth-iss-auth-resp-05" number="9207"
submissionType="IETF" category="std" consensus="true" updates="" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" consensus="true"> xmlns:xi="http://www.w3.org/2001/XInclude">

<front>
  <title abbrev="oauth-iss-auth-resp">OAuth abbrev="OAuth 2.0 Auth Server ID">OAuth 2.0 Authorization Server Issuer Identification</title><seriesInfo value="draft-ietf-oauth-iss-auth-resp-05" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo> Identification</title>
  <seriesInfo name="RFC" value="9207"/>
<author initials="K." surname="Meyer zu Selhausen" fullname="Karsten Meyer zu Selhausen"><organization>Hackmanit</organization><address><postal><street></street>
</postal><email>karsten.meyerzuselhausen@hackmanit.de</email>
</address></author>
<author initials="D." surname="Fett" fullname="Daniel Fett"><organization>yes.com</organization><address><postal><street></street>
</postal><email>mail@danielfett.de</email>
</address></author>
<date/>
<date year="2022" month="February" />
<area>Security</area>
<workgroup>Web Authorization Protocol</workgroup>
<keyword>security</keyword>
<keyword>oauth2</keyword>

<abstract>
<t>This document specifies a new parameter <tt>iss</tt> that called <tt>iss</tt>. This parameter is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The <tt>iss</tt> parameter serves as an effective countermeasure to &quot;mix-up attacks&quot;.</t>
</abstract>

</front>

<middle>

<section anchor="Introduction"><name>Introduction</name>
<t>The OAuth authorization framework 2.0 Authorization Framework <xref target="RFC6749"></xref> allows clients to interact with multiple independent authorization servers under the control of separate entities.
Some OAuth grant types utilize the resource owner's user-agent user agent to deliver the authorization server's response to the OAuth client. One example of this pattern is the authorization response of the authorization code grant.</t>
<t>The authorization response as specified in Section 4.1.2 of <xref target="RFC6749"></xref> target="RFC6749" section="4.1.2" sectionFormat="of"></xref> does not contain any information about the identity of the authorization server which that issued the response.
Therefore, clients receiving a response from the resource owner's user-agent user agent cannot 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 attacks called &quot;mix-up attacks&quot;.</t>
<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 servers is under an attacker's control, the attacker can launch a mix-up attack to acquire authorization codes or access tokens issued by any one of the other authorization servers. There are multiple ways in which an attacker can gain control over an authorization server supported by the client: For client; for instance, an authorization server could become compromised, or the attacker could register their own authorization server, for example, using dynamic client registration (<xref target="RFC7591"></xref>).</t> <xref target="RFC7591"></xref>.</t>
<t>OAuth clients that interact with only one authorization server are not vulnerable to mix-up attacks. However, when such clients decide to add support for a second authorization server in the future future, they become vulnerable and need to apply 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 threat to the confidentiality and integrity of resources whose access is managed with OAuth.
A detailed description and different variants of the mix-up attack class can be found in Section 4.4 <xref target="I-D.ietf-oauth-security-topics" sectionFormat="bare" section="4.4"/> of the OAuth "OAuth 2.0 Security Best Current Practice Practice" <xref target="I-D.ietf-oauth-security-topics"></xref> target="I-D.ietf-oauth-security-topics"/> as well as in the original research first highlighting this attack class, &quot;On "On the security of modern Single Sign-On Protocols: Second-Order Vulnerabilities in OpenID Connect&quot; Connect" <xref target="arXiv.1508.04324"></xref> target="arXiv.1508.04324"/> and &quot;A "A Comprehensive Formal Security Analysis of OAuth 2.0&quot; 2.0" <xref target="arXiv.1601.01229"></xref>.</t> target="arXiv.1601.01229"/>.</t>

<t>This document defines a new parameter in the authorization response called <tt>iss</tt>. The <tt>iss</tt> parameter allows the authorization server to include 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 authorization server (e.g., retrieved from its metadata) it believes it is interacting with. The <tt>iss</tt> parameter gives the client certainty about the authorization server's identity and enables it to send credentials such as authorization codes and access tokens only to the intended recipients.</t>
<t>The effectiveness of the <tt>iss</tt> parameter against mix-up attacks was analyzed and formally proven in &quot;A Comprehensive Formal Security Analysis of OAuth 2.0&quot; <xref target="arXiv.1601.01229"></xref>.</t>

<section anchor="conventions-and-terminology"><name>Conventions and Terminology</name>
<t>The
        <t>
    The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL
NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;,
&quot;MAY&quot;, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and &quot;OPTIONAL&quot; "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"></xref> target="RFC2119"/> <xref target="RFC8174"></xref> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

<t>This specification uses the terms &quot;access token&quot;, &quot;authorization code&quot;, &quot;authorization code grant&quot;, &quot;authorization server&quot;, &quot;resource server&quot;, &quot;authorization response&quot;, &quot;grant type&quot;, and &quot;client&quot; defined by the OAuth 2.0 Authorization Framework <xref target="RFC6749"></xref> and the target="RFC6749" format="default"/>. The term &quot;issuer identifier&quot; is defined by OAuth 2.0 Authorization Server Metadata <xref target="RFC8414"></xref>.</t> target="RFC8414" format="default"/>.</t>
</section>
</section>

<section anchor="iss_parameter"><name>Response Parameter <tt>iss</tt></name>
<t>In authorization responses to the client, including error responses, an authorization server supporting this specification MUST <bcp14>MUST</bcp14> indicate its identity by including the <tt>iss</tt> parameter in the response.</t>
<t>The <tt>iss</tt> parameter value is the issuer identifier of the authorization server which that created the authorization response, as defined in <xref target="RFC8414"></xref>. Its value MUST <bcp14>MUST</bcp14> be a URL that uses the &quot;https&quot; scheme without any query or fragment components.</t>

<section anchor="example-authorization-response"><name>Example Authorization Response</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>

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

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

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

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

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

<ul>
<li><t>The issuer identifier included in the server's metadata value <tt>issuer</tt> MUST <bcp14>MUST</bcp14> be identical to the <tt>iss</tt> parameter's value.</t>
</li>
<li><t>The server MUST <bcp14>MUST</bcp14> indicate its support for the <tt>iss</tt> parameter by setting the metadata parameter <tt>authorization_response_iss_parameter_supported</tt>, defined in <xref target="as_metadata"></xref>, to <tt>true</tt>.</t>
</li>
</ul>
<t>Authorization servers MAY <bcp14>MAY</bcp14> additionally provide the issuer identifier to clients by any other mechanism mechanism, which is outside of the scope of this specification.</t>
</section>

<section anchor="iss_parameter_validation"><name>Validation of anchor="iss_parameter_validation"><name>Validating the Issuer Identifier <tt>iss</tt></name> Identifier</name>
<t>Clients that support this specification MUST <bcp14>MUST</bcp14> extract the value of the <tt>iss</tt> parameter from authorization responses they receive if the parameter is present. Clients MUST <bcp14>MUST</bcp14> then decode the value from its &quot;application/x-www-form-urlencoded&quot; form according to <xref target="RFC6749"></xref>, Appendix B, target="RFC6749" sectionFormat="of" section="B"></xref> and compare the result to the issuer identifier of the authorization server where the authorization request was sent to. This comparison MUST <bcp14>MUST</bcp14> use simple string comparison as defined in Section 6.2.1 of <xref target="RFC3986"></xref>. target="RFC3986" sectionFormat="of" section="6.2.1"></xref>. If the value does not match the expected issuer identifier, clients MUST <bcp14>MUST</bcp14> reject the authorization response and MUST NOT <bcp14>MUST NOT</bcp14> proceed with the authorization grant. For error responses, clients MUST NOT <bcp14>MUST NOT</bcp14> assume that the error originates from the intended authorization server.</t>
<t>More precisely, clients that interact with authorization servers supporting OAuth metadata <xref target="RFC8414"></xref> MUST <bcp14>MUST</bcp14> compare the <tt>iss</tt> parameter value to the <tt>issuer</tt> value in the server's metadata document. If OAuth metadata is not used, clients MUST <bcp14>MUST</bcp14> use deployment-specific ways, for example ways (for example, a static configuration, configuration) to decide if the returned <tt>iss</tt> value is the expected value in the current flow (see also <xref target="security_considerations"></xref>).</t>

<t>If clients interact with both authorization servers supporting this specification and authorization servers not supporting this specification,
clients MUST <bcp14>MUST</bcp14> retain state about whether each
authorization server supports the <tt>iss</tt> parameter.

Clients MUST <bcp14>MUST</bcp14> reject authorization responses without the <tt>iss</tt> parameter from authorization servers which that do support the parameter according to the client's configuration. Clients SHOULD <bcp14>SHOULD</bcp14> discard authorization responses with the <tt>iss</tt> parameter from authorization servers which that do not indicate their support for the parameter. However, there might be legitimate authorization servers that provide the <tt>iss</tt> parameter without indicating their support in their metadata. Local policy or configuration can determine whether to accept such responses responses, and specific guidance is out of scope for this specification.</t>
<t>In general, clients that support this specification MAY <bcp14>MAY</bcp14> accept authorization responses that do not contain the <tt>iss</tt> parameter or reject them and exclusively support authorization servers which that provide the <tt>iss</tt> parameter in the authorization response. Local policy or configuration can determine when to accept such responses responses, and specific guidance is out of scope for this specification.</t>
<t>In OpenID Connect <xref target="OIDC.Core"></xref> flows where an ID Token is returned from the authorization endpoint, the value in the <tt>iss</tt> parameter MUST <bcp14>MUST</bcp14> always be identical to the <tt>iss</tt> claim in the ID Token.</t>
<t>Section 4.1.2 of <xref target="RFC6749"></xref>

<t><xref target="RFC6749" sectionFormat="of" section="4.1.2"></xref> already mandates that clients that do not support this specification MUST <bcp14>MUST</bcp14> ignore the unrecognized <tt>iss</tt> parameter.</t>

<aside>
  <t>Note: The &quot;JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)&quot; <xref target="JARM"></xref> defines a mechanism that conveys all authorization response parameters in a JWT. JSON Web Token (JWT). This JWT contains an <tt>iss</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 anchor="as_metadata"><name>Authorization Server Metadata</name>
<t>The following parameter for the authorization server metadata <xref target="RFC8414"></xref> is introduced to signal the authorization server's support for this specification:</t>

<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 the <tt>iss</tt> parameter in the authorization response as defined in <xref target="iss_parameter"></xref>. If omitted, the default value is false.</t>
</dd>
</dl>
</section>

<section anchor="security_considerations"><name>Security Considerations</name>
<t>Clients MUST <bcp14>MUST</bcp14> validate the <tt>iss</tt> parameter precisely as described in <xref target="iss_parameter_validation"></xref> and MUST NOT <bcp14>MUST NOT</bcp14> allow multiple authorization servers to use the same issuer identifier. In particular, when authorization server details can be manually configured in the client, the client MUST <bcp14>MUST</bcp14> ensure that the accepted <tt>iss</tt> values are unique for each authorization server.</t>
<t>The <tt>iss</tt> parameter enables a client to decide if an authorization server &quot;expects&quot; to be used in an OAuth flow together with a certain token endpoint and potentially other endpoints, like the userinfo endpoint (<xref target="OIDC.Core"></xref>). <xref target="OIDC.Core"></xref>. When OAuth metadata is used, the <tt>iss</tt> parameter identifies the issuer and therefore the respective OAuth metadata document which that points to the other endpoints. When OAuth metadata is not used, the client can use, for example, a statically configured expected <tt>iss</tt> value for each configured authorization server.</t>
<t>The issuer identifier contained in the authorization response is not cryptographically protected against tampering. In general, mechanisms such as JWTs (as specified in JARM <xref target="JARM"></xref>) could be used to protect the integrity of the authorization response. However, in mix-up attacks, the client generally receives the authorization response from an uncompromised authorization server. 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 code. The attacker does not need to execute a mix-up attack to steal the authorization code. Therefore, integrity protection for the authorization response is not necessary to defend against mix-up attacks.</t>
<t>There are also alternative countermeasures to mix-up attacks. When an authorization response already includes an authorization server's issuer identifier by other means, means and this identifier is checked as laid out in <xref target="iss_parameter_validation"></xref>, the use and verification of the <tt>iss</tt> parameter is not necessary and MAY <bcp14>MAY</bcp14> be omitted. This
For example, this is the case when OpenID Connect response types that return an ID token Token from the authorization endpoint (e.g., <tt>response_type=code id_token</tt>) or JARM response mode <xref target="JARM"></xref> are used, for example. used.
However, if a client receives an authorization response that contains multiple issuer identifiers, the client MUST <bcp14>MUST</bcp14> reject the response if these issuer identifiers do not match. The details of alternative countermeasures are outside of the scope of this specification.</t>
<t>Mix-up attacks are only relevant to clients that interact with multiple authorization servers. However, clients interacting with only one authorization server might add support for a second authorization server in the future. By supporting multiple authorization servers servers, they become vulnerable to mix-up attacks and need to apply countermeasures.</t>
</section>

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

<section anchor="oauth-authorization-server-metadata"><name>OAuth Authorization Server Metadata</name>
<t>This specification adds
<t>IANA has registered the following values to in the IANA &quot;OAuth Authorization Server Metadata&quot; registry of <xref target="IANA.OAuth.Parameters"></xref> established by <xref target="RFC8414"></xref>.</t>

<dl newline="false" spacing="compact">
<dt>Metadata Name:</dt>
<dd><t><tt>authorization_response_iss_parameter_supported</tt></t>
<dd><tt>authorization_response_iss_parameter_supported</tt>
</dd>
<dt>Metadata Description:</dt>
<dd><t>Boolean
<dd>Boolean value indicating whether the authorization server provides the <tt>iss</tt> parameter in the authorization response.</t> response.
</dd>
<dt>Change Controller:</dt>
<dd><t>IETF</t>
<dd>IETF
</dd>
<dt>Specification Document(s):</dt>
<dd><t><xref
<dd><xref target="as_metadata"></xref> of [[ this document ]]</t> RFC 9207
</dd>
</dl>
</section>

<section anchor="oauth-parameters-registration"><name>OAuth Parameters Registration</name>
<t>This specification updates
<t>IANA has updated the <tt>iss</tt> entry to appear as follows in the IANA &quot;OAuth Parameters&quot; registry of <xref target="IANA.OAuth.Parameters"></xref> established by <xref target="RFC6749"></xref>.</t>

<dl newline="false" spacing="compact">
<dt>Parameter name:</dt>
<dd><t><tt>iss</tt></t>
<dd><tt>iss</tt>
</dd>
<dt>Parameter usage location:</dt>
<dd><t>authorization
<dd>authorization request, authorization response</t> response
</dd>
<dt>Change Controller:</dt>
<dd><t>IETF</t>
<dd>IETF
</dd>
<dt>Specification Document(s):</dt>
<dd><t><xref
<dd><xref target="iss_parameter"></xref> of [[ this document ]], RFC 9207, <xref target="RFC9101"></xref>, and Section 4.1.1 of <xref target="RFC7519"></xref>.</t> target="RFC7519" sectionFormat="of" section="4.1.1"></xref>.
</dd>
</dl>
</section>
</section>

</middle>

<back>

<displayreference target="I-D.ietf-oauth-security-topics" to="OAUTH-SECURITY-TOPICS"/>
<references><name>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.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.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8414.xml"/>
</references>
<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.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.ietf-oauth-security-topics.xml"/>

<reference anchor="arXiv.1601.01229" target="https://arxiv.org/abs/1601.01229">
  <front>
    <title>A Comprehensive Formal Security Analysis of OAuth 2.0</title>
    <author fullname="Daniel Fett" initials="D." surname="Fett">
      <organization>University of Trier</organization>
    </author>
    <author fullname="Ralf Kuesters" initials="R." surname="Kuesters">
      <organization>University of Trier</organization>
    </author>
    <author fullname="Guido Schmitz" initials="G." surname="Schmitz">
      <organization>University of Trier</organization>
    </author>
    <date year="2016" month="Jan" day="6"></date> month="January"></date>
  </front>
  <seriesInfo name="DOI" value="10.1145/2976749.2978385"/>
</reference>

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

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

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

<reference anchor="JARM" target="https://openid.net/specs/openid-financial-api-jarm.html">
  <front>
    <title>Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)</title>
    <author fullname="Torsten Lodderstedt" initials="T." surname="Lodderstedt">
      <organization>Yes</organization>
    </author>
    <author fullname="Brian Campbell" initials="B." surname="Campbell">
      <organization>Ping</organization>
    </author>
    <date year="2018" month="Oct" day="17"></date> month="Oct"></date>
  </front>
</reference>

<reference anchor="arXiv.1508.04324" target="https://arxiv.org/abs/1508.04324">
  <front>
    <title>On the security of modern Single Sign-On Protocols: Second-Order Vulnerabilities in OpenID Connect</title>
    <author fullname="Christian Mainka" initials="C." surname="Mainka">
      <organization>Ruhr University Bochum</organization>
    </author>
    <author fullname="Vladislav Mladenov" initials="V." surname="Mladenov">
      <organization>Ruhr University Bochum</organization>
    </author>
    <author fullname="Jörg Schwenk" initials="J." surname="Schwenk">
      <organization>Ruhr University Bochum</organization>
    </author>
    <date year="2015" month="Aug" day="18"></date> month="August"></date>
  </front>
</reference>
</references>
</references>
<section numbered="false" anchor="Acknowledgements"><name>Acknowledgements</name>
<t>We would like to thank
Brian Campbell,
Roman Danyliw,
Vladimir Dzhuvinov,
Joseph Heenan,
Takahiko Kawasaki,
Torsten Lodderstedt,
Christian Mainka,
Vladislav Mladenov,
Warren Parad,
Aaron Parecki,
and
Rifaat Shekh-Yusef
<contact fullname="Brian Campbell"/>,
<contact fullname="Roman Danyliw"/>,
<contact fullname="Vladimir Dzhuvinov"/>,
<contact fullname="Joseph Heenan"/>,
<contact fullname="Takahiko Kawasaki"/>,
<contact fullname="Torsten Lodderstedt"/>,
<contact fullname="Christian Mainka"/>,
<contact fullname="Vladislav Mladenov"/>,
<contact fullname="Warren Parad"/>,
<contact fullname="Aaron Parecki"/>,
and
<contact fullname="Rifaat Shekh-Yusef"/>
for their valuable feedback on this document.</t>
</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>

</rfc>