rfc9126.original.xml		rfc9126.xml
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process
	or - mmark.miek.nl" -->		<!DOCTYPE rfc [
	<rfc version="3" ipr="trust200902" docName="draft-ietf-oauth-par-10" submissionT		<!ENTITY nbsp "&#160;">
	ype="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclud		<!ENTITY zwsp "&#8203;">
	e" consensus="true">		<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
			]>
			<rfc version="3" ipr="trust200902" docName="draft-ietf-oauth-par-10" number="912
			6" submissionType="IETF" category="std" consensus="true" updates="" obsoletes=""
			tocInclude="true" symRefs="true" sortRefs="true" xml:lang="en" xmlns:xi="http:/
			/www.w3.org/2001/XInclude">
	<front>		<front>
	<title abbrev="OAuth PAR">OAuth 2.0 Pushed Authorization Requests</title><series		<title abbrev="OAuth PAR">OAuth 2.0 Pushed Authorization Requests</title>
	Info value="draft-ietf-oauth-par-10" stream="IETF" status="standard" name="Inter		<seriesInfo name="RFC" value="9126"/>
	net-Draft"></seriesInfo>
	<author initials="T." surname="Lodderstedt" fullname="Torsten Lodderstedt"><orga nization>yes.com</organization><address><postal><street></street>		<author initials="T." surname="Lodderstedt" fullname="Torsten Lodderstedt"><orga nization>yes.com</organization><address><postal><street></street>
	</postal><email>torsten@lodderstedt.net</email>		</postal><email>torsten@lodderstedt.net</email>
	</address></author>		</address></author>
	<author initials="B." surname="Campbell" fullname="Brian Campbell"><organization >Ping Identity</organization><address><postal><street></street>		<author initials="B." surname="Campbell" fullname="Brian Campbell"><organization >Ping Identity</organization><address><postal><street></street>
	</postal><email>bcampbell@pingidentity.com</email>		</postal><email>bcampbell@pingidentity.com</email>
	</address></author>		</address></author>
	<author initials="N." surname="Sakimura" fullname="Nat Sakimura"><organization>N AT.Consulting</organization><address><postal><street></street>		<author initials="N." surname="Sakimura" fullname="Nat Sakimura"><organization>N AT.Consulting</organization><address><postal><street></street>
	</postal><email>nat@sakimura.org</email>		</postal><email>nat@sakimura.org</email>
	</address></author>		</address></author>
	<author initials="D." surname="Tonge" fullname="Dave Tonge"><organization>Moneyh ub Financial Technology</organization><address><postal><street></street>		<author initials="D." surname="Tonge" fullname="Dave Tonge"><organization>Moneyh ub Financial Technology</organization><address><postal><street></street>
	</postal><email>dave@tonge.org</email>		</postal><email>dave@tonge.org</email>
	</address></author>		</address></author>
	<author initials="F." surname="Skokan" fullname="Filip Skokan"><organization>Aut h0</organization><address><postal><street></street>		<author initials="F." surname="Skokan" fullname="Filip Skokan"><organization>Aut h0</organization><address><postal><street></street>
	</postal><email>panva.ip@gmail.com</email>		</postal><email>panva.ip@gmail.com</email>
	</address></author>		</address></author>
	<date/>
			<date year="2021" month="September" />
	<area>Security</area>		<area>Security</area>
	<workgroup>Web Authorization Protocol</workgroup>		<workgroup>Web Authorization Protocol</workgroup>
	<keyword>security</keyword>		<keyword>security</keyword>
	<keyword>oauth2</keyword>		<keyword>oauth2</keyword>
	<abstract>		<abstract>
	<t>This document defines the pushed authorization request (PAR) endpoint, which allows		<t>This document defines the pushed authorization request (PAR) endpoint, which allows
	clients to push the payload of an OAuth 2.0 authorization request to the		clients to push the payload of an OAuth 2.0 authorization request to the
	authorization server via a direct request and provides them		authorization server via a direct request and provides them
	with a request URI that is used as reference to the data in a		with a request URI that is used as reference to the data in a
	subsequent call to the authorization endpoint.</t>		subsequent call to the authorization endpoint.</t>
	</abstract>		</abstract>
	skipping to change at line 41 ¶		skipping to change at line 56 ¶
	authorization server via a direct request and provides them		authorization server via a direct request and provides them
	with a request URI that is used as reference to the data in a		with a request URI that is used as reference to the data in a
	subsequent call to the authorization endpoint.</t>		subsequent call to the authorization endpoint.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="Introduction"><name>Introduction</name>		<section anchor="Introduction"><name>Introduction</name>
	<t>A pushed authorization request (PAR), defined by this document, enables an OA uth <xref target="RFC6749"></xref> client		<t>This document defines the pushed authorization request (PAR) endpoint, which enables an OAuth <xref target="RFC6749"></xref> client
	to push the payload of an authorization request directly		to push the payload of an authorization request directly
	to the authorization server. A request URI value is received in in exchange, whi ch is used as reference		to the authorization server. A request URI value is received in exchange; it is used as reference
	to the authorization request payload data in a subsequent call to the authorizat ion endpoint		to the authorization request payload data in a subsequent call to the authorizat ion endpoint
	via the user agent.</t>		via the user agent.</t>
	<t>In OAuth <xref target="RFC6749"></xref> authorization request parameters are typically sent as URI query		<t>In OAuth <xref target="RFC6749"></xref>, authorization request parameters are typically sent as URI query
	parameters via redirection in the user agent. This is simple but also yields cha llenges:</t>		parameters via redirection in the user agent. This is simple but also yields cha llenges:</t>
	<ul>		<ul>
	<li>There is no cryptographic integrity and authenticity protection. An attacker could, for example, modify the scope of access requested or swap the context of a payment transaction by changing scope values. Although protocol facilities ex ist to enable clients or users to detect some such changes, preventing modificat ions early in the process is a more robust solution.</li>		<li>There is no cryptographic integrity and authenticity protection. An attacker could, for example, modify the scope of access requested or swap the context of a payment transaction by changing scope values. Although protocol facilities ex ist to enable clients or users to detect some such changes, preventing modificat ions early in the process is a more robust solution.</li>
	<li>There is no mechanism to ensure confidentiality of the request parameters. A lthough HTTPS is required for the authorization endpoint, the request data passe s through the user agent in the clear and query string data can inadvertently le ak to web server logs and to other sites via referer. The impact of such leakage can be significant, if personally identifiable information or other regulated d ata is sent in the authorization request (which might well be the case in identi ty, open banking, and similar scenarios).</li>		<li>There is no mechanism to ensure confidentiality of the request parameters. A lthough HTTPS is required for the authorization endpoint, the request data passe s through the user agent in the clear, and query string data can inadvertently l eak to web server logs and to other sites via the referer. The impact of such le akage can be significant, if personally identifiable information or other regula ted data is sent in the authorization request (which might well be the case in i dentity, open banking, and similar scenarios).</li>
	<li>Authorization request URLs can become quite large, especially in scenarios r equiring fine-grained authorization data, which might cause errors in request pr ocessing.</li>		<li>Authorization request URLs can become quite large, especially in scenarios r equiring fine-grained authorization data, which might cause errors in request pr ocessing.</li>
	</ul>		</ul>
	<t>JWT Secured Authorization Request (JAR) <xref target="I-D.ietf-oauth-jwsreq">		<t>JWT-Secured Authorization Request (JAR) <xref target="RFC9101"></xref> provid
	</xref> provides solutions for the security challenges by allowing OAuth clients		es solutions for the security challenges by allowing OAuth clients to wrap autho
	to wrap authorization request parameters in a request object, which is a signed		rization request parameters in a Request Object, which is a signed and optionall
	and optionally encrypted JSON Web Token (JWT) <xref target="RFC7519"></xref>. I		y encrypted JSON Web Token (JWT) <xref target="RFC7519"></xref>.
	n order to cope with the size restrictions, JAR introduces the <tt>request_uri</
	tt> parameter that allows clients to send a reference to a request object instea		In order to cope with the size restrictions, JAR introduces the <tt>request_uri<
	d of the request object itself.</t>		/tt> parameter that allows clients to send a reference to a Request Object inste
			ad of the Request Object itself.</t>
	<t>This document complements JAR by providing an interoperable way to push the p ayload of an authorization request directly to the authorization server in excha nge for a <tt>request_uri</tt> value usable at the authorization server in a sub sequent authorization request.</t>		<t>This document complements JAR by providing an interoperable way to push the p ayload of an authorization request directly to the authorization server in excha nge for a <tt>request_uri</tt> value usable at the authorization server in a sub sequent authorization request.</t>
	<t>PAR fosters OAuth security by providing clients a simple means for a confiden		<t>PAR fosters OAuth security by providing clients a simple means for a confiden
	tial and integrity protected authorization request. Clients requiring an even hi		tial and integrity-protected authorization request. Clients requiring an even hi
	gher security level, especially cryptographically confirmed non-repudiation, are		gher security level, especially cryptographically confirmed non-repudiation, are
	able to use JWT-based request objects as defined by <xref target="I-D.ietf-oaut		able to use JWT-based Request Objects as defined by <xref target="RFC9101"></xr
	h-jwsreq"></xref> in conduction with PAR.</t>		ef>
			in conjunction with PAR.</t>
	<t>PAR allows the authorization server to authenticate the client before any use r interaction happens.		<t>PAR allows the authorization server to authenticate the client before any use r interaction happens.
	The increased confidence in the identity of the client during the authorization process allows the authorization server to refuse illegitimate requests much ear lier in the process, which can prevent attempts to spoof clients or otherwise ta mper with or misuse an authorization request.</t>		The increased confidence in the identity of the client during the authorization process allows the authorization server to refuse illegitimate requests much ear lier in the process, which can prevent attempts to spoof clients or otherwise ta mper with or misuse an authorization request.</t>
	<t>Note that HTTP <tt>POST</tt> requests to the authorization endpoint via the u ser agent, as described in Section 3.1 of <xref target="RFC6749"></xref> and Sec tion 3.1.2.1 of <xref target="OIDC"></xref>, could also be used to cope with the request size limitations described above. However, it's only optional per <xref target="RFC6749"></xref> and, even when supported, it is a viable option for tr aditional web applications but is prohibitively difficult to use with native mob ile applications. As described in <xref target="RFC8252"></xref> those apps use platform-specific APIs to open the authorization request URI in the system brows er. When a native app launches a browser, however, the resultant initial request is constrained to use the <tt>GET</tt> method. Using <tt>POST</tt> for the auth orization request would require the app to first direct the browser to open a UR I that the app controls via <tt>GET</tt> while somehow conveying the sizable aut horization request payload and then have the resultant response contain content and script to initiate a cross-site form <tt>POST</tt> towards the authorization server. PAR is simpler to use and has additional security benefits described ab ove.</t>		<t>Note that HTTP <tt>POST</tt> requests to the authorization endpoint via the u ser agent, as described in <xref target="RFC6749" sectionFormat="of" section="3. 1"></xref> and Section 3.1.2.1 of <xref target="OIDC"></xref>, could also be use d to cope with the request size limitations described above. However, it's only optional per <xref target="RFC6749"></xref>, and, even when supported, it is a v iable option for conventional web applications but is prohibitively difficult to use with installed mobile applications. As described in <xref target="RFC8252"> </xref>, those apps use platform-specific APIs to open the authorization request URI in the system browser. When a mobile app launches a browser, however, the r esultant initial request is constrained to use the <tt>GET</tt> method. Using <t t>POST</tt> for the authorization request would require the app to first direct the browser to open a URI that the app controls via <tt>GET</tt> while somehow c onveying the sizable authorization request payload and then having the resultant response contain the content and script to initiate a cross-site form <tt>POST< /tt> towards the authorization server. PAR is simpler to use and has additional security benefits, as described above.</t>
	<section anchor="introductory-example"><name>Introductory Example</name>		<section anchor="introductory-example"><name>Introductory Example</name>
	<t>In traditional OAuth 2.0, a client typically initiates an authorization reque st by directing the user agent to make an HTTP request like the following to the authorization server's authorization endpoint (extra line breaks and indentatio n for display purposes only):</t>		<t>In conventional OAuth 2.0, a client typically initiates an authorization requ est by directing the user agent to make an HTTP request like the following to th e authorization server's authorization endpoint (extra line breaks and indentati on for display purposes only):</t>
	<artwork> GET /authorize?response_type=code		<sourcecode type="http-message"> GET /authorize?response_type=code
	&amp;client_id=CLIENT1234&amp;state=duk681S8n00GsJpe7n9boxdzen		&amp;client_id=CLIENT1234&amp;state=duk681S8n00GsJpe7n9boxdzen
	&amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1		&amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
	Host: as.example.com		Host: as.example.com
	</artwork>		</sourcecode>
	<t>Such a request could instead be pushed directly to the authorization server b		<t>Such a request could instead be pushed directly to the authorization server b
	y the client with a <tt>POST</tt> request to the PAR endpoint as illustrated in		y the client with a <tt>POST</tt> request to the PAR endpoint as illustrated in
	the following example (extra line breaks and whitespace for display purposes onl		the following example (extra line breaks and spaces for display purposes only).
	y).		The client can authenticate (e.g., using JWT client assertion-based authenticati
	The client can authenticate (e.g., using JWT client assertion based authenticati		on as shown) because the request is made directly to the authorization server.</
	on as shown) because the request is made directly to the authorization server.</		t>
	t>
	<artwork> POST /as/par HTTP/1.1		<sourcecode type="http-message"> POST /as/par HTTP/1.1
	Host: as.example.com		Host: as.example.com
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	&amp;response_type=code		&amp;response_type=code
	&amp;client_id=CLIENT1234&amp;state=duk681S8n00GsJpe7n9boxdzen		&amp;client_id=CLIENT1234&amp;state=duk681S8n00GsJpe7n9boxdzen
	&amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb		&amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
	&amp;client_assertion_type=		&amp;client_assertion_type=
	urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer		urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
	&amp;client_assertion=eyJraWQiOiI0MiIsImFsZyI6IkVTMjU2In0.eyJpc3MiOiJDTE		&amp;client_assertion=eyJraWQiOiI0MiIsImFsZyI6IkVTMjU2In0.eyJpc3MiOiJDTE
	lFTlQxMjM0Iiwic3ViIjoiQ0xJRU5UMTIzNCIsImF1ZCI6Imh0dHBzOi8vc2VydmVyL		lFTlQxMjM0Iiwic3ViIjoiQ0xJRU5UMTIzNCIsImF1ZCI6Imh0dHBzOi8vc2VydmVyL
	mV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY4ODc4fQ.Igw8QrpAWRNPDGoWGRmJumLBM		mV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY4ODc4fQ.Igw8QrpAWRNPDGoWGRmJumLBM
	wbLjeIYwqWUu-ywgvvufl_0sQJftNs3bzjIrP0BV9rRG-3eI1Ksh0kQ1CwvzA		wbLjeIYwqWUu-ywgvvufl_0sQJftNs3bzjIrP0BV9rRG-3eI1Ksh0kQ1CwvzA
	</artwork>		</sourcecode>
	<t>The authorization server responds with a request URI:</t>		<t>The authorization server responds with a request URI:</t>
	<artwork> HTTP/1.1 201 Created		<sourcecode type="http-message"> HTTP/1.1 201 Created
	Cache-Control: no-cache, no-store		Cache-Control: no-cache, no-store
	Content-Type: application/json		Content-Type: application/json
	{		{
	&quot;request_uri&quot;: &quot;urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2&quot;,		&quot;request_uri&quot;: &quot;urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2&quot;,
	&quot;expires_in&quot;: 90		&quot;expires_in&quot;: 90
	}		}
	</artwork>		</sourcecode>
	<t>The client uses the request URI value to create the subsequent authorization request by directing the user agent to make an HTTP request to the authorization server's authorization endpoint like the following (extra line breaks and inden tation for display purposes only):</t>		<t>The client uses the request URI value to create the subsequent authorization request by directing the user agent to make an HTTP request to the authorization server's authorization endpoint like the following (extra line breaks and inden tation for display purposes only):</t>
	<artwork> GET /authorize?client_id=CLIENT1234		<sourcecode type="http-message"> GET /authorize?client_id=CLIENT1234
	&amp;request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1		&amp;request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1
	Host: as.example.com		Host: as.example.com
	</artwork>		</sourcecode>
	</section>		</section>
	<section anchor="conventions-and-terminology"><name>Conventions and Terminology< /name>		<section anchor="conventions-and-terminology"><name>Conventions and Terminology< /name>
	<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &		<t>
	quot;SHALL&quot;, &quot;SHALL		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;,		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	&quot;NOT RECOMMENDED&quot;,		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	&quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	as		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref		be interpreted as
	> when, and only when, they		described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	appear in all capitals, as shown here.</t>		when, and only when, they appear in all capitals, as shown here.
			</t>
	<t>This specification uses the terms &quot;access token&quot;,		<t>This specification uses the terms &quot;access token&quot;,
	&quot;authorization server&quot;, &quot;authorization endpoint&quot;,		&quot;authorization server&quot;, &quot;authorization endpoint&quot;,
	&quot;authorization request&quot;, &quot;token endpoint&quot;,		&quot;authorization request&quot;, &quot;token endpoint&quot;,
	and		and
	&quot;client&quot; defined by The OAuth 2.0 Authorization Framework <xref target ="RFC6749"></xref>.</t>		&quot;client&quot; defined by "The OAuth 2.0 Authorization Framework" <xref targ et="RFC6749" format="default"/>.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="pushed-authorization-request-endpoint"><name>Pushed Authorizati on Request Endpoint</name>		<section anchor="pushed-authorization-request-endpoint"><name>Pushed Authorizati on Request Endpoint</name>
	<t>The pushed authorization request endpoint is an HTTP API at the authorization		<t>The pushed authorization request endpoint is an HTTP API at the authorization
	server that accepts HTTP <tt>POST</tt> requests with parameters in the HTTP req		server that accepts HTTP <tt>POST</tt> requests with parameters in the HTTP req
	uest message body using the <tt>application/x-www-form-urlencoded</tt> format wi		uest message body using the <tt>application/x-www-form-urlencoded</tt> format. T
	th a character encoding of UTF-8 as described in Appendix B of <xref target="RFC		his format has a character encoding of UTF-8, as described in <xref target="RFC6
	6749"></xref>. The PAR endpoint URL MUST use the &quot;https&quot; scheme.</t>		749" sectionFormat="of" section="B"></xref>. The PAR endpoint URL <bcp14>MUST</b
	<t>Authorization servers supporting PAR SHOULD include the URL of their pushed a		cp14> use the &quot;https&quot; scheme.</t>
	uthorization request endpoint in their authorization server metadata document <x		<t>Authorization servers supporting PAR <bcp14>SHOULD</bcp14> include the URL of
	ref target="RFC8414"></xref> using the <tt>pushed_authorization_request_endpoint		their pushed authorization request endpoint in their authorization server metad
	</tt> parameter as defined in <xref target="as_metadata"></xref>.</t>		ata document <xref target="RFC8414"></xref> using the <tt>pushed_authorization_r
	<t>The endpoint accepts the authorization request parameters defined in <xref ta		equest_endpoint</tt> parameter as defined in <xref target="as_metadata"></xref>.
	rget="RFC6749"></xref> for the authorization endpoint as well as all applicable		</t>
	extensions defined for the authorization endpoint. Some examples of such extensi		<t>The endpoint accepts the authorization request parameters defined in <xref ta
	ons include PKCE <xref target="RFC7636"></xref>, Resource Indicators <xref targe		rget="RFC6749"></xref> for the authorization endpoint as well as all applicable
	t="RFC8707"></xref>, and OpenID Connect <xref target="OIDC"></xref>. The endpoin		extensions defined for the authorization endpoint. Some examples of such extensi
	t MAY also support sending the set of authorization request parameters as a requ		ons include Proof Key for Code Exchange (PKCE) <xref target="RFC7636"></xref>, R
	est object according to <xref target="I-D.ietf-oauth-jwsreq"></xref> and <xref t		esource Indicators <xref target="RFC8707"></xref>, and OpenID Connect (OIDC) <xr
	arget="request_parameter"></xref>.</t>		ef target="OIDC"></xref>. The endpoint <bcp14>MAY</bcp14> also support sending t
	<t>The rules for client authentication as defined in <xref target="RFC6749"></xr		he set of authorization request parameters as a Request Object according to <xre
	ef> for token endpoint requests, including the applicable authentication methods		f target="RFC9101"></xref> and <xref target="request_parameter"></xref> of this
	, apply for the PAR endpoint as well. If applicable, the <tt>token_endpoint_auth		document.</t>
	_method</tt> client metadata <xref target="RFC7591"></xref> parameter indicates		<t>The rules for client authentication as defined in <xref target="RFC6749"></xr
	the registered authentication method for the client to use when making direct re		ef> for token endpoint requests, including the applicable authentication methods
	quests to the authorization server, including requests to the PAR endpoint. Simi		, apply for the PAR endpoint as well. If applicable, the <tt>token_endpoint_auth
	larly, the <tt>token_endpoint_auth_methods_supported</tt> authorization server m		_method</tt> client metadata parameter <xref target="RFC7591"></xref> indicates
	etadata <xref target="RFC8414"></xref> parameter lists client authentication met		the registered authentication method for the client to use when making direct re
	hods supported by the authorization server when accepting direct requests from c		quests to the authorization server, including requests to the PAR endpoint. Simi
	lients, including requests to the PAR endpoint.</t>		larly, the <tt>token_endpoint_auth_methods_supported</tt> authorization server m
	<t>Due to historical reasons there is potential ambiguity regarding the appropri		etadata <xref target="RFC8414"></xref> parameter lists client authentication met
	ate audience		hods supported by the authorization server when accepting direct requests from c
	value to use when employing JWT client assertion based authentication (defined i		lients, including requests to the PAR endpoint.</t>
	n Section 2.2 of <xref target="RFC7523"></xref> with <tt>private_key_jwt</tt> or		<t>Due to historical reasons, there is potential ambiguity regarding the appropr
	<tt>client_secret_jwt</tt> authentication method names per Section 9 of <xref t		iate audience
	arget="OIDC"></xref>). To address that ambiguity the issuer identifier URL of th		value to use when employing JWT client assertion-based authentication (defined i
	e authorization server according to <xref target="RFC8414"></xref> SHOULD be use		n <xref target="RFC7523" sectionFormat="of" section="2.2"></xref> with <tt>priva
	d as the value of the audience. In order to facilitate interoperability the auth		te_key_jwt</tt> or <tt>client_secret_jwt</tt> authentication method names per Se
	orization server MUST accept its issuer identifier, token endpoint URL, or pushe		ction 9 of <xref target="OIDC"></xref>). To address that ambiguity, the issuer i
	d authorization request endpoint URL as values that identify it as an intended a		dentifier URL of the authorization server according to <xref target="RFC8414"></
	udience.</t>		xref> <bcp14>SHOULD</bcp14> be used as the value of the audience. In order to fa
			cilitate interoperability, the authorization server <bcp14>MUST</bcp14> accept i
			ts issuer identifier, token endpoint URL, or pushed authorization request endpoi
			nt URL as values that identify it as an intended audience.</t>
	<section anchor="request"><name>Request</name>		<section anchor="request"><name>Request</name>
	<t>A client sends the parameters that comprise an authorization request directly		<t>A client sends the parameters that comprise an authorization request directly
	to the PAR endpoint. A typical parameter set might include: <tt>client_id</tt>,		to the PAR endpoint. A typical parameter set might include: <tt>client_id</tt>,
	<tt>response_type</tt>, <tt>redirect_uri</tt>, <tt>scope</tt>, <tt>state</tt>,		<tt>response_type</tt>, <tt>redirect_uri</tt>, <tt>scope</tt>, <tt>state</tt>,
	<tt>code_challenge</tt>, and <tt>code_challenge_method</tt> as shown in the exam		<tt>code_challenge</tt>, and <tt>code_challenge_method</tt> as shown in the exam
	ple below. However, the pushed authorization request can be composed of any of t		ple below. However, the pushed authorization request can be composed of any of t
	he parameters applicable for use at authorization endpoint including those defin		he parameters applicable for use at the authorization endpoint, including those
	ed in <xref target="RFC6749"></xref> as well as all applicable extensions. The <		defined in <xref target="RFC6749"></xref> as well as all applicable extensions.
	tt>request_uri</tt> authorization request parameter is one exception, which MUST		The <tt>request_uri</tt> authorization request parameter is one exception, and i
	NOT be provided.</t>		t <bcp14>MUST NOT</bcp14> be provided.</t>
	<t>The request also includes, as appropriate for the given client, any additiona		<t>The request also includes, as appropriate for the given client, any additiona
	l parameters necessary for client authentication (e.g., <tt>client_secret</tt>,		l parameters necessary for client authentication (e.g., <tt>client_secret</tt>
	or <tt>client_assertion</tt> and <tt>client_assertion_type</tt>). Such parameter		or <tt>client_assertion</tt> and <tt>client_assertion_type</tt>). Such parameter
	s are defined and registered for use at the token endpoint but are applicable on		s are defined and registered for use at the token endpoint but are applicable on
	ly for client authentication. When present in a pushed authorization request, th		ly for client authentication. When present in a pushed authorization request, th
	ey are relied upon only for client authentication and are not germane to the aut		ey are relied upon only for client authentication and are not germane to the aut
	horization request itself. Any token endpoint parameters that are not related to		horization request itself. Any token endpoint parameters that are not related to
	client authentication have no defined meaning for a pushed authorization reques		client authentication have no defined meaning for a pushed authorization reques
	t. The <tt>client_id</tt> parameter is defined with the same semantics for both		t. The <tt>client_id</tt> parameter is defined with the same semantics for both
	authorization requests and requests to the token endpoint; as a required authori		authorization requests and requests to the token endpoint; as a required authori
	zation request parameter, it is similarly required in a pushed authorization req		zation request parameter, it is similarly required in a pushed authorization req
	uest.</t>		uest.</t>
	<t>The client constructs the message body of an HTTP <tt>POST</tt> request with		<t>The client constructs the message body of an HTTP <tt>POST</tt> request with
	<tt>x-www-form-urlencoded</tt> formatted parameters using a character encoding o		parameters formatted with <tt>x-www-form-urlencoded</tt> using a character encod
	f UTF-8 as described in Appendix B of <xref target="RFC6749"></xref>. If applica		ing of UTF-8, as described in <xref target="RFC6749" sectionFormat="of" section=
	ble, the client also adds its authentication credentials to the request header o		"B"></xref>. If applicable, the client also adds its authentication credentials
	r the request body using the same rules as for token endpoint requests.</t>		to the request header or the request body using the same rules as for token endp
			oint requests.</t>
	<t>This is illustrated by the following example (extra line breaks in the messag e body for display purposes only):</t>		<t>This is illustrated by the following example (extra line breaks in the messag e body for display purposes only):</t>
	<artwork> POST /as/par HTTP/1.1		<sourcecode type="http-message"> POST /as/par HTTP/1.1
	Host: as.example.com		Host: as.example.com
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	response_type=code&amp;state=af0ifjsldkj&amp;client_id=s6BhdRkqt3		response_type=code&amp;state=af0ifjsldkj&amp;client_id=s6BhdRkqt3
	&amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb		&amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
	&amp;code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U		&amp;code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U
	&amp;code_challenge_method=S256&amp;scope=account-information		&amp;code_challenge_method=S256&amp;scope=account-information
	&amp;client_assertion_type=		&amp;client_assertion_type=
	urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer		urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
	&amp;client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi		&amp;client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi
	OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc		OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc
	2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh		2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh
	TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se		TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se
	f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K		f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K
	dTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8W		dTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8W
	yeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJE		yeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJE
	RWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6		RWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6
	GQ		GQ
	</artwork>		</sourcecode>
	<t>The authorization server MUST process the request as follows:</t>		<t>The authorization server <bcp14>MUST</bcp14> process the request as follows:<
			/t>
	<ol>		<ol>
	<li>Authenticate the client in the same way as at the token endpoint (Section 2. 3 of <xref target="RFC6749"></xref>).</li>		<li>Authenticate the client in the same way as at the token endpoint (<xref targ et="RFC6749" sectionFormat="of" section="2.3"></xref>).</li>
	<li>Reject the request if the <tt>request_uri</tt> authorization request paramet er is provided.</li>		<li>Reject the request if the <tt>request_uri</tt> authorization request paramet er is provided.</li>
	<li>Validate the pushed request as it would an authorization request sent to the authorization endpoint. For example, the authorization server checks whether th e redirect URI matches one of the redirect URIs configured for the client and al so checks whether the client is authorized for the scope for which it is request ing access. This validation allows the authorization server to refuse unauthoriz ed or fraudulent requests early. The authorization server MAY omit validation st eps that it is unable to perform when processing the pushed request, however, su ch checks MUST then be performed when processing the authorization request at th e authorization endpoint.</li>		<li>Validate the pushed request as it would an authorization request sent to the authorization endpoint. For example, the authorization server checks whether th e redirect URI matches one of the redirect URIs configured for the client and al so checks whether the client is authorized for the scope for which it is request ing access. This validation allows the authorization server to refuse unauthoriz ed or fraudulent requests early. The authorization server <bcp14>MAY</bcp14> omi t validation steps that it is unable to perform when processing the pushed reque st; however, such checks <bcp14>MUST</bcp14> then be performed when processing t he authorization request at the authorization endpoint.</li>
	</ol>		</ol>
	<t>The authorization server MAY allow clients with authentication credentials to establish per-authorization-request redirect URIs with every pushed authorizati on request. Described in more detail in <xref target="redirect_uri_mgmt"></xref> , this is possible since, in contrast to <xref target="RFC6749"></xref>, this sp ecification gives the authorization server the ability to authenticate clients a nd validate client requests before the actual authorization request is performed .</t>		<t>The authorization server <bcp14>MAY</bcp14> allow clients with authentication credentials to establish per-authorization-request redirect URIs with every pus hed authorization request. Described in more detail in <xref target="redirect_ur i_mgmt"></xref>, this is possible since, in contrast to <xref target="RFC6749">< /xref>, this specification gives the authorization server the ability to authent icate clients and validate client requests before the actual authorization reque st is performed.</t>
	</section>		</section>
	<section anchor="par-response"><name>Successful Response</name>		<section anchor="par-response"><name>Successful Response</name>
	<t>If the verification is successful, the server MUST generate a request URI and		<t>If the verification is successful, the server <bcp14>MUST</bcp14> generate a
	provide it in the response with a <tt>201</tt> HTTP status code. The following		request URI and provide it in the response with a <tt>201</tt> HTTP status code.
	parameters are included as top-level members in the message body of the HTTP res		The following parameters are included as top-level members in the message body
	ponse using the <tt>application/json</tt> media type as defined by <xref target=		of the HTTP response using the <tt>application/json</tt> media type as defined b
	"RFC8259"></xref>.</t>		y <xref target="RFC8259"></xref>.
			</t>
	<ul>		<dl newline="true">
	<li><tt>request_uri</tt> : The request URI corresponding to the authorization re		<dt>request_uri</dt><dd>The request URI corresponding to the authorization reque
	quest posted. This URI is a single-use reference to the respective request data		st posted. This URI is a single-use reference to the respective request data in
	in the subsequent authorization request. The way the authorization process obtai		the subsequent authorization request. The way the authorization process obtains
	ns the authorization request data is at the discretion of the authorization serv		the authorization request data is at the discretion of the authorization server
	er and out of scope of this specification. There is no need to make the authoriz		and is out of scope of this specification. There is no need to make the authoriz
	ation request data available to other parties via this URI.</li>		ation request data available to other parties via this URI.</dd>
	<li><tt>expires_in</tt> : A JSON number that represents the lifetime of the requ		<dt>expires_in</dt><dd> A JSON number that represents the lifetime of the reques
	est URI in seconds as a positive integer. The request URI lifetime is at the dis		t URI in seconds as a positive integer. The request URI lifetime is at the discr
	cretion of the authorization server but will typically be relatively short (e.g.		etion of the authorization server but will typically be relatively short (e.g.,
	, between 5 and 600 seconds).</li>		between 5 and 600 seconds).</dd>
	</ul>		</dl>
	<t>The format of the <tt>request_uri</tt> value is at the discretion of the auth		<t>The format of the <tt>request_uri</tt> value is at the discretion of the auth
	orization server but it MUST contain some part generated using a cryptographical		orization server, but it <bcp14>MUST</bcp14> contain some part generated using a
	ly strong pseudorandom algorithm such that it is computationally infeasible to p		cryptographically strong pseudorandom algorithm such that it is computationally
	redict or guess a valid value (see Section 10.10 of <xref target="RFC6749"></xre		infeasible to predict or guess a valid value (see <xref target="RFC6749" sectio
	f> for specifics). The authorization server MAY construct the <tt>request_uri</t		nFormat="of" section="10.10"></xref> for specifics). The authorization server <b
	t> value using the form <tt>urn:ietf:params:oauth:request_uri:&lt;reference-valu		cp14>MAY</bcp14> construct the <tt>request_uri</tt> value using the form <tt>urn
	e&gt;</tt> with <tt>&lt;reference-value&gt;</tt> as the random part of the URI t		:ietf:params:oauth:request_uri:&lt;reference-value&gt;</tt> with <tt>&lt;referen
	hat references the respective authorization request data.</t>		ce-value&gt;</tt> as the random part of the URI that references the respective a
	<t>The <tt>request_uri</tt> value MUST be bound to the client that posted the au		uthorization request data.</t>
	thorization request.</t>		<t>The <tt>request_uri</tt> value <bcp14>MUST</bcp14> be bound to the client tha
			t posted the authorization request.</t>
	<t>The following is an example of such a response:</t>		<t>The following is an example of such a response:</t>
	<artwork> HTTP/1.1 201 Created		<sourcecode type="http-message"> HTTP/1.1 201 Created
	Content-Type: application/json		Content-Type: application/json
	Cache-Control: no-cache, no-store		Cache-Control: no-cache, no-store
	{		{
	&quot;request_uri&quot;:		&quot;request_uri&quot;:
	&quot;urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c&quot;,		&quot;urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c&quot;,
	&quot;expires_in&quot;: 60		&quot;expires_in&quot;: 60
	}		}
	</artwork>		</sourcecode>
	</section>		</section>
	<section anchor="error_response"><name>Error Response</name>		<section anchor="error_response"><name>Error Response</name>
	<t>The authorization server returns an error response with the same format as is		<t>The authorization server returns an error response with the same format as is
	specified for error responses from the token endpoint in Section 5.2 of <xref t		specified for error responses from the token endpoint in <xref target="RFC6749"
	arget="RFC6749"></xref> using the appropriate error code from therein or from Se		sectionFormat="of" section="5.2"></xref> using the appropriate error code from
	ction 4.1.2.1 of <xref target="RFC6749"></xref>. In those cases where Section 4		therein or from <xref target="RFC6749" sectionFormat="of" section="4.1.2.1"></xr
	.1.2.1 of <xref target="RFC6749"></xref> prohibits automatic redirection with an		ef>. In those cases where <xref target="RFC6749" sectionFormat="of" section="4.
	error back to the requesting client and hence doesn’t define an error code, for		1.2.1"></xref> prohibits automatic redirection with an error back to the request
	example when the request fails due to a missing, invalid, or mismatching redire		ing client and hence doesn't define an error code (for example, when the request
	ction URI, the <tt>invalid_request</tt> error code can be used as the default er		fails due to a missing, invalid, or mismatching redirection URI), the <tt>inval
	ror code. Error codes defined by OAuth extension can also be used when such an e		id_request</tt> error code can be used as the default error code. Error codes de
	xtension is involved in the initial processing of authorization request that was		fined by the OAuth extension can also be used when such an extension is involved
	pushed. Since initial processing of the pushed authorization request does not i		in the initial processing of the authorization request that was pushed. Since i
	nvolve resource owner interaction, error codes related to user interaction, such		nitial processing of the pushed authorization request does not involve resource
	as <tt>consent_required</tt> defined by <xref target="OIDC"></xref>, are never		owner interaction, error codes related to user interaction, such as <tt>consent_
	returned.</t>		required</tt> defined by <xref target="OIDC"></xref>, are never returned.</t>
	<t>If the client is required to use signed request objects, either by authorizat		<t>If the client is required to use signed Request Objects, by either the author
	ion server or client policy (see <xref target="I-D.ietf-oauth-jwsreq"></xref>, s		ization server or the client policy (see <xref target="RFC9101" sectionFormat="c
	ection 10.5), the authorization server MUST only accept requests complying with		omma" section="10.5"></xref>), the authorization server <bcp14>MUST</bcp14> only
	the definition given in <xref target="request_parameter"></xref> and MUST refuse		accept requests complying with the definition given in <xref target="request_pa
	any other request with HTTP status code 400 and error code <tt>invalid_request<		rameter"></xref> and <bcp14>MUST</bcp14> refuse any other request with HTTP stat
	/tt>.</t>		us code 400 and error code <tt>invalid_request</tt>.</t>
	<t>In addition to the above, the PAR endpoint can also make use of the following HTTP status codes:</t>		<t>In addition to the above, the PAR endpoint can also make use of the following HTTP status codes:</t>
	<ul>		<dl indent="6">
	<li><t>405: If the request did not use the <tt>POST</tt> method, the authorizati		<dt>405:</dt><dd> If the request did not use the <tt>POST</tt> method, the autho
	on server responds with an HTTP 405 (Method Not Allowed) status code.</t>		rization server responds with an HTTP 405 (Method Not Allowed) status code.</dd>
	</li>		<dt>413:</dt><dd> If the request size was beyond the upper bound that the author
	<li><t>413: If the request size was beyond the upper bound that the authorizatio		ization server allows, the authorization server responds with an HTTP 413 (Paylo
	n server allows, the authorization server responds with an HTTP 413 (Payload Too		ad Too Large) status code.</dd>
	Large) status code.</t>		<dt>429:</dt><dd> If the number of requests from a client during a particular ti
	</li>		me period exceeds the number the authorization server allows, the authorization
	<li><t>429: If the number of requests from a client during a particular time per		server responds with an HTTP 429 (Too Many Requests) status code.</dd>
	iod exceeds the number the authorization server allows, the authorization server		</dl>
	responds with an HTTP 429 (Too Many Requests) status code.</t>
	</li>
	</ul>
	<t>The following is an example of an error response from the PAR endpoint:</t>		<t>The following is an example of an error response from the PAR endpoint:</t>
	<artwork> HTTP/1.1 400 Bad Request		<sourcecode type="http-message"> HTTP/1.1 400 Bad Request
	Content-Type: application/json		Content-Type: application/json
	Cache-Control: no-cache, no-store		Cache-Control: no-cache, no-store
	{		{
	&quot;error&quot;: &quot;invalid_request&quot;,		&quot;error&quot;: &quot;invalid_request&quot;,
	&quot;error_description&quot;:		&quot;error_description&quot;:
	&quot;The redirect_uri is not valid for the given client&quot;		&quot;The redirect_uri is not valid for the given client&quot;
	}		}
	</artwork>		</sourcecode>
	</section>		</section>
	<section anchor="redirect_uri_mgmt"><name>Management of Client Redirect URIs</na me>		<section anchor="redirect_uri_mgmt"><name>Management of Client Redirect URIs</na me>
	<t>OAuth 2.0 <xref target="RFC6749"></xref> allows clients to use unregistered <		<t>OAuth 2.0 <xref target="RFC6749"></xref> allows clients to use unregistered <
	tt>redirect_uri</tt> values in certain circumstances or for the authorization se		tt>redirect_uri</tt> values in certain circumstances or for the authorization se
	rver to apply its own matching semantics to the <tt>redirect_uri</tt> value pres		rver to apply its own matching semantics to the <tt>redirect_uri</tt> value pres
	ented by the client at the authorization endpoint. However, the OAuth Security B		ented by the client at the authorization endpoint. However, the OAuth security B
	CP <xref target="I-D.ietf-oauth-security-topics"></xref> as well as OAuth 2.1 <x		CP <xref target="I-D.ietf-oauth-security-topics"></xref> as well as the OAuth 2.
	ref target="I-D.ietf-oauth-v2-1"></xref> require an authorization server exactly		1 specification <xref target="I-D.ietf-oauth-v2-1"></xref> require an authorizat
	match the <tt>redirect_uri</tt> parameter against the set of redirect URIs prev		ion server to exactly match the <tt>redirect_uri</tt> parameter against the set
	iously established for a particular client. This is a means for early detection		of redirect URIs previously established for a particular client. This is a means
	of client impersonation attempts and prevents token leakage and open redirection		for early detection of client impersonation attempts and prevents token leakage
	. As a downside, this can make client management more cumbersome since the redir		and open redirection. As a downside, this can make client management more cumbe
	ect URI is typically the most volatile part of a client policy.</t>		rsome since the redirect URI is typically the most volatile part of a client pol
	<t>The exact matching requirement MAY be relaxed when using PAR for clients that		icy.</t>
	have established authentication credentials with the authorization server. This		<t>The exact matching requirement <bcp14>MAY</bcp14> be relaxed when using PAR f
	is possible since, in contrast to a traditional authorization request, the auth		or clients that have established authentication credentials with the authorizati
	orization server authenticates the client before the authorization process start		on server. This is possible since, in contrast to a conventional authorization r
	s and thus ensures it is interacting with the legitimate client. The authorizati		equest, the authorization server authenticates the client before the authorizati
	on server MAY allow such clients to specify <tt>redirect_uri</tt> values that we		on process starts and thus ensures it is interacting with the legitimate client.
	re not previously registered with the authorization server. This will give the c		The authorization server <bcp14>MAY</bcp14> allow such clients to specify <tt>r
	lient more flexibility (e.g., to mint distinct redirect URI values per authoriza		edirect_uri</tt> values that were not previously registered with the authorizati
	tion server at runtime) and can simplify client management. It is at the discret		on server. This will give the client more flexibility (e.g., to mint distinct <t
	ion of the authorization server to apply restrictions on supplied <tt>redirect_u		t>redirect_uri</tt> values per authorization server at runtime) and can simplify
	ri</tt> values, e.g., the authorization server MAY require a certain URI prefix		client management. It is at the discretion of the authorization server to apply
	or allow only a query parameter to vary at runtime.</t>		restrictions on supplied <tt>redirect_uri</tt> values, e.g., the authorization
	<t>Note: The ability to set up transaction specific redirect URIs is also useful		server <bcp14>MAY</bcp14> require a certain URI prefix or allow only a query par
	in situations where client ids and corresponding credentials and policies are m		ameter to vary at runtime.</t>
	anaged by a trusted 3rd party, e.g. via client certificates containing client pe
	rmissions. Such an externally managed client could interact with an authorizatio		<aside><t>Note: The ability to set up transaction-specific redirect URIs is also
	n server trusting the respective 3rd party without the need for an additional re		useful in situations where client IDs and corresponding credentials and policie
	gistration step.</t>		s are managed by a trusted third party, e.g., via client certificates containing
			client permissions. Such an externally managed client could interact with an au
			thorization server trusting the respective third party without the need for an a
			dditional registration step.</t></aside>
	</section>		</section>
	</section>		</section>
	<section anchor="request_parameter"><name>The &quot;request&quot; Request Parame ter</name>		<section anchor="request_parameter"><name>The &quot;request&quot; Request Parame ter</name>
	<t>Clients MAY use the <tt>request</tt> parameter as defined in JAR <xref target		<t>Clients <bcp14>MAY</bcp14> use the <tt>request</tt> parameter as defined in J
	="I-D.ietf-oauth-jwsreq"></xref> to push a request object JWT to the authorizati		AR <xref target="RFC9101"></xref> to push a Request Object JWT to the authorizat
	on server. The rules for processing, signing, and encryption of the request obje		ion server. The rules for processing, signing, and encryption of the Request Obj
	ct as defined in JAR <xref target="I-D.ietf-oauth-jwsreq"></xref> apply. Request		ect as defined in JAR <xref target="RFC9101"></xref> apply. Request parameters r
	parameters required by a given client authentication method are included in the		equired by a given client authentication method are included in the <tt>applicat
	<tt>application/x-www-form-urlencoded</tt> request directly, and are the only p		ion/x-www-form-urlencoded</tt> request directly and are the only parameters othe
	arameters other than <tt>request</tt> in the form body (e.g. Mutual TLS client a		r than <tt>request</tt> in the form body (e.g., mutual TLS client authentication
	uthentication <xref target="RFC8705"></xref> uses the <tt>client_id</tt> HTTP re		<xref target="RFC8705"></xref> uses the <tt>client_id</tt> HTTP request paramet
	quest parameter while JWT assertion based client authentication <xref target="RF		er, while JWT assertion-based client authentication <xref target="RFC7523"></xre
	C7523"></xref> uses <tt>client_assertion</tt> and <tt>client_assertion_type</tt>		f> uses <tt>client_assertion</tt> and <tt>client_assertion_type</tt>). All other
	). All other request parameters, i.e., those pertaining to the authorization req		request parameters, i.e., those pertaining to the authorization request itself,
	uest itself, MUST appear as claims of the JWT representing the authorization req		<bcp14>MUST</bcp14> appear as claims of the JWT representing the authorization
	uest.</t>		request.</t>
	<t>The following is an example of a pushed authorization request using a signed		<t>The following is an example of a pushed authorization request using a signed
	request object with the same authorization request payload as the example in <xr		Request Object with the same authorization request payload as the example in <xr
	ef target="request"></xref>. The client is authenticated with JWT client asserti		ef target="request"></xref>. The client is authenticated with JWT client asserti
	on based authentication <xref target="RFC7523"></xref> (extra line breaks and wh		on-based authentication <xref target="RFC7523"></xref> (extra line breaks and sp
	itespace for display purposes only):</t>		aces for display purposes only):</t>
	<artwork> POST /as/par HTTP/1.1		<sourcecode type="http-message"> POST /as/par HTTP/1.1
	Host: as.example.com		Host: as.example.com
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	client_assertion_type=		client_assertion_type=
	urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer		urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
	&amp;client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi		&amp;client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi
	OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc		OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc
	2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh		2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh
	TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se		TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se
	f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K		f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K
	skipping to change at line 254 ¶		skipping to change at line 275 ¶
	b3JnL2NiIiwic2NvcGUiOiJhY2NvdW50LWluZm9ybWF0aW9uIiwic3RhdGUiOiJhZ		b3JnL2NiIiwic2NvcGUiOiJhY2NvdW50LWluZm9ybWF0aW9uIiwic3RhdGUiOiJhZ
	jBpZmpzbGRraiIsImNvZGVfY2hhbGxlbmdlIjoiSzItbHRjODNhY2M0aDBjOXc2RV		jBpZmpzbGRraiIsImNvZGVfY2hhbGxlbmdlIjoiSzItbHRjODNhY2M0aDBjOXc2RV
	NDX3JFTVRKM2J3dy11Q0hhb2VLMXQ4VSIsImNvZGVfY2hhbGxlbmdlX21ldGhvZCI		NDX3JFTVRKM2J3dy11Q0hhb2VLMXQ4VSIsImNvZGVfY2hhbGxlbmdlX21ldGhvZCI
	6IlMyNTYifQ.l9R3RC9bFBHry_8acObQjEf4fX5yfJkWUPfak3J3iiBm0aaQznPw5		6IlMyNTYifQ.l9R3RC9bFBHry_8acObQjEf4fX5yfJkWUPfak3J3iiBm0aaQznPw5
	BZ0B3VQZ9_KYdPt5bTkaflS5fSDklM3_7my9MyOSKFYmf46INk6ju_qUuC2crkOQX		BZ0B3VQZ9_KYdPt5bTkaflS5fSDklM3_7my9MyOSKFYmf46INk6ju_qUuC2crkOQX
	ZWYJB-0bnYEbdHpUjazFSUvN49cEGstNQeE-dKDWHNgEojgcuNA_pjKfL9VYp1dEA		ZWYJB-0bnYEbdHpUjazFSUvN49cEGstNQeE-dKDWHNgEojgcuNA_pjKfL9VYp1dEA
	6-WjXZ_OlJ7R_mBWpjFAzc0UkQwqX5hfOJoGTqB2tE4a4aB2z8iYlUJp0DeeYp_hP		6-WjXZ_OlJ7R_mBWpjFAzc0UkQwqX5hfOJoGTqB2tE4a4aB2z8iYlUJp0DeeYp_hP
	N6svtmdvte73p5bLGDFpRIlmrBQIAQuxiS0skORpXlS0cBcgHimXVnXOJG7E-A_lS		N6svtmdvte73p5bLGDFpRIlmrBQIAQuxiS0skORpXlS0cBcgHimXVnXOJG7E-A_lS
	_5y54dVLQPA1jKYx-fxbYSG7dp2fw		_5y54dVLQPA1jKYx-fxbYSG7dp2fw
	&amp;client_id=s6BhdRkqt3		&amp;client_id=s6BhdRkqt3
	</artwork>		</sourcecode>
	<t>The authorization server MUST take the following steps beyond the processing		<t>The authorization server <bcp14>MUST</bcp14> take the following steps beyond
	rules defined in <xref target="request"></xref>:</t>		the processing rules defined in <xref target="request"></xref>:</t>
	<ol>		<ol>
	<li>If applicable, decrypt the request object as specified in JAR <xref target="		<li>If applicable, decrypt the Request Object as specified in JAR <xref target="
	I-D.ietf-oauth-jwsreq"></xref>, section 6.1.</li>		RFC9101" sectionFormat="comma" section="6.1"></xref>.</li>
	<li>Validate the request object signature as specified in JAR <xref target="I-D.		<li>Validate the Request Object signature as specified in JAR <xref target="RFC9
	ietf-oauth-jwsreq"></xref>, section 6.2.</li>		101" sectionFormat="comma" section="6.2"></xref>.</li>
	<li>If the client has authentication credentials established with the authorizat		<li>If the client has authentication credentials established with the authorizat
	ion server, reject the request if the authenticated <tt>client_id</tt> does not		ion server, reject the request if the authenticated <tt>client_id</tt> does not
	match the <tt>client_id</tt> claim in the request object. Additionally requiring		match the <tt>client_id</tt> claim in the Request Object. Additionally, requirin
	the <tt>iss</tt> claim to match the <tt>client_id</tt> is at the discretion of		g the <tt>iss</tt> claim to match the <tt>client_id</tt> is at the discretion of
	authorization server.</li>		the authorization server.</li>
	</ol>		</ol>
	<t>The following RSA key pair, represented in JWK <xref target="RFC7517"></xref> format, can be used to validate or recreate the request object signature in the above example (extra line breaks and indentation within values for display purp oses only):</t>		<t>The following RSA key pair, represented in JSON Web Key (JWK) format <xref ta rget="RFC7517"></xref>, can be used to validate or recreate the Request Object s ignature in the above example (extra line breaks and indentation within values f or display purposes only):</t>
	<artwork> {		<sourcecode type="json"> {
	&quot;kty&quot;: &quot;RSA&quot;,		&quot;kty&quot;: &quot;RSA&quot;,
	&quot;kid&quot;:&quot;k2bdc&quot;,		&quot;kid&quot;:&quot;k2bdc&quot;,
	&quot;n&quot;: &quot;y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAt KlE		&quot;n&quot;: &quot;y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAt KlE
	5P7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5Oa		5P7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5Oa
	aXDFI6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVj		aXDFI6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVj
	dEFgZaZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghL		dEFgZaZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghL
	L0HzOuYRadBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUG		L0HzOuYRadBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUG
	sqkNA9b3xVW53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw&quot;,		sqkNA9b3xVW53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw&quot;,
	&quot;e&quot;: &quot;AQAB&quot;,		&quot;e&quot;: &quot;AQAB&quot;,
	&quot;d&quot;: &quot;LNwG_pCKrwowALpCpRdcOKlSVqylSurZhE6CpkRiE9cpDgGKIkO9CxPl XOL		&quot;d&quot;: &quot;LNwG_pCKrwowALpCpRdcOKlSVqylSurZhE6CpkRiE9cpDgGKIkO9CxPl XOL
	skipping to change at line 297 ¶		skipping to change at line 318 ¶
	&quot;p&quot;: &quot;5sd9Er3I2FFT9R-gy84_oakEyCmgw036B_nfYEEOCwpSvi2z7UcIVK3b SEL		&quot;p&quot;: &quot;5sd9Er3I2FFT9R-gy84_oakEyCmgw036B_nfYEEOCwpSvi2z7UcIVK3b SEL
	5WCW6BNgB3HDWhq8aYPirwQnqm0K9mX1E-4xM10WWZ-rP3XjYpQeS0Snru5		5WCW6BNgB3HDWhq8aYPirwQnqm0K9mX1E-4xM10WWZ-rP3XjYpQeS0Snru5
	LFVWsAzi-FX7BOqBibSAXLdEGXcXa44l08iec_bPD3xduq5V_1YoE&quot;,		LFVWsAzi-FX7BOqBibSAXLdEGXcXa44l08iec_bPD3xduq5V_1YoE&quot;,
	&quot;dq&quot;: &quot;Nz2PF3XM6bEc4XsluKZO70ErdYdKgdtIJReUR7Rno_tOZpejwlPGBYV W19		&quot;dq&quot;: &quot;Nz2PF3XM6bEc4XsluKZO70ErdYdKgdtIJReUR7Rno_tOZpejwlPGBYV W19
	zpAeYtCT82jxroB2XqhLxGeMxEPQpsz2qTKLSe4BgHY2ml2uxSDGdjcsrbb		zpAeYtCT82jxroB2XqhLxGeMxEPQpsz2qTKLSe4BgHY2ml2uxSDGdjcsrbb
	NoKUKaN1CuyZszhWl1n0AT_bENl4bJgQj_Fh0UEsQj5YBBUJt5gr_k&quot;,		NoKUKaN1CuyZszhWl1n0AT_bENl4bJgQj_Fh0UEsQj5YBBUJt5gr_k&quot;,
	&quot;dp&quot;: &quot;Zc877jirkkLOtyTs2vxyNe9KnMNAmOidlUc2tE_-0gAL4Lpo1hSwKCt Kwe		&quot;dp&quot;: &quot;Zc877jirkkLOtyTs2vxyNe9KnMNAmOidlUc2tE_-0gAL4Lpo1hSwKCt Kwe
	ZJ-gkqt1hT-dwNx_0Xtg_-NXsadMRMwJnzBMYwYAfjApUkfqABc0yUCJJl3		ZJ-gkqt1hT-dwNx_0Xtg_-NXsadMRMwJnzBMYwYAfjApUkfqABc0yUCJJl3
	KozRCugf1WXkU9GZAH2_x8PUopdNUEa70ISowPRh04HANKX4fkjWAE&quot;		KozRCugf1WXkU9GZAH2_x8PUopdNUEa70ISowPRh04HANKX4fkjWAE&quot;
	}		}
	</artwork>		</sourcecode>
	</section>		</section>
	<section anchor="authorization-request"><name>Authorization Request</name>		<section anchor="authorization-request"><name>Authorization Request</name>
	<t>The client uses the <tt>request_uri</tt> value returned by the authorization server to build an authorization request as defined in <xref target="I-D.ietf-oa uth-jwsreq"></xref>. This is shown in the following example where the client dir ects the user agent to make the following HTTP request (extra line breaks and in dentation for display purposes only):</t>		<t>The client uses the <tt>request_uri</tt> value returned by the authorization server to build an authorization request as defined in <xref target="RFC9101"></ xref>. This is shown in the following example where the client directs the user agent to make the following HTTP request (extra line breaks and indentation for display purposes only):</t>
	<artwork> GET /authorize?client_id=s6BhdRkqt3&amp;request_uri=urn%3Aietf%3Aparam s		<sourcecode type="http-message"> GET /authorize?client_id=s6BhdRkqt3&amp;request _uri=urn%3Aietf%3Aparams
	%3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc014ltc14eY22c HTTP/1.1		%3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc014ltc14eY22c HTTP/1.1
	Host: as.example.com		Host: as.example.com
	</artwork>		</sourcecode>
	<t>Since parts of the authorization request content, e.g. the <tt>code_challenge		<t>Since parts of the authorization request content, e.g., the <tt>code_challeng
	</tt> parameter value, are unique to a particular authorization request, the cli		e</tt> parameter value, are unique to a particular authorization request, the cl
	ent MUST only use a <tt>request_uri</tt> value once. Authorization servers SHOU		ient <bcp14>MUST</bcp14> only use a <tt>request_uri</tt> value once. Authorizat
	LD treat <tt>request_uri</tt> values as one-time use but MAY allow for duplicate		ion servers <bcp14>SHOULD</bcp14> treat <tt>request_uri</tt> values as one-time
	requests due to a user reloading/refreshing their user agent. An expired <tt>re		use but <bcp14>MAY</bcp14> allow for duplicate requests due to a user reloading/
	quest_uri</tt> MUST be rejected as invalid.</t>		refreshing their user agent. An expired <tt>request_uri</tt> <bcp14>MUST</bcp14>
	<t>The authorization server MUST validate authorization requests arising from a		be rejected as invalid.</t>
	pushed request as it would any other authorization request. The authorization se		<t>The authorization server <bcp14>MUST</bcp14> validate authorization requests
	rver MAY omit validation steps that it performed when the request was pushed, pr		arising from a pushed request as it would any other authorization request. The a
	ovided that it can validate that the request was a pushed request, and that the		uthorization server <bcp14>MAY</bcp14> omit validation steps that it performed w
	request or the authorization server’s policy has not been modified in a way that		hen the request was pushed, provided that it can validate that the request was a
	would affect the outcome of the omitted steps.</t>		pushed request and that the request or the authorization server's policy has no
	<t>Authorization server policy MAY dictate, either globally or on a per-client b		t been modified in a way that would affect the outcome of the omitted steps.</t>
	asis, that PAR is the only means for a client to pass authorization request data		<t>Authorization server policy <bcp14>MAY</bcp14> dictate, either globally or on
	. In this case, the authorization server will refuse, using the <tt>invalid_requ		a per-client basis, that PAR be the only means for a client to pass authorizati
	est</tt> error code, to process any request to the authorization endpoint that d		on request data. In this case, the authorization server will refuse, using the <
	oes not have a <tt>request_uri</tt> parameter with a value obtained from the PAR		tt>invalid_request</tt> error code, to process any request to the authorization
	endpoint.</t>		endpoint that does not have a <tt>request_uri</tt> parameter with a value obtain
	<t>Note: authorization server and clients MAY use metadata as defined in <xref t		ed from the PAR endpoint.</t>
	arget="as_metadata"></xref> and <xref target="c_metadata"></xref> to signal the		<aside><t>Note: Authorization server and clients <bcp14>MAY</bcp14> use metadata
	desired behavior.</t>		as defined in Sections <xref target="as_metadata" format="counter"></xref> and
			<xref target="c_metadata" format="counter"></xref> to signal the desired behavio
			r.</t></aside>
	</section>		</section>
	<section anchor="as_metadata"><name>Authorization Server Metadata</name>		<section anchor="as_metadata"><name>Authorization Server Metadata</name>
	<t>The following authorization server metadata <xref target="RFC8414"></xref> pa rameters are introduced to signal the server's capability and policy with respec t to PAR.</t>		<t>The following authorization server metadata parameters <xref target="RFC8414" ></xref> are introduced to signal the server's capability and policy with respec t to PAR.</t>
	<dl>		<dl newline="true">
	<dt><tt>pushed_authorization_request_endpoint</tt></dt>		<dt>pushed_authorization_request_endpoint</dt>
	<dd>The URL of the pushed authorization request endpoint at which a client can p ost an authorization request to exchange for a <tt>request_uri</tt> value usable at the authorization server.</dd>		<dd>The URL of the pushed authorization request endpoint at which a client can p ost an authorization request to exchange for a <tt>request_uri</tt> value usable at the authorization server.</dd>
	<dt><tt>require_pushed_authorization_requests</tt></dt>		<dt>require_pushed_authorization_requests</dt>
	<dd>Boolean parameter indicating whether the authorization server accepts author ization request data only via PAR. If omitted, the default value is <tt>false</t t>.</dd>		<dd>Boolean parameter indicating whether the authorization server accepts author ization request data only via PAR. If omitted, the default value is <tt>false</t t>.</dd>
	</dl>		</dl>
	<t>Note that the presence of <tt>pushed_authorization_request_endpoint</tt> is s ufficient for a client to determine that it may use the PAR flow. A <tt>request_ uri</tt> value obtained from the PAR endpoint is usable at the authorization end point regardless of other authorization server metadata such as <tt>request_uri_ parameter_supported</tt> or <tt>require_request_uri_registration</tt> <xref targ et="OIDC.Disco"></xref>.</t>		<t>Note that the presence of <tt>pushed_authorization_request_endpoint</tt> is s ufficient for a client to determine that it may use the PAR flow. A <tt>request_ uri</tt> value obtained from the PAR endpoint is usable at the authorization end point regardless of other authorization server metadata such as <tt>request_uri_ parameter_supported</tt> or <tt>require_request_uri_registration</tt> <xref targ et="OIDC.Disco"></xref>.</t>
	</section>		</section>
	<section anchor="c_metadata"><name>Client Metadata</name>		<section anchor="c_metadata"><name>Client Metadata</name>
	<t>The Dynamic Client Registration Protocol <xref target="RFC7591"></xref> defin es an API for dynamically registering OAuth 2.0 client metadata with authorizati on servers. The metadata defined by [RFC7591], and registered extensions to it, also imply a general data model for clients that is useful for authorization ser ver implementations even when the Dynamic Client Registration Protocol isn't in play. Such implementations will typically have some sort of user interface avail able for managing client configuration. The following client metadata parameter is introduced by this document to indicate whether pushed authorization requests are required for the given client.</t>		<t>The Dynamic Client Registration Protocol <xref target="RFC7591"></xref> defin es an API for dynamically registering OAuth 2.0 client metadata with authorizati on servers. The metadata defined by <xref target="RFC7591"/>, and registered ext ensions to it, also imply a general data model for clients that is useful for au thorization server implementations even when the Dynamic Client Registration Pro tocol isn't in play. Such implementations will typically have some sort of user interface available for managing client configuration. The following client meta data parameter is introduced by this document to indicate whether pushed authori zation requests are required for the given client.</t>
	<dl>		<dl newline="true">
	<dt><tt>require_pushed_authorization_requests</tt></dt>		<dt>require_pushed_authorization_requests</dt>
	<dd>Boolean parameter indicating whether the only means of initiating an authori zation request the client is allowed to use is PAR. If omitted, the default valu e is <tt>false</tt>.</dd>		<dd>Boolean parameter indicating whether the only means of initiating an authori zation request the client is allowed to use is PAR. If omitted, the default valu e is <tt>false</tt>.</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="security-considerations"><name>Security Considerations</name>		<section anchor="security-considerations"><name>Security Considerations</name>
	<section anchor="request-uri-guessing"><name>Request URI Guessing</name>		<section anchor="request-uri-guessing"><name>Request URI Guessing</name>
	<t>An attacker could attempt to guess and replay a valid request URI value and		<t>An attacker could attempt to guess and replay a valid request URI value and
	try to impersonate the respective client. The authorization server MUST consider		try to impersonate the respective client.
	the considerations
	given in JAR <xref target="I-D.ietf-oauth-jwsreq"></xref>, section 10.2, clause		The authorization server <bcp14>MUST</bcp14> account for the considerations
	(d) on request URI entropy.</t>		given in JAR <xref target="RFC9101" sectionFormat="comma" section="10.2"></xref>
			, clause (d) on request URI entropy.</t>
	</section>		</section>
	<section anchor="open-redirection"><name>Open Redirection</name>		<section anchor="open-redirection"><name>Open Redirection</name>
	<t>An attacker could try to register a redirect URI pointing to a site under his control in order to obtain authorization codes or launch other attacks towards the user. The authorization server MUST only accept new redirect URIs in the pus hed authorization request from authenticated clients.</t>		<t>An attacker could try to register a redirect URI pointing to a site under the ir control in order to obtain authorization codes or launch other attacks toward s the user. The authorization server <bcp14>MUST</bcp14> only accept new redirec t URIs in the pushed authorization request from authenticated clients.</t>
	</section>		</section>
	<section anchor="request-object-replay"><name>Request Object Replay</name>		<section anchor="request-object-replay"><name>Request Object Replay</name>
	<t>An attacker could replay a request URI captured from a legitimate authorizati on request. In order to cope with such attacks, the authorization server SHOULD make the request URIs one-time use.</t>		<t>An attacker could replay a request URI captured from a legitimate authorizati on request. In order to cope with such attacks, the authorization server <bcp14> SHOULD</bcp14> make the request URIs one-time use.</t>
	</section>		</section>
	<section anchor="client-policy-change"><name>Client Policy Change</name>		<section anchor="client-policy-change"><name>Client Policy Change</name>
	<t>The client policy might change between the lodging of the request object and		<t>The client policy might change between the lodging of the Request Object and
	the		the
	authorization request using a particular request object. It is therefore recomme		authorization request using a particular Request Object. Therefore, it is recomm
	nded that the authorization server check the request parameter against the clien		ended that the authorization server check the request parameter against the clie
	t policy when processing the authorization request.</t>		nt policy when processing the authorization request.</t>
	</section>		</section>
	<section anchor="request-uri-swapping"><name>Request URI Swapping</name>		<section anchor="request-uri-swapping"><name>Request URI Swapping</name>
	<t>An attacker could capture the request URI from one request and then substitut e it into a different authorization request. For example, in the context of Open ID Connect, an attacker could replace a request URI asking for a high level of a uthentication assurance with one that requires a lower level of assurance. Clien ts SHOULD make use of PKCE <xref target="RFC7636"></xref>, a unique <tt>state</t t> parameter <xref target="RFC6749"></xref>, or the OIDC “nonce” parameter <xref target="OIDC"></xref> in the pushed request object to prevent this attack.</t>		<t>An attacker could capture the request URI from one request and then substitut e it into a different authorization request. For example, in the context of Open ID Connect, an attacker could replace a request URI asking for a high level of a uthentication assurance with one that requires a lower level of assurance. Clien ts <bcp14>SHOULD</bcp14> make use of PKCE <xref target="RFC7636"></xref>, a uniq ue <tt>state</tt> parameter <xref target="RFC6749"></xref>, or the OIDC "nonce" parameter <xref target="OIDC"></xref> in the pushed Request Object to prevent th is attack.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="privacy-considerations"><name>Privacy Considerations</name>		<section anchor="privacy-considerations"><name>Privacy Considerations</name>
	<t>OAuth 2.0 is a complex and flexible framework with broad-ranging privacy impl		<t>OAuth 2.0 is a complex and flexible framework with broad-ranging privacy impl
	ications due to the very nature of it having one entity intermediate user author		ications due to its very nature of having one entity intermediate user authoriza
	ization to data access between two other entities. The privacy considerations of		tion to data access between two other entities. The privacy considerations of al
	all of OAuth are beyond the scope of this document, which only defines an alter		l of OAuth are beyond the scope of this document, which only defines an alternat
	native way of initiating one message sequence in the larger framework. Using PAR		ive way of initiating one message sequence in the larger framework. However, usi
	, however, may improve privacy by reducing the potential for inadvertent informa		ng PAR may improve privacy by reducing the potential for inadvertent information
	tion disclosure since it passes the authorization request data directly between		disclosure since it passes the authorization request data directly between the
	client and authorization server over a secure connection in the message body of		client and authorization server over a secure connection in the message body of
	an HTTP request, rather than in the query component of a URL that passes through		an HTTP request rather than in the query component of a URL that passes through
	the user agent in the clear.</t>		the user agent in the clear.</t>
	</section>
	<section anchor="Acknowledgements"><name>Acknowledgements</name>
	<t>This specification is based on the work towards <eref target="https://bitbuck
	et.org/openid/fapi/src/master/Financial_API_Pushed_Request_Object.md">Pushed Req
	uest Object</eref>
	conducted at the Financial-grade API working group at the OpenID Foundation. We
	would like to thank the members of the WG for their valuable contributions.</t>
	<t>We would like to thank
	Vladimir Dzhuvinov,
	Aaron Parecki,
	Justin Richer,
	Sascha Preibisch,
	Daniel Fett,
	Michael B. Jones,
	Annabelle Backman,
	Joseph Heenan,
	Sean Glencross,
	Maggie Hung,
	Neil Madden,
	Karsten Meyer zu Selhausen,
	Roman Danyliw,
	Meral Shirazipour,
	and
	Takahiko Kawasaki
	for their valuable feedback on this draft.</t>
	</section>		</section>
	<section anchor="iana_considerations"><name>IANA Considerations</name>		<section anchor="iana_considerations"><name>IANA Considerations</name>
	<section anchor="oauth-authorization-server-metadata"><name>OAuth Authorization Server Metadata</name>		<section anchor="oauth-authorization-server-metadata"><name>OAuth Authorization Server Metadata</name>
	<t>This specification requests registration of the following values in the IANA &quot;OAuth Authorization Server Metadata&quot; registry of <xref target="IANA.O Auth.Parameters"></xref> established by <xref target="RFC8414"></xref>.</t>		<t>IANA has registered the following values in the IANA &quot;OAuth Authorizatio n Server Metadata&quot; registry of <xref target="IANA.OAuth.Parameters"></xref> established by <xref target="RFC8414"></xref>.</t>
	<dl spacing="compact">		<dl spacing="compact">
	<dt>Metadata Name:</dt>		<dt>Metadata Name:</dt>
	<dd><tt>pushed_authorization_request_endpoint</tt></dd>		<dd><tt>pushed_authorization_request_endpoint</tt></dd>
	<dt>Metadata Description:</dt>		<dt>Metadata Description:</dt>
	<dd>URL of the authorization server's pushed authorization request endpoint</dd>		<dd>URL of the authorization server's pushed authorization request endpoint.</dd >
	<dt>Change Controller:</dt>		<dt>Change Controller:</dt>
	<dd>IESG</dd>		<dd>IESG</dd>
	<dt>Specification Document(s):</dt>		<dt>Specification Document(s):</dt>
	<dd><xref target="as_metadata"></xref> of [[ this document ]]</dd>		<dd><xref target="as_metadata"></xref> of RFC 9126</dd>
	<dt></dt>		</dl>
	<dd></dd>
			<dl spacing="compact">
	<dt>Metadata Name:</dt>		<dt>Metadata Name:</dt>
	<dd><tt>require_pushed_authorization_requests</tt></dd>		<dd><tt>require_pushed_authorization_requests</tt></dd>
	<dt>Metadata Description:</dt>		<dt>Metadata Description:</dt>
	<dd>Indicates whether the authorization server accepts authorization requests on ly via PAR.</dd>		<dd>Indicates whether the authorization server accepts authorization requests on ly via PAR.</dd>
	<dt>Change Controller:</dt>		<dt>Change Controller:</dt>
	<dd>IESG</dd>		<dd>IESG</dd>
	<dt>Specification Document(s):</dt>		<dt>Specification Document(s):</dt>
	<dd><xref target="as_metadata"></xref> of [[ this document ]]</dd>		<dd><xref target="as_metadata"></xref> of RFC 9126</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="oauth-dynamic-client-registration-metadata"><name>OAuth Dynamic Client Registration Metadata</name>		<section anchor="oauth-dynamic-client-registration-metadata"><name>OAuth Dynamic Client Registration Metadata</name>
	<t>This specification requests registration of the following value in the IANA & quot;OAuth Dynamic Client Registration Metadata&quot; registry of <xref target=" IANA.OAuth.Parameters"></xref> established by <xref target="RFC7591"></xref>.</t >		<t>IANA has registered the following value in the IANA &quot;OAuth Dynamic Clien t Registration Metadata&quot; registry of <xref target="IANA.OAuth.Parameters">< /xref> established by <xref target="RFC7591"></xref>.</t>
	<dl spacing="compact">		<dl spacing="compact">
	<dt>Client Metadata Name:</dt>		<dt>Client Metadata Name:</dt>
	<dd><tt>require_pushed_authorization_requests</tt></dd>		<dd><tt>require_pushed_authorization_requests</tt></dd>
	<dt>Client Metadata Description:</dt>		<dt>Client Metadata Description:</dt>
	<dd>Indicates whether the client is required to use the PAR to initiate authoriz ation requests.</dd>		<dd>Indicates whether the client is required to use PAR to initiate authorizatio n requests.</dd>
	<dt>Change Controller:</dt>		<dt>Change Controller:</dt>
	<dd>IESG</dd>		<dd>IESG</dd>
	<dt>Specification Document(s):</dt>		<dt>Specification Document(s):</dt>
	<dd><xref target="c_metadata"></xref> of [[ this document ]]</dd>		<dd><xref target="c_metadata"></xref> of RFC 9126</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="oauth-uri-registration"><name>OAuth URI Registration</name>		<section anchor="oauth-uri-registration"><name>OAuth URI Registration</name>
	<t>This specification requests registration of the following value in the &quot; OAuth URI&quot; registry of <xref target="IANA.OAuth.Parameters"></xref> establi shed by <xref target="RFC6755"></xref>.</t>		<t>IANA has registered the following value in the &quot;OAuth URI&quot; registry of <xref target="IANA.OAuth.Parameters"></xref> established by <xref target="RF C6755"></xref>.</t>
	<dl spacing="compact">		<dl spacing="compact">
	<dt>URN:</dt>		<dt>URN:</dt>
	<dd><tt>urn:ietf:params:oauth:request_uri:</tt></dd>		<dd><tt>urn:ietf:params:oauth:request_uri:</tt></dd>
	<dt>Common Name:</dt>		<dt>Common Name:</dt>
	<dd>A URN Sub-Namespace for OAuth Request URIs.</dd>		<dd>A URN Sub-Namespace for OAuth Request URIs.</dd>
	<dt>Change Controller:</dt>		<dt>Change Controller:</dt>
	<dd>IESG</dd>		<dd>IESG</dd>
	<dt>Specification Document(s):</dt>		<dt>Specification Document(s):</dt>
	<dd><xref target="par-response"></xref> of [[ this document ]]</dd>		<dd><xref target="par-response"></xref> of RFC 9126</dd>
	</dl>		</dl>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="I-D.ietf-oauth-security-topics" to="OAUTH-SECURITY-TOP
			ICS"/>
			<displayreference target="I-D.ietf-oauth-v2-1" to="OAUTH-V2"/>
			<references>
			<name>References</name>
	<references><name>Normative References</name>		<references><name>Normative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i etf-oauth-jwsreq.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8414. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8414. xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9101.
			xml"/>
	</references>		</references>
	<references><name>Informative References</name>		<references><name>Informative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i etf-oauth-security-topics.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i etf-oauth-security-topics.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i etf-oauth-v2-1.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i etf-oauth-v2-1.xml"/>
	<reference anchor="IANA.OAuth.Parameters" target="http://www.iana.org/assignment s/oauth-parameters">		<reference anchor="IANA.OAuth.Parameters" target="http://www.iana.org/assignment s/oauth-parameters">
	<front>		<front>
	<title>OAuth Parameters</title>		<title>OAuth Parameters</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	<date></date>		<date></date>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="OIDC" target="http://openid.net/specs/openid-connect-core-1_0 .html">		<reference anchor="OIDC" target="http://openid.net/specs/openid-connect-core-1_0 .html">
	<front>		<front>
	<title>OpenID Connect Core 1.0 incorporating errata set 1</title>		<title>OpenID Connect Core 1.0 incorporating errata set 1</title>
	<author fullname="Nat Sakimura" initials="N." surname="Sakimura">		<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	<organization>NRI</organization>		<organization>NRI</organization>
	</author>		</author>
	<author fullname="John Bradley" initials="J." surname="Bradley">		<author fullname="John Bradley" initials="J." surname="Bradley">
	<organization>Ping Identity</organization>		<organization>Ping Identity</organization>
	</author>		</author>
	<author fullname="Mike Jones" initials="M." surname="Jones">		<author fullname="Mike Jones" initials="M." surname="Jones">
	skipping to change at line 486 ¶		skipping to change at line 500 ¶
	</author>		</author>
	<author fullname="Mike Jones" initials="M." surname="Jones">		<author fullname="Mike Jones" initials="M." surname="Jones">
	<organization>Microsoft</organization>		<organization>Microsoft</organization>
	</author>		</author>
	<author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">		<author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
	<organization>Google</organization>		<organization>Google</organization>
	</author>		</author>
	<author fullname="Chuck Mortimore" initials="C." surname="Mortimore">		<author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
	<organization>Salesforce</organization>		<organization>Salesforce</organization>
	</author>		</author>
	<date year="2014" month="Nov" day="8"></date>		<date year="2014" month="November"></date>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="OIDC.Disco" target="http://openid.net/specs/openid-connect-di scovery-1_0.html">		<reference anchor="OIDC.Disco" target="http://openid.net/specs/openid-connect-di scovery-1_0.html">
	<front>		<front>
	<title>OpenID Connect Discovery 1.0</title>		<title>OpenID Connect Discovery 1.0 incorporating errata set 1</title>
	<author fullname="Nat Sakimura" initials="N." surname="Sakimura">		<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	<organization abbrev="NRI">Nomura Research Institute, Ltd.</organization>		<organization abbrev="NRI">Nomura Research Institute, Ltd.</organization>
	</author>		</author>
	<author fullname="John Bradley" initials="J." surname="Bradley">		<author fullname="John Bradley" initials="J." surname="Bradley">
	<organization abbrev="Ping Identity">Ping Identity</organization>		<organization abbrev="Ping Identity">Ping Identity</organization>
	</author>		</author>
	<author fullname="Michael B. Jones" initials="M.B." surname="Jones">		<author fullname="Michael B. Jones" initials="M." surname="Jones">
	<organization abbrev="Microsoft">Microsoft</organization>		<organization abbrev="Microsoft">Microsoft</organization>
	</author>		</author>
	<author fullname="Edmund Jay" initials="E." surname="Jay">		<author fullname="Edmund Jay" initials="E." surname="Jay">
	<organization abbrev="Illumila">Illumila</organization>		<organization abbrev="Illumila">Illumila</organization>
	</author>		</author>
	<date year="2014" month="November" day="8"></date>		<date year="2014" month="November"></date>
	</front>		</front>
	</reference>		</reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6755. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6755. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7517. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7517. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7523. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7523. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7591. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7591. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7636. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7636. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8252. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8252. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8705. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8705. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8707. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8707. xml"/>
	</references>		</references>
			</references>
	<section anchor="document-history"><name>Document History</name>		<section anchor="Acknowledgements" numbered="false"><name>Acknowledgements</name
	<t>[[ To be removed from the final specification ]]</t>		>
	<t>-10</t>		<t>This specification is based on the work on <eref target="https://bitbucket.or
			g/openid/fapi/src/master/Financial_API_Pushed_Request_Object.md">Pushed Request
	<ul>		Object</eref>
	<li>Updates from mistakenly overlooked IESG evaluation comments</li>		conducted at the Financial-grade API Working Group at the OpenID Foundation. We
	</ul>		would like to thank the members of the WG for their valuable contributions.</t>
	<t>-09</t>		<t>We would like to thank
			<contact fullname="Vladimir Dzhuvinov"/>,
	<ul>		<contact fullname="Aaron Parecki"/>,
	<li>Editorial fixes from Genart last call review</li>		<contact fullname="Justin Richer"/>,
	<li>Updates from IESG evaluation comments</li>		<contact fullname="Sascha Preibisch"/>,
	</ul>		<contact fullname="Daniel Fett"/>,
	<t>-08</t>		<contact fullname="Michael B. Jones"/>,
			<contact fullname="Annabelle Backman"/>,
	<ul>		<contact fullname="Joseph Heenan"/>,
	<li>Updates to address feedback from AD Review <eref target="https://mailarchive		<contact fullname="Sean Glencross"/>,
	.ietf.org/arch/msg/oauth/bGSyonUqsvJ1vtY7l_ohwov25SA/">https://mailarchive.ietf.		<contact fullname="Maggie Hung"/>,
	org/arch/msg/oauth/bGSyonUqsvJ1vtY7l_ohwov25SA/</eref></li>		<contact fullname="Neil Madden"/>,
	</ul>		<contact fullname="Karsten Meyer zu Selhausen"/>,
	<t>-07</t>		<contact fullname="Roman Danyliw"/>,
			<contact fullname="Meral Shirazipour"/>,
	<ul>		and
	<li>updated references (however they did not actually update due to tooling issu		<contact fullname="Takahiko Kawasaki"/>
	es - some info in this thread: <eref target="https://mailarchive.ietf.org/arch/m		for their valuable feedback on this document.</t>
	sg/xml2rfc/zqYiMxZ070SCIi7CRNF9vbDeYno/">https://mailarchive.ietf.org/arch/msg/x
	ml2rfc/zqYiMxZ070SCIi7CRNF9vbDeYno/</eref> )</li>
	</ul>
	<t>-06</t>
	<ul>
	<li>Add a note clarifying that the presence of <tt>pushed_authorization_request_
	endpoint</tt> is sufficient for a client to know that it can use the PAR flow</l
	i>
	</ul>
	<t>-05</t>
	<ul>
	<li>Mention use of <tt>invalid_request</tt> error code for cases, like a bad <tt
	>redirect_uri</tt>, that don't have a more specific one</li>
	</ul>
	<t>-04</t>
	<ul>
	<li>Edits to address WGLC comments</li>
	<li>Replace I-D.ietf-oauth-mtls reference with now published RFC8705</li>
	<li>Moved text about redirect URI management from introduction into separate sec
	tion</li>
	</ul>
	<t>-03</t>
	<ul>
	<li>Editorial updates</li>
	<li>Mention that https is required for the PAR endpoint</li>
	<li>Add some discussion of browser form posting an authz request vs. the benefit
	s of PAR for any application</li>
	<li>Added text about motivations behind PAR - integrity, confidentiality and ear
	ly client auth</li>
	<li>Better explain one-time use recommendation of the request_uri</li>
	<li>Drop the section on special error responses for request objects</li>
	<li>Clarify authorization request examples to say that the client directs the us
	er agent to make the HTTP GET request (vs. making the request itself)</li>
	</ul>
	<t>-02</t>
	<ul>
	<li>Update Resource Indicators reference to the somewhat recently published RFC
	8707</li>
	<li>Added metadata in support of pushed authorization requests only feature</li>
	<li>Update to comply with draft-ietf-oauth-jwsreq-21, which requires <tt>client_
	id</tt> in the authorization request in addition to the <tt>request_uri</tt></li
	>
	<li>Clarified timing of request validation</li>
	<li>Add some guidance/options on the request URI structure</li>
	<li>Add the key used in the request object example so that a reader could valida
	te or recreate the request object signature</li>
	<li>Update to draft-ietf-oauth-jwsreq-25 and added note regarding <tt>require_si
	gned_request_object</tt></li>
	</ul>
	<t>-01</t>
	<ul spacing="compact">
	<li>Use the newish RFC v3 XML and HTML format</li>
	<li>Added IANA registration request for <tt>pushed_authorization_request_endpoin
	t</tt></li>
	<li>Changed abbrev to &quot;OAuth PAR&quot;</li>
	</ul>
	<t>-00 (WG draft)</t>
	<ul spacing="compact">
	<li>Reference RFC6749 sec 2.3.1 for client secret basic rather than RFC7617</li>
	<li>further clarify that a request object JWT contains all the authorization req
	uest parameters while client authentication params, if applicable, are outside t
	hat JWT as regular form encoded params in HTTP body</li>
	</ul>
	<t>-01</t>
	<ul spacing="compact">
	<li>List <tt>client_id</tt> as one of the basic parameters</li>
	<li>Explicitly forbid <tt>request_uri</tt> in the processing rules</li>
	<li>Clarification regarding client authentication and that public clients are al
	lowed</li>
	<li>Added option to let clients register per-authorization request redirect URIs
	</li>
	<li>General clean up and wording improvements</li>
	</ul>
	<t>-00</t>
	<ul>
	<li>first draft</li>
	</ul>
	</section>		</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 85 change blocks.
	459 lines changed or deleted		390 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/