draft-ietf-oauth-rfc7523bis.xml

<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN" "http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
  category="std" ipr="trust200902"
  docName="draft-ietf-oauth-rfc7523bis-latest"
  updates="7521, 7522, 7523, 9126">

  <?rfc toc="yes"?>
  <?rfc tocompact="yes"?>
  <?rfc tocdepth="5"?>
  <?rfc tocindent="yes"?>
  <?rfc symrefs="yes"?>
  <?rfc sortrefs="yes"?>
  <?rfc compact="yes"?>
  <?rfc subcompact="no"?>

  <front>
    <title abbrev="Updates to Audience Values for ASs">Updates to Audience Values for OAuth 2.0 Authorization Servers</title>

    <author fullname="Michael B. Jones" surname="Jones" initials="M.B.">
      <organization>Self-Issued Consulting</organization>
      <address>
        <email>michael_b_jones@hotmail.com</email>
        <uri>https://self-issued.info/</uri>
      </address>
    </author>

    <author fullname="Brian Campbell" initials="B." surname="Campbell">
      <organization abbrev="Ping Identity">Ping Identity</organization>
      <address>
        <email>bcampbell@pingidentity.com</email>
      </address>
    </author>

    <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
      <organization abbrev="Disney">Disney</organization>
      <address>
        <email>charliemortimore@gmail.com</email>
      </address>
    </author>

    <date day="23" month="April" year="2025" />

    <area>Security</area>
    <workgroup>OAuth Working Group</workgroup>

    <keyword>OAuth</keyword>
    <keyword>JWT</keyword>
    <keyword>Assertion</keyword>
    <keyword>Token</keyword>
    <keyword>Security Token</keyword>

    <abstract>
      <t>
	This specification updates the requirements for audience values
	for tokens whose audience is an OAuth 2.0 authorization server
	to address a security vulnerability identified in the previous
	requirements for those audience values in multiple OAuth 2.0 specifications.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction" anchor="Introduction">
      <t>
	Multiple OAuth 2.0 specifications use tokens (also known as "assertions")
	that are sent to authorization servers.
	These tokens contain an audience value or values intended to
	identify the recipients that the token is intended for.
	When the token is a JSON Web Token (JWT) <xref target="JWT"/>,
	the audience value(s) are contained in the
	<spanx style="verb">aud</spanx> (audience) claim.
      </t>
      <t>
	When performing a security analysis of a pre-final version of
	the OpenID Federation specification <xref target="OpenID.Federation.ID4"/>,
	University of Stuttgart security researchers
	Pedram Hosseyni, Dr. Ralf Küsters, and Tim Würtele
	discovered a vulnerability affecting multiple OpenID and OAuth
	specifications caused by ambiguities in the audience values
	of tokens sent to authorization servers.
	The vulnerability was disclosed to the OAuth working group
	in an interim meeting in January 2025 called for that purpose,
	including providing a description of the vulnerability
	<xref target="private_key_jwt.Disclosure"/>.
	A paper they published describing the attack is
	<xref target="Audience.Injection"/>.
      </t>
      <t>
	This specification updates the affected OAuth specifications
	to address the security vulnerability identified.
	Specifically, it eliminates former ambiguities in the audience values
	of tokens sent to OAuth 2.0 authorization servers.
      </t>
      <t>
	A general description of the update made to each specification is for it
	to require that the issuer identifier URL of the authorization server,
	as defined in <xref target="RFC8414"/>,
	be used as the sole value of the token audience.
	Furthermore, the authorization server MUST reject any such token that
	does not contain its own issuer identifier as the sole audience value.
	An explicit type for each affected kind of token,
	as defined in <xref target="RFC8725"/>,
	is also defined to facilitate distinguishing between
	tokens produced in accordance with specifications
	published prior to these updates and those incorporating them.
	Specific updates made to each affected specification follow.
      </t>

      <section title="Notational Conventions" anchor="NotationalConventions">
        <t>
	  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	  "OPTIONAL" in this document are to be interpreted as described in
	  BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
	  only when, they appear in all capitals, as shown here.
	</t>
      </section>

      <section title="Terminology" anchor="Terminology">
        <t>
	  All terms are as defined in the following specifications:
	  "The OAuth 2.0 Authorization Framework" <xref target="RFC6749"/>,
	  "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" <xref target="RFC7521"/>,
	  and "JSON Web Token (JWT)" <xref target="JWT"/>.
        </t>
      </section>

    </section>

    <section title="Updates to RFC 7521" anchor="RFC7521Updates">
      <t>
	This section updates
	"Assertion Framework for OAuth 2.0 Client Authentication and
	Authorization Grants" <xref target="RFC7521"/>
	to tighten its audience requirements.
      </t>
      <t>
	The description of the Audience parameter
	in Section 5.1 of <xref target="RFC7521"/> (Assertion Metamodel)
	is replaced by:
	<list style="hanging">

	  <t hangText="Audience">
	    <vspace/>
            A value that identifies the party intended to process the assertion.
	    The audience MUST contain the issuer identifier <xref target="RFC8414"/>
	    of the authorization server as its sole value.
	    Unlike the audience value specified
	    in <xref target="RFC7521"/>, there MUST be no value other than
	    the issuer identifier of the intended authorization server
	    used as the audience of the assertion;
	    this includes that the token endpoint URL of the authorization server
	    MUST NOT be used as an audience value.
	  </t>
	</list>
      </t>
      <t>
	The description of the Audience parameter
	in Section 5.2 of <xref target="RFC7521"/> (General Assertion Format and Processing Rules)
	is replaced by:
	<list style="empty">
	  <t>
	    The assertion MUST contain an audience that identifies the
            authorization server as the intended audience,
	    with the issuer identifier <xref target="RFC8414"/>
	    of the authorization server as its sole value.
            The authorization server MUST reject any assertion that does not
            contain its own issuer identifier as the sole audience value.
	  </t>
	</list>
      </t>
      <t>
	In the list of agreements required by participants
	in Section 7 of <xref target="RFC7521"/> (Interoperability Considerations),
	"audience identifiers" is removed from the list.
      </t>
    </section>

    <section title="Updates to RFC 7522" anchor="RFC7522Updates">
      <t>
	This section updates
	"Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0
	Client Authentication and Authorization Grants" <xref target="RFC7522"/>
	to tighten its audience requirements.
      </t>
      <t>
	The description of the Audience element in Item 2 of
	Section 3 of <xref target="RFC7522"/> (Assertion Format and Processing Requirements)
	is replaced by:
	<list style="empty">
	  <t>
	    The Assertion MUST contain a &lt;Conditions&gt; element
	    with an &lt;AudienceRestriction&gt; element
	    with a single &lt;Audience&gt; element that identifies the
	    authorization server as the intended audience.
	    The value of the &lt;Audience&gt; element MUST be
	    the issuer identifier <xref target="RFC8414"/> of the authorization server.
	    Section 2.5.1.4 of
	    "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0"
	    <xref target="OASIS.saml-core-2.0-os"/>
	    defines the &lt;AudienceRestriction&gt; and &lt;Audience&gt; elements.
	    Unlike the audience value specified in <xref target="RFC7522"/>,
	    there MUST be no value other than
	    the issuer identifier of the intended authorization server
	    used as the audience of the assertion;
	    this includes that the token endpoint URL of the authorization server
	    MUST NOT be used as an audience value.
	    <vspace blankLine="1"/>

	    The authorization server MUST reject any assertion that does not
	    contain its own issuer identifier as the sole audience value.
	  </t>
	</list>
      </t>
      <t>
	In Section 4 of <xref target="RFC7522"/> (Authorization Grant Example),
	the sentence:
	<list style="empty">
	  <t>
	    The intended audience of the Assertion is
	    <spanx style="verb">https://saml-sp.example.net</spanx>,
	    which is an identifier for a SAML Service Provider
	    with which the authorization server identifies itself.
	  </t>
	</list>
	is replaced by:
	<list style="empty">
	  <t>
	    The intended audience of the Assertion is
	    <spanx style="verb">https://authz.example.net</spanx>,
	    which is the authorization server's issuer identifier.
	  </t>
	</list>
      </t>
      <figure title="Example SAML 2.0 Assertion" anchor="assertion">
	<preamble>
	  In the same section, the SAML 2.0 Assertion example is replaced by:
	</preamble>
	<artwork><![CDATA[
  <Assertion IssueInstant="2024-11-17T00:53:34.619Z"
    ID="ef1xsbZxPV2oqjd7HTLRLIBlBb7"
    Version="2.0"
    xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
   <Issuer>https://saml-idp.example.com</Issuer>
   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    [...omitted for brevity...]
   </ds:Signature>
   <Subject>
    <NameID
     Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
     brian@example.com
    </NameID>
    <SubjectConfirmation
      Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
     <SubjectConfirmationData
       NotOnOrAfter="2024-11-17T00:58:34.619Z"
       Recipient="https://authz.example.net/token.oauth2"/>
     </SubjectConfirmation>
    </Subject>
    <Conditions>
      <AudienceRestriction>
        <Audience>https://authz.example.net</Audience>
      </AudienceRestriction>
    </Conditions>
    <AuthnStatement AuthnInstant="2024-11-17T00:53:34.371Z">
      <AuthnContext>
        <AuthnContextClassRef>
          urn:oasis:names:tc:SAML:2.0:ac:classes:X509
        </AuthnContextClassRef>
      </AuthnContext>
    </AuthnStatement>
  </Assertion>
]]></artwork>
      </figure>
      <t>
	In the list of agreements required by participants
	in Section 5 of <xref target="RFC7521"/> (Interoperability Considerations),
	"audience identifiers" is removed from the list.
      </t>
    </section>

    <section title="Updates to RFC 7523" anchor="RFC7523Updates">
      <t>
	This section updates
	"JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" <xref target="RFC7523"/>
	to tighten its audience requirements.
      </t>
      <t>
	In Section 3 of <xref target="RFC7523"/> (JWT Format and Processing Requirements),

	Item 3, which describes the audience value,
	is replaced by:
	<list style="empty">
	  <t>
	    The JWT MUST contain an <spanx style="verb">aud</spanx>
	    (audience) claim containing
	    the issuer identifier <xref target="RFC8414"/>
	    of the authorization server as its sole value.
	    The authorization server MUST have an issuer identifier
	    to be used with this specification.
	    Unlike the <spanx style="verb">aud</spanx> value specified
	    in <xref target="RFC7523"/>, there MUST be no value other than
	    the issuer identifier of the intended authorization server
	    used as the audience of the JWT;
	    this includes that the token endpoint URL of the authorization server
	    MUST NOT be used as an audience value.
	    To simplify implementations,
	    the <spanx style="verb">aud</spanx> claim value MUST
	    be a JSON string, and not a single-valued JSON array.
	    The authorization server MUST reject any JWT that does not
	    contain its issuer identifier as its sole audience value.
	    In the absence of an application profile specifying
	    otherwise, compliant applications MUST compare the audience
	    values using the Simple String Comparison method defined in Section
	    6.2.1 of RFC 3986 <xref target="RFC3986"/>.
	  </t>
	</list>
      </t>
      <t>
	In Section 3.1 of <xref target="RFC7523"/> (Authorization Grant Processing),
	the following requirement is added:
	<list style="empty">
	  <t>
	    Authorization grant JWTs MUST be explicitly typed by using the
	    <spanx style="verb">typ</spanx> header parameter value
	    <spanx style="verb">authorization-grant+jwt</spanx> or
	    another more specific explicit type value defined by a specification profiling this specification.
	    Authorization grant JWTs not using the explicit type value
	    MUST be rejected by the authorization server.
	  </t>
	</list>
      </t>
      <t>
	In Section 3.2 of <xref target="RFC7523"/> (Client Authentication Processing),
	the following requirement is added:
	<list style="empty">
	  <t>
	    Client authentication JWTs MUST be explicitly typed by using the
	    <spanx style="verb">typ</spanx> header parameter value
	    <spanx style="verb">client-authentication+jwt</spanx>
	    another more specific explicit type value defined by a specification profiling this specification.
	    Client authentication JWTs not using the explicit type value
	    MUST be rejected by the authorization server.
	  </t>
	</list>
      </t>
      <t>
	In Section 4 of <xref target="RFC7523"/> (Authorization Grant Example),
	the sentence:
	<list style="empty">
	  <t>
	    The intended audience of the JWT is
	    <spanx style="verb">https://jwt-rp.example.net</spanx>, which is an
	    identifier with which the authorization server identifies itself.
	  </t>
	</list>
	is replaced by:
	<list style="empty">
	  <t>
	    The intended audience of the JWT is
	    <spanx style="verb">https://authz.example.net</spanx>,
	    which is the authorization server's issuer identifier.
	  </t>
	</list>
      </t>
      <figure title="Example JWT Claims Set" anchor="JWTClaims">
	<preamble>
	  In the same section, the JWT Claims Set example is replaced by:
	</preamble>
	<artwork><![CDATA[
  {"aud":"https://authz.example.net",
   "iss":"https://jwt-idp.example.com",
   "sub":"mailto:mike@example.com",
   "iat":1731721541,
   "exp":1731725141,
   "http://claims.example.com/member":true
  }
]]></artwork>
      </figure>
      <t>
	In the same section, the sentence:
	<list style="empty">
	  <t>
	    The following example JSON object, used as the header of a
	    JWT, declares that the JWT is signed with the Elliptic Curve
	    Digital Signature Algorithm (ECDSA) P-256
	    SHA-256 using a key identified by the <spanx style="verb">kid</spanx> value <spanx style="verb">16</spanx>.
	  </t>
	</list>
	is replaced by:
	<list style="empty">
	  <t>
	    The following example JSON object, used as the header parameters of a JWT,
	    declares that the JWT is an authorization grant JWT,
	    is signed with the Elliptic Curve Digital Signature Algorithm (ECDSA) P-256 with SHA-256,
	    and was signed with a key identified by
	    the <spanx style="verb">kid</spanx> value <spanx style="verb">16</spanx>.
	  </t>
	</list>
      </t>
      <figure title="Example JOSE Header Parameters" anchor="HeaderParameters">
	<preamble>
	  In the same section, the JOSE Header Parameters example is replaced by:
	</preamble>
	<artwork><![CDATA[
  {"typ":"authorization-grant+jwt","alg":"ES256","kid":"16"}
]]></artwork>
      </figure>
      <figure title="Example POST Body" anchor="POSTBody">
	<preamble>
	  In the same section, the example POST body is replaced by:
	</preamble>
	<artwork><![CDATA[
  grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
  &assertion=eyJ0eXAiOiJhdXRob3JpemF0aW9uLWdyYW50K2p3dCIsImFsZyI6Ik
    VTMjU2Iiwia2lkIjoiMTYifQ.
  eyJhdWQiOiJodHRwczovLw[...omitted for brevity...].
  J9l-ZhwP[...omitted for brevity...]
]]></artwork>
      </figure>
      <t>
	In the list of agreements required by participants
	in Section 5 of <xref target="RFC7523"/> (Interoperability Considerations),
	"audience identifiers" is removed from the list.
      </t>
    </section>

    <section title="Updates to RFC 9126" anchor="RFC9126Updates">
      <t>
	This section updates
	"OAuth 2.0 Pushed Authorization Requests" <xref target="RFC9126"/>
	to tighten its audience requirements.
      </t>
      <t>
	The paragraph describing the audience value
	in Section 2 of <xref target="RFC9126"/> (Pushed Authorization Request Endpoint)
	is replaced by:
	<list style="empty">
	  <t>
	    This update resolves the potential ambiguity regarding
	    the appropriate audience value to use when employing
	    JWT client assertion-based authentication
	    (as defined in Section 2.2 of <xref target="RFC7523"/> with the
	    <spanx style="verb">private_key_jwt</spanx> or
	    <spanx style="verb">client_secret_jwt</spanx> authentication method names
	    per Section 9 of <xref target="OpenID.Core"/>)
	    that was described in <xref target="RFC9126"/>.
	    To address that ambiguity, the issuer identifier URL
	    of the authorization server according to <xref target="RFC8414"/>
	    MUST be used as the sole value of the audience.
            The authorization server MUST reject any such JWT that does not
            contain its own issuer identifier as the sole audience value.
	  </t>
	</list>
      </t>
    </section>

    <section anchor="Security" title="Security Considerations">

      <t>
	The security considerations described within the following specifications are all applicable
	to this document:
	"Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" <xref target="RFC7521"/>,
	"Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0
	Client Authentication and Authorization Grants" <xref target="RFC7522"/>,
	"JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" <xref target="RFC7523"/>,
	"OAuth 2.0 Pushed Authorization Requests" <xref target="RFC9126"/>,
	"The OAuth 2.0 Authorization Framework" <xref target="RFC6749"/>,
	and "JSON Web Token (JWT)" <xref target="JWT"/>.
      </t>
      <t>
	This specification tightens token audience requirements to prevent attacks
	that could result from exploiting audience ambiguities
	previously allowed by
	<xref target="RFC7521"/>, <xref target="RFC7522"/>,
	<xref target="RFC7523"/>, and <xref target="RFC9126"/>.
	These attacks are described in <xref target="private_key_jwt.Disclosure"/>
	and <xref target="Audience.Injection"/>.
      </t>

    </section>

    <section title="IANA Considerations" anchor="IANA">

      <section title="Media Type Registration" anchor="MediaReg">
        <t>
          This section registers the following media types <xref target="RFC2046"/>
          in the "Media Types" registry <xref target="IANA.MediaTypes"/>
          in the manner described in <xref target="RFC6838"/>.
        </t>

        <section title="Registry Contents" anchor="MediaContents">
          <t>
            <?rfc subcompact="yes"?>
            <list style="symbols">
              <t>
                Type name: application
              </t>
              <t>
                Subtype name: authorization-grant+jwt
              </t>
              <t>
                Required parameters: n/a
              </t>
              <t>
                Optional parameters: n/a
              </t>
              <t>
                Encoding considerations: binary;
                An authorization grant JWT is a JWT;
                JWT values are encoded as a
                series of base64url-encoded values (some of which may be the
                empty string) separated by period ('.') characters.
              </t>
              <t>
                Security considerations: See <xref target="Security"/> of this specification
              </t>
              <t>
                Interoperability considerations: n/a
              </t>
              <t>
                Published specification: <xref target="RFC7523Updates"/> of this specification
              </t>
              <t>
                Applications that use this media type:
                Applications that use this specification
              </t>
              <t>
                Fragment identifier considerations: n/a
              </t>
              <t>
                Additional information:<list style="empty">
                <t>Magic number(s): n/a</t>
                <t>File extension(s): n/a</t>
                <t>Macintosh file type code(s): n/a </t></list>
                <vspace/>
              </t>
              <t>
                Person &amp; email address to contact for further information:
                <vspace/>
                Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Intended usage: COMMON
              </t>
              <t>
                Restrictions on usage: none
              </t>
              <t>
                Author: Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Provisional registration? No
              </t>
            </list>
            <?rfc subcompact="no"?>
          </t>

          <t>
            <?rfc subcompact="yes"?>
            <list style="symbols">
              <t>
                Type name: application
              </t>
              <t>
                Subtype name: client-authentication+jwt
              </t>
              <t>
                Required parameters: n/a
              </t>
              <t>
                Optional parameters: n/a
              </t>
              <t>
                Encoding considerations: binary;
                A client authentication JWT is a JWT;
                JWT values are encoded as a
                series of base64url-encoded values (some of which may be the
                empty string) separated by period ('.') characters.
              </t>
              <t>
                Security considerations: See <xref target="Security"/> of this specification
              </t>
              <t>
                Interoperability considerations: n/a
              </t>
              <t>
                Published specification: <xref target="RFC7523Updates"/> of this specification
              </t>
              <t>
                Applications that use this media type:
                Applications that use this specification
              </t>
              <t>
                Fragment identifier considerations: n/a
              </t>
              <t>
                Additional information:<list style="empty">
                <t>Magic number(s): n/a</t>
                <t>File extension(s): n/a</t>
                <t>Macintosh file type code(s): n/a </t></list>
                <vspace/>
              </t>
              <t>
                Person &amp; email address to contact for further information:
                <vspace/>
                Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Intended usage: COMMON
              </t>
              <t>
                Restrictions on usage: none
              </t>
              <t>
                Author: Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Change controller: IETF
              </t>
              <t>
                Provisional registration? No
              </t>
            </list>
            <?rfc subcompact="no"?>
          </t>
        </section>

      </section>
    </section>

  </middle>

  <back>

    <references title="Normative References">

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7521.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7522.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7523.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8414.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8725.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9126.xml"/>

      <!-- Reference from https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml with change to anchor="JWT" -->

      <reference anchor="JWT" target="https://www.rfc-editor.org/info/rfc7519">
	<front>
	  <title>JSON Web Token (JWT)</title>
	  <author fullname="M. Jones" initials="M." surname="Jones"/>
	  <author fullname="J. Bradley" initials="J." surname="Bradley"/>
	  <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
	  <date month="May" year="2015"/>
	  <abstract>
	    <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
	  </abstract>
	</front>
	<seriesInfo name="RFC" value="7519"/>
	<seriesInfo name="DOI" value="10.17487/RFC7519"/>
      </reference>

      <reference target="https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf" anchor="OASIS.saml-core-2.0-os">
	<front><title>Assertions and Protocols for the OASIS Security Assertion Markup Language
	(SAML) V2.0</title>
	<author fullname="Scott Cantor" initials="S." surname="Cantor">
	  <organization>Internet2</organization>
	<address><email>cantor.2@osu.edu</email></address></author>
	<author fullname="John Kemp" initials="J." surname="Kemp"><organization>Nokia</organization>
	<address><email>John.Kemp@nokia.com</email></address></author><author fullname="Rob Philpott" initials="R." surname="Philpott">
	<organization>RSA Security</organization>
	<address><email>rphilpott@rsasecurity.com</email></address></author>
	<author fullname="Eve Maler" initials="E." surname="Maler">
	<organization>Sun Microsystems</organization><address><email>eve.maler@sun.com</email></address></author>
	<date year="2005" month="March"/></front>
	<seriesInfo name="OASIS Standard" value="saml-core-2.0-os"/>
      </reference>

    </references>

    <references title="Informative References">
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>

      <reference anchor="Audience.Injection" target="https://eprint.iacr.org/2025/629">
	<front>
	  <title>Audience Injection Attacks: A New Class of Attacks on Web-Based Authorization and Authentication Standards</title>

	  <author fullname="Pedram Hosseyni" initials="P." surname="Hosseyni">
	    <organization>University of Stuttgart</organization>
	  </author>

	  <author fullname="Ralf Küsters" initials="R." surname="Küsters">
	    <organization>University of Stuttgart</organization>
	  </author>

	  <author fullname="Tim Würtele" initials="T." surname="Würtele">
	    <organization>University of Stuttgart</organization>
	  </author>

	  <date month="April" year="2025"/>
	</front>
	<seriesInfo name="Cryptology ePrint Archive" value="Paper 2025/629" />
      </reference>

      <reference anchor="private_key_jwt.Disclosure" target="https://openid.net/wp-content/uploads/2025/01/OIDF-Responsible-Disclosure-Notice-on-Security-Vulnerability-for-private_key_jwt.pdf">
	<front>
	  <title>OIDF Responsible Disclosure Notice on Security Vulnerability for private_key_jwt</title>
	  <author>
	    <organization>OpenID Foundation</organization>
	  </author>
	  <date year="2025" month="January" day="24"/>
	</front>
      </reference>

      <reference anchor="OpenID.Core" target="https://openid.net/specs/openid-connect-core-1_0.html">
	<front>
	  <title>OpenID Connect Core 1.0 incorporating errata set 2</title>

	  <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	    <organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
	  </author>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Self-Issued Consulting (was at Microsoft)">Self-Issued Consulting</organization>
	  </author>

	  <author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
	    <organization abbrev="Google">Google</organization>
	  </author>

	  <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
	    <organization abbrev="Disney (was at Salesforce)">Disney</organization>
	  </author>

	  <date day="15" month="December" year="2023"/>
	</front>
      </reference>

      <reference anchor="OpenID.Federation.ID4" target="https://openid.net/specs/openid-federation-1_0-ID4.html">
	<front>
	  <title>OpenID Federation 1.0</title>
	  <author fullname="Roland Hedberg">
	    <organization>independent</organization>
	  </author>
	  <author fullname="Michael B. Jones">
	    <organization>Self-Issued Consulting</organization>
	  </author>
	  <author fullname="A. Solberg">
	    <organization>Sikt</organization>
	  </author>
	  <author fullname="John Bradley">
	    <organization>Yubico</organization>
	  </author>
	  <author fullname="Giuseppe De Marco">
	    <organization>independent</organization>
	  </author>
	  <author fullname="Vladimir Dzhuvinov">
	    <organization>Connect2id</organization>
	  </author>
	  <date day="31" month="May" year="2024"/>
	</front>
      </reference>

      <reference anchor="IANA.MediaTypes" target="https://www.iana.org/assignments/media-types">
	<front>
	  <title>Media Types</title>
	  <author>
	    <organization>IANA</organization>
	  </author>
	  <date/>
	</front>
      </reference>

    </references>

    <section title="Document History" anchor="History">
      <t>
	[[ to be removed by the RFC Editor before publication as an RFC ]]
      </t>

      <t>
	-01
	<list style="symbols">
	  <t>
	    Reworked to make updates to RFC 7523, rather than replacing it.
	  </t>
	  <t>
	    Removed updates to RFC 9101.
	  </t>
	  <t>
	    Added reference to the University of Stuttgart paper <xref target="Audience.Injection"/>.
	  </t>
	</list>
      </t>

      <t>
	-00
	<list style="symbols">
	  <t>
	    Initial working group draft, replacing draft-jones-oauth-rfc7523bis-00.
	  </t>
	</list>
      </t>

    </section>

    <section title="Acknowledgements" anchor="Acknowledgements" numbered="no">
      <t>
	We would like to acknowledge the contributions of the following
	people to this specification:
	John Bradley,
	Ralph Bragg,
	Joseph Heenan,
	Pedram Hosseyni,
	Aaron Parecki,
	Filip Skokan,
	and
	Tim Würtele.
      </t>
    </section>

  </back>
</rfc>