rfc9101xml2.original.xml   rfc9101.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629
.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en"
<rfc category="std" docName="draft-ietf-oauth-jwsreq-34" ipr="trust200902"> submissionType="IETF" category="std" consensus="true"
<?rfc toc="yes"?> docName="draft-ietf-oauth-jwsreq-34" number="9101" ipr="trust200902"
<?rfc tocompact="yes"?> tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true"
<?rfc tocdepth="3"?> version="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"?>
<front> <front>
<title abbrev="OAuth JAR">The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)</title> <title abbrev="OAuth JAR">The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)</title>
<author fullname="Nat Sakimura" initials="N." <seriesInfo name="RFC" value="9101"/>
surname="Sakimura"> <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization>NAT.Consulting</organization> <organization>NAT.Consulting</organization>
<address> <address>
<postal> <postal>
<street>2-22-17 Naka</street> <street>Kunitachi</street>
<city>Kunitachi</city> <region>Tokyo 186-0004</region>
<code>186-0004</code>
<region>Tokyo</region> <extaddr>2-22-17 Naka</extaddr>
<country>Japan</country> <country>Japan</country>
</postal> </postal>
<phone>+81-42-580-7401</phone> <phone>+81-42-580-7401</phone>
<email>nat@nat.consulting</email> <email>nat@nat.consulting</email>
<uri>http://nat.sakimura.org/</uri> <uri>https://nat.sakimura.org/</uri>
</address> </address>
</author> </author>
<author fullname="John Bradley" initials="J." surname="Bradley"> <author fullname="John Bradley" initials="J." surname="Bradley">
<organization>Yubico</organization> <organization>Yubico</organization>
<address> <address>
<postal> <postal>
<street>Casilla 177, Sucursal Talagante</street> <street>Casilla 177</street>
<extaddr>Sucursal Talagante</extaddr>
<city>Talagante</city> <city>Talagante</city>
<region>RM</region> <region>RM</region>
<code/> <code/>
<country>Chile</country> <country>Chile</country>
</postal> </postal>
<phone>+1.202.630.5272</phone> <phone>+1.202.630.5272</phone>
<facsimile/> <email>rfc9101@ve7jtb.com</email>
<email>ve7jtb@ve7jtb.com</email>
<uri>http://www.thread-safe.com/</uri> <uri>http://www.thread-safe.com/</uri>
</address> </address>
</author> </author>
<author fullname="Michael B. Jones" surname="Jones" initials="M.">
<author fullname="Michael B. Jones" surname="Jones" initials="M.B.">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<postal> <postal>
<street>One Microsoft Way</street> <street>One Microsoft Way</street>
<city>Redmond</city> <city>Redmond</city>
<region>Washington</region> <region>Washington</region>
<code>98052</code> <code>98052</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>mbj@microsoft.com</email> <email>mbj@microsoft.com</email>
<uri>https://self-issued.info/</uri> <uri>https://self-issued.info/</uri>
</address> </address>
</author> </author>
<date month="August" year="2021"/>
<date day="8" month="April" year="2021"/>
<area>Security</area> <area>Security</area>
<workgroup>OAuth Working Group</workgroup> <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>Assertion</keyword>
<keyword>Claim</keyword> <keyword>Claim</keyword>
<keyword>Security Token</keyword> <keyword>Security Token</keyword>
<keyword>OAuth</keyword> <keyword>OAuth</keyword>
<keyword>JavaScript Object Notation</keyword> <keyword>JavaScript Object Notation</keyword>
<keyword>JSON</keyword> <keyword>JSON</keyword>
<keyword>JSON Web Token</keyword> <keyword>JSON Web Token</keyword>
<keyword>JWT</keyword> <keyword>JWT</keyword>
<keyword>JSON Web Signature</keyword> <keyword>JSON Web Signature</keyword>
<keyword>JWS</keyword> <keyword>JWS</keyword>
skipping to change at line 94 skipping to change at line 75
<keyword>Security Token</keyword> <keyword>Security Token</keyword>
<keyword>OAuth</keyword> <keyword>OAuth</keyword>
<keyword>JavaScript Object Notation</keyword> <keyword>JavaScript Object Notation</keyword>
<keyword>JSON</keyword> <keyword>JSON</keyword>
<keyword>JSON Web Token</keyword> <keyword>JSON Web Token</keyword>
<keyword>JWT</keyword> <keyword>JWT</keyword>
<keyword>JSON Web Signature</keyword> <keyword>JSON Web Signature</keyword>
<keyword>JWS</keyword> <keyword>JWS</keyword>
<keyword>JSON Web Encryption</keyword> <keyword>JSON Web Encryption</keyword>
<keyword>JWE</keyword> <keyword>JWE</keyword>
<abstract> <abstract>
<t>The authorization request in OAuth 2.0 described in <t>The authorization request in OAuth 2.0 described in RFC 6749 utilizes
RFC 6749 utilizes query parameter query parameter serialization, which means that authorization request
serialization, which means that Authorization Request parameters are parameters are encoded in the URI of the request and sent through user
encoded in the URI of the request and sent through user agents such as agents such as web browsers. While it is easy to implement, it means
web browsers. that a) the communication through the user agents is not integrity
While it is easy to implement, it means that protected and thus, the parameters can be tainted, b) the source of
(a) the communication through the user agents is not integrity protecte the communication is not authenticated, and c) the communication
d through the user agents can be monitored. Because of these weaknesses,
and thus the parameters can be tainted, several attacks to the protocol have now been put forward.</t>
(b) the source of the communication is not authenticated, and
(c) the communication through the user agents can be monitored.
Because of these weaknesses, several attacks to the protocol have now b
een
put forward.</t>
<t>This document introduces the ability to send request parameters in a <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 Token (JWT) instead, which allows the request to be signed with
JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so
so that the integrity, source authentication and confidentiality proper that the integrity, source authentication, and confidentiality
ty properties of the authorization request are attained. The request can
of the Authorization Request is attained. be sent by value or by reference.
The request can be sent by value or by reference.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section>
<name>Introduction</name>
<t> <t>
The Authorization Request in <xref target="RFC6749">OAuth 2.0</xref> ut The authorization request in <xref target="RFC6749">OAuth 2.0</xref>
ilizes query parameter utilizes query parameter
serialization and is typically sent through user agents such as web browse rs. serialization and is typically sent through user agents such as web browse rs.
</t>
<t>
For example, the parameters <spanx style="verb">response_type</spanx>,
<spanx style="verb">client_id</spanx>, <spanx style="verb">state</spanx>, and <s
panx style="verb">redirect_uri</spanx> are encoded in the URI of the request:
</t> </t>
<figure> <t>
<artwork><![CDATA[ For example, the parameters <tt>response_type</tt>, <tt>client_id</tt>,
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz <tt>state</tt>, and <tt>redirect_uri</tt> are encoded in the URI of the request
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 :
</t>
<sourcecode type="http-message">
GET /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 Host: server.example.com
]]></artwork> </sourcecode>
</figure> <t>
<t>
While it is easy to implement, the encoding in the URI While it is easy to implement, the encoding in the URI
does not allow application layer security to be used to does not allow application-layer security to be used to
provide confidentiality and integrity protection. provide confidentiality and integrity protection.
While TLS is used to offer communication security While TLS is used to offer communication security
between the Client and the user-agent as well as the user-agent and the between the client and the user agent as well as the user agent and the
Authorization Server, TLS sessions are terminated in the user-agent. authorization server, TLS sessions are terminated in the user agent.
In addition, TLS sessions may be terminated In addition, TLS sessions may be terminated
prematurely at some middlebox (such as a load balancer). prematurely at some middlebox (such as a load balancer).
</t> </t>
<t>
As the result, the Authorization Request of <xref target="RFC6749" /> h <t>
as As a result, the authorization request of <xref target="RFC6749"/> has
shortcomings in that: shortcomings in that:
</t> </t>
<t><list style="format (%c)"> <ol spacing="normal" type="(%c)">
<t>the communication through the user agents is <li>the communication through the user agents is
not integrity protected and thus the parameters can be tainted not integrity protected, and thus, the parameters can be tainted
(integrity protection failure)</t> (integrity protection failure);</li>
<t>the source of the communication is not authenticated <li>the source of the communication is not authenticated
(source authentication failure)</t> (source authentication failure);</li>
<t>the communication through the user agents can be monitored <li>the communication through the user agents can be monitored
(containment / confidentiality failure). </t> (containment/confidentiality failure). </li>
</list></t> </ol>
<t>
Due to these inherent weaknesses, several attacks against the protocol,
such as Redirection URI rewriting, have been identified.
</t>
<t>
The use of application layer security mitigates these issues.
</t>
<t> <t>
The use of application layer security allows requests to be prepared Due to these inherent weaknesses, several attacks against the
by a trusted third party so that a client application cannot request more protocol, such as redirection URI rewriting, have been identified.
permissions </t>
than previously agreed. <t>
The use of application-layer security mitigates these issues.
</t>
<t>
The use of 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 upon.
</t> </t>
<t> <t>
Furthermore, passing the request by reference allows the reduction of over -the-wire overhead. Furthermore, passing the request by reference allows the reduction of over -the-wire overhead.
</t> </t>
<t>The <xref target="RFC7519">JWT</xref> encoding has been chosen because <t>The <xref target="RFC7519">JWT</xref> encoding has been chosen because
of </t> of:</t>
<t><list style="format (%d)"> <ol spacing="normal" type="(%d)">
<t>its close relationship with JSON, <li>its close relationship with JSON,
which is used as OAuth's response format </t> which is used as OAuth's response format </li>
<t>its developer friendliness due to its textual nature</t> <li>its developer friendliness due to its textual nature</li>
<t>its relative compactness compared to XML </t> <li>its relative compactness compared to XML </li>
<t>its development status as a Proposed Standard, along <li>its development status as a Proposed Standard, along
with the associated signing and encryption methods with the associated signing and encryption methods
<xref target="RFC7515" /> <xref target="RFC7516" /></t> <xref target="RFC7515"/> <xref target="RFC7516"/></li>
<t>the relative ease of JWS and JWE compared to XML Signature and <li>the relative ease of JWS and JWE compared to XML Signature and Encry
Encryption. </t> ption. </li>
</list> </ol>
<t>The parameters <tt>request</tt> and <tt>request_uri</tt> are
introduced as additional authorization request parameters for the <xref
target="RFC6749">OAuth 2.0</xref> flows. The <tt>request</tt> parameter
is a <xref target="RFC7519">JSON Web Token (JWT)</xref> whose JWT Claims
Set holds the 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 <xref target="IANA.OAuth.Parameters"/>,
supplemented with only a few of the IANA-managed JSON Web Token Claims
<xref target="IANA.JWT.Claims"/>, in particular, <tt>iss</tt> and
<tt>aud</tt>. The JWT in the <tt>request</tt> parameter is integrity
protected and source authenticated using JWS.
</t> </t>
<t>The parameters <spanx style="verb">request</spanx> and <spanx <t>
style="verb">request_uri</spanx> are introduced as additional The <xref target="RFC7519">JWT</xref> can be passed to the authorizatio
authorization request parameters for the <xref target="RFC6749">OAuth n endpoint by reference,
2.0</xref> flows. The <spanx style="verb">request</spanx> parameter is a in which case the parameter <tt>request_uri</tt> is
<xref target="RFC7519">JSON Web Token (JWT)</xref> whose JWT Claims Set ho used instead of <tt>request</tt>.</t>
lds the 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 <xref target="IANA.OAuth.Parameters"/>,
supplemented with only a few of the IANA-managed
JSON Web Token Claims <xref target="IANA.JWT.Claims"/> –
in particular <spanx style="verb">iss</spanx> and <spanx style="verb">a
ud</spanx>.
The JWT in the <spanx style="verb">request</spanx> parameter is integri
ty 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> is
used instead of the <spanx style="verb">request</spanx>.</t>
<t>Using <xref target="RFC7519">JWT</xref> as the request encoding instead of query <t>Using <xref target="RFC7519">JWT</xref> as the request encoding instead of query
parameters has several advantages:</t> parameters has several advantages:</t>
<ol spacing="normal" type="(%c)">
<t><list style="format (%c)"> <li>Integrity protection.
<t>(integrity protection) The request can be signed so that the integrity of the request
The request can be signed so that the integrity of the request can be checked.</li>
can be checked.</t> <li>Source authentication.
<t>(source authentication) The request can be signed so that the signer can be authenticat
The request can be signed so that the signer can be authenticat ed.</li>
ed.</t> <li>Confidentiality protection.
<t>(confidentiality protection)
The request can be encrypted so that end-to-end The request can be encrypted so that end-to-end
confidentiality can be provided even if the TLS connection is confidentiality can be provided even if the TLS connection is
terminated at one point or another (including at and before use terminated at one point or another (including at and before use
r-agents). </t> r agents). </li>
<t>(collection minimization) <li>Collection minimization. The request can be signed by a trusted
The request can be signed by a trusted third party attesting th third party attesting that the authorization request is compliant with
at a certain policy. For example, a request can be pre-examined by a
the authorization request is compliant with a certain policy. trusted third party to confirm that all the personal data requested is
For example, a request can be pre-examined by a trusted third p strictly necessary to perform the process that the end user asked for;
arty the request would then be signed by that trusted third party. The
that all the personal data requested is strictly necessary authorization server then examines the signature and shows the
to perform the process that the end-user asked for, and conformance status to the end user who would have some assurance as to
signed by that trusted third party. the legitimacy of the request when authorizing it. In some cases, it
The authorization server then examines the signature may even be desirable to skip the authorization dialogue under such
and shows the conformance status to the end-user, circumstances.
who would have some assurance as to </li>
the legitimacy of the request when authorizing it. </ol>
In some cases, it may even be desirable to skip the authorizati <t>There are a few cases where request by reference is useful, such as:</t
on dialogue >
under such circumstances. <ol spacing="normal" type="1">
</t> <li>when it is desirable to reduce the size of a transmitted request.
</list></t> The use of application-layer security increases the size of the
request particularly when public-key cryptography is used. </li>
<t>There are a few cases that request by reference is useful such <li>when the client does not want to do the application-level
as:</t> cryptography. The authorization server may provide an endpoint to
accept the authorization request through direct communication with the
<t><list style="numbers"> client, so that the client is authenticated and the channel is TLS
<t>When it is desirable to reduce the size of transmitted request. protected. </li>
The use of application layer security increases </ol>
the size of the request, particularly when public key <t>This capability is in use by OpenID Connect <xref target="OpenID.Core"/
cryptography is used. </t> >.</t>
<section>
<t>When the client does not want to do the application level cr <name>Requirements Language</name>
yptography. <t>
The Authorization Server may provide an endpoint to The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
accept the Authorization Request through direct communication "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
with the Client so that the Client is authenticated NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
and the channel is TLS protected. </t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
</list></t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<t>This capability is in use by OpenID Connect <xref target="OpenID.Core" <xref target="RFC8174"/> when, and only when, they appear in all capitals,
/>.</t> as shown here.
</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119" />
<xref target="RFC8174" /> when, and only when, they
appear in all capitals, as shown here.</t>
</section> </section>
</section> </section>
<section anchor="Terminology">
<name>Terminology</name>
<section anchor="Terminology" title="Terminology">
<t>For the purposes of this specification, the following terms and <t>For the purposes of this specification, the following terms and
definitions in addition to what is defined in definitions apply in addition to what is defined in
<xref target="RFC6749">OAuth 2.0 Framework</xref>, <xref target="RFC6749">OAuth 2.0 Framework</xref>,
<xref target="RFC7515">JSON Web Signature</xref>, and <xref target="RFC7515">JSON Web Signature</xref>, and
<xref target="RFC7519">JSON Web Encryption</xref> apply.</t> <xref target="RFC7516">JSON Web Encryption</xref>.</t>
<section anchor="request_object">
<section anchor="request_object" title="Request Object"> <name>Request Object</name>
<t> <t>
<xref target="RFC7519">JSON Web Token (JWT)</xref> whose JWT Claims Set A Request Object is a <xref target="RFC7519">JSON Web Token
holds the JSON (JWT)</xref> whose JWT Claims
encoded OAuth 2.0 authorization request parameters. Set holds the JSON-encoded OAuth 2.0 authorization request
</t> parameters.
</t>
</section> </section>
<section anchor="request_uri">
<name>Request Object URI</name>
<section anchor="request_uri" title="Request Object URI"> <t>A Request Object URI is an absolute URI that references the set of
<t>Absolute URI that references the set of parameters comprising an OAut parameters comprising an OAuth 2.0 authorization request. The content
h 2.0 authorization request. of the resource referenced by the URI is a <xref
The contents of the resource referenced by the URI are a <xref target="r target="request_object">Request Object</xref>, unless the URI was
equest_object">Request Object</xref>, provided to the client by the same authorization server, in which case
unless the URI was provided to the client by the same Authorization Serv the content is an implementation detail at the discretion of the
er, authorization server. The content being a Request Object is to ensure in
in which case the content is an implementation detail at the discretion teroperability in
the Authorization Server. The former is cases where the provider of the <tt>request_uri</tt> is a separate
to ensure interoperability in cases where the provider of the request_ur entity from the consumer, such as when a client provides a URI
i is a separate referencing a Request Object stored on the client's backend service
entity from the consumer, such as when a client provides a URI referenci that is made accessible via HTTPS. In the latter case, where the
ng a Request Object stored on the client's authorization server is both provider and consumer of the URI, such as
backend service and made accessible via HTTPS. In the latter case where when it offers an endpoint that provides a URI in exchange for a
the Authorization Server is both provider Request Object, this interoperability concern does not apply.</t>
and consumer of the URI, such as when it offers an endpoint that provide
s
a URI in exchange for a Request Object, this interoperability concern do
es not apply.</t>
</section> </section>
</section> </section>
<section anchor="abbreviation">
<section anchor="abbreviation" title="Symbols and abbreviated terms"> <name>Symbols and Abbreviated Terms</name>
<t> <t>
The following abbreviations are common to this specificat The following abbreviations are common to this specification.
ion. </t>
</t> <dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>JSON:</dt>
<t hangText="JSON">JavaScript Object Notation</t> <dd>JavaScript Object Notation</dd>
<t hangText="JWT">JSON Web Token</t> <dt>JWT:</dt>
<t hangText="JWS">JSON Web Signature</t> <dd>JSON Web Token</dd>
<t hangText="JWE">JSON Web Encryption</t> <dt>JWS:</dt>
<t hangText="URI">Uniform Resource Identifier</t> <dd>JSON Web Signature</dd>
<t hangText="URL">Uniform Resource Locator</t> <dt>JWE:</dt>
</list></t> <dd>JSON Web Encryption</dd>
</section> <dt>URI:</dt>
<dd>Uniform Resource Identifier</dd>
<section anchor="authorization_request_object" title="Request Object"> <dt>URL:</dt>
<dd>Uniform Resource Locator</dd>
</dl>
</section>
<section anchor="authorization_request_object">
<name>Request Object</name>
<t>A <xref target="request_object">Request Object</xref> is used to <t>A <xref target="request_object">Request Object</xref> is used to
provide authorization request parameters for an OAuth 2.0 authorization provide authorization request parameters for an OAuth 2.0 authorization
request. It MUST contain all the parameters (including extension request. It <bcp14>MUST</bcp14> contain all the parameters (including exte nsion
parameters) used to process the <xref target="RFC6749">OAuth 2.0</xref> parameters) used to process the <xref target="RFC6749">OAuth 2.0</xref>
authorization request except the <spanx style="verb">request</spanx> and authorization request except the <tt>request</tt> and
<spanx style="verb">request_uri</spanx> parameters that are defined in <tt>request_uri</tt> parameters that are defined in
this document. this document.
The parameters are represented as the JWT claims of the object. The parameters are represented as the JWT Claims of the object.
Parameter names and string values MUST be included as JSON strings. Parameter names and string values <bcp14>MUST</bcp14> be included as JS
ON strings.
Since Request Objects are handled across domains and potentially Since Request Objects are handled across domains and potentially
outside of a closed ecosystem, per section 8.1 of <xref target="RFC8259 outside of a closed ecosystem, per <xref
" />, target="RFC8259" sectionFormat="of" section="8.1"/>,
these JSON strings MUST be encoded using UTF-8 <xref target="RFC3629" / these JSON strings <bcp14>MUST</bcp14> be encoded using UTF-8 <xref tar
>. get="RFC3629"/>.
Numerical values MUST be included as JSON numbers. Numerical values <bcp14>MUST</bcp14> be included as JSON numbers.
It MAY include any extension parameters. The Request Object <bcp14>MAY</bcp14> include any extension parameters.
This <xref target="RFC8259">JSON</xref> object constitutes the This <xref target="RFC8259">JSON</xref> object constitutes the
JWT Claims Set defined in <xref JWT Claims Set defined in <xref target="RFC7519">JWT</xref>.
target="RFC7519">JWT</xref>.
The JWT Claims Set is then signed or signed and encrypted. </t> 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 <xref
target="RFC7519">JWT</xref>. If signed, the
Authorization Request Object SHOULD contain the Claims <spanx
style="verb">iss</spanx> (issuer) and <spanx style="verb">aud</spanx>
(audience) as 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> should be the value of the
Authorization Server (AS)
<spanx style="verb">issuer</spanx> as defined in
<xref target="RFC8414">RFC8414</xref>.</t>
<t>To encrypt, <xref <t>To sign, <xref target="RFC7515">JSON Web Signature (JWS)</xref> is
target="RFC7516">JWE</xref> is used. used. The result is a JWS-signed <xref target="RFC7519">JWT</xref>. If
signed, the Authorization Request Object <bcp14>SHOULD</bcp14> contain
the Claims <tt>iss</tt> (issuer) and <tt>aud</tt> (audience) as members
with their semantics being the same as defined in the <xref
target="RFC7519">JWT</xref> specification. The value of <tt>aud</tt>
should be the value of the authorization server (AS) <tt>issuer</tt>, as
defined in <xref target="RFC8414">RFC 8414</xref>.</t>
<t>To encrypt, <xref target="RFC7516">JWE</xref> is used.
When both signature and encryption are being applied, When both signature and encryption are being applied,
the JWT MUST be signed then encrypted as described in the JWT <bcp14>MUST</bcp14> be signed, then encrypted, as described in
Section 11.2 of <xref target="RFC7519" />. <xref target="RFC7519" sectionFormat="of" section="11.2"/>.
The result is a Nested JWT, as defined in The result is a Nested JWT, as defined in
<xref target="RFC7519" />. <xref target="RFC7519"/>.
</t> </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>, and
<spanx style="verb">request_object_encryption_enc</spanx>.
Likewise, the authorization server can inform the client of the algor
ithms that it supports
in its authorization server metadata <xref target="RFC8414"/>,
specifically, the metadata values
<spanx style="verb">request_object_signing_alg_values_supported</span
x>,
<spanx style="verb">request_object_encryption_alg_values_supported</s
panx>, and
<spanx style="verb">request_object_encryption_enc_values_supported</s
panx>.
</t>
<t>
The Request Object MAY be sent by value as
described in <xref target="RequestParameter" />
or by reference as described in <xref target="RequestUriParameter" />
.
<spanx style="verb">request</spanx> and
<spanx style="verb">request_uri</spanx> parameters
MUST NOT 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>.
Note that some existing deployments may alternatively be using the type
<spanx style="verb">application/jwt</spanx>.
</t>
<figure> <t>
<preamble> 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
<tt>request_object_signing_alg</tt>,
<tt>request_object_encryption_alg</tt>, and
<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
<tt>request_object_signing_alg_values_supported</tt>,
<tt>request_object_encryption_alg_values_supported</tt>, and
<tt>request_object_encryption_enc_values_supported</tt>.
</t>
<t>
The Request Object <bcp14>MAY</bcp14> be sent by value, as
described in <xref target="RequestParameter"/>,
or by reference, as described in <xref target="RequestUriParameter"/>
.
<tt>request</tt> and
<tt>request_uri</tt> parameters
<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"/>
<tt>application/oauth-authz-req+jwt</tt>. Note that some existing
deployments may alternatively be using the type
<tt>application/jwt</tt>.
</t>
<t keepWithNext="true">
The following is an example of the Claims in The following is an example of the Claims in
a Request Object before base64url <xref target="RFC7515"/> encoding and signing. a Request Object before base64url <xref target="RFC7515"/> encoding and signing.
Note that it includes the extension parameters Note that it includes the extension parameters
<spanx style="verb">nonce</spanx> and <spanx style="verb">max_a <tt>nonce</tt> and <tt>max_age</tt>.
ge</spanx>. </t>
</preamble> <sourcecode type="json">
<artwork><![CDATA[
{ {
"iss": "s6BhdRkqt3", "iss": "s6BhdRkqt3",
"aud": "https://server.example.com", "aud": "https://server.example.com",
"response_type": "code id_token", "response_type": "code id_token",
"client_id": "s6BhdRkqt3", "client_id": "s6BhdRkqt3",
"redirect_uri": "https://client.example.org/cb", "redirect_uri": "https://client.example.org/cb",
"scope": "openid", "scope": "openid",
"state": "af0ifjsldkj", "state": "af0ifjsldkj",
"nonce": "n-0S6_WzA2Mj", "nonce": "n-0S6_WzA2Mj",
"max_age": 86400 "max_age": 86400
} }
]]></artwork> </sourcecode>
</figure> <t keepWithNext="true">
<figure> Signing it with the <tt>RS256</tt> algorithm <xref target="RFC7518"
<preamble> />
Signing it with the <spanx style="verb">RS256</spanx> algorithm
<xref target="RFC7518"/>
results in this Request Object value results in this Request Object value
(with line wraps within values for display purposes only): (with line wraps within values for display purposes only):
</preamble> </t>
<sourcecode type="jwt">
<artwork><![CDATA[
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2 ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2 b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6 HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
]]></artwork> </sourcecode>
</figure> <t keepWithNext="true">
<figure> The following RSA public key, represented in JSON Web Key (JWK)
<preamble> format, can be used to validate the Request Object signature in
The following RSA public key, represented in JWK format, can be use this and subsequent Request Object examples (with line wraps
d to within values for display purposes only):
validate the Request Object signature in this </t>
and subsequent Request Object examples <sourcecode type="json">
(with line wraps within values for display purposes only):
</preamble>
<artwork><![CDATA[
{ {
"kty":"RSA", "kty":"RSA",
"kid":"k2bdc", "kid":"k2bdc",
"n":"x5RbkAZkmpRxia65qRQ1wwSMSxQUnS7gcpVTV_cdHmfmG2ltd2yabEO9XadD8 "n":"x5RbkAZkmpRxia65qRQ1wwSMSxQUnS7gcpVTV_cdHmfmG2ltd2yabEO9XadD8
pJNZubINPpmgHh3J1aD9WRwS05ucmFq3CfFsluLt13_7oX5yDRSKX7poXmT_5 pJNZubINPpmgHh3J1aD9WRwS05ucmFq3CfFsluLt13_7oX5yDRSKX7poXmT_5
ko8k4NJZPMAO8fPToDTH7kHYbONSE2FYa5GZ60CUsFhSonI-dcMDJ0Ary9lxI ko8k4NJZPMAO8fPToDTH7kHYbONSE2FYa5GZ60CUsFhSonI-dcMDJ0Ary9lxI
w5k2z4TAdARVWcS7sD07VhlMMshrwsPHBQgTatlkxyIHXbYdtak8fqvNAwr7O w5k2z4TAdARVWcS7sD07VhlMMshrwsPHBQgTatlkxyIHXbYdtak8fqvNAwr7O
lVEvM_Ipf5OfmdB8Sd-wjzaBsyP4VhJKoi_qdgSzpC694XZeYPq45Sw-q51iF lVEvM_Ipf5OfmdB8Sd-wjzaBsyP4VhJKoi_qdgSzpC694XZeYPq45Sw-q51iF
UlcOlTCI7z6jltUtnR6ySn6XDGFnzH5Fe5ypw", UlcOlTCI7z6jltUtnR6ySn6XDGFnzH5Fe5ypw",
"e":"AQAB" "e":"AQAB"
} }
]]></artwork> </sourcecode>
</figure>
</section> </section>
<section anchor="authreq">
<section title="Authorization Request" anchor="authreq"> <name>Authorization Request</name>
<t>The client constructs the authorization request URI <t>The client constructs the authorization request URI
by adding the following parameters by adding the following parameters
to the query component of the authorization to the query component of the authorization
endpoint URI using the <spanx style="verb">application/x-www-form-urlencod ed</spanx> endpoint URI using the <tt>application/x-www-form-urlencoded</tt>
format:</t> format:</t>
<dl newline="true" spacing="normal">
<t><list style="hanging"> <dt>request</dt>
<t hangText="request"> <dd>
<vspace/> <bcp14>REQUIRED</bcp14> unless <tt>request_uri</tt>
REQUIRED unless <spanx style="verb">request_uri</spanx>
is specified. The <xref target="request_object">Request Object</xref> that is specified. The <xref target="request_object">Request Object</xref> that
holds authorization request parameters stated in section 4 of holds authorization request parameters stated in
<xref target="RFC6749">OAuth 2.0</xref>. <xref target="RFC6749" sectionFormat="of" section="4"/> (OAuth 2.0).
If this parameter is present in the authorization request, If this parameter is present in the authorization request,
<spanx style="verb">request_uri</spanx> MUST NOT be present. <tt>request_uri</tt> <bcp14>MUST NOT</bcp14> be present.
</t> </dd>
<dt>request_uri</dt>
<t hangText="request_uri"> <dd>
<vspace/> <bcp14>REQUIRED</bcp14> unless <tt>request</tt>
REQUIRED unless <spanx style="verb">request</spanx> is specified. The absolute URI, as defined by <xref
is specified. The absolute URI as defined by <xref target="RFC3986">RFC 3986</xref>, that is the <xref
target="RFC3986">RFC3986</xref> that is the <xref target="request_uri">Request Object URI</xref> referencing the
target="request_uri">Request Object URI</xref> referencing the authori authorization request
zation request parameters stated in <xref target="RFC6749"
parameters stated in section 4 of <xref target="RFC6749">OAuth sectionFormat="of" section="4"/> (OAuth
2.0</xref>. 2.0).
If this parameter is present in the authorization request, If this parameter is present in the authorization request,
<spanx style="verb">request</spanx> MUST NOT be present. <tt>request</tt> <bcp14>MUST NOT</bcp14> be present.
</t> </dd>
<dt>client_id</dt>
<t hangText="client_id"> <dd>
<vspace/> <bcp14>REQUIRED</bcp14>. <xref target="RFC6749">OAuth 2.0</xref>
REQUIRED. <xref target="RFC6749">OAuth 2.0</xref> <tt>client_id</tt>. The value <bcp14>MUST</bcp14> match the
<spanx style="verb">client_id</spanx>. The value MUST match the <tt>request</tt> or <tt>request_uri</tt>
<spanx style="verb">request</spanx> or <spanx style="verb">request_uri
</spanx>
<xref target="request_object">Request Object's</xref> <xref target="request_object">Request Object's</xref>
<spanx style="verb">client_id</spanx>.</t> <tt>client_id</tt>.</dd>
</list>The client directs the resource owner to the constructed URI </dl>
using an HTTP redirection response, or by other means available to it <t>The client directs the resource owner to the constructed URI
via the user-agent.</t> using an HTTP redirection response or by other means available to it
via the user agent.</t>
<t>For example, the client directs the end user's user-agent to make the <t>For example, the client directs the end user's user agent to make the
following HTTPS request:</t> following HTTPS request:</t>
<sourcecode type="http-message">
<figure> GET /authz?client_id=s6BhdRkqt3&amp;request=eyJhbG..AlMGzw HTTP/1.1
<artwork><![CDATA[GET /authz?client_id=s6BhdRkqt3&request=eyJhbG..AlMGzw Host: server.example.com
HTTP/1.1 </sourcecode>
Host: server.example.com]]></artwork> <t keepWithPrevious="true">
<postamble>
The value for the request parameter is abbreviated The value for the request parameter is abbreviated
for brevity. for brevity.
</postamble> </t>
</figure> <t>The Authorization Request Object <bcp14>MUST</bcp14> be one of the foll
owing: </t>
<t>The authorization request object MUST be one of the following: </t> <ol spacing="normal" type="(%c)">
<t><list style="format (%c)"> <li>JWS signed </li>
<t>JWS signed </t> <li>JWS signed and JWE encrypted</li>
<t>JWS signed and JWE encrypted</t> </ol>
</list></t> <t>The client <bcp14>MAY</bcp14> send the parameters included in
<t>The client MAY send the parameters included in the Request Object duplicated in the query parameters as well
the request object duplicated in the query parameters as well for backward compatibility, etc.
for the backward compatibility etc.
However, the authorization server supporting this specification However, the authorization server supporting this specification
MUST only use the parameters included in the request object. <bcp14>MUST</bcp14> only use the parameters included in the Request Obj
</t> ect.
</t>
<section anchor="RequestParameter" <section anchor="RequestParameter">
title='Passing a Request Object by Value'> <name>Passing a Request Object by Value</name>
<t>The Client sends the Authorization Request as a <t>The client sends the authorization request as a
Request Object to the Authorization Endpoint as the Request Object to the authorization endpoint as the
<spanx style="verb">request</spanx> parameter value.</t> <tt>request</tt> parameter value.</t>
<t keepWithNext="true">The following is an example of an
<t> authorization request using the <tt>request</tt>
<figure>
<preamble>The following is an example of an
Authorization Request using the <spanx style='verb'>request</spanx>
parameter parameter
(with line wraps within values for display purposes only): (with line wraps within values for display purposes only):
</preamble> </t>
<sourcecode type="url">
<artwork><![CDATA[ https://server.example.com/authorize?client_id=s6BhdRkqt3&amp;
https://server.example.com/authorize?client_id=s6BhdRkqt3&
request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6 request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6
ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs
ZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAg ZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAg
ICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6 ICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6
ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAi ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAi
b3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2Ui b3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2Ui
OiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VU OiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VU
ElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC ElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC
0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKz 0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKz
uKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3E uKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3E
YLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W YLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W
9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3 9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3
j1i7tLR_5Nz-g j1i7tLR_5Nz-g
]]></artwork> </sourcecode>
</figure> </section>
</t> <section anchor="RequestUriParameter">
</section> <name>Passing a Request Object by Reference</name>
<t>
The <tt>request_uri</tt> authorization request parameter enables
OAuth authorization requests to be passed by reference rather than
by value. This parameter is used identically to the
<tt>request</tt> parameter, except that the Request Object value is
retrieved from the resource identified by the specified URI rather
than passed by value.
</t>
<section anchor="RequestUriParameter" title="Passing a Request Object by R <t>
eference"> The entire Request URI <bcp14>SHOULD NOT</bcp14> exceed 512 ASCII chara
<t> cters.
The <spanx style="verb">request_uri</spanx> Authorization Request param
eter enables
OAuth authorization requests to be passed by reference, rather than by
value.
This parameter is used identically to the
<spanx style="verb">request</spanx> parameter, other than that
the Request Object value is retrieved from the resource identified by t
he specified URI
rather than passed by value.
</t>
<t>
The entire Request URI SHOULD NOT exceed 512 ASCII characters.
There are two reasons for this restriction: There are two reasons for this restriction:
</t> </t>
<t><list style="numbers"> <ol spacing="normal" type="1">
<t>Many phones in the market as of this writing still <li>Many phones on the market as of this writing still do not accept
do not accept large payloads. large payloads. The restriction is typically either 512 or 1024
The restriction is typically either 512 or 1024 ASCII character ASCII characters.</li>
s.</t> <li>On a slow connection such as a 2G mobile connection, a large URL
<t>On a slow connection such as 2G mobile connection, would cause a slow response; therefore, the use of such is not
a large URL would cause the slow response and therefore the use advisable from the user-experience point of view.
of such </li>
is not advisable from the user experience point of view. </ol>
</t> <t>
</list> The contents of the resource referenced by the <tt>request_uri</tt>
</t> <bcp14>MUST</bcp14> be a Request Object and <bcp14>MUST</bcp14> be reac
<t> hable by the authorization server
The contents of the resource referenced by the <spanx style="verb">requ unless the URI was provided to the client by the authorization server.
est_uri</spanx> In the first case, the <tt>request_uri</tt> <bcp14>MUST</bcp14> be
MUST be a Request Object and MUST be reachable by the Authorization Ser an <tt>https</tt> URI,
ver as specified in <xref target="RFC7230"
unless the URI was provided to the client by the Authorization Server. sectionFormat="of" section="2.7.2"/>.
In the first case, the <spanx style="verb">request_uri</spanx> MUST be In the second case, it <bcp14>MUST</bcp14> be a URN,
an <spanx style="verb">https</spanx> URI, as specified in <xref target="RFC8141"/>.
as specified in Section 2.7.2 of <xref target="RFC7230">RFC7230</xref>. </t>
In the second case, it MUST be a URN, <t keepWithNext="true">The following is an example of
as specified in <xref target="RFC8141">RFC8141</xref>.
</t>
<t>
<figure>
<preamble>The following is an example of
the contents of a Request Object resource that can be the contents of a Request Object resource that can be
referenced by a <spanx style="verb">request_uri</spanx> referenced by a <tt>request_uri</tt>
(with line wraps within values for display purposes only):</preamble> (with line wraps within values for display purposes only):</t>
<sourcecode type="jwt">
<artwork><![CDATA[
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2 ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2 b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6 HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
]]></artwork> </sourcecode>
</figure> <section anchor="CreateRequestUri">
</t> <name>URI Referencing the Request Object</name>
<t>
<section anchor="CreateRequestUri" The client stores the Request Object resource either
title="URI Referencing the Request Object"> locally or remotely at a URI the authorization server can access.
<t> Such a facility may be provided by the authorization server
The Client stores the Request Object resource either
locally or remotely at a URI the Authorization Server can access.
Such facility may be provided by the authorization server
or a trusted third party. For example, the authorization server m ay or a trusted third party. For example, the authorization server m ay
provide a URL to which the client POSTs the request object and provide a URL to which the client POSTs the Request Object and
obtains the Request URI. obtains the Request URI.
This URI is the Request Object URI, <spanx style="verb">request_uri</ This URI is the Request Object URI, <tt>request_uri</tt>.
spanx>. </t>
</t> <t>
<t>
It is possible for the Request Object to include values that It is possible for the Request Object to include values that
are to be revealed only to the Authorization Server. are to be revealed only to the authorization server.
As such, the <spanx style="verb">request_uri</spanx> MUST have As such, the <tt>request_uri</tt> <bcp14>MUST</bcp14> have
appropriate entropy for its lifetime appropriate entropy for its lifetime
so that the URI is not guessable if publicly retrievable. so that the URI is not guessable if publicly retrievable.
For the guidance, refer to 5.1.4.2.2 of For the guidance, refer to
<xref target="RFC6819" /> and <xref target="RFC6819" sectionFormat="of" section="5.1.4.2.2"/> and
<xref target="CapURLs">Good Practices for Capability URLs</xref>. "<xref target="CapURLs" format="title"/>" <xref target="CapURLs"/>.
It is RECOMMENDED that it be removed It is <bcp14>RECOMMENDED</bcp14> that the <tt>request_uri</tt> be rem
oved
after a reasonable timeout after a reasonable timeout
unless access control measures are taken. unless access control measures are taken.
</t> </t>
<figure> <t keepWithNext="true">The following is an example
<preamble>The following is an example
of a Request Object URI value of a Request Object URI value
(with line wraps within values for display purposes only). (with line wraps within values for display purposes only).
In this example, a trusted third-party service hosts the Request Ob ject. In this example, a trusted third-party service hosts the Request Ob ject.
</preamble> </t>
<sourcecode type="url">
<artwork><![CDATA[
https://tfp.example.org/request.jwt/ https://tfp.example.org/request.jwt/
GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
]]></artwork> </sourcecode>
</figure> </section>
<section anchor="UseRequestUri">
</section> <name>Request Using the "request_uri" Request Parameter</name>
<t>The client sends the authorization request to the
<section anchor="UseRequestUri" authorization endpoint.</t>
title='Request using the "request_uri" Request Parameter'> <t keepWithNext="true">The following is an example
<t>The Client sends the Authorization Request to the of an authorization request using the <tt>request_uri</tt> parameter
Authorization Endpoint.</t> (with line wraps within values for display purposes only):</t>
<figure>
<preamble>The following is an example
of an Authorization Request using the <spanx style="verb">request_uri
</spanx> parameter
(with line wraps within values for display purposes only):</preamble>
<artwork><![CDATA[ <sourcecode type="url">
https://server.example.com/authorize? https://server.example.com/authorize?
client_id=s6BhdRkqt3 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 %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
]]></artwork> </sourcecode>
</figure> </section>
</section> <section anchor="GetRequestUri">
<name>Authorization Server Fetches Request Object</name>
<section anchor="GetRequestUri" title="Authorization Server Fetches Reque
st Object">
<t>Upon receipt of the Request, the Authorization Server MUST
send an HTTP <spanx style="verb">GET</spanx> request
to the <spanx style="verb">request_uri</spanx>
to retrieve the referenced Request Object, unless it is stored in a way
so that
it can retrieve it through other mechanism securely, and parse it
to recreate the Authorization Request parameters.</t>
<figure>
<preamble>The following is an example of this fetch
process.
In this example, a trusted third-party service hosts the Request Ob
ject.
</preamble>
<artwork><![CDATA[ <t>Upon receipt of the Request, the authorization server
GET /request.jwt/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM HTTP/1.1 <bcp14>MUST</bcp14> send an HTTP <tt>GET</tt> request to the
Host: tfp.example.org <tt>request_uri</tt> to retrieve the referenced Request Object
]]></artwork> unless the Request Object is stored in a way so that the server can
</figure> retrieve it through other mechanisms securely and parse it to
<figure> recreate the authorization request parameters.</t>
<preamble>The following is an example of the fetch <t keepWithNext="true">The following is an example of this fetch
response:</preamble> process. In this example, a trusted third-party service hosts the
Request Object.
</t>
<artwork><![CDATA[ <sourcecode type="http-message">
GET /request.jwt/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM HTTP/1.1
Host: tfp.example.org
</sourcecode>
<t keepWithNext="true">The following is an example of the fetch
response:</t>
<sourcecode type="http-message">
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Thu, 20 Aug 2020 23:52:39 GMT Date: Thu, 20 Aug 2020 23:52:39 GMT
Server: Apache/2.4.43 (tfp.example.org) Server: Apache/2.4.43 (tfp.example.org)
Content-type: application/oauth-authz-req+jwt Content-type: application/oauth-authz-req+jwt
Content-Length: 797 Content-Length: 797
Last-Modified: Wed, 19 Aug 2020 23:52:32 GMT Last-Modified: Wed, 19 Aug 2020 23:52:32 GMT
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2 ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2 b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6 HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
]]></artwork> </sourcecode>
</figure> </section>
</section>
</section>
</section>
</section> </section>
<section anchor="JWTRequestValidation">
<section anchor="JWTRequestValidation" title="Validating JWT-Based Requests"> <name>Validating JWT-Based Requests</name>
<section anchor="EncryptedRequestObject">
<section anchor="EncryptedRequestObject" title="JWE Encrypted Request Obj <name>JWE Encrypted Request Object</name>
ect"> <t>
If the Request Object is encrypted,
<t> the authorization server <bcp14>MUST</bcp14> decrypt the JWT in accor
If the request object is encrypted, dance with
the Authorization Server MUST decrypt the JWT in accordance with
the <xref target="RFC7516">JSON Web Encryption</xref> the <xref target="RFC7516">JSON Web Encryption</xref>
specification. specification.
</t> </t>
<t> <t>
The result is a signed request object. The result is a signed Request Object.
</t> </t>
<t>
<t> If decryption fails, the authorization server <bcp14>MUST</bcp14>
If decryption fails, return an <tt>invalid_request_object</tt> error to the client in
the Authorization Server MUST return an response to the authorization request.
<spanx style="verb">invalid_request_object</spanx> error </t>
to the client in response to the authorization request. </section>
</t> <section anchor="SignedRequestObject">
</section> <name>JWS-Signed Request Object</name>
<t>
<section anchor="SignedRequestObject" title="JWS Signed Request Object"> The authorization server <bcp14>MUST</bcp14> validate the
signature of the JWS-signed <xref target="RFC7515"/> Request
<t> Object. If a <tt>kid</tt> Header Parameter is present, the key identi
The Authorization Server MUST validate the signature of the fied
<xref target="RFC7515">JSON Web Signature</xref> signed Request Objec <bcp14>MUST</bcp14> be the key used and <bcp14>MUST</bcp14> be a
t. key associated with the client. The signature <bcp14>MUST</bcp14>
If a <spanx style="verb">kid</spanx> Header Parameter is present, be validated using a key associated with the client and the
the key identified MUST be the key used, and MUST be a key associated algorithm specified in the <tt>alg</tt> Header Parameter. Algorithm v
with the client. erification <bcp14>MUST</bcp14> be performed, as specified in Sections <xref tar
The signature MUST be validated using a key associated with the clien get="RFC8725" format="default" sectionFormat="bare" section="3.1"></xref> and <x
t ref target="RFC8725" format="default" sectionFormat="bare" section="3.2"></xref>
and the algorithm specified in the <spanx style="verb">alg</spanx> He of <xref target="RFC8725"/>.
ader Parameter. </t>
Algorithm verification MUST be performed, as specified in Sections 3. <t>
1 and 3.2 of <xref target="RFC8725"/>. If the key is not associated with the client or if signature
</t> validation fails, the authorization server <bcp14>MUST</bcp14>
return an <tt>invalid_request_object</tt> error to the client in resp
<t> onse to the authorization request.
If the key is not associated with the client </t>
or if signature validation fails, </section>
the Authorization Server MUST return an <section anchor="RequestParameterValidation">
<spanx style="verb">invalid_request_object</spanx> error <name>Request Parameter Assembly and Validation</name>
to the client in response to the authorization request. <t>
</t> The authorization server <bcp14>MUST</bcp14> extract
</section> the set of authorization request parameters
<section anchor="RequestParameterValidation" title="Request Parameter Ass
embly and Validation">
<t>
The Authorization Server MUST extract
the set of Authorization Request parameters
from the Request Object value. from the Request Object value.
The Authorization Server MUST only use the The authorization server <bcp14>MUST</bcp14> only use the
parameters in the Request Object even if the parameters in the Request Object, even if the
same parameter is provided in the query parameter. same parameter is provided in the query parameter.
The Client ID values in the <spanx style="verb">client_id</spanx> req The client ID values in the <tt>client_id</tt> request parameter
uest parameter and in the Request Object <tt>client_id</tt> claim <bcp14>MUST</bcp14
and in the Request Object <spanx style="verb">client_id</spanx> claim > be identical.
MUST be identical. The authorization server then validates the request,
The Authorization Server then validates the request
as specified in <xref target="RFC6749">OAuth 2.0</xref>. as specified in <xref target="RFC6749">OAuth 2.0</xref>.
</t> </t>
<t> <t>
If the Client ID check or the request validation fails, If the Client ID check or the request validation fails, then the
then the Authorization Server MUST return an error authorization server <bcp14>MUST</bcp14> return an error to the
to the client in response to the authorization request, client in response to the authorization request, as specified in
as specified in Section 5.2 of <xref target="RFC6749">OAuth 2.0</xref <xref target="RFC6749" section="5.2" sectionFormat="of"/> (OAuth 2.0)
>. .
</t> </t>
</section>
</section> </section>
<section>
</section> <name>Authorization Server Response</name>
<t>The authorization server response is created and sent to the client as
<section title="Authorization Server Response"> in
<t>Authorization Server Response is created and sent to the client as in <xref target="RFC6749" sectionFormat="of" section="4"/> (OAuth 2.0).</t>
Section 4 of <xref target="RFC6749">OAuth 2.0</xref>.</t>
<t>In addition, this document uses these additional error values: <t>In addition, this document uses these additional error values:
<list style="hanging"> </t>
<t hangText="invalid_request_uri"> <dl newline="true" spacing="normal">
<vspace/> <dt>invalid_request_uri</dt>
The <spanx style="verb">request_uri</spanx> in the <dd>
Authorization Request returns an error or contains invalid data The <tt>request_uri</tt> in the
.</t> authorization request returns an error or contains invalid data.</dd>
<dt>invalid_request_object</dt>
<t hangText="invalid_request_object"> <dd>
<vspace/>
The request parameter contains The request parameter contains
an invalid Request Object.</t> an invalid Request Object.</dd>
<dt>request_not_supported</dt>
<t hangText="request_not_supported"> <dd>
<vspace/> The authorization server does not support
The Authorization Server does not support the use of the <tt>request</tt> parameter.</dd>
the use of the <spanx style="verb">request</spanx> parameter.</ <dt>request_uri_not_supported</dt>
t> <dd>
The authorization server does not support the use of
<t hangText="request_uri_not_supported"> the <tt>request_uri</tt> parameter.</dd>
<vspace/> </dl>
The Authorization Server does not support the use of
the <spanx style="verb">request_uri</spanx> parameter.</t>
</list></t>
</section> </section>
<section anchor="tlsreq" title="TLS Requirements"> <section anchor="tlsreq">
<t> <name>TLS Requirements</name>
Client implementations supporting the Request Object URI
method <t>
MUST support TLS following Client implementations supporting the Request Object URI method
<xref target="BCP195">Recommendations for Secure Use <bcp14>MUST</bcp14> support TLS, following
of Transport Layer Security (TLS) and <xref target="RFC7525">"Recommendations for Secure Use
Datagram Transport Layer Security (DTLS)</xref>. of Transport Layer Security (TLS) and
</t> Datagram Transport Layer Security (DTLS)"</xref>.
<t> </t>
<t>
To protect against information disclosure and tampering, To protect against information disclosure and tampering,
confidentiality protection MUST be applied using TLS with a confidentiality protection <bcp14>MUST</bcp14> be applied using TLS with a
cipher suite that provides confidentiality and integrity protection. cipher suite that provides confidentiality and integrity protection.
</t> </t>
<t> HTTP clients MUST also verify the TLS server certificate, usi <t> HTTP clients <bcp14>MUST</bcp14> also verify the TLS server certificat
ng e, using
DNS-ID DNS-ID
<xref target="RFC6125" />, to avoid man-in-the-middle att acks. <xref target="RFC6125"/>, to avoid man-in-the-middle atta cks.
The rules and guidelines defined in The rules and guidelines defined in
<xref target="RFC6125" /> apply here, with the following considera <xref target="RFC6125"/> apply here, with the following considerat
tions: ions:
<list style="symbols"> </t>
<t> <ul spacing="normal">
Support for DNS-ID identifier type (that is, the <li>
dNSName identity Support for DNS-ID identifier type (that is, the dNSName identity
in the subjectAltName extension) is REQUIRED. Certificat in the subjectAltName extension) is <bcp14>REQUIRED</bcp14>. Certifica
ion tion
authorities which issue server certificates MUST support authorities that issue server certificates
the DNS-ID identifier type, and the DNS-ID identifier typ <bcp14>MUST</bcp14> support
e MUST the DNS-ID identifier type, and the DNS-ID identifier type <bcp14>MUST<
be present in server certificates.</t> /bcp14>
<t> be present in server certificates.</li>
DNS names in server certificates MAY contain the <li>
wildcard character "*". </t> DNS names in server certificates <bcp14>MAY</bcp14> contain the
<t> wildcard character <tt>*</tt>. </li>
Clients MUST NOT use CN-ID
identifiers; a CN field may be present in the server
certificate's
subject name, but MUST NOT be used for authentication wit
hin the
rules described in <xref target="BCP195" />. </t>
<t>
SRV-ID and URI-ID as described in Section 6.5 of <xref ta
rget="RFC6125" />
MUST NOT be used for comparison.
</t>
</list> </t>
</section> <li>
<section anchor="IANA" title="IANA Considerations"> Clients <bcp14>MUST NOT</bcp14> use CN-ID identifiers; a Common Name
<section anchor="OAuthParametersRegistry" title="OAuth Parameters field (CN field) may be present in the server certificate's subject
Registration"> name but <bcp14>MUST NOT</bcp14> be used for authentication within
<t>Since the request object is a JWT, the core JWT claims cannot be the rules described in <xref target="RFC7525"/>. </li>
used for <li>
any purpose in the request object other than for what JWT dictates. SRV-ID and URI-ID as described in <xref
Thus, they need to be registered as OAuth Authorization Request para target="RFC6125" sectionFormat="of" section="6.5"/>
meters to avoid <bcp14>MUST NOT</bcp14> be used for comparison.
future OAuth extensions using them with different meanings.</t> </li>
<t>This specification adds the following values to the "O </ul>
Auth Parameters" registry </section>
<xref target="IANA.OAuth.Parameters"/> established by <xr <section anchor="IANA">
ef target="RFC6749" />.</t> <name>IANA Considerations</name>
<t> <?rfc subcompact="yes"?> <section anchor="OAuthParametersRegistry">
<list style='symbols'> <name>OAuth Parameters Registration</name>
<t>Name: <spanx style="verb">iss</spanx>< <t>Since the Request Object is a JWT, the core JWT claims cannot be
/t> used for any purpose in the Request Object other than for what JWT
<t>Parameter Usage Location: authorizatio dictates. Thus, they have been registered as OAuth
n request</t> authorization request parameters to avoid future OAuth extensions
<t>Change Controller: IETF</t> using them with different meanings.</t>
<t>Specification Document(s): Section 4.1 <t>This specification adds the following values to the "OAuth
.1 of <xref target="RFC7519" /> and this document. </t> Parameters" registry <xref target="IANA.OAuth.Parameters"/>
</list> established by <xref target="RFC6749"/>.</t>
<list style='symbols'> <dl spacing="compact">
<t>Name: <spanx style="verb">sub</spanx>< <dt>Name:</dt><dd><tt>iss</tt></dd>
/t> <dt>Parameter Usage Location:</dt><dd>authorization request</dd>
<t>Parameter Usage Location: authorizatio <dt>Change Controller:</dt><dd>IETF</dd>
n request</t> <dt>Specification Document(s):</dt><dd>This document and <xref
<t>Change Controller: IETF</t> target="RFC7519" sectionFormat="of" section="4.1.1"/>.</dd>
<t>Specification Document(s): Section 4.1 </dl>
.2 of <xref target="RFC7519" /> and this document. </t>
</list>
<list style='symbols'>
<t>Name: <spanx style="verb">aud</spanx><
/t>
<t>Parameter Usage Location: authorizatio
n request</t>
<t>Change Controller: IETF</t>
<t>Specification Document(s): Section 4.1
.3 of <xref target="RFC7519" /> and this document. </t>
</list>
<list style='symbols'>
<t>Name: <spanx style="verb">exp</spanx><
/t>
<t>Parameter Usage Location: authorizatio
n request</t>
<t>Change Controller: IETF</t>
<t>Specification Document(s): Section 4.1
.4 of <xref target="RFC7519" /> and this document. </t>
</list>
<list style='symbols'>
<t>Name: <spanx style="verb">nbf</spanx><
/t>
<t>Parameter Usage Location: authorizatio
n request</t>
<t>Change Controller: IETF</t>
<t>Specification Document(s): Section 4.1
.5 of <xref target="RFC7519" /> and this document. </t>
</list>
<list style='symbols'>
<t>Name: <spanx style="verb">iat</spanx><
/t>
<t>Parameter Usage Location: authorizatio
n request</t>
<t>Change Controller: IETF</t>
<t>Specification Document(s): Section 4.1
.6 of <xref target="RFC7519" /> and this document. </t>
</list>
<list style='symbols'>
<t>Name: <spanx style="verb">jti</spanx><
/t>
<t>Parameter Usage Location: authorizatio
n request</t>
<t>Change Controller: IETF</t>
<t>Specification Document(s): Section 4.1
.7 of <xref target="RFC7519" /> and this document. </t>
</list>
</t>
</section>
<section anchor="OAuthAuthorizationServerMetadataRegistry" title=
"OAuth Authorization Server Metadata Registry">
<t>This specification adds the following value to the "OAuth Au
thorization Server Metadata" registry
<xref target="IANA.OAuth.Parameters"/> established by <xref tar
get="RFC8414" />.</t>
<t> <?rfc subcompact="yes"?>
<list style='symbols'>
<t>Metadata Name: <spanx style="verb">req
uire_signed_request_object</spanx></t>
<t>Metadata Description: Indicates where
authorization request needs to be protected as Request Object and provided
through either <spanx style="verb">request</spanx> or <spanx
style="verb">request_uri parameter</spanx>. </t>
<t>Change Controller: IETF</t>
<t>Specification Document(s): Section 10.
5 of this document. </t>
</list>
</t>
</section>
<section anchor="OAuthDynamicClientRegistrationMetadataRegistry"
title="OAuth Dynamic Client Registration Metadata Registry">
<t>This specification adds the following value to the "OAuth Dy
namic Client Registration Metadata" registry
<xref target="IANA.OAuth.Parameters"/> established by <xref tar
get="RFC7591" />.</t>
<t> <?rfc subcompact="yes"?>
<list style='symbols'>
<t>Metadata Name: <spanx style="verb">req
uire_signed_request_object</spanx></t>
<t>Metadata Description: Indicates where
authorization request needs to be protected as Request Object and provided
through either <spanx style="verb">request</spanx> or <spanx
style="verb">request_uri parameter</spanx>. </t>
<t>Change Controller: IETF</t>
<t>Specification Document(s): Section 10.
5 of this document. </t>
</list>
</t>
</section>
<section title="Media Type Registration" anchor="MediaReg"> <dl spacing="compact">
<section title="Registry Contents" anchor="MediaContents"> <dt>Name:</dt><dd><tt>sub</tt></dd>
<t> <dt>Parameter Usage 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" sectionFormat="of" section="4.1.2"/>.</dd>
</dl>
<dl spacing="compact">
<dt>Name:</dt><dd><tt>aud</tt></dd>
<dt>Parameter Usage 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" sectionFormat="of" section="4.1.3"/>.</dd>
</dl>
<dl spacing="compact">
<dt>Name:</dt><dd><tt>exp</tt></dd>
<dt>Parameter Usage 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" sectionFormat="of" section="4.1.4"/>.</dd>
</dl>
<dl spacing="compact">
<dt>Name:</dt><dd><tt>nbf</tt></dd>
<dt>Parameter Usage 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" sectionFormat="of" section="4.1.5"/>.</dd>
</dl>
<dl spacing="compact">
<dt>Name:</dt><dd><tt>iat</tt></dd>
<dt>Parameter Usage 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" sectionFormat="of" section="4.1.6"/>.</dd>
</dl>
<dl spacing="compact">
<dt>Name:</dt><dd><tt>jti</tt></dd>
<dt>Parameter Usage 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" sectionFormat="of" section="4.1.7"/>.</dd>
</dl>
</section>
<section anchor="OAuthAuthorizationServerMetadataRegistry">
<name>OAuth Authorization Server Metadata 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>
<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 <tt>request</tt> or <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.</dd>
</dl>
</section>
<section anchor="OAuthDynamicClientRegistrationMetadataRegistry">
<name>OAuth Dynamic Client Registration Metadata 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>
<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 <tt>request</tt> or <tt>request_uri parameter</tt>. </dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Specification Document(s):</dt><dd><xref target="require_signed_re
quest_object"/> of this document.</dd>
</dl>
</section>
<section anchor="MediaReg">
<name>Media Type Registration</name>
<section anchor="MediaContents">
<name>Registry Contents</name>
<t>
This section registers the 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" media type <xref target="RFC2046"/> in the "Media Types"
registry <xref target="IANA.MediaTypes"/> in the manner registry <xref target="IANA.MediaTypes"/> in the manner
described in <xref target="RFC6838"/>, which can be used to described in <xref target="RFC6838"/>. It can be used to
indicate that the content is a JWT containing Request indicate that the content is a JWT containing Request
Object claims. Object claims.
</t> </t>
<t> <?rfc subcompact="yes"?> <dl spacing="compact">
<list style="symbols"> <dt>Type name:</dt><dd>application</dd>
<t> <dt>Subtype name:</dt><dd>oauth-authz-req+jwt</dd>
Type name: application <dt>Required parameters:</dt><dd>N/A</dd>
</t> <dt>Optional parameters:</dt><dd>N/A</dd>
<t> <dt>Encoding considerations:</dt><dd>binary;
Subtype name: oauth-authz-req+jwt a Request Object is a JWT;
</t> JWT values are encoded as a
<t> series of base64url-encoded values (some of which may be the
Required parameters: n/a empty string) separated by period (<tt>.</tt>) characters.</dd>
</t> <dt>Security considerations:</dt><dd>See <xref target="Security"/>
<t> of RFC 9101</dd>
Optional parameters: n/a <dt>Interoperability considerations:</dt><dd>N/A</dd>
</t> <dt>Published specification:</dt><dd><xref
<t> target="authorization_request_object"/> of RFC 9101</dd>
Encoding considerations: binary; <dt>Applications that use this media type:</dt><dd>Applications
A Request Object is a JWT; that use Request Objects to make an OAuth 2.0 authorization
JWT values are encoded as a request</dd>
series of base64url-encoded values (some of which ma <dt>Fragment identifier considerations:</dt><dd>N/A</dd>
y be the <dt>Additional information:</dt><dd>
empty string) separated by period ('.') characters. <t><br/></t>
</t> <dl spacing="compact">
<t> <dt>Deprecated alias names for this type:</dt><dd>N/A</dd>
Security considerations: See <xref target="Security" <dt>Magic number(s):</dt><dd>N/A</dd>
/> of [[ this specification ]] <dt>File extension(s):</dt><dd>N/A</dd>
</t> <dt>Macintosh file type code(s):</dt><dd>N/A</dd>
<t> </dl>
Interoperability considerations: n/a </dd>
</t> <dt>Person &amp; email address to contact for further
<t> information:</dt><dd><br/>Nat Sakimura &lt;nat@nat.consulting&gt;</dd
Published specification: <xref target="authorization >
_request_object"/> of [[ this specification ]] <dt>Intended usage:</dt><dd>COMMON</dd>
</t> <dt>Restrictions on usage:</dt><dd>none</dd>
<t> <dt>Author:</dt><dd>Nat Sakimura &lt;nat@nat.consulting&gt;</dd>
Applications that use this media type: <dt>Change controller:</dt><dd>IETF</dd>
Applications that use Request Objects to make an OAu <dt>Provisional registration?</dt><dd>No</dd>
th 2.0 Authorization Request </dl>
</t>
<t>
Fragment identifier considerations: n/a
</t>
<t>
Additional information:<list style="empty">
<t>Magic number(s): n/a</t>
<t>File extension(s): n/a</t>
<t>Macintosh file type code(s): n/a </t></list>
<vspace/>
</t>
<t>
Person &amp; email address to contact for further in
formation:
<vspace/>
Nat Sakimura, nat@nat.consulting
</t>
<t>
Intended usage: COMMON
</t>
<t>
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>
</section>
<?rfc subcompact="no"?>
</section> </section>
</section>
</section> </section>
<section anchor="Security">
<name>Security Considerations</name>
<t>In addition to all the <xref target="RFC6819"> security
considerations discussed in OAuth 2.0</xref>, the security
considerations in <xref target="RFC7515"/>, <xref target="RFC7516"/>,
<xref target="RFC7518"/>, and <xref target="RFC8725"/> need to be
considered. Also, there are several academic papers such as <xref
target="BASIN"/> that provide useful insight into the security
properties of protocols like OAuth.
</t>
<section anchor="Security" title="Security Considerations"> <t>
<t>In addition to the all <xref target="RFC6819"> In consideration of the above, this document advises taking the
the security considerations discussed in OAuth 2.0</xref>, following security considerations into account.
the security considerations in </t>
<xref target="RFC7515" />,
<xref target="RFC7516" />,
<xref target="RFC7518" />, and
<xref target="RFC8725" /> need to be considered.
Also, there are several academic papers such as
<xref 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 of Algorithms">
<t>When sending the authorization request object through <spanx
style="verb">request</spanx> parameter, it MUST either be
signed using <xref target="RFC7515">JWS</xref>
or signed then encrypted using <xref target="RFC7515">JWS</xref> an
d
<xref target="RFC7516">JWE</xref> respectively,
with then considered appropriate algorithms. </t>
</section>
<section anchor="src_authn" title="Request Source Authentication"> <section anchor="alg_choice">
<t> <name>Choice of Algorithms</name>
The source of the Authorization Request MUST always be <t>When sending the Authorization Request Object through the
verified. There are several ways to do it: <tt>request</tt> parameter, it <bcp14>MUST</bcp14> be either
</t> signed using <xref target="RFC7515">JWS</xref>
<t><list style="format (%c)"> or signed and then encrypted using <xref target="RFC7515">JWS</xref> and
<t>Verifying the JWS Signature of the Request Object.</t> <xref target="RFC7516">JWE</xref>, respectively,
<t>Verifying that the symmetric key for the JWE encryptio with algorithms considered appropriate at the time. </t>
n is the correct one </section>
if the JWE is using symmetric encryption. <section anchor="src_authn">
Note however, that if public key encryption is used, <name>Request Source Authentication</name>
no source authentication is enabled by the encryption, <t>
as any party can encrypt content to the public key. The source of the authorization request <bcp14>MUST</bcp14> always be
</t> verified. There are several ways to do it:
<t>Verifying the TLS Server Identity of the Request Objec </t>
t URI. <ol spacing="normal" type="(%c)">
In this case, the Authorization Server MUST know <li>Verifying the JWS Signature of the Request Object.</li>
out-of-band that the Client uses Request Object URI and <li>Verifying that the symmetric key for the JWE encryption is the
only the Client is covered by the TLS certificate. correct one if the JWE is using symmetric encryption. Note, however,
In general, it is not a reliable method. that if public key encryption is used, no source authentication is
</t> enabled by the encryption, as any party can encrypt to the public
<t>When an Authorization Server implements a service key.</li>
that returns a Request Object URI in exchange for <li>Verifying the TLS Server Identity of the Request Object URI.
a Request Object, the Authorization In this case, the authorization server <bcp14>MUST</bcp14> know
Server MUST perform Client Authentication to accept out-of-band that the client uses the Request Object URI and
the Request Object and bind the Client Identifier only the client is covered by the TLS certificate.
to the Request Object URI it is providing. In general, this is not a reliable method.
It MUST validate the signature, per (a). </li>
Since Request Object URI can be replayed, the lifetime <li>When an authorization server implements a service
of the Request Object URI MUST be short and preferably that returns a Request Object URI in exchange for
one-time use. The entropy of the Request Object URI a Request Object, the authorization
MUST be sufficiently large. server <bcp14>MUST</bcp14> perform client authentication to accept
the Request Object and bind the client identifier
to the Request Object URI it is providing.
It <bcp14>MUST</bcp14> validate the signature, per (a).
Since the Request Object URI can be replayed, the lifetime
of the Request Object URI <bcp14>MUST</bcp14> be short and preferably
one-time use. The entropy of the Request Object URI
<bcp14>MUST</bcp14> be sufficiently large.
The adequate shortness of the validity and The adequate shortness of the validity and
the entropy of the Request Object URI depends the entropy of the Request Object URI depends
on the risk calculation based on the value on the risk calculation based on the value
of the resource being protected. A general guidance of the resource being protected. A general guidance
for the validity time would be less than a minute for the validity time would be less than a minute,
and the Request Object URI is to include a cryptographic and the Request Object URI is to include a cryptographic
random value of 128bit or more at the time of the random value of 128 bits or more at the time of the
writing of this specification. writing of this specification.
</t> </li>
<t> <li>When a trusted third-party service returns a Request Object URI
When a trusted third-party service in exchange for a Request Object, it <bcp14>MUST</bcp14> validate
returns a Request Object URI in exchange for the signature, per (a). In addition, the authorization server
a Request Object, <bcp14>MUST</bcp14> be trusted by the third-party service and
it MUST validate the signature, per (a). <bcp14>MUST</bcp14> know out-of-band that the client is also trusted b
In addition, the Authorization Server y it.
MUST be trusted by the third-party service and </li>
MUST know out-of-band that the client is also trusted by </ol>
it. </section>
</t> <section anchor="explicit_endpoints">
</list></t> <name>Explicit Endpoints</name>
</section>
<section anchor="explicit_endpoints" title="Explicit Endpoints"> <t>
<t>
Although this specification does not require them, Although this specification does not require them,
research such as <xref target="BASIN" /> points out that research such as <xref target="BASIN"/> points out that
it is a good practice to explicitly state it is a good practice to explicitly state
the intended interaction endpoints and the message the intended interaction endpoints and the message
position in the sequence in a tamper evident position in the sequence in a tamper-evident
manner so that the intent of the initiator is unambiguous. manner so that the intent of the initiator is unambiguous. It
The following endpoints defined in <xref target="RFC6749" />, is <bcp14>RECOMMENDED</bcp14> by this specification to use this
<xref target="RFC6750" />, and <xref target="RFC8414" /> are practice for the following endpoints defined in <xref
RECOMMENDED by this specification to use this practice : target="RFC6749"/>, <xref target="RFC6750"/>, and <xref
</t> target="RFC8414"/>:
<t><list style="format (%c)"> </t>
<t>Protected Resources (<spanx style="verb">protected_resources</sp <ol spacing="normal" type="(%c)">
anx>)</t> <li>Protected resources (<tt>protected_resources</tt>)</li>
<t>Authorization Endpoint (<spanx style="verb">authorization_endpoi <li>Authorization endpoint (<tt>authorization_endpoint</tt>)</li>
nt</spanx>)</t> <li>Redirection URI (<tt>redirect_uri</tt>)</li>
<t>Redirection URI (<spanx style="verb">redirect_uri</spanx>)</t> <li>Token endpoint (<tt>token_endpoint</tt>)</li>
<t>Token Endpoint (<spanx style="verb">token_endpoint</spanx>)</t> </ol>
</list></t> <t>
<t>
Further, if dynamic discovery is used, then this practice also appl ies Further, if dynamic discovery is used, then this practice also appl ies
to the discovery related endpoints. to the discovery-related endpoints.
</t> </t>
<t> <t>
In <xref target="RFC6749" />, In <xref target="RFC6749"/>,
while Redirection URI is included in the Authorization Request, oth while the redirection URI is included in the authorization request,
ers others
are not. are not. As a result, the same applies to the Authorization
As a result, the same applies to Authorization Request Object. Request Object.
</t> </t>
</section>
<section anchor="request_uri_threats" title="Risks Associated with requ </section>
est_uri"> <section anchor="request_uri_threats">
<t> <name>Risks Associated with request_uri</name>
The introduction of <spanx style="verb">request_uri</spanx> <t>
The introduction of <tt>request_uri</tt>
introduces several attack possibilities. introduces several attack possibilities.
Consult the security considerations in Section 7 of Consult the security considerations in
<xref target="RFC3986">RFC3986</xref> for more information regard <xref target="RFC3986" sectionFormat="of"
ing section="7"/> for more information
regarding
risks associated with URIs. risks associated with URIs.
</t> </t>
<section anchor="ddos_on_authz_server" title="DDoS Attack on the Auth <section anchor="ddos_on_authz_server">
orization Server"> <name>DDoS Attack on the Authorization Server</name>
<t> <t>
A set of malicious client can launch a DoS attack A set of malicious clients can launch a DoS attack
to the authorization server by pointing the to the authorization server by pointing the
<spanx style="verb">request_uri</spanx> to a URI <tt>request_uri</tt> to a URI
that returns extremely large content or extremely slow to respond that returns extremely large content or is extremely slow to resp
. ond.
Under such an attack, the server may use up its resource Under such an attack, the server may use up its resource
and start failing. and start failing.
</t> </t>
<t> <t>
Similarly, a malicious client can specify the Similarly, a malicious client can specify a
<spanx style="verb">request_uri</spanx> value <tt>request_uri</tt> value
that itself points to an authorization request URI that itself points to an authorization request URI
that uses <spanx style="verb">request_uri</spanx> to that uses <tt>request_uri</tt> to
cause the recursive lookup. cause the recursive lookup.
</t>
<t>
To prevent such attack to succeed, the server should
(a) check that the value of <spanx style="verb">request_uri</span
x>
parameter does not point to an unexpected location,
(b) check the media type of the response is
<spanx style="verb">application/oauth-authz-req+jwt</spanx>,
(c) implement a time-out for obtaining the content of
<spanx style="verb">request_uri</spanx>, and
(d) not perform recursive GET on the
<spanx style="verb">request_uri</spanx>.
</t>
</section>
<section anchor="request_uri_rewrite" title="Request URI Rewrite">
<t>
The value of <spanx style="verb">request_uri</spanx> is not signe
d
thus it can be tampered by Man-in-the-browser attacker.
Several attack possibilities rise because of this, e.g.,
(a) attacker may create another file that the rewritten
URI points to making it possible to request extra scope
(b) attacker launches a DoS attack to a victim site
by setting the value of <spanx style="verb">request_uri</spanx>
to be that of the victim.
</t>
<t>
To prevent such attack to succeed, the server should
(a) check that the value of <spanx style="verb">request_uri</span
x>
parameter does not point to an unexpected location,
(b) check the media type of the response is
<spanx style="verb">application/oauth-authz-req+jwt</spanx>, and
(c) implement a time-out for obtaining the content of
<spanx style="verb">request_uri</spanx>.
</t>
</section>
</section>
<section anchor="require_signed_request_object" title="Downgrade Attack">
<t>
Unless the protocol used by client and the server is locked down to
use OAuth JAR, it is possible for an attacker to use RFC6749 request
s
to bypass all the protection provided by this specification.
</t> </t>
<t> <t>
To prevent it, this specification defines a new client metadata and To prevent such an attack from succeeding, the server should
server metadata <spanx style="verb">require_signed_request_object</s a) check that the value of the <tt>request_uri</tt>
panx> parameter does not point to an unexpected location,
whose value is a boolean. b) check that the media type of the response is
<tt>application/oauth-authz-req+jwt</tt>,
c) implement a timeout for obtaining the content of
<tt>request_uri</tt>, and
d) not perform recursive GET on the
<tt>request_uri</tt>.
</t> </t>
</section>
<section anchor="request_uri_rewrite">
<name>Request URI Rewrite</name>
<t> <t>
When the value of it as a client metadata The value of <tt>request_uri</tt> is not signed;
is <spanx style="verb">true</spanx>, thus, it can be tampered with by a man-in-the-browser attacker.
then the server MUST reject the authorization request from Several attack possibilities arise because of this. For
the client that does example,
not conform to this specification. a) an attacker may create another file that the rewritten
It MUST also reject the request if the request object uses "alg":"no URI points to, making it possible to request extra scope, or
ne" b) an attacker may launch a DoS attack on a victim site
when this client metadata value is <spanx style="verb">true</spanx>. by setting the value of <tt>request_uri</tt>
If omitted, the default value is <spanx style="verb">false</spanx>. to be that of the victim.
</t> </t>
<t> <t>
When the value of it as a server metadata To prevent such an attack from succeeding, the server should
is <spanx style="verb">true</spanx>, a) check that the value of the <tt>request_uri</tt>
then the server MUST reject the authorization request from parameter does not point to an unexpected location,
any client that does b) check that the media type of the response is
not conform to this specification. <tt>application/oauth-authz-req+jwt</tt>, and
It MUST also reject the request if the request object uses "alg":"no c) implement a timeout for obtaining the content of
ne" <tt>request_uri</tt>.
when this server metadata value is <spanx style="verb">true</spanx>. </t>
If omitted, the default value is <spanx style="verb">false</spanx>. </section>
</t>
<t>
Note that even if <spanx style="verb">require_signed_request_object</
spanx>
metadata values are not present, the client MAY use signed request ob
jects,
provided that there are signing algorithms mutually supported by the
client and the server.
Use of signing algorithm metadata is described in <xref target="autho
rization_request_object"/>.
</t>
</section> </section>
<section 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 JWT-Secured Authorization Request (JAR), it is possible
for an attacker to use RFC 6749 requests
to bypass all the protection provided by this specification.
</t>
<t>
To prevent this kind of attack, this specification defines new
client metadata and server metadata values, both named
<tt>require_signed_request_object</tt>, whose values are both
booleans.
</t>
<t>
When the value of it as client metadata is <tt>true</tt>, then the
server <bcp14>MUST</bcp14> reject the authorization request from
the client that does not conform to this specification. It
<bcp14>MUST</bcp14> also reject the request if the Request Object
uses an <tt>alg</tt> value of <tt>none</tt> when this server
metadata value is <tt>true</tt>. If omitted, the default value is
<tt>false</tt>.
</t>
<section title="TLS Security Considerations" anchor="tls_sec"> <t>
<t>Current security When the value of it as server metadata is <tt>true</tt>, then the
considerations can be found in <xref target="BCP195">Recommendations server <bcp14>MUST</bcp14> reject the authorization request from
for Secure Use of TLS and DTLS</xref>. This any client that does not conform to this specification. It
<bcp14>MUST</bcp14> also reject the request if the Request Object
uses an <tt>alg</tt> value of <tt>none</tt>. If omitted, the
default value is <tt>false</tt>.
</t>
<t>Note that even if <tt>require_signed_request_object</tt> metadata
values are not present, the client <bcp14>MAY</bcp14> use signed 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>
</section>
<section anchor="tls_sec">
<name>TLS Security Considerations</name>
<t>Current security
considerations can be found in "<xref target="RFC7525" format="title"/>" <
xref target="RFC7525"/>. This
supersedes the TLS version recommendations in <xref target="RFC6749">OAuth supersedes the TLS version recommendations in <xref target="RFC6749">OAuth
2.0</xref>.</t> 2.0</xref>.</t>
</section> </section>
<section anchor="ParameterMismatches">
<section title="Parameter Mismatches" anchor="ParameterMismatches"> <name>Parameter Mismatches</name>
<t> <t>
Given that OAuth parameter values are being sent in two different place s, Given that OAuth parameter values are being sent in two different place s,
as normal OAuth parameters and as Request Object claims, as normal OAuth parameters and as Request Object claims,
implementations must guard against attacks that could use mismatching implementations must guard against attacks that could use mismatching
parameter values to obtain unintended outcomes. parameter values to obtain unintended outcomes.
That is the reason that the two Client ID values MUST match, That is the reason that the two client ID values <bcp14>MUST</bcp14> ma tch,
the reason that only the parameter values from the Request Object are t o be used, the reason that only the parameter values from the Request Object are t o be used,
and the reason that neither <spanx style="verb">request</spanx> nor and the reason that neither <tt>request</tt> nor
<spanx style="verb">request_uri</spanx> can appear in a Request Object. <tt>request_uri</tt> can appear in a Request Object.
</t> </t>
</section> </section>
<section anchor="CrossJWT">
<section title="Cross-JWT Confusion" anchor="CrossJWT"> <name>Cross-JWT Confusion</name>
<t> <t>
As described in Section 2.8 of <xref target="RFC8725"/>, As described in <xref 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. 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 O bjects. The mitigations described for these attacks can be applied to Request O bjects.
</t> </t>
<t> <t>
One way that an attacker might attempt to repurpose a Request Object One way that an attacker might attempt to repurpose a Request Object
is to try to use it as a client authentication JWT, is to try to use it as a client authentication JWT,
as described in Section 2.2 of <xref target="RFC7523"/>. as described in <xref target="RFC7523"
A simple way to prevent this is to never use the Client ID sectionFormat="of" section="2.2"/>.
as the <spanx style="verb">sub</spanx> value in a Request Object. A simple way to prevent this is to never use the client ID
</t> as the <tt>sub</tt> value in a Request Object.
<t> </t>
<t>
Another way to prevent cross-JWT confusion is to use explicit typing, Another way to prevent cross-JWT confusion is to use explicit typing,
as described in Section 3.11 of <xref target="RFC8725"/>. as described in <xref target="RFC8725"
sectionFormat="of" section="3.11"/>.
One would explicitly type a Request Object by including a One would explicitly type a Request Object by including a
<spanx style="verb">typ</spanx> Header Parameter with the value <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"/>. (which is registered in <xref target="MediaContents"/>).
Note however, that requiring explicitly typed Requests Objects Note, however, that requiring explicitly typed Request Objects
at existing authorization servers will break most existing deployments, at existing authorization servers will break most existing deployments,
as existing clients are already commonly using untyped Request Objects, as existing clients are already commonly using untyped Request Objects,
especially with OpenID Connect <xref target="OpenID.Core"/>. especially with OpenID Connect <xref target="OpenID.Core"/>.
However, requiring explicit typing would be a good idea However, requiring explicit typing would be a good idea
for new OAuth deployment profiles where compatibility with existing dep loyments for new OAuth deployment profiles where compatibility with existing dep loyments
is not a consideration. is not a consideration.
</t> </t>
<t> <t>
Finally, yet another way to prevent cross-JWT confusion is to use a key Finally, yet another way to prevent cross-JWT confusion is to use a key
management regime in which management regime in which keys used to sign Request Objects are
keys used to sign Request Objects are identifiably distinct from those identifiably distinct from those used for other purposes. Then, if an
used for other purposes. adversary attempts to repurpose the Request Object in another context, a key
Then, if an adversary attempts to repurpose the Request Object in anoth mismatch will occur, thwarting the attack.
er context, </t>
a key mismatch will occur, thwarting the attack.
</t>
</section> </section>
</section> </section>
<section anchor="Privacy">
<name>Privacy Considerations</name>
<section anchor="Privacy" title="Privacy Considerations"> <t>
<t> When the client is being granted access to a protected re
When the Client is being granted access to a protected re source
source containing personal data, both the client
containing personal data, both the Client and the authorization server need to adhere to
and the Authorization Server need to adhere to
Privacy Principles. Privacy Principles.
<xref target="RFC6973"> "<xref target="RFC6973" format="title"/>"
RFC 6973 Privacy Considerations for Internet Protocols <xref target="RFC6973" />
</xref>
gives excellent guidance on the gives excellent guidance on the
enhancement of protocol design and implementation. enhancement of protocol design and implementation.
The provision listed in it should be followed. The provisions listed in it should be followed.
</t> </t>
<t> <t>
Most of the provision would apply to Most of the provisions would apply to
<xref target="RFC6749">The OAuth 2.0 Authorization Framew "<xref target="RFC6749" format="title"/>" <xref target="R
ork</xref> FC6749"/>
and <xref target="RFC6750"> and "<xref target="RFC6750" format="title"/>" <xref targe
The OAuth 2.0 Authorization Framework: t="RFC6750"/>
Bearer Token Usage</xref>
and are not specific to this specification. and are not specific to this specification.
In what follows, only the specific provisions In what follows, only the provisions specific
to this specification are noted. to this specification are noted.
</t> </t>
<section anchor="collection_limitation">
<section anchor="collection_limitation" title="Collection limitat <name>Collection Limitation</name>
ion"> <t>
<t> When the client is being granted access to a protected resource
When the Client is being granted access to a prot containing personal data, the client <bcp14>SHOULD</bcp14> limit the
ected resource collection of personal data to that which is within the bounds of
containing personal data, applicable law and strictly necessary for the specified purpose(s).
the Client SHOULD limit the collection of </t>
personal data to that which is within <t>
the bounds of applicable law and strictly necessa It is often hard for the user to find out if the personal data asked
ry for is strictly necessary. A trusted third-party service can help the
for the specified purpose(s). user by examining the client request, comparing it to the proposed
</t> processing by the client, and certifying the request. After the
<t> certification, the client, when making an authorization request, can
It is often hard for the user to find out if submit an authorization request to the trusted third-party service to
the personal data asked for is strictly necessary obtain the Request Object URI. This process has two steps:
. </t>
A trusted third-party service can help the user <ol spacing="normal" type="(%d)">
by examining the Client request and comparing <li>(Certification Process) The trusted third-party service examines
to the proposed processing by the Client and the business process of the client and determines what claims they
certifying the request. After the certification, need; this is the certification process. Once the client is
the Client, when making an Authorization Request, certified, they are issued a client credential to authenticate
can submit Authorization Request to the against to push Request Objects to the trusted third-party service
trusted third-party service to obtain the Request to get the <tt>request_uri</tt>.</li>
Object URI. <li>(Translation Process) The client uses the client credential that
This process is two steps: it got to push the Request Object to the trusted third-party service
<list style="format (%d)"> to get the <tt>request_uri</tt>. The trusted third-party service
<t>(Certification Process) The trusted third-part also verifies that the Request Object is consistent with the claims
y service examines the business that the client is eligible for, per the prior step.
process of the client and determines what claims </li>
they need: </ol>
This is the certification process. Once the clien <t>
t is certified, Upon receiving such a Request Object URI in the authorization request,
then they are issued a client credential to authe the authorization server first verifies that the authority portion of
nticate against the Request Object URI is a legitimate one for the trusted third-party
to push request objects to the trusted third-part service. Then, the authorization server issues an HTTP GET request to
y service to get the the Request Object URI. Upon connecting, the authorization server
<spanx style="verb">request_uri</spanx>.</t> <bcp14>MUST</bcp14> verify that the server identity represented in the
<t>(Translation Process) The client uses the clie TLS certificate is legitimate for the Request Object URI. Then, the
nt credential authorization server can obtain the Request Object, which includes the
that it got to push the request object to the tru <tt>client_id</tt> representing the client.
sted third-party service to get the </t>
<spanx style="verb">request_uri</spanx>. <t>
The trusted third-party service also verifies tha The Consent screen <bcp14>MUST</bcp14> indicate the client and
t the Request Object is consistent with <bcp14>SHOULD</bcp14> indicate that the request has been vetted by the
the claims that the client is eligible for, per p trusted third-party service for the adherence to the collection
rior step. limitation principle.
</t> </t>
</list> </section>
</t> <section anchor="disclosure_limitation">
<t> <name>Disclosure Limitation</name>
Upon receiving such Request Object URI in the Aut <section anchor="request_disclosure">
horization <name>Request Disclosure</name>
Request, the Authorization Server first verifies
that the authority portion of the Request Object
URI
is a legitimate one for the trusted third-party s
ervice.
Then, the Authorization Server issues
HTTP GET request to the Request Object URI.
Upon connecting, the Authorization Server MUST
verify the server identity represented in the
TLS certificate is legitimate for the Request Obj
ect URI.
Then,
the Authorization Server can obtain the Request O
bject,
which includes the <spanx style="verb">client_id<
/spanx>
representing the Client.
</t>
<t>
The Consent screen
MUST indicate the Client and SHOULD indicate
that the request has been vetted by the trusted t
hird-party service
for adherence to the Collection Limitation princi
ple.
</t>
</section>
<section anchor="disclosure_limitation" title="Disclosure Limitat
ion">
<section anchor="request_disclosure" title="Request Discl
osure">
<t>
This specification allows extension param
eters.
These may include potentially sensitive i
nformation.
Since URI query parameter may leak throug
h various
means but most notably through referrer a
nd browser history,
if the authorization request contains a p
otentially sensitive
parameter, the Client SHOULD
<xref target="RFC7516">JWE</xref> encrypt
the request object.
</t>
<t>
Where Request Object URI method is being
used,
if the request object contains personally
identifiable
or sensitive information, the <spanx styl
e="verb">request_uri</spanx> SHOULD be
used only once, have a short validity per
iod, and MUST have large enough entropy
deemed necessary with applicable security
policy
unless the Request Object itself is
<xref target="RFC7516">JWE</xref> Encrypt
ed.
The adequate shortness of the validity an
d
the entropy of the Request Object URI dep
ends
on the risk calculation based on the valu
e
of the resource being protected. A genera
l guidance
for the validity time would be less than
a minute
and the Request Object URI is to include
a cryptographic
random value of 128bit or more at the tim
e of the
writing of this specification.
</t>
</section>
<section anchor="tracking" title="Tracking using Request
Object URI">
<t>
Even if the protected resource does not i
nclude a
personally identifiable information,
it is sometimes possible to identify the
user
through the Request Object URI if persist
ent static per-user
Request Object URIs are used. A third par
ty may observe
it through browser 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 Ob
ject URIs should be avoided.
Single-use Request Object URIs are one al
ternative.
</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> <t>
Annabelle Backman (Amazon), This specification allows extension parameters.
Dirk Balfanz (Google), These may include potentially sensitive information.
Sergey Beryozkin, Since URI query parameters may leak through various
Ben Campbell (as AD), means but most notably through referrer and browser history,
Brian Campbell (Ping Identity), if the authorization request contains a potentially sensitive
Roman Danyliw (as AD), parameter, the client <bcp14>SHOULD</bcp14> encrypt
Martin Duke (as AD), the Request Object using <xref target="RFC7516">JWE</xref>.
Vladimir Dzhuvinov (Connect2id), </t>
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 <xre <t>
f Where the Request Object URI method is being used, if the Request
target="OpenID.Core">the OpenID Connect Core 1.0</xref>.</t> Object contains personally identifiable or sensitive information,
the <tt>request_uri</tt> <bcp14>SHOULD</bcp14> be used only once
and have a short validity period, and it <bcp14>MUST</bcp14> have
sufficient entropy for the applicable security policies unless the
Request Object itself is encrypted using <xref
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, and the Request Object URI is to include a
cryptographic random value of 128 bits or more at the time of the
writing of this specification.
<t> </t>
Brian Campbell (Ping Identity), </section>
George Fletcher (AOL), <section anchor="tracking">
Ryo Itou (Mixi), <name>Tracking Using Request Object URI</name>
Edmund Jay (Illumila), <t>
Breno de Medeiros (Google), Even if the protected resource does not include
Hideki Nara (TACT), personally identifiable information,
Justin Richer (MITRE). it is sometimes possible to identify the user
</t> through the Request Object URI if persistent static per-user
Request Object URIs are used. A third party may observe
it through browser 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>
<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, Frances
ca 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 revie
w comments, including:
</t>
<t>
Added Security Considerations text saying not to use the Cl
ient ID
as the <spanx style="verb">sub</spanx> value
to prevent Cross-JWT Confusion.
</t>
<t>
Added Security Considerations text about using explicit typ
ing
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 ob
ject parameters,
removed extension parameters from example
s </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 UR
Ls </t>
<t>Section 5.2.3. Added entropy fragment to examp
le request</t>
<t>Section 8. Replaced "subjectAltName dnsName"
with "DNS-ID"</t>
<t>Section 9. Registers authorization request par
ameters in JWT Claims Registry. </t>
<t>Section 9. Registers application/oauth.authz.r
eq in IANA mime-types registry </t>
<t>Section 10.1. Clarified encrypted request obj
ects 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 t
he practice </t>
<t>Section 10.4 Replaced "redirect_uri" to "requ
est_uri" </t>
<t>Section 10.4. Added reference to RFC 3986 for
risks </t>
<t>Section 10.4.1.d Deleted "do" to maintain gram
mar flow </t>
<t>Section 10.4.1, 10.4.2 Replaced "application/
jose" to "application/jwt"</t>
<t>Section 12.1. Extended description for submitt
ing authorization request to TFP to obtain request object</t>
<t>Section 12.2.2. Replaced per-user Request Obj
ect URI with static per-user Request URIs</t>
<t>Section 13. Combined OAuth WG contributors tog
ether</t>
<t>Section Whole doc Replaced application/jwt wit
h 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 s
emicolons 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 - Inc
onsistent colons after initial sentence of list items.</t>
<t>fixes #53 - OPSDIR Review : 6.2 JWS Signed Req
uest Object - Clarify JOSE Header</t>
<t>fixes #42 - OPSDIR Review : Introduction - rea
dability 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 - 'pr
operties' sounds awkward and are not exactly 'properties'</t>
<t>fixes #56 - OPSDIR Review : 12 Acknowledgement
s - 'contribution is' => 'contribution are'</t>
<t>fixes #55 - OPSDIR Review : 11.2.2 Privacy Con
siderations - ' It is in a way' => 'In a way, it is'</t>
<t>fixes #54 - OPSDIR Review : 11 Privacy Conside
rations - '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 - 'ov
er- 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 - 'ha
s' => 'have'</t>
<t>fixes #41 - OPSDIR Review : Introduction - mis
sing 'is' before 'typically sent'</t>
<t>fixes #38 - OPSDIR Review : Section 11 - Delet
e '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 th
e TLS section.
</t>
<t>#21: KM2 - the additional attacks against OAut
h 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 a
ddition
to ISO 29100
</t>
<t>#24: SECDIR review: Section 4 -- Confusing req
uirements
for sign+encrypt
</t>
<t>#25: SECDIR review: Section 6 -- authenticatio
n and integrity
need not be provided if the requestor encrypts th
e token?
</t>
<t>#26: SECDIR Review: Section 10 -- why no refer
ence for
JWS algorithms?
</t>
<t>#27: SECDIR Review: Section 10.2 - how to do t
he 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 m
issing articles</t>
<t>#31: SECDIR Review: Section 10.4 - Clearer sta
tement
on the lack of endpoint identifiers needed</t>
<t>#32: SECDIR Review: Section 11 - ISO29100 need
s
to be moved to normative reference</t>
<t>#33: SECDIR Review: Section 11 - Better Englis
h and Entropy
language needed</t>
<t>#34: Section 4: Typo</t>
<t>#35: More Acknowledgment</t>
<t>#36: DP - More precise qualification on Encryp
tion 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 acknowledgme
nt. </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 w
ere used. </t>
<t>Generalized the language in 4.2.1 to convey th
e intent
more clearly.</t>
<t>Changed "Server" to "Authorization Server" as
a clarification.</t>
<t>Stopped talking about request_object_signing_a
lg.</t>
<t>IANA considerations now reflect the current st
atus.</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 e
tc.</t>
<t>1.Introduction improved.</t>
</list>
</t>
<t>-06</t>
<t>
<list style="symbols">
<t>Added explanation on the 512 chars URL restric
tion. </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 -> reque
st_uri, cliend_id -> client_id) </t>
<t>Aligned the error messages with the OAuth IANA
registry.</t>
<t>Added another rationale for having request obj
ect.</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 valu
es in the request itself and the request object from 'MUST MATCH" to 'Req Obj ta
kes 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> </middle>
<back> <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'?>
<reference anchor="IANA.MediaTypes" target="http://www.iana.org/a
ssignments/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-An
dre'>
<organization /></author>
<date year='2015' month='May' />
<abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Se
curity (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, severa
l serious
attacks on TLS have emerged, including attacks on its most commo
nly used cipher
suites and their modes of operation. This document provides rec
ommendations for
improving the security of deployed services that use TLS and DTL
S. The
recommendations are applicable to the majority of use cases.</t>
</abstract></front>
<seriesInfo name='BCP' value='195' /> <references>
<seriesInfo name='RFC' value='7525' /> <name>References</name>
<format type='TXT' octets='60283' target='http://www.rfc-editor.o <references>
rg/bcp/bcp195.txt' /> <name>Normative References</name>
</reference> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
</references> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3629.xml"/>
<references title="Informative References"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3986.xml"/>
<reference anchor="IANA.OAuth.Parameters" target="http://www.iana.org/ass <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ignments/oauth-parameters"> ence.RFC.6125.xml"/>
<front> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<title>OAuth Parameters</title> ence.RFC.6749.xml"/>
<author> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<organization>IANA</organization> ence.RFC.6750.xml"/>
</author>
<date/>
</front>
</reference>
<reference anchor="IANA.JWT.Claims" target="http://www.iana.org/assignment <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
s/jwt"> ence.RFC.7230.xml"/>
<front> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<title>JSON Web Token Claims</title> ence.RFC.7515.xml"/>
<author> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<organization>IANA</organization> ence.RFC.7516.xml"/>
</author> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<date/> ence.RFC.7518.xml"/>
</front> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</reference> ence.RFC.7519.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8141.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8259.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8414.xml"/>
<?rfc include='reference.RFC.7591'?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include='reference.RFC.6819'?> ence.RFC.7525.xml"/>
<?rfc include='reference.RFC.6973'?> </references>
<?rfc include='reference.RFC.2046' ?> <references>
<?rfc include='reference.RFC.6838' ?>
<?rfc include='reference.RFC.7523' ?>
<?rfc include='reference.RFC.8725' ?>
<reference anchor="OpenID.Core" target="http://openid.net/specs/openid-con <name>Informative References</name>
nect-core-1_0.html">
<front>
<title>OpenID Connect Core 1.0</title>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura"> <reference anchor="IANA.MediaTypes" target="https://www.iana.org/assignm
<organization abbrev="NAT Consulting">NAT Consulting</organization> ents/media-types">
</author> <front>
<title>Media Types</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<author fullname="John Bradley" initials="J." surname="Bradley"> <reference anchor="IANA.OAuth.Parameters" target="https://www.iana.org/a
<organization abbrev="Ping Identity">Ping Identity</organization> ssignments/oauth-parameters">
</author> <front>
<title>OAuth Parameters</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones"> <reference anchor="IANA.JWT.Claims" target="https://www.iana.org/assignm
<organization abbrev="Microsoft">Microsoft</organization> ents/jwt">
</author> <front>
<title>JSON Web Token (JWT)</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<author fullname="Breno de Medeiros" initials="B." surname="de Medeiro <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
s"> ence.RFC.7591.xml"/>
<organization abbrev="Google">Google</organization> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</author> ence.RFC.6819.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6973.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2046.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6838.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7523.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8725.xml"/>
<author fullname="Chuck Mortimore" initials="C." surname="Morti <reference anchor="OpenID.Core" target="http://openid.net/specs/openid-c
more"> onnect-core-1_0.html">
<organization abbrev="Salesforce">Salesforce</organizatio <front>
n> <title>OpenID Connect Core 1.0 incorporating errata set 1</title>
</author> <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 Medei
ros">
<organization abbrev="Google">Google</organization>
</author>
<author fullname="Chuck Mortimore" initials="C." surname="Mortimore"
>
<organization abbrev="Salesforce">Salesforce</organization>
</author>
<date day="8" month="November" year="2014"/>
</front>
<refcontent>OpenID Foundation Standards</refcontent>
</reference>
<date day="25" month="February" year="2014"/> <reference anchor="BASIN" target="https://www.cs.ox.ac.uk/people/cas.cre
</front> mers/downloads/papers/BCM2012-iso9798.pdf">
<seriesInfo name="OpenID Foundation" <front>
value="Standards" /> <title>Provably Repairing the ISO/IEC 9798 Standard for Entity Authe
</reference> ntication</title>
<author fullname="David Basin" initials="D." surname="Basin"/>
<author fullname="Cas Cremers" initials="C." surname="Cremers"/>
<author fullname="Simon Meier" initials="S." surname="Meier"/>
<date month="November" year="2013"/>
</front>
<refcontent>Journal of Computer Security - Security and Trust Princi
ples, Volume 21, Issue 6, pp. 817-846</refcontent>
<reference anchor="BASIN" target="https://www.cs.ox.ac.uk/people/cas.creme </reference>
rs/downloads/papers/BCM2012-iso9798.pdf">
<front>
<title>Provably Repairing the ISO/IEC 9798 Standard for Entity Authent
ication</title>
<author fullname="David Basin" initials="D." surname="Basin"></author>
<author fullname="Cas Cremers" initials="C." surname="Cremers"></autho
r>
<author fullname="Simon Meier" initials="S." surname="Meier"></author>
<date month="November" year="2013" />
</front>
<seriesInfo name="Journal of Computer Security - Security and Trust Prin
ciples"
value="Volume 21 Issue 6, Pages 817-846" />
</reference>
<reference anchor="CapURLs" target="https://www.w3.org/TR/capability-url s/"> <reference anchor="CapURLs" target="https://www.w3.org/TR/capability-url s/">
<front> <front>
<title>Good Practices for Capability URLs</title> <title>Good Practices for Capability URLs</title>
<author fullname="Jeni Tennison" initials="J." surname="Tennison <author fullname="Jeni Tennison" initials="J." surname="Tennison" ro
"></author> le="editor"/>
<date day="18" month="February" year="2014" /> <date day="18" month="February" year="2014"/>
</front> </front>
<seriesInfo name="W3C" <refcontent>W3C First Public Working Draft</refcontent>
value="Working Draft" />
</reference> </reference>
</references>
</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> </back>
</rfc> </rfc>
 End of changes. 162 change blocks. 
1939 lines changed or deleted 1249 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/