<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en"
     submissionType="IETF" category="std"  consensus="true"
     docName="draft-ietf-oauth-jwsreq-34" ipr="trust200902">
  <?rfc toc="yes"?>
  <?rfc tocompact="yes"?>
  <?rfc tocdepth="3"?>
  <?rfc tocindent="yes"?>
  <?rfc symrefs="yes"?>
  <?rfc sortrefs="yes"?>
  <?rfc comments="yes"?>
  <?rfc inline="yes"?>
  <?rfc compact="yes"?>
  <?rfc subcompact="no"?>
  <?rfc strict="no"?> number="9101" ipr="trust200902"
     tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true"
     version="3">

  <front>
    <title abbrev="OAuth JAR">The OAuth 2.0 Authorization Framework: JWT Secured JWT-Secured Authorization Request (JAR)</title>

    <seriesInfo name="RFC" value="9101"/>
    <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
      <organization>NAT.Consulting</organization>
      <address>
        <postal>
          <street>2-22-17 Naka</street>
          <city>Kunitachi</city>
          <code>186-0004</code>
          <region>Tokyo</region>
          <street>Kunitachi</street>
          <region>Tokyo 186-0004</region>

          <extaddr>2-22-17 Naka</extaddr>
          <country>Japan</country>
        </postal>
        <phone>+81-42-580-7401</phone>
        <email>nat@nat.consulting</email>
        <uri>http://nat.sakimura.org/</uri>
        <uri>https://nat.sakimura.org/</uri>
      </address>
    </author>

    <author fullname="John Bradley" initials="J." surname="Bradley">
      <organization>Yubico</organization>
      <address>
        <postal>
          <street>Casilla 177, Sucursal Talagante</street> 177</street>
          <extaddr>Sucursal Talagante</extaddr>
          <city>Talagante</city>
          <region>RM</region>
          <code/>
          <country>Chile</country>
        </postal>
        <phone>+1.202.630.5272</phone>
        <facsimile/>
        <email>ve7jtb@ve7jtb.com</email>
        <email>rfc9101@ve7jtb.com</email>
        <uri>http://www.thread-safe.com/</uri>
      </address>
    </author>
    <author fullname="Michael B. Jones" surname="Jones" initials="M.B."> initials="M.">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <street>One Microsoft Way</street>
          <city>Redmond</city>
          <region>Washington</region>
          <code>98052</code>
          <country>United States of America</country>
        </postal>
        <email>mbj@microsoft.com</email>
        <uri>https://self-issued.info/</uri>
      </address>
    </author>
    <date day="8" month="April" month="August" year="2021"/>
    <area>Security</area>
    <workgroup>OAuth Working Group</workgroup>

    <keyword>RFC</keyword>
    <keyword>Request for Comments</keyword>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>Assertion</keyword>
    <keyword>Claim</keyword>
    <keyword>Security Token</keyword>
    <keyword>OAuth</keyword>
    <keyword>JavaScript Object Notation</keyword>
    <keyword>JSON</keyword>
    <keyword>JSON Web Token</keyword>
    <keyword>JWT</keyword>
    <keyword>JSON Web Signature</keyword>
    <keyword>JWS</keyword>
    <keyword>JSON Web Encryption</keyword>
    <keyword>JWE</keyword>
    <abstract>
      <t>The authorization request in OAuth 2.0 described in RFC 6749 utilizes
      query parameter serialization, which means that Authorization Request authorization request
      parameters are encoded in the URI of the request and sent through user
      agents such as web browsers.  While it is easy to implement, it means
      that
	  (a) a) the communication through the user agents is not integrity
      protected and thus thus, the parameters can be tainted,
	  (b) b) the source of
      the communication is not authenticated, and
	  (c) c) the communication
      through the user agents can be monitored.  Because of these weaknesses,
      several attacks to the protocol have now been put forward.</t>
      <t>This document introduces the ability to send request parameters in a
      JSON Web Token (JWT) instead, which allows the request to be signed with
      JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so
      that the integrity, source authentication authentication, and confidentiality property
      properties of the Authorization Request is authorization request are attained.  The request can
      be sent by value or by reference.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
    <section>
      <name>Introduction</name>
      <t>
	  The Authorization Request authorization request in <xref target="RFC6749">OAuth 2.0</xref>
	  utilizes query parameter
      serialization and is typically sent through user agents such as web browsers.
      </t>
      <t>
	  For example, the parameters <spanx style="verb">response_type</spanx>, <spanx style="verb">client_id</spanx>, <spanx style="verb">state</spanx>, <tt>response_type</tt>, <tt>client_id</tt>, <tt>state</tt>, and <spanx style="verb">redirect_uri</spanx> <tt>redirect_uri</tt> are encoded in the URI of the request:
      </t>
      <figure>
        <artwork><![CDATA[
<sourcecode type="http-message">
    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb /authorize?response_type=code&amp;client_id=s6BhdRkqt3&amp;state=xyz
    &amp;redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com
        ]]></artwork>
	  </figure>
</sourcecode>
      <t>
	  While it is easy to implement,  the encoding in the URI
	  does not allow application layer application-layer security to be used to
	  provide confidentiality and integrity protection.
	  While TLS is used to offer communication security
	  between the Client client and the user-agent user agent as well as the user-agent user agent and the
	  Authorization Server,
	  authorization server, TLS sessions are terminated in the user-agent. user agent.
	  In addition, TLS sessions may be terminated
      prematurely at some middlebox (such as a load balancer).
      </t>

      <t>
	  As the a result, the Authorization Request authorization request of <xref target="RFC6749" /> target="RFC6749"/> has
	  shortcomings in that:
      </t>
	  <t><list style="format (%c)">
	    <t>the
      <ol spacing="normal" type="(%c)">
        <li>the communication through the user agents is
		not integrity protected protected, and thus thus, the parameters can be tainted
		(integrity protection failure)</t>
	    <t>the failure);</li>
        <li>the source of the communication is not authenticated
		(source authentication failure)</t>
		<t>the failure);</li>
        <li>the communication through the user agents can be monitored
		(containment / confidentiality
		(containment/confidentiality failure). </t>
	  </list></t> </li>
      </ol>
      <t>
	  Due to these inherent weaknesses, several attacks against the
	  protocol, such as Redirection redirection URI rewriting, have been identified.
      </t>
      <t>
	  The use of application layer application-layer security mitigates these issues.
      </t>
      <t>
      The use of application layer application-layer security allows requests to be prepared by
      a trusted third party so that a client application cannot request more
      permissions than previously agreed. agreed upon.
      </t>
      <t>
      Furthermore, passing the request by reference allows the reduction of over-the-wire overhead.
      </t>
      <t>The <xref target="RFC7519">JWT</xref> encoding has been chosen because of </t>
      <t><list style="format (%d)">
        <t>its of:</t>
      <ol spacing="normal" type="(%d)">
        <li>its close relationship with JSON,
        which is used as OAuth's response format </t>
        <t>its </li>
        <li>its developer friendliness due to its textual nature</t>
        <t>its nature</li>
        <li>its relative compactness compared to XML </t>
        <t>its </li>
        <li>its development status as a Proposed Standard,  along
		with the associated signing and encryption methods
        <xref target="RFC7515" /> target="RFC7515"/> <xref target="RFC7516" /></t>
		<t>the target="RFC7516"/></li>
        <li>the relative ease of JWS and JWE compared to XML Signature and Encryption. </t>
      </list>
      </t> </li>
      </ol>
      <t>The parameters <spanx style="verb">request</spanx> <tt>request</tt> and <spanx
      style="verb">request_uri</spanx> <tt>request_uri</tt> are
      introduced as additional authorization request parameters for the <xref
      target="RFC6749">OAuth 2.0</xref> flows. The <spanx style="verb">request</spanx> <tt>request</tt> parameter
      is a <xref target="RFC7519">JSON Web Token (JWT)</xref> whose JWT Claims
      Set holds the JSON
      encoded JSON-encoded OAuth 2.0 authorization request parameters.
      Note that, in contrast to RFC 7519, the elements of the Claims Set are
      encoded OAuth Request Parameters request parameters <xref target="IANA.OAuth.Parameters"/>,
      supplemented with only a few of the IANA-managed JSON Web Token Claims
      <xref target="IANA.JWT.Claims"/> – target="IANA.JWT.Claims"/>, in particular <spanx style="verb">iss</spanx> particular, <tt>iss</tt> and <spanx style="verb">aud</spanx>.
      <tt>aud</tt>.  The JWT in the <spanx style="verb">request</spanx> <tt>request</tt> parameter is integrity
      protected and source authenticated using JWS.
      </t>
      <t>
	  The <xref target="RFC7519">JWT</xref> can be passed to the authorization endpoint by reference,
      in which case the parameter <spanx style="verb">request_uri</spanx> <tt>request_uri</tt> is
      used instead of the <spanx style="verb">request</spanx>.</t> <tt>request</tt>.</t>
      <t>Using <xref target="RFC7519">JWT</xref> as the request encoding instead of query
      parameters has several advantages:</t>

      <t><list style="format (%c)">
          <t>(integrity protection)
      <ol spacing="normal" type="(%c)">
        <li>Integrity protection.
		  The request can be signed so that the integrity of the request can be checked.</t>
		  <t>(source authentication) checked.</li>
        <li>Source authentication.
		  The request can be signed so that the signer can be authenticated.</t>

          <t>(confidentiality protection) authenticated.</li>
        <li>Confidentiality protection.
		  The request can be encrypted so that end-to-end
		  confidentiality can be provided even if the TLS connection is
		  terminated at one point or another (including at and before user-agents). </t>
		  <t>(collection minimization) user agents). </li>
        <li>Collection minimization.  The request can be signed by a trusted
        third party attesting that the authorization request is compliant with
        a certain policy.  For example, a request can be pre-examined by a
        trusted third party to confirm that all the personal data requested is
        strictly necessary to perform the process that the end-user end user asked for, and for;
        the request would then be signed by that trusted third party.  The
        authorization server then examines the signature and shows the
        conformance status to the end-user, end user who would have some assurance as to
        the legitimacy of the request when authorizing it.  In some cases, it
        may even be desirable to skip the authorization dialogue under such
        circumstances.
		  </t>
        </list></t>
		  </li>
      </ol>
      <t>There are a few cases that where request by reference is useful useful, such as:</t>

      <t><list style="numbers">
          <t>When
      <ol spacing="normal" type="1">
        <li>when it is desirable to reduce the size of a transmitted request.
        The use of application layer application-layer security increases the size of the request,
        request particularly when public key public-key cryptography is used. </t>

		  <t>When </li>
        <li>when the client does not want to do the application level application-level
        cryptography.  The Authorization Server authorization server may provide an endpoint to
        accept the Authorization Request authorization request through direct communication with the Client
        client, so that the Client client is authenticated and the channel is TLS
        protected. </t>
        </list></t> </li>
      </ol>
      <t>This capability is in use by OpenID Connect <xref target="OpenID.Core" />.</t>

      <section title="Requirements Language">
        <t>The target="OpenID.Core"/>.</t>
      <section>
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
		"MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" /> target="RFC2119"/>
    <xref target="RFC8174" /> target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t> here.
        </t>

      </section>
    </section>
    <section anchor="Terminology" title="Terminology"> anchor="Terminology">
      <name>Terminology</name>

      <t>For the purposes of this specification, the following terms and
      definitions apply in addition to what is defined in
	  <xref target="RFC6749">OAuth 2.0 Framework</xref>,
	  <xref target="RFC7515">JSON Web Signature</xref>, and
	  <xref target="RFC7519">JSON target="RFC7516">JSON Web Encryption</xref> apply.</t> Encryption</xref>.</t>
      <section anchor="request_object" title="Request Object"> anchor="request_object">
        <name>Request Object</name>
        <t>
	  A Request Object is a <xref target="RFC7519">JSON Web Token
	  (JWT)</xref> whose JWT Claims
	  Set holds the JSON
	  encoded JSON-encoded OAuth 2.0 authorization request
	  parameters.
        </t>
      </section>
      <section anchor="request_uri" title="Request anchor="request_uri">
        <name>Request Object URI</name>

        <t>A Request Object URI">
        <t>Absolute URI is an absolute URI that references the set of
        parameters comprising an OAuth 2.0 authorization request.  The contents content
        of the resource referenced by the URI are is a <xref
        target="request_object">Request Object</xref>, unless the URI was
        provided to the client by the same Authorization Server, authorization server, in which case
        the content is an implementation detail at the discretion of the Authorization Server.
        authorization server. The former content being a Request Object is to ensure interoperability in
        cases where the provider of the request_uri <tt>request_uri</tt> is a separate
        entity from the consumer, such as when a client provides a URI
        referencing a Request Object stored on the client's backend service and
        that is made accessible via HTTPS. In the latter case case, where the Authorization Server
        authorization server is both provider and consumer of the URI, such as
        when it offers an endpoint that provides a URI in exchange for a
        Request Object, this interoperability concern does not apply.</t>
      </section>
    </section>
    <section anchor="abbreviation" title="Symbols anchor="abbreviation">
      <name>Symbols and abbreviated terms"> Abbreviated Terms</name>
      <t>
	The following abbreviations are common to this specification.
      </t>
		<t><list style="hanging">
			<t hangText="JSON">JavaScript Object Notation</t>
			<t hangText="JWT">JSON
      <dl newline="false" spacing="normal">
        <dt>JSON:</dt>
        <dd>JavaScript Object Notation</dd>
        <dt>JWT:</dt>
        <dd>JSON Web Token</t>
			<t hangText="JWS">JSON Token</dd>
        <dt>JWS:</dt>
        <dd>JSON Web Signature</t>
			<t hangText="JWE">JSON Signature</dd>
        <dt>JWE:</dt>
        <dd>JSON Web Encryption</t>
			<t hangText="URI">Uniform Encryption</dd>
        <dt>URI:</dt>
        <dd>Uniform Resource Identifier</t>
			<t hangText="URL">Uniform Identifier</dd>
        <dt>URL:</dt>
        <dd>Uniform Resource Locator</t>
		</list></t> Locator</dd>
      </dl>
    </section>
    <section anchor="authorization_request_object" title="Request Object"> anchor="authorization_request_object">
      <name>Request Object</name>
      <t>A <xref target="request_object">Request Object</xref> is used to
      provide authorization request parameters for an OAuth 2.0 authorization
      request. It MUST <bcp14>MUST</bcp14> contain all the parameters (including extension
      parameters) used to process the <xref target="RFC6749">OAuth 2.0</xref>
      authorization request except the <spanx style="verb">request</spanx> <tt>request</tt> and
      <spanx style="verb">request_uri</spanx>
      <tt>request_uri</tt> parameters that are defined in
      this document.
	  The parameters are represented as the JWT claims Claims of the object.
	  Parameter names and string values MUST <bcp14>MUST</bcp14> be included as JSON strings.
	  Since Request Objects are handled across domains and potentially
	  outside of a closed ecosystem, per section 8.1 of <xref
	  target="RFC8259" />, sectionFormat="of" section="8.1"/>,
	  these JSON strings MUST <bcp14>MUST</bcp14> be encoded using UTF-8 <xref target="RFC3629" />. target="RFC3629"/>.
	  Numerical values MUST <bcp14>MUST</bcp14> be included as JSON numbers.
	  It MAY
	  The Request Object <bcp14>MAY</bcp14> include any extension parameters.

	  This <xref target="RFC8259">JSON</xref> object constitutes the
      JWT Claims Set defined in <xref target="RFC7519">JWT</xref>.
	  The JWT Claims Set is then signed or signed and encrypted. </t>

      <t>To sign, <xref target="RFC7515">JSON Web Signature (JWS)</xref> is
      used.  The result is a JWS signed JWS-signed <xref target="RFC7519">JWT</xref>. If
      signed, the Authorization Request Object SHOULD <bcp14>SHOULD</bcp14> contain
      the Claims <spanx
      style="verb">iss</spanx> <tt>iss</tt> (issuer) and <spanx style="verb">aud</spanx> <tt>aud</tt> (audience) as members, members
      with their semantics being the same as defined in the <xref
      target="RFC7519">JWT</xref> specification.  The value of <spanx style="verb">aud</spanx> <tt>aud</tt>
      should be the value of the
	  Authorization Server authorization server (AS)
      <spanx style="verb">issuer</spanx> <tt>issuer</tt>, as
      defined in <xref target="RFC8414">RFC8414</xref>.</t> target="RFC8414">RFC 8414</xref>.</t>
      <t>To encrypt, <xref target="RFC7516">JWE</xref> is used.
	  When both signature and encryption are being applied,
	  the JWT MUST <bcp14>MUST</bcp14> be signed signed, then encrypted encrypted, as described in
	  Section 11.2 of
	  <xref target="RFC7519" />. sectionFormat="of" section="11.2"/>.
	  The result is a Nested JWT, as defined in
	  <xref target="RFC7519" />. target="RFC7519"/>.
      </t>

      <t>
	    The client determines the algorithms used to sign and encrypt
	    Request Objects.  The algorithms chosen need to be supported by
	    both the client and the authorization server.  The client can
	    inform the authorization server of the algorithms that it supports
	    in its dynamic client registration metadata <xref
	    target="RFC7591"/>, specifically, the metadata values
	    <spanx style="verb">request_object_signing_alg</spanx>,
	    <spanx style="verb">request_object_encryption_alg</spanx>,
	    <tt>request_object_signing_alg</tt>,
	    <tt>request_object_encryption_alg</tt>, and
	    <spanx style="verb">request_object_encryption_enc</spanx>.
	    <tt>request_object_encryption_enc</tt>.  Likewise, the
	    authorization server can inform the client of the algorithms that
	    it supports in its authorization server metadata <xref
	    target="RFC8414"/>, specifically, the metadata values
	    <spanx style="verb">request_object_signing_alg_values_supported</spanx>,
	    <spanx style="verb">request_object_encryption_alg_values_supported</spanx>,
	    <tt>request_object_signing_alg_values_supported</tt>,
	    <tt>request_object_encryption_alg_values_supported</tt>, and
	    <spanx style="verb">request_object_encryption_enc_values_supported</spanx>.
	    <tt>request_object_encryption_enc_values_supported</tt>.
      </t>
      <t>
	    The Request Object MAY <bcp14>MAY</bcp14> be sent by value value, as
	    described in <xref target="RequestParameter" /> target="RequestParameter"/>,
	    or by reference reference, as described in <xref target="RequestUriParameter" />.
	    <spanx style="verb">request</spanx> target="RequestUriParameter"/>.
	    <tt>request</tt> and
	    <spanx style="verb">request_uri</spanx>
	    <tt>request_uri</tt> parameters
	    MUST NOT
	    <bcp14>MUST NOT</bcp14> be included in Request Objects.
      </t>
      <t>
	  A <xref target="request_object">Request Object</xref> has the media
	  type <xref target="RFC2046"/>
	  <spanx style="verb">application/oauth-authz-req+jwt</spanx>.
	  <tt>application/oauth-authz-req+jwt</tt>.  Note that some existing
	  deployments may alternatively be using the type
	  <spanx style="verb">application/jwt</spanx>.
	  <tt>application/jwt</tt>.
      </t>

	  <figure>
	    <preamble>

      <t keepWithNext="true">
	      The following is an example of the Claims in
	      a Request Object before base64url <xref target="RFC7515"/> encoding and signing.
		  Note that it includes the extension parameters
		  <spanx style="verb">nonce</spanx>
		  <tt>nonce</tt> and <spanx style="verb">max_age</spanx>.
	    </preamble>

	    <artwork><![CDATA[ <tt>max_age</tt>.
      </t>
<sourcecode type="json">
  {
   "iss": "s6BhdRkqt3",
   "aud": "https://server.example.com",
   "response_type": "code id_token",
   "client_id": "s6BhdRkqt3",
   "redirect_uri": "https://client.example.org/cb",
   "scope": "openid",
   "state": "af0ifjsldkj",
   "nonce": "n-0S6_WzA2Mj",
   "max_age": 86400
  }
]]></artwork>
	  </figure>
	  <figure>
	    <preamble>
</sourcecode>
      <t keepWithNext="true">
	      Signing it with the <spanx style="verb">RS256</spanx> <tt>RS256</tt> algorithm <xref target="RFC7518"/>
	      results in this Request Object value
	      (with line wraps within values for display purposes only):
	    </preamble>

	    <artwork><![CDATA[
      </t>
<sourcecode type="jwt">
  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
]]></artwork>
	  </figure>
	  <figure>
	    <preamble>
</sourcecode>
      <t keepWithNext="true">
	      The following RSA public key, represented in JWK JSON Web Key (JWK)
	      format, can be used to validate the Request Object signature in
	      this and subsequent Request Object examples (with line wraps
	      within values for display purposes only):
	    </preamble>

	    <artwork><![CDATA[
      </t>
<sourcecode type="json">
  {
   "kty":"RSA",
   "kid":"k2bdc",
   "n":"x5RbkAZkmpRxia65qRQ1wwSMSxQUnS7gcpVTV_cdHmfmG2ltd2yabEO9XadD8
        pJNZubINPpmgHh3J1aD9WRwS05ucmFq3CfFsluLt13_7oX5yDRSKX7poXmT_5
        ko8k4NJZPMAO8fPToDTH7kHYbONSE2FYa5GZ60CUsFhSonI-dcMDJ0Ary9lxI
        w5k2z4TAdARVWcS7sD07VhlMMshrwsPHBQgTatlkxyIHXbYdtak8fqvNAwr7O
        lVEvM_Ipf5OfmdB8Sd-wjzaBsyP4VhJKoi_qdgSzpC694XZeYPq45Sw-q51iF
        UlcOlTCI7z6jltUtnR6ySn6XDGFnzH5Fe5ypw",
   "e":"AQAB"
  }
]]></artwork>
	  </figure>
</sourcecode>
    </section>
    <section title="Authorization Request" anchor="authreq">
      <name>Authorization Request</name>
      <t>The client constructs the authorization request URI
	  by adding the following parameters
	  to the query component of the authorization
      endpoint URI using the <spanx style="verb">application/x-www-form-urlencoded</spanx> <tt>application/x-www-form-urlencoded</tt>
      format:</t>

      <t><list style="hanging">
          <t hangText="request">
	    <vspace/>
	    REQUIRED
      <dl newline="true" spacing="normal">
        <dt>request</dt>
        <dd>
	    <bcp14>REQUIRED</bcp14> unless <spanx style="verb">request_uri</spanx> <tt>request_uri</tt>
          is specified. The <xref target="request_object">Request Object</xref> that
          holds authorization request parameters stated in section 4 of
          <xref target="RFC6749">OAuth 2.0</xref>. target="RFC6749" sectionFormat="of" section="4"/> (OAuth 2.0).
		  If this parameter is present in the authorization request,
		  <spanx style="verb">request_uri</spanx> MUST NOT
		  <tt>request_uri</tt> <bcp14>MUST NOT</bcp14> be present.
		  </t>

          <t hangText="request_uri">
	    <vspace/>
	    REQUIRED
		  </dd>
        <dt>request_uri</dt>
        <dd>
	    <bcp14>REQUIRED</bcp14> unless <spanx style="verb">request</spanx> <tt>request</tt>
          is specified. The absolute URI URI, as defined by <xref
          target="RFC3986">RFC3986</xref>
	  target="RFC3986">RFC 3986</xref>, that is the <xref
	  target="request_uri">Request Object URI</xref> referencing the
	  authorization request
          parameters stated in section 4 of <xref target="RFC6749">OAuth
          2.0</xref>. target="RFC6749"
	  sectionFormat="of" section="4"/> (OAuth
          2.0).
		  If this parameter is present in the authorization request,
		  <spanx style="verb">request</spanx> MUST NOT
		  <tt>request</tt> <bcp14>MUST NOT</bcp14> be present.
		  </t>

          <t hangText="client_id">
	    <vspace/>
	    REQUIRED.
		  </dd>
        <dt>client_id</dt>
        <dd>
	    <bcp14>REQUIRED</bcp14>. <xref target="RFC6749">OAuth 2.0</xref>
          <spanx style="verb">client_id</spanx>.
          <tt>client_id</tt>. The value MUST <bcp14>MUST</bcp14> match the
          <spanx style="verb">request</spanx>
          <tt>request</tt> or <spanx style="verb">request_uri</spanx> <tt>request_uri</tt>
          <xref target="request_object">Request Object's</xref>
          <spanx style="verb">client_id</spanx>.</t>
        </list>The
          <tt>client_id</tt>.</dd>
      </dl>
      <t>The client directs the resource owner to the constructed URI
      using an HTTP redirection response, response or by other means available to it
      via the user-agent.</t> user agent.</t>
      <t>For example, the client directs the end user's user-agent user agent to make the
      following HTTPS request:</t>

      <figure>
        <artwork><![CDATA[GET /authz?client_id=s6BhdRkqt3&request=eyJhbG..AlMGzw
<sourcecode type="http-message">
GET /authz?client_id=s6BhdRkqt3&amp;request=eyJhbG..AlMGzw HTTP/1.1
Host: server.example.com]]></artwork>
		<postamble> server.example.com
</sourcecode>
      <t keepWithPrevious="true">
		The value for the request parameter is abbreviated
		for brevity.
		</postamble>
      </figure>
      </t>
      <t>The authorization request object MUST Authorization Request Object <bcp14>MUST</bcp14> be one of the following: </t>
	  <t><list style="format (%c)">
			<t>JWS
      <ol spacing="normal" type="(%c)">
        <li>JWS signed </t>
			<t>JWS </li>
        <li>JWS signed and JWE encrypted</t>
	  </list></t> encrypted</li>
      </ol>
      <t>The client MAY <bcp14>MAY</bcp14> send the parameters included in
	  the request object Request Object duplicated in the query parameters as well
	  for the backward compatibility compatibility, etc.
	  However, the authorization server supporting this specification
	  MUST
	  <bcp14>MUST</bcp14> only use the parameters included in the request object. Request Object.
      </t>
      <section anchor="RequestParameter"
		 title='Passing anchor="RequestParameter">
        <name>Passing a Request Object by Value'> Value</name>
        <t>The Client client sends the Authorization Request authorization request as a
	  Request Object to the Authorization Endpoint authorization endpoint as the
	  <spanx style="verb">request</spanx>
	  <tt>request</tt> parameter value.</t>

	  <t>
	    <figure>
	      <preamble>The
        <t keepWithNext="true">The following is an example of an
	      Authorization Request
	      authorization request using the <spanx style='verb'>request</spanx> <tt>request</tt>
	      parameter
	      (with line wraps within values for display purposes only):
	      </preamble>

	      <artwork><![CDATA[
  https://server.example.com/authorize?client_id=s6BhdRkqt3&
        </t>
<sourcecode type="url">
  https://server.example.com/authorize?client_id=s6BhdRkqt3&amp;
    request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6
    ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs
    ZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAg
    ICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6
    ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAi
    b3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2Ui
    OiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VU
    ElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC
    0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKz
    uKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3E
    YLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W
    9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3
    j1i7tLR_5Nz-g
]]></artwork>
	    </figure>
	  </t>
</sourcecode>
      </section>
      <section anchor="RequestUriParameter" title="Passing anchor="RequestUriParameter">
        <name>Passing a Request Object by Reference"> Reference</name>
        <t>
	  The <spanx style="verb">request_uri</spanx> Authorization Request <tt>request_uri</tt> authorization request parameter enables
	  OAuth authorization requests to be passed by reference, reference rather than
	  by value.  This parameter is used identically to the
	  <spanx style="verb">request</spanx>
	  <tt>request</tt> parameter, other than except that the Request Object value is
	  retrieved from the resource identified by the specified URI rather
	  than passed by value.
        </t>

        <t>
	  The entire Request URI SHOULD NOT <bcp14>SHOULD NOT</bcp14> exceed 512 ASCII characters.
	  There are two reasons for this restriction:
        </t>
	<t><list style="numbers">
          <t>Many
        <ol spacing="normal" type="1">
          <li>Many phones in on the market as of this writing still do not accept
          large payloads.  The restriction is typically either 512 or 1024
          ASCII characters.</t>
		  <t>On characters.</li>
          <li>On a slow connection such as a 2G mobile connection, a large URL
          would cause the a slow response and therefore response; therefore, the use of such is not
          advisable from the user experience user-experience point of view.
		  </t>
		</list>
	</t>
		  </li>
        </ol>
        <t>
	  The contents of the resource referenced by the <spanx style="verb">request_uri</spanx>
	  MUST <tt>request_uri</tt>
	  <bcp14>MUST</bcp14> be a Request Object and MUST <bcp14>MUST</bcp14> be reachable by the Authorization Server authorization server
	  unless the URI was provided to the client by the Authorization Server. authorization server.
	  In the first case, the <spanx style="verb">request_uri</spanx> MUST <tt>request_uri</tt> <bcp14>MUST</bcp14> be
	  an <spanx style="verb">https</spanx> <tt>https</tt> URI,
	  as specified in Section 2.7.2 of <xref target="RFC7230">RFC7230</xref>. target="RFC7230"
	  sectionFormat="of" section="2.7.2"/>.
	  In the second case, it MUST <bcp14>MUST</bcp14> be a URN,
	  as specified in <xref target="RFC8141">RFC8141</xref>. target="RFC8141"/>.
        </t>

	<t>
	  <figure>
	    <preamble>The
        <t keepWithNext="true">The following is an example of
	    the contents of a Request Object resource that can be
	    referenced by a <spanx style="verb">request_uri</spanx> <tt>request_uri</tt>
	    (with line wraps within values for display purposes only):</preamble>

	    <artwork><![CDATA[ only):</t>
<sourcecode type="jwt">
  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
  ]]></artwork>
	  </figure>
	</t>
</sourcecode>
        <section anchor="CreateRequestUri"
		 title="URI anchor="CreateRequestUri">
          <name>URI Referencing the Request Object"> Object</name>
          <t>
	    The Client client stores the Request Object resource either
	    locally or remotely at a URI the Authorization Server authorization server can access.
		Such a facility may be provided by the authorization server
		or a trusted third party. For example, the authorization server may
		provide a URL to which the client POSTs the request object Request Object and
		obtains the Request URI.
	    This URI is the Request Object URI, <spanx style="verb">request_uri</spanx>. <tt>request_uri</tt>.
          </t>
          <t>
	    It is possible for the Request Object to include values that
	    are to be revealed only to the Authorization Server. authorization server.
	    As such, the <spanx style="verb">request_uri</spanx> MUST <tt>request_uri</tt> <bcp14>MUST</bcp14> have
	    appropriate entropy for its lifetime
	    so that the URI is not guessable if publicly retrievable.
	    For the guidance, refer to 5.1.4.2.2 of
	    <xref target="RFC6819" /> sectionFormat="of" section="5.1.4.2.2"/> and
	    "<xref target="CapURLs" format="title"/>" <xref target="CapURLs">Good Practices for Capability URLs</xref>. target="CapURLs"/>.
	    It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that it the <tt>request_uri</tt> be removed
		after a reasonable timeout
	    unless access control measures are taken.
          </t>
	  <figure>
	    <preamble>The
          <t keepWithNext="true">The following is an example
	    of a Request Object URI value
	      (with line wraps within values for display purposes only).
	      In this example, a trusted third-party service hosts the Request Object.
	    </preamble>

	    <artwork><![CDATA[
          </t>
<sourcecode type="url">
  https://tfp.example.org/request.jwt/
    GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
]]></artwork>
	  </figure>
</sourcecode>
        </section>
        <section anchor="UseRequestUri"
		 title='Request using anchor="UseRequestUri">
          <name>Request Using the "request_uri" Request Parameter'> Parameter</name>
          <t>The Client client sends the Authorization Request authorization request to the
	  Authorization Endpoint.</t>

	  <figure>
	    <preamble>The
	  authorization endpoint.</t>
          <t keepWithNext="true">The following is an example
	    of an Authorization Request authorization request using the <spanx style="verb">request_uri</spanx> <tt>request_uri</tt> parameter
	    (with line wraps within values for display purposes only):</preamble>

	    <artwork><![CDATA[ only):</t>

<sourcecode type="url">
  https://server.example.com/authorize?
    client_id=s6BhdRkqt3
    &request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
    &amp;request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
    %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
]]></artwork>
	  </figure>
</sourcecode>
        </section>
        <section anchor="GetRequestUri" title="Authorization anchor="GetRequestUri">
          <name>Authorization Server Fetches Request Object"> Object</name>

          <t>Upon receipt of the Request, the Authorization Server MUST authorization server
          <bcp14>MUST</bcp14> send an HTTP <spanx style="verb">GET</spanx> <tt>GET</tt> request to the <spanx style="verb">request_uri</spanx>
          <tt>request_uri</tt> to retrieve the referenced Request Object, Object
          unless it the Request Object is stored in a way so that
	  it the server can
          retrieve it through other mechanism securely, mechanisms securely and parse it to
          recreate the Authorization Request authorization request parameters.</t>

	  <figure>
	    <preamble>The
          <t keepWithNext="true">The following is an example of this fetch
          process.  In this example, a trusted third-party service hosts the
          Request Object.
	    </preamble>

	    <artwork><![CDATA[
          </t>

<sourcecode type="http-message">
GET /request.jwt/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM HTTP/1.1
Host: tfp.example.org
]]></artwork>
	  </figure>
	  <figure>
	    <preamble>The
</sourcecode>
          <t keepWithNext="true">The following is an example of the fetch
	    response:</preamble>

	    <artwork><![CDATA[
	    response:</t>
<sourcecode type="http-message">
  HTTP/1.1 200 OK
  Date: Thu, 20 Aug 2020 23:52:39 GMT
  Server: Apache/2.4.43 (tfp.example.org)
  Content-type: application/oauth-authz-req+jwt
  Content-Length: 797
  Last-Modified: Wed, 19 Aug 2020 23:52:32 GMT

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
]]></artwork>
	  </figure>
</sourcecode>
        </section>
      </section>
    </section>
    <section anchor="JWTRequestValidation" title="Validating anchor="JWTRequestValidation">
      <name>Validating JWT-Based Requests"> Requests</name>
      <section anchor="EncryptedRequestObject" title="JWE anchor="EncryptedRequestObject">
        <name>JWE Encrypted Request Object"> Object</name>
        <t>
	    If the request object Request Object is encrypted,
	    the Authorization Server MUST authorization server <bcp14>MUST</bcp14> decrypt the JWT in accordance with
	    the <xref target="RFC7516">JSON Web Encryption</xref>
	    specification.
        </t>
        <t>
		The result is a signed request object. Request Object.
        </t>
        <t>
	    If decryption fails, the Authorization Server MUST authorization server <bcp14>MUST</bcp14>
	    return an
		<spanx style="verb">invalid_request_object</spanx> <tt>invalid_request_object</tt> error to the client in
	    response to the authorization request.
        </t>
      </section>
      <section anchor="SignedRequestObject" title="JWS Signed anchor="SignedRequestObject">
        <name>JWS-Signed Request Object"> Object</name>
        <t>
	    The Authorization Server MUST authorization server <bcp14>MUST</bcp14> validate the
	    signature of the JWS-signed <xref target="RFC7515">JSON Web Signature</xref> signed target="RFC7515"/> Request
	    Object. If a <spanx style="verb">kid</spanx> <tt>kid</tt> Header Parameter is present, the key identified MUST
	    <bcp14>MUST</bcp14> be the key used, used and MUST <bcp14>MUST</bcp14> be a
	    key associated with the client. The signature MUST <bcp14>MUST</bcp14>
	    be validated using a key associated with the client and the
	    algorithm specified in the <spanx style="verb">alg</spanx> <tt>alg</tt> Header Parameter. Algorithm verification MUST <bcp14>MUST</bcp14> be performed, as specified in Sections 3.1 <xref target="RFC8725" format="default" sectionFormat="bare" section="3.1"></xref> and 3.2 <xref target="RFC8725" format="default" sectionFormat="bare" section="3.2"></xref> of <xref target="RFC8725"/>.
        </t>
        <t>
	    If the key is not associated with the client or if signature
	    validation fails, the Authorization Server MUST authorization server <bcp14>MUST</bcp14>
	    return an
		<spanx style="verb">invalid_request_object</spanx> <tt>invalid_request_object</tt> error to the client in response to the authorization request.
        </t>
      </section>
      <section anchor="RequestParameterValidation" title="Request anchor="RequestParameterValidation">
        <name>Request Parameter Assembly and Validation"> Validation</name>
        <t>
	    The Authorization Server MUST authorization server <bcp14>MUST</bcp14> extract
	    the set of Authorization Request authorization request parameters
	    from the Request Object value.
	    The Authorization Server MUST authorization server <bcp14>MUST</bcp14> only use the
	    parameters in the Request Object Object, even if the
	    same parameter is provided in the query parameter.
	    The Client client ID values in the <spanx style="verb">client_id</spanx> <tt>client_id</tt> request parameter
	    and in the Request Object <spanx style="verb">client_id</spanx> <tt>client_id</tt> claim MUST <bcp14>MUST</bcp14> be identical.
	    The Authorization Server authorization server then validates the request request,
	    as specified in <xref target="RFC6749">OAuth 2.0</xref>.
        </t>
        <t>
	    If the Client ID check or the request validation fails, then the Authorization Server MUST
	    authorization server <bcp14>MUST</bcp14> return an error to the
	    client in response to the authorization request, as specified in Section 5.2 of
	    <xref target="RFC6749">OAuth 2.0</xref>. target="RFC6749" section="5.2" sectionFormat="of"/> (OAuth 2.0).
        </t>
      </section>
    </section>

    <section title="Authorization Server Response">
      <t>Authorization
    <section>
      <name>Authorization Server Response Response</name>
      <t>The authorization server response is created and sent to the client as in
      Section 4 of
      <xref target="RFC6749">OAuth 2.0</xref>.</t> target="RFC6749" sectionFormat="of" section="4"/> (OAuth 2.0).</t>
      <t>In addition, this document uses these additional error values:
	    <list style="hanging">
          <t hangText="invalid_request_uri">
	    <vspace/>
      </t>
      <dl newline="true" spacing="normal">
        <dt>invalid_request_uri</dt>
        <dd>
	  The <spanx style="verb">request_uri</spanx> <tt>request_uri</tt> in the
		  Authorization Request
	authorization request returns an error or contains invalid data.</t>

          <t hangText="invalid_request_object">
	    <vspace/> data.</dd>
        <dt>invalid_request_object</dt>
        <dd>
	    The request parameter contains
          an invalid Request Object.</t>

		  <t hangText="request_not_supported">
		    <vspace/> Object.</dd>
        <dt>request_not_supported</dt>
        <dd>
		  The Authorization Server authorization server does not support
		  the use of the <spanx style="verb">request</spanx> parameter.</t>

		  <t hangText="request_uri_not_supported">
		    <vspace/> <tt>request</tt> parameter.</dd>
        <dt>request_uri_not_supported</dt>
        <dd>
		  The Authorization Server authorization server does not support the use of
		  the <spanx style="verb">request_uri</spanx> parameter.</t>
        </list></t> <tt>request_uri</tt> parameter.</dd>
      </dl>
    </section>
    <section anchor="tlsreq" title="TLS Requirements"> anchor="tlsreq">
      <name>TLS Requirements</name>

      <t>
	Client implementations supporting the Request Object URI method
			MUST
	<bcp14>MUST</bcp14> support TLS TLS, following
	<xref target="BCP195">Recommendations target="RFC7525">"Recommendations for Secure Use
	of Transport Layer Security (TLS) and
	Datagram Transport Layer Security (DTLS)</xref>. (DTLS)"</xref>.
      </t>
      <t>
			To protect against information disclosure and tampering,
			confidentiality protection MUST <bcp14>MUST</bcp14> be applied using TLS with a
			cipher suite that provides confidentiality and integrity protection.
      </t>
      <t> HTTP clients MUST <bcp14>MUST</bcp14> also verify the TLS server certificate, using
            DNS-ID
  			<xref target="RFC6125" />, target="RFC6125"/>, to avoid man-in-the-middle attacks.
  			  The rules and guidelines defined in
              <xref target="RFC6125" /> target="RFC6125"/> apply here, with the following considerations:
              <list style="symbols">
          		<t>
      </t>
      <ul spacing="normal">
        <li>
	  Support for DNS-ID identifier type (that is, the dNSName identity
     	  in the subjectAltName extension) is REQUIRED. <bcp14>REQUIRED</bcp14>.  Certification
     	  authorities which that issue server certificates MUST
	  <bcp14>MUST</bcp14> support
     	  the DNS-ID identifier type, and the DNS-ID identifier type MUST <bcp14>MUST</bcp14>
     	be present in server certificates.</t>
     			<t> certificates.</li>
        <li>
     	  DNS names in server certificates MAY <bcp14>MAY</bcp14> contain the
     	wildcard character "*". </t>
     			<t> <tt>*</tt>. </li>

        <li>
     	  Clients MUST NOT <bcp14>MUST NOT</bcp14> use CN-ID identifiers; a CN Common Name
     	  field (CN field) may be present in the server certificate's subject name,
     	  name but MUST NOT <bcp14>MUST NOT</bcp14> be used for authentication within
     	  the rules described in <xref target="BCP195" />. </t>
     			<t> target="RFC7525"/>. </li>
        <li>
     	  SRV-ID and URI-ID as described in Section 6.5 of <xref
	  target="RFC6125" />
     			MUST NOT sectionFormat="of" section="6.5"/>
     	  <bcp14>MUST NOT</bcp14> be used for comparison.
     			</t>
     			</list> </t>
     	</li>
      </ul>
    </section>
    <section anchor="IANA" title="IANA  Considerations"> anchor="IANA">
      <name>IANA Considerations</name>
      <section anchor="OAuthParametersRegistry" title="OAuth anchor="OAuthParametersRegistry">
        <name>OAuth Parameters Registration"> Registration</name>
        <t>Since the request object Request Object is a JWT, the core JWT claims cannot be
        used for any purpose in the request object Request Object other than for what JWT
        dictates.  Thus, they need to be have been registered as OAuth Authorization Request
        authorization request parameters to avoid future OAuth extensions
        using them with different meanings.</t>
        <t>This specification adds the following values to the "OAuth
        Parameters" registry <xref target="IANA.OAuth.Parameters"/>
        established by <xref target="RFC6749" />.</t>
			<t> <?rfc subcompact="yes"?>
				<list style='symbols'>
					<t>Name: <spanx style="verb">iss</spanx></t>
					<t>Parameter target="RFC6749"/>.</t>
        <dl spacing="compact">
          <dt>Name:</dt><dd><tt>iss</tt></dd>
          <dt>Parameter Usage Location: authorization request</t>
					<t>Change Controller: IETF</t>
					<t>Specification Document(s): Section 4.1.1 of Location:</dt><dd>authorization request</dd>
          <dt>Change Controller:</dt><dd>IETF</dd>
          <dt>Specification Document(s):</dt><dd>This document and <xref
	  target="RFC7519" /> and this document. </t>
				</list>
				<list style='symbols'>
					<t>Name: <spanx style="verb">sub</spanx></t>
					<t>Parameter sectionFormat="of" section="4.1.1"/>.</dd>
        </dl>

        <dl spacing="compact">
          <dt>Name:</dt><dd><tt>sub</tt></dd>
          <dt>Parameter Usage Location: authorization request</t>
					<t>Change Controller: IETF</t>
					<t>Specification Document(s): Section 4.1.2 of Location:</dt><dd>authorization request</dd>
          <dt>Change Controller:</dt><dd>IETF</dd>
          <dt>Specification Document(s):</dt><dd>This document and <xref
	  target="RFC7519" /> and this document. </t>
				</list>
				<list style='symbols'>
					<t>Name: <spanx style="verb">aud</spanx></t>
					<t>Parameter sectionFormat="of" section="4.1.2"/>.</dd>
        </dl>

        <dl spacing="compact">
          <dt>Name:</dt><dd><tt>aud</tt></dd>
          <dt>Parameter Usage Location: authorization request</t>
					<t>Change Controller: IETF</t>
					<t>Specification Document(s): Section 4.1.3 of Location:</dt><dd>authorization request</dd>
          <dt>Change Controller:</dt><dd>IETF</dd>
          <dt>Specification Document(s):</dt><dd>This document and <xref
	  target="RFC7519" /> and this document. </t>
				</list>
				<list style='symbols'>
					<t>Name: <spanx style="verb">exp</spanx></t>
					<t>Parameter sectionFormat="of" section="4.1.3"/>.</dd>
        </dl>

        <dl spacing="compact">
          <dt>Name:</dt><dd><tt>exp</tt></dd>
          <dt>Parameter Usage Location: authorization request</t>
					<t>Change Controller: IETF</t>
					<t>Specification Document(s): Section 4.1.4 of Location:</dt><dd>authorization request</dd>
          <dt>Change Controller:</dt><dd>IETF</dd>
          <dt>Specification Document(s):</dt><dd>This document and <xref
	  target="RFC7519" /> and this document. </t>
				</list>
				<list style='symbols'>
					<t>Name: <spanx style="verb">nbf</spanx></t>
					<t>Parameter sectionFormat="of" section="4.1.4"/>.</dd>
        </dl>

        <dl spacing="compact">
          <dt>Name:</dt><dd><tt>nbf</tt></dd>
          <dt>Parameter Usage Location: authorization request</t>
					<t>Change Controller: IETF</t>
					<t>Specification Document(s): Section 4.1.5 of Location:</dt><dd>authorization request</dd>
          <dt>Change Controller:</dt><dd>IETF</dd>
          <dt>Specification Document(s):</dt><dd>This document and <xref
	  target="RFC7519" /> and this document. </t>
				</list>
				<list style='symbols'>
					<t>Name: <spanx style="verb">iat</spanx></t>
					<t>Parameter sectionFormat="of" section="4.1.5"/>.</dd>
        </dl>

        <dl spacing="compact">
          <dt>Name:</dt><dd><tt>iat</tt></dd>
          <dt>Parameter Usage Location: authorization request</t>
					<t>Change Controller: IETF</t>
					<t>Specification Document(s): Section 4.1.6 of Location:</dt><dd>authorization request</dd>
          <dt>Change Controller:</dt><dd>IETF</dd>
          <dt>Specification Document(s):</dt><dd>This document and <xref
	  target="RFC7519" /> and this document. </t>
				</list>
				<list style='symbols'>
					<t>Name: <spanx style="verb">jti</spanx></t>
					<t>Parameter sectionFormat="of" section="4.1.6"/>.</dd>
        </dl>

        <dl spacing="compact">
          <dt>Name:</dt><dd><tt>jti</tt></dd>
          <dt>Parameter Usage Location: authorization request</t>
					<t>Change Controller: IETF</t>
					<t>Specification Document(s): Section 4.1.7 of Location:</dt><dd>authorization request</dd>
          <dt>Change Controller:</dt><dd>IETF</dd>
          <dt>Specification Document(s):</dt><dd>This document and <xref
	  target="RFC7519" /> and this document. </t>
				</list>
			</t> sectionFormat="of" section="4.1.7"/>.</dd>
        </dl>
      </section>
      <section anchor="OAuthAuthorizationServerMetadataRegistry" title="OAuth anchor="OAuthAuthorizationServerMetadataRegistry">
        <name>OAuth Authorization Server Metadata Registry"> Registry</name>
        <t>This specification adds the following value to the "OAuth
        Authorization Server Metadata" registry <xref
        target="IANA.OAuth.Parameters"/> established by <xref target="RFC8414" />.</t>
			<t> <?rfc subcompact="yes"?>
				<list style='symbols'>
					<t>Metadata Name: <spanx style="verb">require_signed_request_object</spanx></t>
					<t>Metadata Description: Indicates
        target="RFC8414"/>.</t>
        <dl spacing="compact">
          <dt>Metadata Name:</dt><dd><tt>require_signed_request_object</tt></dd>
          <dt>Metadata Description:</dt><dd>Indicates where authorization
	  request needs to be protected as Request Object and provided through
	  either <spanx style="verb">request</spanx> <tt>request</tt> or <spanx style="verb">request_uri parameter</spanx>. </t>
					<t>Change Controller: IETF</t>
					<t>Specification Document(s): Section 10.5 <tt>request_uri parameter</tt>.</dd>
          <dt>Change Controller:</dt><dd>IETF</dd>
          <dt>Specification Document(s):</dt><dd><xref
	  target="require_signed_request_object"/> of this document. </t>
				</list>
            </t> document.</dd>
        </dl>
      </section>
      <section anchor="OAuthDynamicClientRegistrationMetadataRegistry" title="OAuth anchor="OAuthDynamicClientRegistrationMetadataRegistry">
        <name>OAuth Dynamic Client Registration Metadata Registry"> Registry</name>
        <t>This specification adds the following value to the "OAuth Dynamic
        Client Registration Metadata" registry <xref
        target="IANA.OAuth.Parameters"/> established by <xref target="RFC7591" />.</t>
			<t> <?rfc subcompact="yes"?>
				<list style='symbols'>
					<t>Metadata Name: <spanx style="verb">require_signed_request_object</spanx></t>
					<t>Metadata Description: Indicates
        target="RFC7591"/>.</t>
        <dl spacing="compact">
          <dt>Metadata Name:</dt><dd><tt>require_signed_request_object</tt></dd>
          <dt>Metadata Description:</dt><dd>Indicates where authorization
	  request needs to be protected as Request Object and provided through
	  either <spanx style="verb">request</spanx> <tt>request</tt> or <spanx style="verb">request_uri parameter</spanx>. </t>
					<t>Change Controller: IETF</t>
					<t>Specification Document(s): Section 10.5 <tt>request_uri parameter</tt>. </dd>
          <dt>Change Controller:</dt><dd>IETF</dd>
          <dt>Specification Document(s):</dt><dd><xref target="require_signed_request_object"/> of this document. </t>
				</list>
            </t> document.</dd>
        </dl>
      </section>
      <section title="Media Type Registration" anchor="MediaReg">
        <name>Media Type Registration</name>
        <section title="Registry Contents" anchor="MediaContents">
          <name>Registry Contents</name>
          <t>
                    This section registers the
                    <spanx style="verb">application/oauth-authz-req+jwt</spanx>
                    <tt>application/oauth-authz-req+jwt</tt>
                    media type <xref target="RFC2046"/> in the "Media Types"
                    registry <xref target="IANA.MediaTypes"/> in the manner
                    described in <xref target="RFC6838"/>, which target="RFC6838"/>. It can be used to
                    indicate that the content is a JWT containing Request
                    Object claims.
          </t>
                <t> <?rfc subcompact="yes"?>
                    <list style="symbols">
                        <t>
                            Type name: application
                        </t>
                        <t>
                            Subtype name: oauth-authz-req+jwt
                        </t>
                        <t>
                            Required parameters: n/a
                        </t>
                        <t>
                            Optional parameters: n/a
                        </t>
                        <t>
                            Encoding considerations: binary;
                            A
          <dl spacing="compact">
            <dt>Type name:</dt><dd>application</dd>
            <dt>Subtype name:</dt><dd>oauth-authz-req+jwt</dd>
            <dt>Required parameters:</dt><dd>N/A</dd>
            <dt>Optional parameters:</dt><dd>N/A</dd>
            <dt>Encoding considerations:</dt><dd>binary;
            a Request Object 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 (<tt>.</tt>) characters.</dd>
            <dt>Security considerations:</dt><dd>See <xref target="Security"/>
	    of [[ this specification ]]
                        </t>
                        <t>
                            Interoperability considerations: n/a
                        </t>
                        <t>
                            Published specification: <xref RFC 9101</dd>
            <dt>Interoperability considerations:</dt><dd>N/A</dd>
            <dt>Published specification:</dt><dd><xref
	    target="authorization_request_object"/> of [[ this specification ]]
                        </t>
                        <t>
                            Applications RFC 9101</dd>
            <dt>Applications that use this media type:
                            Applications type:</dt><dd>Applications
	    that use Request Objects to make an OAuth 2.0 Authorization Request
                        </t>
                        <t>
                            Fragment authorization
	    request</dd>
            <dt>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 considerations:</dt><dd>N/A</dd>
            <dt>Additional information:</dt><dd>
	    <t><br/></t>
	    <dl spacing="compact">
	      <dt>Deprecated alias names for this type:</dt><dd>N/A</dd>
	      <dt>Magic number(s):</dt><dd>N/A</dd>
	      <dt>File extension(s):</dt><dd>N/A</dd>
	      <dt>Macintosh file type code(s): n/a </t></list>
                            <vspace/>
                        </t>
                        <t>
                            Person code(s):</dt><dd>N/A</dd>
	    </dl>
            </dd>
            <dt>Person &amp; email address to contact for further information:
                            <vspace/>
                            Nat Sakimura, nat@nat.consulting
                        </t>
                        <t>
                            Intended usage: COMMON
                        </t>
                        <t>
                            Restrictions
	    information:</dt><dd><br/>Nat Sakimura &lt;nat@nat.consulting&gt;</dd>
            <dt>Intended usage:</dt><dd>COMMON</dd>
            <dt>Restrictions on usage: none
                        </t>
                        <t>
                            Author: Nat Sakimura, nat@nat.consulting
                        </t>
                        <t>
                            Change controller: IETF
                        </t>
                        <t>
                            Provisional registration? No
                        </t>
                    </list>
                </t> usage:</dt><dd>none</dd>
            <dt>Author:</dt><dd>Nat Sakimura &lt;nat@nat.consulting&gt;</dd>
            <dt>Change controller:</dt><dd>IETF</dd>
            <dt>Provisional registration?</dt><dd>No</dd>
          </dl>
        </section>
            <?rfc subcompact="no"?>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> anchor="Security">
      <name>Security Considerations</name>
      <t>In addition to the all the <xref target="RFC6819">
      the security
      considerations discussed in OAuth 2.0</xref>, the security
      considerations in <xref target="RFC7515" />, target="RFC7515"/>, <xref target="RFC7516" />, target="RFC7516"/>,
      <xref target="RFC7518" />, target="RFC7518"/>, and <xref target="RFC8725" /> target="RFC8725"/> need to be
      considered.  Also, there are several academic papers such as <xref target="BASIN" />
      target="BASIN"/> that provide useful insight into the security
      properties of protocols like OAuth.
      </t>

      <t>
	  In consideration of the above, this document advises taking the
	  following security considerations into account.
      </t>

      <section anchor="alg_choice" title="Choice anchor="alg_choice">
        <name>Choice of Algorithms"> Algorithms</name>
        <t>When sending the authorization request object Authorization Request Object through <spanx
		  style="verb">request</spanx> the
	<tt>request</tt> parameter, it MUST either <bcp14>MUST</bcp14> be either
	signed using <xref target="RFC7515">JWS</xref>
	or signed and then encrypted using <xref target="RFC7515">JWS</xref> and
	<xref target="RFC7516">JWE</xref> target="RFC7516">JWE</xref>, respectively,
	with then algorithms considered appropriate algorithms. at the time. </t>
      </section>
      <section anchor="src_authn" title="Request anchor="src_authn">
        <name>Request Source Authentication"> Authentication</name>
        <t>
	  The source of the Authorization Request MUST authorization request <bcp14>MUST</bcp14> always be
	  verified. There are several ways to do it:
        </t>
		<t><list style="format (%c)">
			<t>Verifying
        <ol spacing="normal" type="(%c)">
          <li>Verifying the JWS Signature of the Request Object.</t>
			<t>Verifying Object.</li>
          <li>Verifying that the symmetric key for the JWE encryption is the
          correct one if the JWE is using symmetric encryption.
			Note Note, however,
          that if public key encryption is used, no source authentication is
          enabled by the encryption, as any party can encrypt content to the public key.
			</t>
			<t>Verifying
          key.</li>
          <li>Verifying the TLS Server Identity of the Request Object URI.
	  In this case, the Authorization Server MUST authorization server <bcp14>MUST</bcp14> know
	  out-of-band that the Client client uses the Request Object URI and
	  only the Client client is covered by the TLS certificate.
	  In general, it this is not a reliable method.
			</t>
			<t>When
	  </li>
          <li>When an Authorization Server authorization server implements a service
	  that returns a Request Object URI in exchange for
	  a Request Object, the Authorization
			Server MUST authorization
	  server <bcp14>MUST</bcp14> perform Client Authentication client authentication to accept
	  the Request Object and bind the Client Identifier client identifier
	  to the Request Object URI it is providing.
	  It MUST <bcp14>MUST</bcp14> validate the signature, per (a).
	  Since the Request Object URI can be replayed, the lifetime
	  of the Request Object URI MUST <bcp14>MUST</bcp14> be short and preferably
	  one-time use. The entropy of the Request Object URI
			MUST
			<bcp14>MUST</bcp14> be sufficiently large.
            The adequate shortness of the validity and
            the entropy of the Request Object URI depends
            on the risk calculation based on the value
            of the resource being protected. A general guidance
            for the validity time would be less than a minute minute,
            and the Request Object URI is to include a cryptographic
            random value of 128bit 128 bits or more at the time of the
            writing of this specification.
			</t>
			<t>
			  When
			</li>
          <li>When a trusted third-party service returns a Request Object URI
          in exchange for a Request Object, it MUST <bcp14>MUST</bcp14> validate
          the signature, per (a).  In addition, the Authorization Server
			MUST authorization server
          <bcp14>MUST</bcp14> be trusted by the third-party service and
			MUST
          <bcp14>MUST</bcp14> know out-of-band that the client is also trusted by it.
			</t>
		</list></t>
	</li>
        </ol>
      </section>
      <section anchor="explicit_endpoints" title="Explicit Endpoints"> anchor="explicit_endpoints">
        <name>Explicit Endpoints</name>

        <t>
	      Although this specification does not require them,
	      research such as <xref target="BASIN" /> target="BASIN"/> points out that
	      it is a good practice to explicitly state
	      the intended interaction endpoints and the message
	      position in the sequence in a tamper evident tamper-evident
	      manner so that the intent of the initiator is unambiguous.
	      The It
	      is <bcp14>RECOMMENDED</bcp14> by this specification to use this
	      practice for the following endpoints defined in <xref target="RFC6749" />,
	      target="RFC6749"/>, <xref target="RFC6750" />, target="RFC6750"/>, and <xref target="RFC8414" /> are
	      RECOMMENDED by this specification to use this practice :
	      target="RFC8414"/>:
        </t>
	    <t><list style="format (%c)">
	      <t>Protected Resources (<spanx style="verb">protected_resources</spanx>)</t>
	      <t>Authorization Endpoint (<spanx style="verb">authorization_endpoint</spanx>)</t>
	      <t>Redirection URI (<spanx style="verb">redirect_uri</spanx>)</t>
	      <t>Token Endpoint (<spanx style="verb">token_endpoint</spanx>)</t>
	    </list></t>
        <ol spacing="normal" type="(%c)">
          <li>Protected resources (<tt>protected_resources</tt>)</li>
          <li>Authorization endpoint (<tt>authorization_endpoint</tt>)</li>
          <li>Redirection URI (<tt>redirect_uri</tt>)</li>
          <li>Token endpoint (<tt>token_endpoint</tt>)</li>
        </ol>
        <t>
	      Further, if dynamic discovery is used, then this practice also applies
	      to the discovery related discovery-related endpoints.
        </t>
        <t>
	      In <xref target="RFC6749" />, target="RFC6749"/>,
	      while Redirection the redirection URI is included in the Authorization Request, authorization request, others
	      are not. As a result, the same applies to the Authorization
	      Request Object.
        </t>

      </section>
      <section anchor="request_uri_threats" title="Risks anchor="request_uri_threats">
        <name>Risks Associated with request_uri"> request_uri</name>
        <t>
	        The introduction of <spanx style="verb">request_uri</spanx> <tt>request_uri</tt>
	        introduces several attack possibilities.
	        Consult the security considerations in Section 7 of
	        <xref target="RFC3986">RFC3986</xref> target="RFC3986" sectionFormat="of"
		      section="7"/> for more information
		regarding
	        risks associated with URIs.
        </t>
        <section anchor="ddos_on_authz_server" title="DDoS anchor="ddos_on_authz_server">
          <name>DDoS Attack on the Authorization Server"> Server</name>
          <t>
	        A set of malicious client clients can launch a DoS attack
	        to the authorization server by pointing the
	        <spanx style="verb">request_uri</spanx>
	        <tt>request_uri</tt> to a URI
	        that returns extremely large content or is extremely slow to respond.
	        Under such an attack, the server may use up its resource
	        and start failing.
          </t>
          <t>
	        Similarly, a malicious client can specify the
		<spanx style="verb">request_uri</spanx> a
		<tt>request_uri</tt> value
		that itself points to an authorization request URI
		that uses <spanx style="verb">request_uri</spanx> <tt>request_uri</tt> to
		cause the recursive lookup.
          </t>
          <t>
	        To prevent such an attack to succeed, from succeeding, the server should
	        (a)
	        a) check that the value of <spanx style="verb">request_uri</spanx> the <tt>request_uri</tt>
	        parameter does not point to an unexpected location,
	        (b)
	        b) check that the media type of the response is
	        <spanx style="verb">application/oauth-authz-req+jwt</spanx>,
	        (c)
	        <tt>application/oauth-authz-req+jwt</tt>,
	        c) implement a time-out timeout for obtaining the content of
	        <spanx style="verb">request_uri</spanx>,
	        <tt>request_uri</tt>, and
		(d)
		d) not perform recursive GET on the
		<spanx style="verb">request_uri</spanx>.
		<tt>request_uri</tt>.
          </t>
        </section>
        <section anchor="request_uri_rewrite" title="Request anchor="request_uri_rewrite">
          <name>Request URI Rewrite"> Rewrite</name>
          <t>
	        The value of <spanx style="verb">request_uri</spanx> <tt>request_uri</tt> is not signed
	        thus signed;
	        thus, it can be tampered with by Man-in-the-browser a man-in-the-browser attacker.
	        Several attack possibilities rise arise because of this, e.g.,
	        (a) this. For
		example,
	        a) an attacker may create another file that the rewritten
	        URI points to to, making it possible to request extra scope
	        (b) scope, or
	        b) an attacker launches may launch a DoS attack to on a victim site
	        by setting the value of <spanx style="verb">request_uri</spanx> <tt>request_uri</tt>
	        to be that of the victim.
          </t>
          <t>
	        To prevent such an attack to succeed, from succeeding, the server should
	        (a)
	        a) check that the value of <spanx style="verb">request_uri</spanx> the <tt>request_uri</tt>
	        parameter does not point to an unexpected location,
	        (b)
	        b) check that the media type of the response is
	        <spanx style="verb">application/oauth-authz-req+jwt</spanx>,
	        <tt>application/oauth-authz-req+jwt</tt>, and
	        (c)
	        c) implement a time-out timeout for obtaining the content of
	        <spanx style="verb">request_uri</spanx>.
	        <tt>request_uri</tt>.
          </t>
        </section>
      </section>
      <section anchor="require_signed_request_object" title="Downgrade Attack"> anchor="require_signed_request_object">
        <name>Downgrade Attack</name>
        <t>
            Unless the protocol used by the client and the server is locked down to
            use an OAuth JAR, JWT-Secured Authorization Request (JAR), it is possible
	    for an attacker to use RFC6749 RFC 6749 requests
            to bypass all the protection provided by this specification.
        </t>
        <t>
	  To prevent it, this kind of attack, this specification defines a new
	  client metadata and server metadata <spanx style="verb">require_signed_request_object</spanx> values, both named
	  <tt>require_signed_request_object</tt>, whose value is a boolean. values are both
	  booleans.
        </t>
        <t>
            When the value of it as a client metadata is <spanx style="verb">true</spanx>, <tt>true</tt>, then the
            server MUST <bcp14>MUST</bcp14> reject the authorization request from
            the client that does not conform to this specification.  It MUST
            <bcp14>MUST</bcp14> also reject the request if the request object Request Object
            uses "alg":"none" an <tt>alg</tt> value of <tt>none</tt> when this client server
            metadata value is <spanx style="verb">true</spanx>. <tt>true</tt>.  If omitted, the default value is <spanx style="verb">false</spanx>.
            <tt>false</tt>.
        </t>

        <t>
            When the value of it as a server metadata is <spanx style="verb">true</spanx>, <tt>true</tt>, then the
            server MUST <bcp14>MUST</bcp14> reject the authorization request from
            any client that does not conform to this specification.  It MUST
            <bcp14>MUST</bcp14> also reject the request if the request object Request Object
            uses "alg":"none"
	    when this server metadata an <tt>alg</tt> value is <spanx style="verb">true</spanx>. of <tt>none</tt>. If omitted, the
            default value is <spanx style="verb">false</spanx>. <tt>false</tt>.
        </t>
	  <t>
	    Note
	<t>Note that even if <spanx style="verb">require_signed_request_object</spanx> <tt>require_signed_request_object</tt> metadata
	values are not present, the client MAY <bcp14>MAY</bcp14> use signed request objects, Request Objects,
	provided that there are signing algorithms mutually supported by the
	client and the server.  Use of signing algorithm metadata is described
	in <xref target="authorization_request_object"/>.
	  </t> target="authorization_request_object"/>.</t>

      </section>
      <section title="TLS Security Considerations" anchor="tls_sec">
        <name>TLS Security Considerations</name>
        <t>Current security
      considerations can be found in "<xref target="RFC7525" format="title"/>" <xref target="BCP195">Recommendations
      for Secure Use of TLS and DTLS</xref>. target="RFC7525"/>.  This
      supersedes the TLS version recommendations in <xref target="RFC6749">OAuth
        2.0</xref>.</t>
      </section>
      <section title="Parameter Mismatches" anchor="ParameterMismatches">
        <name>Parameter Mismatches</name>
        <t>
	  Given that OAuth parameter values are being sent in two different places,
	  as normal OAuth parameters and as Request Object claims,
	  implementations must guard against attacks that could use mismatching
	  parameter values to obtain unintended outcomes.
	  That is the reason that the two Client client ID values MUST <bcp14>MUST</bcp14> match,
	  the reason that only the parameter values from the Request Object are to be used,
	  and the reason that neither <spanx style="verb">request</spanx> <tt>request</tt> nor
	  <spanx style="verb">request_uri</spanx>
	  <tt>request_uri</tt> can appear in a Request Object.
        </t>
      </section>
      <section title="Cross-JWT Confusion" anchor="CrossJWT">
        <name>Cross-JWT Confusion</name>
        <t>
	  As described in Section 2.8 of <xref target="RFC8725"/>, target="RFC8725"
	  sectionFormat="of" section="2.8"/>,
	  attackers may attempt to use a JWT issued for one purpose in a context that it was not intended for.
	  The mitigations described for these attacks can be applied to Request Objects.
        </t>
        <t>
	  One way that an attacker might attempt to repurpose a Request Object
	  is to try to use it as a client authentication JWT,
	  as described in Section 2.2 of <xref target="RFC7523"/>. target="RFC7523"
	  sectionFormat="of" section="2.2"/>.
	  A simple way to prevent this is to never use the Client client ID
	  as the <spanx style="verb">sub</spanx> <tt>sub</tt> value in a Request Object.
        </t>
        <t>
	  Another way to prevent cross-JWT confusion is to use explicit typing,
	  as described in Section 3.11 of <xref target="RFC8725"/>. target="RFC8725"
	  sectionFormat="of" section="3.11"/>.
	  One would explicitly type a Request Object by including a
	  <spanx style="verb">typ</spanx>
	  <tt>typ</tt> Header Parameter with the value
	  <spanx style="verb">oauth-authz-req+jwt</spanx>
	  <tt>oauth-authz-req+jwt</tt>
	  (which is registered in <xref target="MediaContents"/>.
	  Note target="MediaContents"/>).
	  Note, however, that requiring explicitly typed Requests Request Objects
	  at existing authorization servers will break most existing deployments,
	  as existing clients are already commonly using untyped Request Objects,
	  especially with OpenID Connect <xref target="OpenID.Core"/>.
	  However, requiring explicit typing would be a good idea
	  for new OAuth deployment profiles where compatibility with existing deployments
	  is not a consideration.
        </t>
<t>
  Finally, yet another way to prevent cross-JWT confusion is to use a key
  management regime in which keys used to sign Request Objects are
  identifiably distinct from those used for other purposes.  Then, if an
  adversary attempts to repurpose the Request Object in another context, a key
  mismatch will occur, thwarting the attack.
</t>
      </section>
    </section>
    <section anchor="Privacy" title="Privacy Considerations"> anchor="Privacy">
      <name>Privacy Considerations</name>

      <t>
			When the Client client is being granted access to a protected resource
			containing personal data, both the Client client
			and the Authorization Server authorization server need to adhere to
			Privacy Principles.
			"<xref target="RFC6973" format="title"/>"
			<xref target="RFC6973">
			RFC 6973 Privacy Considerations for Internet Protocols
			</xref> target="RFC6973" />
			gives excellent guidance on the
			enhancement of protocol design and implementation.
			The provision provisions listed in it should be followed.
      </t>
      <t>
			Most of the provision provisions would apply to
			"<xref target="RFC6749" format="title"/>" <xref target="RFC6749">The OAuth 2.0 Authorization Framework</xref> target="RFC6749"/>
			and "<xref target="RFC6750" format="title"/>" <xref target="RFC6750">
			The OAuth 2.0 Authorization Framework:
			Bearer Token Usage</xref> target="RFC6750"/>
			and are not specific to this specification.
			In what follows, only the specific provisions specific
			to this specification are noted.
      </t>
      <section anchor="collection_limitation" title="Collection limitation"> anchor="collection_limitation">
        <name>Collection Limitation</name>
        <t>
	When the Client client is being granted access to a protected resource
	containing personal data, the Client SHOULD client <bcp14>SHOULD</bcp14> limit the
	collection of personal data to that which is within the bounds of
	applicable law and strictly necessary for the specified purpose(s).
        </t>
        <t>
	It is often hard for the user to find out if the personal data asked
	for is strictly necessary.  A trusted third-party service can help the
	user by examining the Client request and client request, comparing it to the proposed
	processing by the Client client, and certifying the request. After the
	certification, the Client, client, when making an Authorization Request, authorization request, can
	submit Authorization Request an authorization request to the trusted third-party service to
	obtain the Request Object URI.  This process is has two steps:
				<list style="format (%d)">
				<t>(Certification
        </t>
        <ol spacing="normal" type="(%d)">
          <li>(Certification Process) The trusted third-party service examines
          the business process of the client and determines what claims they need:
				This
          need; this is the certification process. Once the client is
          certified,
				then they are issued a client credential to authenticate
          against to push request objects Request Objects to the trusted third-party service
          to get the
				<spanx style="verb">request_uri</spanx>.</t>
				<t>(Translation <tt>request_uri</tt>.</li>
          <li>(Translation Process) The client uses the client credential that
          it got to push the request object Request Object to the trusted third-party service
          to get the
				<spanx style="verb">request_uri</spanx>. <tt>request_uri</tt>.  The trusted third-party service
          also verifies that the Request Object is consistent with the claims
          that the client is eligible for, per the prior step.
				</t>
				</list>
			</t>
				</li>
        </ol>
        <t>
	Upon receiving such a Request Object URI in the Authorization
				Request, authorization request,
	the Authorization Server authorization server first verifies that the authority portion of
	the Request Object URI is a legitimate one for the trusted third-party
	service.  Then, the Authorization Server authorization server issues an HTTP GET request to
	the Request Object URI.  Upon connecting, the Authorization Server MUST authorization server
	<bcp14>MUST</bcp14> verify that the server identity represented in the
	TLS certificate is legitimate for the Request Object URI.  Then, the Authorization Server
	authorization server can obtain the Request Object, which includes the <spanx style="verb">client_id</spanx>
	<tt>client_id</tt> representing the Client. client.
        </t>
        <t>
	The Consent screen
				MUST <bcp14>MUST</bcp14> indicate the Client client and SHOULD
	<bcp14>SHOULD</bcp14> indicate that the request has been vetted by the
	trusted third-party service for the adherence to the Collection Limitation collection
	limitation principle.
        </t>
      </section>
      <section anchor="disclosure_limitation" title="Disclosure Limitation">
			<section anchor="request_disclosure" title="Request Disclosure"> anchor="disclosure_limitation">
        <name>Disclosure Limitation</name>
        <section anchor="request_disclosure">
          <name>Request Disclosure</name>

          <t>
	    This specification allows extension parameters.
	    These may include potentially sensitive information.
	    Since URI query parameter parameters may leak through various
	    means but most notably through referrer and browser history,
	    if the authorization request contains a potentially sensitive
	    parameter, the Client SHOULD
					<xref target="RFC7516">JWE</xref> client <bcp14>SHOULD</bcp14> encrypt
	    the request object. Request Object using <xref target="RFC7516">JWE</xref>.
          </t>

          <t>
	    Where the Request Object URI method is being used, if the request object Request
	    Object contains personally identifiable or sensitive information,
	    the <spanx style="verb">request_uri</spanx> SHOULD <tt>request_uri</tt> <bcp14>SHOULD</bcp14> be used only once, once
	    and have a short validity period, and MUST it <bcp14>MUST</bcp14> have large enough
	    sufficient entropy
					deemed necessary with for the applicable security policy policies unless the
	    Request Object itself is encrypted using <xref target="RFC7516">JWE</xref> Encrypted.
	    target="RFC7516">JWE</xref>. The adequate shortness of the
	    validity and the entropy of the Request Object URI depends on the
	    risk calculation based on the value of the resource being
	    protected. A general guidance for the validity time would be less
	    than a minute minute, and the Request Object URI is to include a
	    cryptographic random value of 128bit 128 bits or more at the time of the
	    writing of this specification.

          </t>
        </section>
        <section anchor="tracking" title="Tracking using anchor="tracking">
          <name>Tracking Using Request Object URI"> URI</name>
          <t>
	    Even if the protected resource does not include a
	    personally identifiable information,
	    it is sometimes possible to identify the user
	    through the Request Object URI if persistent static per-user
	    Request Object URIs are used. A third party may observe
	    it through browser history history, etc. and start correlating
	    the user's activity using it.
	    In a way, it is a data disclosure as well and
	    should be avoided.
          </t>
          <t>
	    Therefore, per-user persistent Request Object URIs should be avoided.
	    Single-use Request Object URIs are one alternative.
          </t>
        </section>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
	  <t>
	    The following people contributed to the creation of this document
	    in the OAuth working group and other IETF roles.
	    (Affiliations at the time of the contribution are used.)
	  </t>

	  <t>
	    Annabelle Backman (Amazon),
	    Dirk Balfanz (Google),
	    Sergey Beryozkin,
	    Ben Campbell (as AD),
	    Brian Campbell (Ping Identity),
	    Roman Danyliw (as AD),
	    Martin Duke (as AD),
	    Vladimir Dzhuvinov (Connect2id),
	    Lars Eggert (as AD),
	    Joel Halpern (as GENART),
	    Benjamin Kaduk (as AD),
	    Stephen Kent (as SECDIR),
	    Murray Kucherawy (as AD),
	    Warren Kumari (as OPSDIR),
	    Watson Ladd (as SECDIR),
	    Torsten Lodderstedt (yes.com),
	    Jim Manico,
	    Axel Nennker (Deutsche Telecom),
	    Hannes Tschofenig (ARM),
	    James H. Manger (Telstra),
	    Kathleen Moriarty (as AD),
	    John Panzer (Google),
	    Francesca Palombini (as AD),
	    David Recordon (Facebook),
	    Marius Scurtescu (Google),
	    Luke Shepard (Facebook),
	    Filip Skokan (Auth0),
	    Éric Vyncke (as AD),
	    and
	    Robert Wilton (as AD).
	  </t>

      <t>The following people contributed to creating this document through <xref
      target="OpenID.Core">the OpenID Connect Core 1.0</xref>.</t>

      <t>
	  Brian Campbell (Ping Identity),
	  George Fletcher (AOL),
	  Ryo Itou (Mixi),
	  Edmund Jay (Illumila),
	  Breno de Medeiros (Google),
	  Hideki Nara (TACT),
	  Justin Richer (MITRE).
	  </t>
    </section>
	<section title="Revision History" anchor="hist">
		<t>Note to the RFC Editor: Please remove this section
			from the final RFC. </t>

		<t>-34</t>
		<t>
		  <list style="symbols">
		    <t>
		      Addressed additional IESG comments by Murray Kucherawy and Francesca Palombini.
		    </t>
		  </list>
		</t>

		<t>-33</t>
		<t>
		  <list style="symbols">
		    <t>
		      Addressed IESG comments prior to 8-Apr-21 telechat.
		      Thanks to Martin Duke, Lars Eggert, Benjamin Kaduk, Francesca Palombini, and Éric Vyncke for their reviews.
		    </t>
		  </list>
		</t>

		<t>-32</t>
		<t>
		  <list style="symbols">
		    <t>
		      Removed outdated JSON reference.
		    </t>
		  </list>
		</t>

		<t>-31</t>
		<t>
		  <list style="symbols">
		    <t>
		      Addressed SecDir review comments by Watson Ladd.
		    </t>
		  </list>
		</t>

		<t>-30</t>
		<t>
		  <list style="symbols">
		    <t>
		      Changed the MIME Type from "oauth.authz.req+jwt" to "oauth-authz-req+jwt",
		      per advice from the designated experts.
		    </t>
		  </list>
		</t>

		<t>-29</t>
		<t>
		  <list style="symbols">
		    <t>
		      Uniformly use the Change Controller "IETF".
		    </t>
		  </list>
		</t>

		<t>-28</t>
		<t>
		  <list style="symbols">
		    <t>
		      Removed unused references, as suggested by Roman Danyliw.
		    </t>
		  </list>
		</t>

		<t>-27</t>
		<t>
		  <list style="symbols">
		    <t>
		      Edits by Mike Jones to address IESG and working group review comments, including:
		    </t>
		    <t>
		      Added Security Considerations text saying not to use the Client ID
		      as the <spanx style="verb">sub</spanx> value
		      to prevent Cross-JWT Confusion.
		    </t>
		    <t>
		      Added Security Considerations text about using explicit typing
		      to prevent Cross-JWT Confusion.
		    </t>
		    <t>
		      Addressed Éric Vyncke's review comments.
		    </t>
		    <t>
		      Addressed Robert Wilton's review comments.
		    </t>
		    <t>
		      Addressed Murray Kucherawy's review comments.
		    </t>
		    <t>
		      Addressed Benjamin Kaduk's review comments.
		    </t>
		    <t>
		      Applied spelling and grammar corrections.
		    </t>
		  </list>
		</t>

		<t>-20</t>
		<t>
			<list style="symbols">
				<t>BK comments </t>
				<t>Section 3 Removed WAP </t>
				<t>Section 4.  Clarified authorization request object parameters,
					removed extension parameters from examples </t>
				<t>Section 4.  Specifies application/oauth.authz.req+jwt as mime-type fore request objects</t>
				<t>Section 5.2.1 Added reference to Capability URLs </t>
				<t>Section 5.2.3. Added entropy fragment to example request</t>
				<t>Section 8.  Replaced "subjectAltName dnsName" with "DNS-ID"</t>
				<t>Section 9. Registers authorization request parameters in JWT Claims Registry.  </t>
				<t>Section 9. Registers application/oauth.authz.req in IANA mime-types registry </t>
				<t>Section 10.1.  Clarified encrypted request objects are "signed then encrypted" to maintain consistency</t>
				<t>Section 10.2.  Clarifies trust between AS and TFP</t>
				<t>Section 10.3. Clarified endpoints subject to the practice </t>
				<t>Section 10.4  Replaced "redirect_uri" to "request_uri" </t>
				<t>Section 10.4. Added reference to RFC 3986 for risks </t>
				<t>Section 10.4.1.d Deleted "do" to maintain grammar flow </t>
				<t>Section 10.4.1, 10.4.2  Replaced "application/jose" to "application/jwt"</t>
				<t>Section 12.1. Extended description for submitting authorization request to TFP to obtain request object</t>
				<t>Section 12.2.2.  Replaced per-user Request Object URI with static per-user Request URIs</t>
				<t>Section 13. Combined OAuth WG contributors together</t>
				<t>Section Whole doc Replaced application/jwt with application/oauth.authz.req+jwt </t>
			</list>
		</t>

		<t>-19</t>
		<t>
			<list style="symbols">
			<t>AD comments </t>
			<t>Section 5.2.1.  s/Requiest URI/Request URI/ </t>
			<t>Section 8  s/[BCP195] ./[BCP195]./ </t>
			<t>Section 10.3.  s/sited/cited/</t>
			<t>Section 11.  Typo.  s/Curent/Current/</t>
			</list>
		</t>
		<t>-17</t>
		<t>
			<list style="symbols">
			<t>#78 Typos in content-type </t>
			</list>
		</t>
		<t>-16</t>
		<t>
			<list style="symbols">
			<t>Treated remaining Ben Campbell comments. </t>
			</list>
		</t>
		<t>-15</t>
		<t>
			<list style="symbols">
			<t>Removed further duplication</t>
			</list>
		</t>
		<t>-14</t>
		<t>
			<list style="symbols">
			<t>#71 Reiterate dynamic params are included. </t>
			<t>#70 Made clear that AS must return error.</t>
			<t>#69 Inconsistency of the need to sign.</t>
			<t>Fixed Mimetype. </t>
			<t>#67 Inconsistence in requiring HTTPS in request URI.</t>
			<t>#66 Dropped ISO 29100 reference.</t>
			<t>#25 Removed Encrypt only option.</t>
			<t>#59 Same with #25.</t>
			</list>
		</t>
		<t>-13</t>
		<t>
			<list style="symbols">
			<t>add TLS Security Consideration section</t>
			<t>replace RFC7525 reference with BCP195</t>
			<t>moved front tag in FETT reference to fix XML structure</t>
			<t>changes reference from SoK to FETT</t>
			</list>
		</t>
		<t>-12</t>
		<t>
			<list style="symbols">
				<t>fixes #62 - Alexey Melnikov Discuss </t>
				<t>fixes #48 - OPSDIR Review : General - delete semicolons after list items</t>
				<t>fixes #58 - DP Comments for the Last Call</t>
				<t>fixes #57 - GENART - Remove "non-normative ... " from examples.</t>
				<t>fixes #45 - OPSDIR Review : Introduction - are attacks discovered or already opened</t>
				<t>fixes #49 - OPSDIR Review : Introduction - Inconsistent colons after initial sentence of list items.</t>
				<t>fixes #53 - OPSDIR Review : 6.2 JWS Signed Request Object - Clarify JOSE Header</t>
				<t>fixes #42 - OPSDIR Review : Introduction - readability of 'and' is confusing</t>
				<t>fixes #50 - OPSDIR Review : Section 4 Request Object - Clarify 'signed, encrypted, or signed and encrypted'</t>
				<t>fixes #39 - OPSDIR Review : Abstract - Explain/Clarify JWS and JWE</t>
				<t>fixed #50 - OPSDIR Review : Section 4 Request Object - Clarify 'signed, encrypted, or signed and encrypted'</t>
				<t>fixes #43 - OPSDIR Review : Introduction - 'properties' sounds awkward and are not exactly 'properties'</t>
				<t>fixes #56 - OPSDIR Review : 12 Acknowledgements - 'contribution is' => 'contribution are'</t>
				<t>fixes #55 - OPSDIR Review : 11.2.2 Privacy Considerations - ' It is in a way' => 'In a way, it is'</t>
				<t>fixes #54 - OPSDIR Review : 11 Privacy Considerations - 'and not specific' => 'and are not specific'</t>
				<t>fixes #51 - OPSDIR Review : Section 4 Request Object - 'It is fine' => 'It is recommended'</t>
				<t>fixes #47 - OPSDIR Review : Introduction - 'over- the- wire' => 'over-the-wire'</t>
				<t>fixes #46 - OPSDIR Review : Introduction - 'It allows' => 'The use of application security' for</t>
				<t>fixes #44 - OPSDIR Review : Introduction - 'has' => 'have'</t>
				<t>fixes #41 - OPSDIR Review : Introduction - missing 'is' before 'typically sent'</t>
				<t>fixes #38 - OPSDIR Review : Section 11 - Delete 'freely accessible' regarding ISO 29100</t>
			</list>
		</t>
		<t>-11</t>
		<t>
			<list style="symbols">
				<t>s/bing/being/</t>
				<t>Added history for -10</t>
			</list>
		</t>
	    <t>-10</t>
		<t>
		    <list style="symbols">
				<t>#20: KM1 -- some wording that is awkward in the TLS section.
				</t>
				<t>#21: KM2 - the additional attacks against OAuth 2.0 should
				also have a pointer
				</t>
				<t>#22: KM3 -- Nit: in the first line of 10.4:
				</t>
				<t>#23: KM4 -- Mention RFC6973 in Section 11 in addition
				to ISO 29100
				</t>
				<t>#24: SECDIR review: Section 4 -- Confusing requirements
				for sign+encrypt
				</t>
				<t>#25: SECDIR review: Section 6 -- authentication and integrity
				need not be provided if the requestor encrypts the token?
				</t>
				<t>#26: SECDIR Review: Section 10 -- why no reference for
				JWS algorithms?
				</t>
				<t>#27: SECDIR Review: Section 10.2 - how to do the agreement
				between client and server "a priori"?
				</t>
				<t>#28: SECDIR Review: Section 10.3 - Indication on "large entropy"
				and "short lifetime" should be indicated
				</t>
				<t>#29: SECDIR Review: Section 10.3 - Typo
				</t>
				<t>#30: SECDIR Review: Section 10.4 - typos and missing articles</t>
				<t>#31: SECDIR Review: Section 10.4 - Clearer statement
				on the lack of endpoint identifiers needed</t>
				<t>#32: SECDIR Review: Section 11 - ISO29100 needs
				to be moved to normative reference</t>
				<t>#33: SECDIR Review: Section 11 - Better English and Entropy
				language needed</t>
				<t>#34: Section 4: Typo</t>
				<t>#35: More Acknowledgment</t>
				<t>#36: DP - More precise qualification on Encryption needed.</t>

			</list>
		</t>
	    <t>-09</t>
		<t>
		    <list style="symbols">
				<t>Minor Editorial Nits. </t>
				<t>Section 10.4 added.</t>
				<t>Explicit reference to Security consideration (10.2) added in
				   section 5 and section 5.2.</t>
				<t>, (add yourself) removed from the acknowledgment. </t>
			</list>
		</t>
	    <t>-08</t>
		<t>
		    <list style="symbols">
				<t>Applied changes proposed by Hannes on 2016-06-29 on IETF OAuth
				list recorded as https://bitbucket.org/Nat/oauth-jwsreq/issues/12/. </t>
				<t>TLS requirements added.</t>
				<t>Security Consideration reinforced.</t>
				<t>Privacy Consideration added.</t>
				<t>Introduction improved. </t>
			</list>
		</t>
		<t>-07</t>
		<t>
			<list style="symbols">
				<t>Changed the abbrev to OAuth JAR from oauth-jar. </t>
				<t>Clarified sig and enc methods. </t>
				<t>Better English.</t>
				<t>Removed claims from one of the example. </t>
				<t>Re-worded the URI construction.</t>
				<t>Changed the example to use request instead of request_uri.</t>
				<t>Clarified that Request Object parameters take precedence
				regardless of request or request_uri parameters were used. </t>
				<t>Generalized the language in 4.2.1 to convey the intent
				more clearly.</t>
				<t>Changed "Server" to "Authorization Server" as a clarification.</t>
				<t>Stopped talking about request_object_signing_alg.</t>
				<t>IANA considerations now reflect the current status.</t>
				<t>Added Brian Campbell to the contributors list.
				Made the lists alphabetic order based on the last names.
				Clarified that the affiliation is at the time of the contribution.</t>
				<t>Added "older versions of " to the reference to IE URI length
				limitations.</t>
				<t>Stopped talking about signed or unsigned JWS etc.</t>
				<t>1.Introduction improved.</t>
			</list>
		</t>
		<t>-06</t>
		<t>
			<list style="symbols">
				<t>Added explanation on the 512 chars URL restriction. </t>
				<t>Updated Acknowledgements. </t>
			</list>
		</t>
		<t>-05</t>
		<t>
			<list style="symbols">
				<t>More alignment with OpenID Connect. </t>
			</list>
		</t>
		<t>-04</t>
		<t>
			<list style="symbols">
				<t>Fixed typos in examples. (request_url -> request_uri, cliend_id -> client_id) </t>
				<t>Aligned the error messages with the OAuth IANA registry.</t>
				<t>Added another rationale for having request object.</t>
			</list>
		</t>
		<t>-03</t>
		<t>
			<list style="symbols">
				<t>Fixed the non-normative description about the advantage of static signature. </t>
				<t>Changed the requirement for the parameter values in the request itself and the request object from 'MUST MATCH" to 'Req Obj takes precedence.</t>
			</list>
		</t>
		<t>-02</t>
		<t>
			<list style="symbols">
				<t>Now that they are RFCs, replaced JWS, JWE, etc. with RFC numbers. </t>
			</list>
		</t>

		<t>-01</t>
		<t>
			<list style="symbols">
				<t>Copy Edits.</t>
			</list>
		</t>
	</section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.3629"?>
      <?rfc include="reference.RFC.3986"?>
      <?rfc include="reference.RFC.6125"?>
      <?rfc include='reference.RFC.6749'?>
      <?rfc include='reference.RFC.6750'?>
      <?rfc include='reference.RFC.7230'?>
      <?rfc include='reference.RFC.7515'?>
      <?rfc include='reference.RFC.7516'?>
      <?rfc include='reference.RFC.7518'?>
      <?rfc include='reference.RFC.7519'?>
	  <?rfc include='reference.RFC.8141'?>
	  <?rfc include='reference.RFC.8174'?>
	  <?rfc include='reference.RFC.8259'?>
	   <?rfc include='reference.RFC.8414'?>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7516.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8141.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8414.xml"/>

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

        <name>Informative References</name>

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

        <reference anchor='BCP195'>
		<front>
		<title>Recommendations for Secure Use of Transport Layer Security (TLS) and
		Datagram Transport Layer Security (DTLS)</title>
		<author initials='Y.' surname='Sheffer' fullname='Y. Sheffer'>
		<organization /></author>
		<author initials='R.' surname='Holz' fullname='R. Holz'>
		<organization /></author>
		<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
		<organization /></author>
		<date year='2015' month='May' />
		<abstract>
		<t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are
		 widely used to protect data exchanged over application protocols such as HTTP,
		 SMTP, IMAP, POP, SIP, and XMPP.  Over the last few years, several serious
		 attacks on TLS have emerged, including attacks on its most commonly used cipher
		 suites and their modes of operation.  This document provides recommendations for
		 improving the security of deployed services that use TLS and DTLS.  The
		 recommendations are applicable to the majority of use cases.</t></abstract></front>

		<seriesInfo name='BCP' value='195' />
		<seriesInfo name='RFC' value='7525' />
		<format type='TXT' octets='60283' target='http://www.rfc-editor.org/bcp/bcp195.txt' />
		</reference>

    </references>

    <references title="Informative References">

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

        <reference anchor="IANA.JWT.Claims" target="http://www.iana.org/assignments/jwt"> target="https://www.iana.org/assignments/jwt">
          <front>
            <title>JSON Web Token Claims</title> (JWT)</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>

	  <?rfc include='reference.RFC.7591'?>
      <?rfc include='reference.RFC.6819'?>
	  <?rfc include='reference.RFC.6973'?>
	  <?rfc include='reference.RFC.2046' ?>
	  <?rfc include='reference.RFC.6838' ?>
	  <?rfc include='reference.RFC.7523' ?>
	  <?rfc include='reference.RFC.8725' ?>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7591.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6819.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7523.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8725.xml"/>

        <reference anchor="OpenID.Core" target="http://openid.net/specs/openid-connect-core-1_0.html">
          <front>
            <title>OpenID Connect Core 1.0</title> 1.0 incorporating errata set 1</title>
            <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
              <organization abbrev="NAT Consulting">NAT Consulting</organization>
            </author>
            <author fullname="John Bradley" initials="J." surname="Bradley">
              <organization abbrev="Ping Identity">Ping Identity</organization>
            </author>
            <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
              <organization abbrev="Microsoft">Microsoft</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="Salesforce">Salesforce</organization>
            </author>
            <date day="25" month="February" day="8" month="November" year="2014"/>
          </front>
		<seriesInfo name="OpenID Foundation"
            value="Standards" />
	  <refcontent>OpenID Foundation Standards</refcontent>
        </reference>

        <reference anchor="BASIN" target="https://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/BCM2012-iso9798.pdf">
          <front>
            <title>Provably Repairing the ISO/IEC 9798 Standard for Entity Authentication</title>
            <author fullname="David Basin" initials="D." surname="Basin"></author> surname="Basin"/>
            <author fullname="Cas Cremers" initials="C." surname="Cremers"></author> surname="Cremers"/>
            <author fullname="Simon Meier" initials="S." surname="Meier"></author> surname="Meier"/>
            <date month="November" year="2013" /> year="2013"/>
          </front>
        <seriesInfo name="Journal
            <refcontent>Journal of Computer Security - Security and Trust Principles"
            value="Volume 21 Principles, Volume 21, Issue 6, Pages 817-846" /> pp. 817-846</refcontent>

        </reference>

        <reference anchor="CapURLs" target="https://www.w3.org/TR/capability-urls/">
          <front>
            <title>Good Practices for Capability URLs</title>
            <author fullname="Jeni Tennison" initials="J." surname="Tennison"></author> surname="Tennison" role="editor"/>
            <date day="18" month="February" year="2014" /> year="2014"/>
          </front>
            <seriesInfo name="W3C"
                        value="Working Draft" />
            <refcontent>W3C First Public Working Draft</refcontent>
        </reference>

      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>

    <t>
	    The following people contributed to the creation of this document
	    in the OAuth Working Group and other IETF roles.
	    (Affiliations at the time of the contribution are used.)
      </t>
      <t>
	    <contact fullname="Annabelle Backman"/> (Amazon),
	    <contact fullname="Dirk Balfanz"/> (Google),
	    <contact fullname="Sergey Beryozkin"/>,
	    <contact fullname="Ben Campbell"/> (as AD),
	    <contact fullname="Brian Campbell"/> (Ping Identity),
	    <contact fullname="Roman Danyliw"/> (as AD),
	    <contact fullname="Martin Duke"/> (as AD),
	    <contact fullname="Vladimir Dzhuvinov"/> (Connect2id),
	    <contact fullname="Lars Eggert"/> (as AD),
	    <contact fullname="Joel Halpern"/> (as GENART),
	    <contact fullname="Benjamin Kaduk"/> (as AD),
	    <contact fullname="Stephen Kent"/> (as SECDIR),
	    <contact fullname="Murray Kucherawy"/> (as AD),
	    <contact fullname="Warren Kumari"/> (as OPSDIR),
	    <contact fullname="Watson Ladd"/> (as SECDIR),
	    <contact fullname="Torsten Lodderstedt"/> (yes.com),
	    <contact fullname="Jim Manico"/>,
	    <contact fullname="James H. Manger"/> (Telstra),
	    <contact fullname="Kathleen Moriarty"/> (as AD),
	    <contact fullname="Axel Nennker"/> (Deutsche Telecom),
	    <contact fullname="John Panzer"/> (Google),
	    <contact fullname="Francesca Palombini"/> (as AD),
	    <contact fullname="David Recordon"/> (Facebook),
	    <contact fullname="Marius Scurtescu"/> (Google),
	    <contact fullname="Luke Shepard"/> (Facebook),
	    <contact fullname="Filip Skokan"/> (Auth0),
	    <contact fullname="Hannes Tschofenig"/> (ARM),
	    <contact fullname="Éric Vyncke"/> (as AD),
	    and
	    <contact fullname="Robert Wilton"/> (as AD).
      </t>
      <t>The following people contributed to creating this document through
      the <xref target="OpenID.Core">OpenID Connect Core 1.0</xref>.</t>
      <t>
	  <contact fullname="Brian Campbell"/> (Ping Identity), <contact
	  fullname="George Fletcher"/> (AOL), <contact fullname="Ryo Itou"/>
	  (Mixi), <contact fullname="Edmund Jay"/> (Illumila), <contact
	  fullname="Breno de Medeiros"/> (Google), <contact fullname="Hideki
	  Nara"/> (TACT), and <contact fullname="Justin Richer"/> (MITRE).
      </t>
    </section>

  </back>
</rfc>