Diff: rfc9728xml2.original.xml

	rfc9728xml2.original.xml	rfc9728.xml

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


	<rfc xmlns:xi="http://www.w3.org/2001/XInclude"	<!DOCTYPE rfc [
	category="std" docName="draft-ietf-oauth-resource-metadata-13" ipr="trust	<!ENTITY nbsp " ">
	200902">	<!ENTITY zwsp "">
		<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
		]>


	<?rfc toc="yes" ?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	<?rfc tocdepth="5" ?>	tf-oauth-resource-metadata-13" number="9728" submissionType="IETF" updates="" ob
	<?rfc symrefs="yes" ?>	soletes="" consensus="true" ipr="trust200902" tocInclude="true" tocDepth="5" sym
	<?rfc sortrefs="yes"?>	Refs="true" sortRefs="true" version="3" xml:lang="en">
	<?rfc strict="yes" ?>
	<?rfc compact='yes' ?>
	<?rfc subcompact='no' ?>

	<front>	<front>
	<title abbrev="OAuth 2.0 Protected Resource Metadata">OAuth 2.0 Protected Re source Metadata</title>	<title abbrev="OAuth 2.0 Protected Resource Metadata">OAuth 2.0 Protected Re source Metadata</title>

		<seriesInfo name="RFC" value="9728"/>
	<author fullname="Michael B. Jones" initials="M.B." surname="Jones">	<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	<organization>Self-Issued Consulting</organization>	<organization>Self-Issued Consulting</organization>
	<address>	<address>
	<email>michael_b_jones@hotmail.com</email>	<email>michael_b_jones@hotmail.com</email>

	<uri>https://self-issued.info/</uri>	<uri>https://self-issued.info/</uri>
	</address>	</address>
	</author>	</author>


	<author fullname="Phil Hunt" initials="P." surname="Hunt">	<author fullname="Phil Hunt" initials="P." surname="Hunt">
	<organization>Independent Identity, Inc.</organization>	<organization>Independent Identity, Inc.</organization>
	<address>	<address>
	<email>phil.hunt@yahoo.com</email>	<email>phil.hunt@yahoo.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Aaron Parecki" initials="A." surname="Parecki">	<author fullname="Aaron Parecki" initials="A." surname="Parecki">
	<organization>Okta</organization>	<organization>Okta</organization>
	<address>	<address>
	<email>aaron@parecki.com</email>	<email>aaron@parecki.com</email>
	<uri>https://aaronparecki.com/</uri>	<uri>https://aaronparecki.com/</uri>
	</address>	</address>
	</author>	</author>

		<date month="April" year="2025"/>
	<date day="15" month="October" year="2024" />	<area>SEC</area>
		<workgroup>oauth</workgroup>
	<area>Security</area>
	<workgroup>OAuth Working Group</workgroup>

	<keyword>OAuth</keyword>	<keyword>OAuth</keyword>
	<keyword>Discovery</keyword>	<keyword>Discovery</keyword>
	<keyword>Metadata</keyword>	<keyword>Metadata</keyword>
	<keyword>Discovery Metadata</keyword>	<keyword>Discovery Metadata</keyword>
	<keyword>Configuration Information</keyword>	<keyword>Configuration Information</keyword>
	<keyword>Resource Server</keyword>	<keyword>Resource Server</keyword>
	<keyword>Protected Resource</keyword>	<keyword>Protected Resource</keyword>
	<keyword>Resource Identifier</keyword>	<keyword>Resource Identifier</keyword>
	<keyword>JavaScript Object Notation</keyword>	<keyword>JavaScript Object Notation</keyword>

	skipping to change at line 60 ¶	skipping to change at line 51 ¶
	<keyword>Metadata</keyword>	<keyword>Metadata</keyword>
	<keyword>Discovery Metadata</keyword>	<keyword>Discovery Metadata</keyword>
	<keyword>Configuration Information</keyword>	<keyword>Configuration Information</keyword>
	<keyword>Resource Server</keyword>	<keyword>Resource Server</keyword>
	<keyword>Protected Resource</keyword>	<keyword>Protected Resource</keyword>
	<keyword>Resource Identifier</keyword>	<keyword>Resource Identifier</keyword>
	<keyword>JavaScript Object Notation</keyword>	<keyword>JavaScript Object Notation</keyword>
	<keyword>JSON</keyword>	<keyword>JSON</keyword>
	<keyword>JSON Web Token</keyword>	<keyword>JSON Web Token</keyword>
	<keyword>JWT</keyword>	<keyword>JWT</keyword>


	<abstract>	<abstract>
	<t>	<t>
	This specification defines a metadata format that	This specification defines a metadata format that
	an OAuth 2.0 client or authorization server can use to obtain	an OAuth 2.0 client or authorization server can use to obtain
	the information needed to interact with	the information needed to interact with
	an OAuth 2.0 protected resource.	an OAuth 2.0 protected resource.
	</t>	</t>
	</abstract>	</abstract>
	</front>	</front>


	<middle>	<middle>

	<section anchor="Introduction" title="Introduction">	<section anchor="Introduction">
		<name>Introduction</name>
	<t>	<t>
	This specification defines a metadata format	This specification defines a metadata format
	enabling OAuth 2.0 clients and authorization servers to obtain informatio n needed	enabling OAuth 2.0 clients and authorization servers to obtain informatio n needed
	to interact with an OAuth 2.0 protected resource.	to interact with an OAuth 2.0 protected resource.

	The structure and content of this specification is intentionally as paral	The structure and content of this specification are intentionally as para
	lel as possible to that of	llel as possible to
	<xref target="RFC7591">"OAuth 2.0 Dynamic Client Registration Protocol"</	(1) <xref target="RFC7591">"OAuth 2.0 Dynamic Client Registration Pr
	xref>,	otocol"</xref>,
	which enables a client to provide metadata about itself	which enables a client to provide metadata about itself

	to an OAuth 2.0 authorization server and to	to an OAuth 2.0 authorization server and (2) "<xref target="RFC8414"
	<xref target="RFC8414">OAuth 2.0 Authorization Server Metadata</xref>,	format="title"/>" <xref target="RFC8414" format="default"/>,
	which enables a client to obtain metadata about	which enables a client to obtain metadata about
	an OAuth 2.0 authorization server.	an OAuth 2.0 authorization server.
	</t>	</t>
	<t>	<t>
	The means by which the client obtains the location	The means by which the client obtains the location
	of the protected resource	of the protected resource

	is out of scope of this document.	is out of scope for this document.
	In some cases, the location may be manually configured into the client;	In some cases, the location may be manually configured into the client;
	for example, an email client could provide an interface for a user to ent er	for example, an email client could provide an interface for a user to ent er

	the URL of their <xref target="RFC8620">JMAP</xref> server.	the URL of their <xref target="RFC8620">JSON Meta Application Protocol (J MAP) server</xref>.
	In other cases, it may be dynamically discovered;	In other cases, it may be dynamically discovered;
	for example, a user could enter their email address into an email client,	for example, a user could enter their email address into an email client,

	the client could perform <xref target="RFC7033">WebFinger</xref> discover	the client could perform <xref target="RFC7033">WebFinger discovery</xref
	y	>
	(in a manner related to the description in Section 2 of	(in a manner related to the description in <xref target="OpenID.Discovery
	<xref target="OpenID.Discovery">"OpenID Connect Discovery 1.0"</xref>)	" section="2" relative="#IssuerDiscovery"/>) to find the resource server, and th
	to find the resource server, then fetch the resource server metadata	e client could then fetch the resource server metadata
	to find the authorization server to use to obtain authorization	to find the authorization server to use to obtain authorization
	to access the user's email.	to access the user's email.

	</t>	</t>
	<t>	<t>
	The metadata for a protected resource	The metadata for a protected resource
	is retrieved from a well-known location as a JSON <xref target="RFC8259"/ > document,	is retrieved from a well-known location as a JSON <xref target="RFC8259"/ > document,

	which declares information about its capabilities and optionally, its rel ationships to other services.	which declares information about its capabilities and, optionally, its re lationships with other services.
	This process is described in <xref target="PRConfig"/>.	This process is described in <xref target="PRConfig"/>.
	</t>	</t>
	<t>	<t>

	This metadata can either be communicated in a self-asserted fashion or as	This metadata can be communicated either in a self-asserted fashion or as
	a set of signed metadata values represented as claims	a set of signed metadata values represented as claims

	in a JSON Web Token (JWT) <xref target="JWT"/>.	in a JSON Web Token (JWT) <xref target="RFC7519"/>.
	In the JWT case, the issuer is vouching for	In the JWT case, the issuer is vouching for
	the validity of the data about the protected resource.	the validity of the data about the protected resource.

	This is analogous to the role that the Software Statement	This is analogous to the role that the software statement
	plays in OAuth Dynamic Client Registration <xref target="RFC7591"/>.	plays in OAuth Dynamic Client Registration <xref target="RFC7591"/>.
	</t>	</t>
	<t>	<t>
	Each protected resource publishing metadata about itself makes its own	Each protected resource publishing metadata about itself makes its own
	metadata document available at a well-known location	metadata document available at a well-known location
	deterministically derived from the protected resource's URL,	deterministically derived from the protected resource's URL,
	even when the resource server implements multiple protected resources.	even when the resource server implements multiple protected resources.

	This prevents attackers from publishing metadata supposedly describing	This prevents attackers from publishing metadata that supposedly describe
	the protected resource, but that is not actually authoritative for	s
		the protected resource but that is not actually authoritative for
	the protected resource, as described in <xref target="Impersonation"/>.	the protected resource, as described in <xref target="Impersonation"/>.
	</t>	</t>
	<t>	<t>
	<xref target="PRMetadata"/> defines metadata parameters that a protected	<xref target="PRMetadata"/> defines metadata parameters that a protected
	resource can publish, which includes things like which scopes are	resource can publish, which includes things like which scopes are
	supported, how a client can present an access token, and more.	supported, how a client can present an access token, and more.

	These values may be used by other specifications, such as the <span	These values, such as the <tt>jwks_uri</tt> (see <xref target="PRMe
	x style="verb">jwks_uri</spanx>	tadata"/>),
	used to publish public keys the resource server uses to sign	may be used with other specifications; for example, the public key
	resource responses, for instance,	s
	as described in <xref target="FAPI.MessageSigning"/>.	published in the <tt>jwks_uri</tt> can be used to verify the signe
	</t>	d
		resource responses, as described in <xref target="FAPI.MessageSign
		ing"/>.
		</t>
	<t>	<t>
	<xref target="WWW-Authenticate"/> describes the use of	<xref target="WWW-Authenticate"/> describes the use of

	<spanx style="verb">WWW-Authenticate</spanx> by protected resources	<tt>WWW-Authenticate</tt> by protected resources
	to dynamically inform clients of	to dynamically inform clients of
	the URL of their protected resource metadata.	the URL of their protected resource metadata.

	This use of <spanx style="verb">WWW-Authenticate</spanx> can indicate tha t	This use of <tt>WWW-Authenticate</tt> can indicate that
	the protected resource metadata may have changed.	the protected resource metadata may have changed.
	</t>	</t>

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


	<t>	<t>
	All uses of <xref target="JWS">JSON Web Signature (JWS)</xref>	All applications of <xref target="RFC7515">JSON Web Signature (JWS) dat
	and <xref target="JWE">JSON Web Encryption (JWE)</xref>	a structures</xref>
	data structures in this specification utilize	and <xref target="RFC7516">JSON Web Encryption (JWE) data structures</x
		ref>
		as discussed in this specification utilize
	the JWS Compact Serialization or the JWE Compact Serialization;	the JWS Compact Serialization or the JWE Compact Serialization;
	the JWS JSON Serialization and the JWE JSON Serialization are not used.	the JWS JSON Serialization and the JWE JSON Serialization are not used.
	Choosing a single serialization is intended to facilitate interoperabil ity.	Choosing a single serialization is intended to facilitate interoperabil ity.

	</t>	</t>
	</section>	</section>

		<section anchor="Terminology">
	<section anchor="Terminology" title="Terminology">	<name>Terminology</name>
	<t>	<t>
	This specification uses the terms "Access Token", "Authorization Code",	This specification uses the terms "access token", "authorization code",
	"Authorization Endpoint", "Authorization Grant", "Authorization Server"	"authorization server",
	,	"client", "client authentication", "client identifier",
	"Client", "Client Authentication", "Client Identifier", "Client Secret"	"protected resource", and
	,	"resource server"
	"Grant Type", "Protected Resource", "Redirection URI", "Refresh Token",	defined by <xref target="RFC6749">OAuth 2.0</xref>, and
	"Resource Owner", "Resource Server", "Response Type", and "Token Endpoi	the terms "Claim Name" and "JSON Web Token (JWT)"
	nt"	defined by "<xref target="RFC7519" format="title"/>" <xref target="RFC7
	defined by <xref target="RFC6749">OAuth 2.0</xref>,	519" format="default"/>.
	the terms "Claim Name", "Claim Value", and "JSON Web Token (JWT)"	</t>
	defined by <xref target="JWT">JSON Web Token (JWT)</xref>.	<t>
	</t>
	<t>
	This specification defines the following term:	This specification defines the following term:

	<list style='hanging'>	</t>
	<t hangText='Resource Identifier:'>	<dl newline="true" spacing="normal">
	<vspace/>	<dt>Resource Identifier:</dt>
	The Protected resource's resource identifier, which is a URL that	<dd>
	uses the <spanx style="verb">https</spanx> scheme and has no fragme	The protected resource's resource identifier, which is a URL that
	nt component.	uses the <tt>https</tt> scheme and has no fragment component.
	As in Section 2 of <xref target="RFC8707"/>, it also SHOULD NOT inc	As specified in <xref section="2" sectionFormat="of" target="RFC870
	lude	7"/>, it also <bcp14>SHOULD NOT</bcp14> include
	a query component, but it is recognized that there are cases that m ake	a query component, but it is recognized that there are cases that m ake
	a query component a useful and necessary part of a resource identif ier.	a query component a useful and necessary part of a resource identif ier.
	Protected resource metadata is published at a	Protected resource metadata is published at a

	<spanx style="verb">.well-known</spanx> location	<tt>.well-known</tt> location
	<xref target="RFC8615"/>	<xref target="RFC8615"/>
	derived from this resource identifier,	derived from this resource identifier,
	as described in <xref target="PRConfig"/>.	as described in <xref target="PRConfig"/>.

	</t>	</dd>
	</list>	</dl>
	</t>
	</section>	</section>
	</section>	</section>

		<section anchor="PRMetadata">
	<section anchor="PRMetadata" title="Protected Resource Metadata">	<name>Protected Resource Metadata</name>
	<t>	<t>
	Protected resources can have metadata describing their configuration.	Protected resources can have metadata describing their configuration.
	The following protected resource metadata parameters	The following protected resource metadata parameters

	are used by this specification and are registered in the IANA	are used by this specification and are registered in the
	"OAuth Protected Resource Metadata" registry	"OAuth Protected Resource Metadata" registry
	established in <xref target="PRMetadataReg"/>:	established in <xref target="PRMetadataReg"/>:


	<list style="hanging">	</t>
		<dl newline="true" spacing="normal">
	<t hangText="resource">	<dt>resource</dt>
	<vspace/>	<dd>
	REQUIRED.	<bcp14>REQUIRED</bcp14>.
	The protected resource's Resource Identifier,	The protected resource's resource identifier,
	as defined in <xref target="Terminology"/>.	as defined in <xref target="Terminology"/>.

	</t>	</dd>
		<dt>authorization_servers</dt>
	<t hangText="authorization_servers">	<dd>
	<vspace/>	<bcp14>OPTIONAL</bcp14>.
	OPTIONAL.
	JSON array containing a list of OAuth authorization server issuer ide ntifiers,	JSON array containing a list of OAuth authorization server issuer ide ntifiers,
	as defined in <xref target="RFC8414"/>,	as defined in <xref target="RFC8414"/>,
	for authorization servers that can be used with this protected resour ce.	for authorization servers that can be used with this protected resour ce.

	Protected resources MAY choose not to advertise some supported author ization servers	Protected resources <bcp14>MAY</bcp14> choose not to advertise some s upported authorization servers
	even when this parameter is used.	even when this parameter is used.
	In some use cases, the set of authorization servers will not be enume rable,	In some use cases, the set of authorization servers will not be enume rable,
	in which case this metadata parameter would not be used.	in which case this metadata parameter would not be used.

	</t>	</dd>
		<dt>jwks_uri</dt>
	<t hangText="jwks_uri">	<dd>
	<vspace/>	<bcp14>OPTIONAL</bcp14>.
	OPTIONAL.	URL of the protected resource's JSON Web Key (JWK) Set <xref target="
	URL of the protected resource's JSON Web Key (JWK) Set <xref target="	RFC7517"/> document.
	JWK"/> document.
	This contains public keys belonging to the protected resource, such a s	This contains public keys belonging to the protected resource, such a s
	signing key(s) that the resource server uses to sign resource respons es.	signing key(s) that the resource server uses to sign resource respons es.

	This URL MUST use the <spanx style="verb">https</spanx> scheme.	This URL <bcp14>MUST</bcp14> use the <tt>https</tt> scheme.
	When both signing and encryption keys are made available,	When both signing and encryption keys are made available,

	a <spanx style="verb">use</spanx> (public key use) parameter	a <tt>use</tt> (public key use) parameter
	value is REQUIRED for all keys in the referenced JWK Set	value is <bcp14>REQUIRED</bcp14> for all keys in the referenced JWK S
		et
	to indicate each key's intended usage.	to indicate each key's intended usage.

	</t>	</dd>
		<dt>scopes_supported</dt>
	<t hangText="scopes_supported">	<dd>
	<vspace/>	<bcp14>RECOMMENDED</bcp14>.
	RECOMMENDED.	JSON array containing a list of scope values, as defined in <xref tar
	JSON array containing a list of the <xref	get="RFC6749">OAuth
	target="RFC6749">OAuth 2.0</xref> <spanx style="verb">scope</spanx> v	2.0</xref>, that
	alues that
	are used in authorization requests to request access to this protecte d resource.	are used in authorization requests to request access to this protecte d resource.

	Protected resources MAY choose not to advertise some scope values sup ported	Protected resources <bcp14>MAY</bcp14> choose not to advertise some s cope values supported
	even when this parameter is used.	even when this parameter is used.

	</t>	</dd>
		<dt>bearer_methods_supported</dt>
	<t hangText="bearer_methods_supported">	<dd>
	<vspace/>	<bcp14>OPTIONAL</bcp14>.
	OPTIONAL.
	JSON array containing a list of the supported methods of sending an	JSON array containing a list of the supported methods of sending an

	OAuth 2.0 Bearer Token <xref target="RFC6750"/> to the protected reso urce.	OAuth 2.0 bearer token <xref target="RFC6750"/> to the protected reso urce.
	Defined values are	Defined values are

	<spanx style="verb">["header", "body", "query"]</spanx>,	<tt>["header", "body", "query"]</tt>,
	corresponding to Sections 2.1, 2.2, and 2.3 of RFC 6750.	corresponding to Sections <xref section="2.1" sectionFormat="bare" ta
	The empty array <spanx style="verb">[]</spanx> can be used	rget="RFC6750"/>, <xref section="2.2" sectionFormat="bare" target="RFC6750"/>, a
	to indicate that no Bearer methods are supported.	nd <xref section="2.3" sectionFormat="bare" target="RFC6750"/> of <xref target="
		RFC6750"/>.
		The empty array <tt>[]</tt> can be used
		to indicate that no bearer methods are supported.
	If this entry is omitted,	If this entry is omitted,

	no default Bearer methods supported are implied,	no default bearer methods supported are implied,
	nor does its absence indicate that they are not supported.	nor does its absence indicate that they are not supported.

	</t>	</dd>
		<dt>resource_signing_alg_values_supported</dt>
	<t hangText="resource_signing_alg_values_supported">	<dd>
	<vspace/>	<bcp14>OPTIONAL</bcp14>.
	OPTIONAL.	JSON array containing a list of the JWS <xref target="RFC7515"/> sign
	JSON array containing a list of the JWS <xref target="JWS" /> signing	ing algorithms
	algorithms	(<tt>alg</tt> values) <xref target="RFC7518"/>
	(<spanx style="verb">alg</spanx> values) <xref target="JWA" />
	supported by the protected resource for signing resource responses,	supported by the protected resource for signing resource responses,
	for instance,	for instance,
	as described in <xref target="FAPI.MessageSigning"/>.	as described in <xref target="FAPI.MessageSigning"/>.
	No default algorithms are implied if this entry is omitted.	No default algorithms are implied if this entry is omitted.

	The value <spanx style="verb">none</spanx> MUST NOT be used.	The value <tt>none</tt> <bcp14>MUST NOT</bcp14> be used.
	</t>	</dd>
		<dt>resource_name</dt>
	<t hangText="resource_name">	<dd>
	<vspace/>
	Human-readable name of the protected resource	Human-readable name of the protected resource

	intended for display to the end-user.	intended for display to the end user.
	It is RECOMMENDED that protected resource metadata includes this fiel	It is <bcp14>RECOMMENDED</bcp14> that protected resource metadata inc
	d.	lude this field.
	The value of this field MAY be internationalized,	The value of this field <bcp14>MAY</bcp14> be internationalized,
	as described in <xref target="HumanReadableMetadata"/>.	as described in <xref target="HumanReadableMetadata"/>.

	</t>	</dd>
		<dt>resource_documentation</dt>
	<t hangText="resource_documentation">	<dd>
	<vspace/>	<bcp14>OPTIONAL</bcp14>.
	OPTIONAL.
	URL of a page containing human-readable information that	URL of a page containing human-readable information that
	developers might want or need to know when using the protected resour ce.	developers might want or need to know when using the protected resour ce.

	The value of this field MAY be internationalized,	The value of this field <bcp14>MAY</bcp14> be internationalized,
	as described in <xref target="HumanReadableMetadata"/>.	as described in <xref target="HumanReadableMetadata"/>.

	</t>	</dd>
		<dt>resource_policy_uri</dt>
	<t hangText="resource_policy_uri">	<dd>
	<vspace/>	<bcp14>OPTIONAL</bcp14>.
	OPTIONAL.
	URL of a page containing human-readable information	URL of a page containing human-readable information
	about the protected resource's requirements on how	about the protected resource's requirements on how
	the client can use the data provided by the protected resource.	the client can use the data provided by the protected resource.

	The value of this field MAY be internationalized,	The value of this field <bcp14>MAY</bcp14> be internationalized,
	as described in <xref target="HumanReadableMetadata"/>.	as described in <xref target="HumanReadableMetadata"/>.

	</t>	</dd>
		<dt>resource_tos_uri</dt>
	<t hangText="resource_tos_uri">	<dd>
	<vspace/>	<bcp14>OPTIONAL</bcp14>.
	OPTIONAL.
	URL of a page containing human-readable information	URL of a page containing human-readable information
	about the protected resource's terms of service.	about the protected resource's terms of service.

	The value of this field MAY be internationalized,	The value of this field <bcp14>MAY</bcp14> be internationalized,
	as described in <xref target="HumanReadableMetadata"/>.	as described in <xref target="HumanReadableMetadata"/>.

	</t>	</dd>
		<dt>tls_client_certificate_bound_access_tokens</dt>
	<t hangText="tls_client_certificate_bound_access_tokens">	<dd>
	<vspace/>	<bcp14>OPTIONAL</bcp14>.
	OPTIONAL.
	Boolean value indicating protected resource support for	Boolean value indicating protected resource support for
	mutual-TLS client certificate-bound access tokens	mutual-TLS client certificate-bound access tokens
	<xref target="RFC8705"/>.	<xref target="RFC8705"/>.
	If omitted, the default value is false.	If omitted, the default value is false.

	</t>	</dd>
		<dt>authorization_details_types_supported</dt>
	<t hangText="authorization_details_types_supported">	<dd>
	<vspace/>	<bcp14>OPTIONAL</bcp14>.
	OPTIONAL.	JSON array containing a list of the authorization details
	A JSON array containing a list of the authorization details	<tt>type</tt> values supported by the resource server
	<spanx style="verb">type</spanx> values supported by the resource ser	when the <tt>authorization_details</tt>
	ver
	when the <spanx style="verb">authorization_details</spanx>
	request parameter <xref target="RFC9396"/> is used.	request parameter <xref target="RFC9396"/> is used.

	</t>	</dd>
		<dt>dpop_signing_alg_values_supported</dt>
	<t hangText="dpop_signing_alg_values_supported">	<dd>
	<vspace/>	<bcp14>OPTIONAL</bcp14>.
	OPTIONAL.	JSON array containing a list of the JWS <tt>alg</tt> values
	A JSON array containing a list of the JWS alg values
	(from the "JSON Web Signature and Encryption Algorithms" registry	(from the "JSON Web Signature and Encryption Algorithms" registry
	<xref target="IANA.JOSE"/>)	<xref target="IANA.JOSE"/>)
	supported by the resource server for validating	supported by the resource server for validating

	DPoP proof JWTs <xref target="RFC9449"/>.	Demonstrating Proof of Possession (DPoP) proof JWTs <xref target="RFC
	</t>	9449"/>.
		</dd>
	<t hangText="dpop_bound_access_tokens_required">	<dt>dpop_bound_access_tokens_required</dt>
	<vspace/>	<dd>
	OPTIONAL.	<bcp14>OPTIONAL</bcp14>.
	A boolean value specifying whether the protected resource always requ	Boolean value specifying whether the protected resource always requir
	ires	es
	the use of DPoP-bound access tokens <xref target="RFC9449"/>.	the use of DPoP-bound access tokens <xref target="RFC9449"/>.
	If omitted, the default value is false.	If omitted, the default value is false.

	</t>	</dd>
		</dl>
	</list>
	</t>
	<t>	<t>

	Additional protected resource metadata parameters MAY also be used.	Additional protected resource metadata parameters <bcp14>MAY</bcp14> also be used.
	</t>	</t>

		<section anchor="HumanReadableMetadata">
	<section anchor="HumanReadableMetadata"	<name>Human-Readable Resource Metadata</name>
	title="Human-Readable Resource Metadata">	<t>
	<t>
	Human-readable resource metadata values	Human-readable resource metadata values
	and resource metadata values that reference human-readable content	and resource metadata values that reference human-readable content

	MAY be represented in multiple languages and scripts.	<bcp14>MAY</bcp14> be represented in multiple languages and scripts.
	For example, the values of fields such as	For example, the values of fields such as

	<spanx style="verb">resource_name</spanx>,	<tt>resource_name</tt>,
	<spanx style="verb">resource_documentation</spanx>,	<tt>resource_documentation</tt>,
	<spanx style="verb">resource_tos_uri</spanx>, and	<tt>resource_tos_uri</tt>, and
	<spanx style="verb">resource_policy_uri</spanx>	<tt>resource_policy_uri</tt>
	might have multiple locale-specific metadata values	might have multiple locale-specific metadata values
	to facilitate use in different locations.	to facilitate use in different locations.

	</t>	</t>
	<t>	<t>
	To specify the languages and scripts, <xref target="RFC5646">BCP 47</xr	To specify the languages and scripts, language tags <xref target="BCP47
	ef>	"/>
	language tags are added to resource metadata parameter names,	are added to resource metadata parameter names,
	delimited by a <spanx style="verb">#</spanx> character.	delimited by a <tt>#</tt> character.
	Since <xref target="RFC8259">JSON</xref> member names are case sensitiv	Since member names as discussed in <xref target="RFC8259">JSON</xref> a
	e,	re case sensitive,
	it is RECOMMENDED that language tag values used in Claim Names be spell	it is <bcp14>RECOMMENDED</bcp14> that language tag values used in Claim
	ed	Names be spelled
	using the character case with which they are registered in the	using the character case with which they are registered in the

	<xref target="IANA.Language">"IANA Language Subtag" registry</xref>.	<xref target="IANA.Language">"Language Subtag Registry"</xref>.
	In particular, normally language names are spelled with lowercase	In particular, normally, language names are spelled with lowercase
	characters, region names are spelled with uppercase characters,	characters, region names are spelled with uppercase characters,
	and languages are spelled with mixed-case characters.	and languages are spelled with mixed-case characters.

	However, since BCP 47 language tag values are case-insensitive,	However, since language tag values are case insensitive per <xref targe
	implementations SHOULD interpret the language tag values supplied	t="BCP47"/>,
	in a case insensitive manner.	implementations <bcp14>SHOULD</bcp14> interpret the language tag values
	Per the recommendations in BCP 47, language tag values used in	supplied
	metadata parameter names should only be as specific as necessary.	in a case-insensitive manner.
	For instance, using <spanx style="verb">fr</spanx> might be sufficient	Per the recommendations in <xref target="BCP47"/>, language tag values
	in many contexts, rather than <spanx style="verb">fr-CA</spanx>	used in
	or <spanx style="verb">fr-FR</spanx>.	metadata parameter names should only be as specific as is necessary.
	</t>	For instance, using <tt>fr</tt> might be sufficient
	<t>	in many contexts, rather than <tt>fr-CA</tt>
		or <tt>fr-FR</tt>.
		</t>
		<t>
	For example, a resource could represent its name in English as	For example, a resource could represent its name in English as

	<spanx style="verb">"resource_name#en": "My Resource"</spanx>	<tt>"resource_name#en": "My Resource"</tt>
	and its name in Italian as	and its name in Italian as

	<spanx style="verb">"resource_name#it": "La mia bella risorsa"</spanx>	<tt>"resource_name#it": "La mia bella risorsa"</tt>
	within its metadata.	within its metadata.

	Any or all of these names MAY be displayed to the end-user,	Any or all of these names <bcp14>MAY</bcp14> be displayed to the end us er,
	choosing which names to display based on system configuration,	choosing which names to display based on system configuration,
	user preferences, or other factors.	user preferences, or other factors.

	</t>	</t>
	<t>	<t>
	If any human-readable field is sent without a language tag,	If any human-readable field is sent without a language tag,

	parties using it MUST NOT make any assumptions about the language,	parties using it <bcp14>MUST NOT</bcp14> make any assumptions about the language,
	character set, or script of the string value, and the string value	character set, or script of the string value, and the string value

	MUST be used as is wherever it is presented in a user interface.	<bcp14>MUST</bcp14> be used as is wherever it is presented in a user in
	To facilitate interoperability, it is RECOMMENDED that	terface.
	each kind of human-readable metadata provided includes	To facilitate interoperability, it is <bcp14>RECOMMENDED</bcp14> that
		each kind of human-readable metadata provided include
	an instance of its metadata parameter without any language tags	an instance of its metadata parameter without any language tags

	in addition to any language-specific parameters, and it is RECOMMENDED that	in addition to any language-specific parameters, and it is <bcp14>RECOM MENDED</bcp14> that
	any human-readable fields sent without language tags contain values	any human-readable fields sent without language tags contain values
	suitable for display on a wide variety of systems.	suitable for display on a wide variety of systems.

	</t>	</t>
	</section>	</section>

		<section anchor="SignedMetadata">
	<section anchor="SignedMetadata" title="Signed Protected Resource Metadata	<name>Signed Protected Resource Metadata</name>
	">	<t>
	<t>	In addition to JSON elements, metadata values <bcp14>MAY</bcp14> also b
	In addition to JSON elements, metadata values MAY also be provided	e provided
	as a <spanx style="verb">signed_metadata</spanx> value,	as a <tt>signed_metadata</tt> value,
	which is a JSON Web Token (JWT) <xref target="JWT"/>	which is a JSON Web Token (JWT) <xref target="RFC7519"/>
	that asserts metadata values about the protected resource as a bundle.	that asserts metadata values about the protected resource as a bundle.
	A set of metadata parameters that can be used in signed metadata as cla ims	A set of metadata parameters that can be used in signed metadata as cla ims
	are defined in <xref target="PRMetadata"/>.	are defined in <xref target="PRMetadata"/>.

	The signed metadata MUST be digitally signed or MACed	The signed metadata <bcp14>MUST</bcp14> be digitally signed or MACed
	using <xref target="JWS">JSON Web Signature (JWS)</xref>	(protected with a Message Authentication Code) using a <xref target="RF
	and MUST contain an <spanx style="verb">iss</spanx> (issuer) claim	C7515">JSON Web Signature (JWS)</xref>
		and <bcp14>MUST</bcp14> contain an <tt>iss</tt> (issuer) claim
	denoting the party attesting to the claims in the signed metadata.	denoting the party attesting to the claims in the signed metadata.

	Consumers of the metadata MAY ignore the signed metadata	Consumers of the metadata <bcp14>MAY</bcp14> ignore the signed metadata
	if they do not support this feature.	if they do not support this feature.
	If the consumer of the metadata supports signed metadata,	If the consumer of the metadata supports signed metadata,
	metadata values conveyed in the signed metadata	metadata values conveyed in the signed metadata

	MUST take precedence over the corresponding values conveyed using plain	<bcp14>MUST</bcp14> take precedence over the corresponding values conve
	JSON elements.	yed using plain JSON elements.
	</t>	</t>
	<t>	<t>
	Signed metadata is included in the protected resource metadata JSON obj ect	Signed metadata is included in the protected resource metadata JSON obj ect

	using this OPTIONAL metadata parameter:	using this <bcp14>OPTIONAL</bcp14> metadata parameter:
	<list style="hanging">	</t>
		<dl newline="true" spacing="normal">
	<t hangText="signed_metadata">	<dt>signed_metadata</dt>
	<vspace/>	<dd>
	A JWT containing metadata parameters about the protected resource a s claims.	A JWT containing metadata parameters about the protected resource a s claims.
	This is a string value consisting of the entire signed JWT.	This is a string value consisting of the entire signed JWT.

	A <spanx style="verb">signed_metadata</spanx>	A <tt>signed_metadata</tt>
	parameter SHOULD NOT appear as a claim in the JWT;	parameter <bcp14>SHOULD NOT</bcp14> appear as a claim in the JWT;
	it is RECOMMENDED to reject any metadata in which this occurs.	it is <bcp14>RECOMMENDED</bcp14> to reject any metadata in which th
	</t>	is occurs.
		</dd>
	</list>	</dl>
	</t>
	</section>	</section>


	</section>	</section>

		<section anchor="PRConfig">
	<section anchor="PRConfig"	<name>Obtaining Protected Resource Metadata</name>
	title="Obtaining Protected Resource Metadata">

	<t>	<t>
	Protected resources supporting metadata	Protected resources supporting metadata

	MUST make a JSON document containing metadata as specified in <xref targe t="PRMetadata"/>	<bcp14>MUST</bcp14> make a JSON document containing metadata as specified in <xref target="PRMetadata"/>
	available at a URL formed by	available at a URL formed by
	inserting a well-known URI string into the protected resource's resource identifier	inserting a well-known URI string into the protected resource's resource identifier
	between the host component and the path and/or query components, if any.	between the host component and the path and/or query components, if any.
	By default, the well-known URI string used is	By default, the well-known URI string used is

	<spanx style="verb">/.well-known/oauth-protected-resource</spanx>.	<tt>/.well-known/oauth-protected-resource</tt>.
	The syntax and semantics of <spanx style="verb">.well-known</spanx>	The syntax and semantics of <tt>.well-known</tt>
	are defined in <xref target="RFC8615"/>.	are defined in <xref target="RFC8615"/>.

	The well-known URI path suffix used MUST be registered in the IANA	The well-known URI path suffix used <bcp14>MUST</bcp14> be registered in the
	"Well-Known URIs" registry <xref target="IANA.well-known"/>.	"Well-Known URIs" registry <xref target="IANA.well-known"/>.
	Examples of this construction can be found in <xref target="PRConfigurati onRequest"/>.	Examples of this construction can be found in <xref target="PRConfigurati onRequest"/>.
	</t>	</t>
	<t>	<t>
	The term "application", as used below (and as used in <xref target="RFC84 14"/>),	The term "application", as used below (and as used in <xref target="RFC84 14"/>),
	encompasses all the components used to accomplish the task for the use ca se.	encompasses all the components used to accomplish the task for the use ca se.
	That can include OAuth clients, authorization servers, protected resource s,	That can include OAuth clients, authorization servers, protected resource s,
	and non-OAuth components, inclusive of the code running in each of them.	and non-OAuth components, inclusive of the code running in each of them.
	Applications are built to solve particular problems	Applications are built to solve particular problems
	and may utilize many components and services.	and may utilize many components and services.
	</t>	</t>
	<t>	<t>
	Different applications utilizing OAuth protected resources in application -specific ways	Different applications utilizing OAuth protected resources in application -specific ways

	MAY define and register different well-known URI path suffixes	<bcp14>MAY</bcp14> define and register different well-known URI path suff ixes
	for publishing protected resource metadata used by those applications.	for publishing protected resource metadata used by those applications.

	For instance, if the Example application uses an OAuth protected resource in an Example-specific way,	For instance, if the Example application uses an OAuth protected resource in an Example-specific way
	and there are Example-specific metadata values that it needs to publish,	and there are Example-specific metadata values that it needs to publish,
	then it might register and use the	then it might register and use the

	<spanx style="verb">example-protected-resource</spanx> URI path suffix an d publish	<tt>example-protected-resource</tt> URI path suffix and publish
	the metadata document at the URL formed by inserting	the metadata document at the URL formed by inserting

	<spanx style="verb">/.well-known/example-protected-resource</spanx>	<tt>/.well-known/example-protected-resource</tt>
	between the host and path and/or query components of the	between the host and path and/or query components of the
	protected resource's resource identifier.	protected resource's resource identifier.
	Alternatively, many such applications will use the default well-known URI string	Alternatively, many such applications will use the default well-known URI string

	<spanx style="verb">/.well-known/oauth-protected-resource</spanx>,	<tt>/.well-known/oauth-protected-resource</tt>,
	which is the right choice for general-purpose OAuth protected resources,	which is the right choice for general-purpose OAuth protected resources,
	and not register an application-specific one.	and not register an application-specific one.
	</t>	</t>
	<t>	<t>

	An OAuth 2.0 application using this specification MUST specify	An OAuth 2.0 application using this specification <bcp14>MUST</bcp14> spe cify
	what well-known URI suffix it will use for this purpose.	what well-known URI suffix it will use for this purpose.

	The same protected resource MAY choose to publish its metadata at multipl	The same protected resource <bcp14>MAY</bcp14> choose to publish its meta
	e	data at multiple
	well-known locations derived from its resource identifier,	well-known locations derived from its resource identifier --
	for example, publishing metadata at both	for example, publishing metadata at both

	<spanx style="verb">/.well-known/example-protected-resource</spanx> and	<tt>/.well-known/example-protected-resource</tt> and
	<spanx style="verb">/.well-known/oauth-protected-resource</spanx>.	<tt>/.well-known/oauth-protected-resource</tt>.
	</t>	</t>

		<section anchor="PRConfigurationRequest">
	<section anchor="PRConfigurationRequest"	<name>Protected Resource Metadata Request</name>
	title="Protected Resource Metadata Request">
	<t>	<t>

	A protected resource metadata document MUST be queried using an HTTP	A protected resource metadata document <bcp14>MUST</bcp14> be queried u
	<spanx style="verb">GET</spanx> request at the previously specified URL	sing an HTTP
	.	<tt>GET</tt> request at the previously specified URL.
	</t>	</t>
	<t>	<t>
	The consumer of the metadata would make the following request when the	The consumer of the metadata would make the following request when the

	resource identifier is <spanx style="verb">https://resource.example.com	resource identifier is <tt>https://resource.example.com</tt>
	</spanx>	and the well-known URI path suffix is <tt>oauth-protected-resource</tt>
	and the well-known URI path suffix is <spanx style="verb">oauth-protect
	ed-resource</spanx>
	to obtain the metadata,	to obtain the metadata,
	since the resource identifier contains no path component:	since the resource identifier contains no path component:

	</t>	</t>
	<t>	<sourcecode type="http-message"><![CDATA[
	<figure>
	<artwork><![CDATA[
	GET /.well-known/oauth-protected-resource HTTP/1.1	GET /.well-known/oauth-protected-resource HTTP/1.1
	Host: resource.example.com	Host: resource.example.com

	]]></artwork>	]]></sourcecode>
	</figure>	<t>
	</t>

	<t>
	If the resource identifier value contains a path or query component,	If the resource identifier value contains a path or query component,

	any terminating <spanx style="verb">/</spanx> following the host compon	any terminating slash (<tt>/</tt>) following the host component
	ent	<bcp14>MUST</bcp14> be removed before inserting
	MUST be removed before inserting	<tt>/.well-known/</tt> and the well-known URI path suffix
	<spanx style="verb">/.well-known/</spanx> and the well-known URI path s
	uffix
	between the host component and the path and/or query components.	between the host component and the path and/or query components.
	The consumer of the metadata would make the following request when the	The consumer of the metadata would make the following request when the

	resource identifier is <spanx style="verb">https://resource.example.com	resource identifier is <tt>https://resource.example.com/resource1</tt>
	/resource1</spanx>	and the well-known URI path suffix is <tt>oauth-protected-resource</tt>
	and the well-known URI path suffix is <spanx style="verb">oauth-protect
	ed-resource</spanx>
	to obtain the metadata,	to obtain the metadata,
	since the resource identifier contains a path component:	since the resource identifier contains a path component:

	</t>	</t>
	<t>	<sourcecode type="http-message"><![CDATA[
	<figure>
	<artwork><![CDATA[
	GET /.well-known/oauth-protected-resource/resource1 HTTP/1.1	GET /.well-known/oauth-protected-resource/resource1 HTTP/1.1
	Host: resource.example.com	Host: resource.example.com

	]]></artwork>	]]></sourcecode>
	</figure>	<t>
	</t>

	<t>
	Using path components enables supporting multiple resources per host.	Using path components enables supporting multiple resources per host.
	This is required in some multi-tenant hosting configurations.	This is required in some multi-tenant hosting configurations.

	This use of <spanx style="verb">.well-known</spanx> is for supporting	This use of <tt>.well-known</tt> is for supporting
	multiple resources per host; unlike its use in	multiple resources per host; unlike its use in
	<xref target="RFC8615"/>, it does not provide	<xref target="RFC8615"/>, it does not provide
	general information about the host.	general information about the host.

	</t>	</t>

	</section>	</section>

		<section anchor="PRConfigurationResponse">
	<section anchor="PRConfigurationResponse"	<name>Protected Resource Metadata Response</name>
	title="Protected Resource Metadata Response">
	<t>	<t>
	The response is a set of metadata parameters about the protected resour ce's	The response is a set of metadata parameters about the protected resour ce's
	configuration.	configuration.

	A successful response MUST use the 200 OK HTTP status code and return	A successful response <bcp14>MUST</bcp14> use the 200 OK HTTP status co
	a JSON object using the <spanx style="verb">application/json</spanx> co	de and return
	ntent type	a JSON object using the <tt>application/json</tt> content type
	that contains a set of metadata parameters as its members	that contains a set of metadata parameters as its members
	that are a subset of the metadata parameters defined in	that are a subset of the metadata parameters defined in
	<xref target="PRMetadata"/>.	<xref target="PRMetadata"/>.

	Additional metadata parameters MAY be defined and used;	Additional metadata parameters <bcp14>MAY</bcp14> be defined and used;
	any metadata parameters that are not understood MUST be ignored.	any metadata parameters that are not understood <bcp14>MUST</bcp14> be
	</t>	ignored.
		</t>
	<t>	<t>
	Parameters with multiple values are represented as JSON arrays.	Parameters with multiple values are represented as JSON arrays.

	Parameters with zero values MUST be omitted from the response.	Parameters with zero values <bcp14>MUST</bcp14> be omitted from the res
	</t>	ponse.
	<t>	</t>
	An error response uses the applicable HTTP status code value.
	</t>
	<t>	<t>

	<figure>	An error response uses the applicable HTTP status code value.
	<preamble>The following is a non-normative example response:</preambl	</t>
	e>	<t keepWithNext="true">The following is a non-normative example response
		:</t>
	<artwork><![CDATA[	<sourcecode type="http-message"><![CDATA[
	HTTP/1.1 200 OK	HTTP/1.1 200 OK
	Content-Type: application/json	Content-Type: application/json

	{	{
	"resource":	"resource":
	"https://resource.example.com",	"https://resource.example.com",
	"authorization_servers":	"authorization_servers":
	["https://as1.example.com",	["https://as1.example.com",
	"https://as2.example.net"],	"https://as2.example.net"],
	"bearer_methods_supported":	"bearer_methods_supported":
	["header", "body"],	["header", "body"],
	"scopes_supported":	"scopes_supported":
	["profile", "email", "phone"],	["profile", "email", "phone"],
	"resource_documentation":	"resource_documentation":
	"https://resource.example.com/resource_documentation.html"	"https://resource.example.com/resource_documentation.html"
	}	}

	]]></artwork>	]]></sourcecode>
	</figure>
	</t>
	</section>	</section>

		<section anchor="PRConfigurationValidation">
	<section anchor="PRConfigurationValidation"	<name>Protected Resource Metadata Validation</name>
	title="Protected Resource Metadata Validation">

	<t>	<t>

	The <spanx style="verb">resource</spanx> value returned MUST be identic al to	The <tt>resource</tt> value returned <bcp14>MUST</bcp14> be identical t o
	the protected resource's resource identifier value into which	the protected resource's resource identifier value into which
	the well-known URI path suffix was inserted to create the URL	the well-known URI path suffix was inserted to create the URL
	used to retrieve the metadata.	used to retrieve the metadata.

	If these values are not identical, the data contained in the response M	If these values are not identical, the data contained in the response <
	UST NOT be used.	bcp14>MUST NOT</bcp14> be used.
	</t>	</t>
	<t>	<t>
	If the protected resource metadata was retrieved from a URL	If the protected resource metadata was retrieved from a URL

	returned by the protected resource via the <spanx style="verb">WWW-Auth	returned by the protected resource via the <tt>WWW-Authenticate</tt>
	enticate</spanx>	<tt>resource_metadata</tt> parameter, then
	<spanx style="verb">resource_metadata</spanx> parameter, then	the <tt>resource</tt> value returned <bcp14>MUST</bcp14> be identical t
	the <spanx style="verb">resource</spanx> value returned MUST be identic	o
	al to
	the URL that the client used to make the request to the resource server .	the URL that the client used to make the request to the resource server .

	If these values are not identical, the data contained in the response M	If these values are not identical, the data contained in the response <
	UST NOT be used.	bcp14>MUST NOT</bcp14> be used.
	</t>	</t>
	<t>	<t>
	These validation actions can thwart impersonation attacks,	These validation actions can thwart impersonation attacks,
	as described in <xref target="Impersonation"/>.	as described in <xref target="Impersonation"/>.

	</t>	</t>
	<t>	<t>
	The recipient MUST validate that any signed metadata was signed	The recipient <bcp14>MUST</bcp14> validate that any signed metadata was
		signed
	by a key belonging to the issuer and that the signature is valid.	by a key belonging to the issuer and that the signature is valid.
	If the signature does not validate or the issuer is not trusted,	If the signature does not validate or the issuer is not trusted,

	the recipient SHOULD treat this as an error condition.	the recipient <bcp14>SHOULD</bcp14> treat this as an error condition.
	</t>	</t>
	</section>	</section>
	</section>	</section>

		<section anchor="ASMetadata">
	<section anchor="ASMetadata" title="Authorization Server Metadata">	<name>Authorization Server Metadata</name>
	<t>	<t>
	To support use cases in which the set of legitimate protected resources	To support use cases in which the set of legitimate protected resources
	to use with the authorization server is enumerable,	to use with the authorization server is enumerable,
	this specification defines the authorization server metadata parameter	this specification defines the authorization server metadata parameter

	<spanx style="verb">protected_resources</spanx>,	<tt>protected_resources</tt>,
	which enables the authorization server to explicitly list the protected r esources.	which enables the authorization server to explicitly list the protected r esources.
	Note that if the set of legitimate authorization servers	Note that if the set of legitimate authorization servers
	to use with a protected resource is also enumerable,	to use with a protected resource is also enumerable,
	lists in the authorization server metadata and protected resource metadat a	lists in the authorization server metadata and protected resource metadat a
	should be cross-checked against one another for consistency	should be cross-checked against one another for consistency
	when these lists are used by the application profile.	when these lists are used by the application profile.
	</t>	</t>
	<t>	<t>
	The following authorization server metadata parameter	The following authorization server metadata parameter

	is defined by this specification and is registered in the IANA	is defined by this specification and is registered in the
	"OAuth Authorization Server Metadata" registry established in	"OAuth Authorization Server Metadata" registry established in

	<xref target="RFC8414">OAuth 2.0 Authorization Server Metadata</xref>.	"<xref target="RFC8414" format="title"/>" <xref target="RFC8414" format="default
		"/>.
	<list style="hanging">


	<t hangText="protected_resources">	</t>
	<vspace/>	<dl newline="true" spacing="normal">
	OPTIONAL.	<dt>protected_resources</dt>
		<dd>
		<bcp14>OPTIONAL</bcp14>.
	JSON array containing a list of resource identifiers for OAuth protec ted resources	JSON array containing a list of resource identifiers for OAuth protec ted resources

	for protected resources that can be used with this authorization serv	that can be used with this authorization server.
	er.	Authorization servers <bcp14>MAY</bcp14> choose not to advertise some
	Authorization servers MAY choose not to advertise some supported prot	supported protected resources
	ected resources
	even when this parameter is used.	even when this parameter is used.
	In some use cases, the set of protected resources will not be enumera ble,	In some use cases, the set of protected resources will not be enumera ble,
	in which case this metadata parameter will not be present.	in which case this metadata parameter will not be present.

	</t>	</dd>
		</dl>
	</list>
	</t>
	</section>	</section>

		<section anchor="WWW-Authenticate">
	<section anchor="WWW-Authenticate" title="Use of WWW-Authenticate for Protec	<name>Use of WWW-Authenticate for Protected Resource Metadata</name>
	ted Resource Metadata">
	<t>	<t>

	A protected resource MAY use the <spanx style="verb">WWW-Authenticate</sp	A protected resource <bcp14>MAY</bcp14> use the <tt>WWW-Authenticate</tt>
	anx>	HTTP response header field, as discussed in <xref target="RFC9110"/>,
	<xref target="RFC9110"/> HTTP response header field
	to return a URL to its protected resource metadata to the client.	to return a URL to its protected resource metadata to the client.
	The client can then retrieve protected resource metadata as described in <xref target="PRConfig"/>.	The client can then retrieve protected resource metadata as described in <xref target="PRConfig"/>.
	The client might then, for instance, determine what authorization server to use for the resource	The client might then, for instance, determine what authorization server to use for the resource
	based on protected resource metadata retrieved.	based on protected resource metadata retrieved.
	</t>	</t>
	<t>	<t>
	A typical end-to-end flow doing so is as follows.	A typical end-to-end flow doing so is as follows.

	Note that while this example uses the OAuth 2.0 Authorization Code flow,	Note that while this example uses the OAuth 2.0 authorization code flow,
	a similar sequence could also be implemented with any other OAuth flow.	a similar sequence could also be implemented with any other OAuth flow.
	</t>	</t>

		<figure>
	<!--	<name>Sequence Diagram</name>
	Diagram Source:	<artset>
	https://www.websequencediagrams.com/?lz=cGFydGljaXBhbnQgQ2xpZW50CgAH	<artwork type="svg" name="sequence.svg">
	DCJSZXNvdXJjZVxuU2VydmVyIiBhcyBSUwAXDkF1dGhvcml6YXRpb24AHQ1BUwoKAFEGLT5SUzogMS4g	<svg xmlns="http://www.w3.org/2000/svg" baseProfile="tiny
	AEoIIFJlcXVlc3RcbldpdGhvdXQgQWNjZXNzIFRva2VuClJTLS0-AIEMBjogMi4gV1dXLUF1dGhlbnRp	" height="550" version="1.2" viewBox="0 0 478 550" width="478">
	Y2F0ZQBKDTMuIEZldGNoIFJTIE1ldGFkYXRhADQONC4AEAwgUmVzcG9uc2UKbm90ZSBvdmVyAIF3Bzog	<path d="M-252,-405.0000000000001 L-252,0" fill="none" stroke="bla
	NS4gVmFsaWRhdGUAQwwsXG5CdWlsZCBBADwLVVJMAIFWCUFTOiA2AIEACAAaCwpBAIE-DDcuADQNAG8Z	ck" stroke-width="1" transform="translate(350.5 468.5)"/>
	LCBBUzogOC05LiBPQXV0aCAAglcNIEZsb3dcbgCDKwYgT2J0YWlucwCCMg4AgmkNMACCYxR3aXRoAIJZ	<rect fill="white" height="48" stroke="black" stroke-width="1" wid
	GzEAgx4OAIIpBw&s=default	th="62" x="67.5" y="15.5"/>
	-->	<text fill="black" font-family="sans-serif" font-size="13.33333333
	<t>	3333334" x="79.23567708333343" y="44.791666666666536">
	<figure>
	<name>Sequence Diagram</name>
	<artset>
	<artwork type="svg" name="sequence.svg">
	<svg baseProfile="tiny" height="550" version="1.2" viewBo
	x="0 0 478 550" width="478" xmlns="http://www.w3.org/2000/svg">
	<path d="M-252,-405.0000000000001 L-252,0" fill="none"
	stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
	<rect fill="white" height="48" stroke="black" stroke-wi
	dth="1" width="62" x="67.5" y="15.5"/>
	<text fill="black" font-family="sans-serif" font-size="
	13.333333333333334" x="79.23567708333343" y="44.791666666666536">
	Client </text>	Client </text>

	<rect fill="white" height="48" stroke="black" stroke-wi	<rect fill="white" height="48" stroke="black" stroke-width="1" wid
	dth="1" width="62" x="67.5" y="468.5"/>	th="62" x="67.5" y="468.5"/>
	<text fill="black" font-family="sans-serif" font-size="	<text fill="black" font-family="sans-serif" font-size="13.33333333
	13.333333333333334" x="79.23567708333343" y="497.35416666666663">	3333334" x="79.23567708333343" y="497.35416666666663">
	Client </text>	Client </text>

	<path d="M-53,-405.00000000000017 L-53,0" fill="none" s	<path d="M-53,-405.00000000000017 L-53,0" fill="none" stroke="blac
	troke="black" stroke-width="1" transform="translate(350.5 468.5)"/>	k" stroke-width="1" transform="translate(350.5 468.5)"/>
	<rect fill="white" height="48" stroke="black" stroke-wi	<rect fill="white" height="48" stroke="black" stroke-width="1" wid
	dth="1" width="85" x="255.5" y="15.5"/>	th="85" x="255.5" y="15.5"/>
	<text fill="black" font-family="sans-serif" font-size="	<text fill="black" font-family="sans-serif" font-size="13.33333333
	13.333333333333334" x="266.95833333333337" y="37.03124999999985">	3333334" x="266.95833333333337" y="37.03124999999985">
	Resource </text>	Resource </text>

	<text fill="black" font-family="sans-serif" font-size=" 13.333333333333334" x="276.11523437500006" y="52.552083333333165">	<text fill="black" font-family="sans-serif" font-size="13.33333333 3333334" x="276.11523437500006" y="52.552083333333165">
	Server </text>	Server </text>

	<rect fill="white" height="48" stroke="black" stroke-wi	<rect fill="white" height="48" stroke="black" stroke-width="1" wid
	dth="1" width="85" x="255.5" y="468.5"/>	th="85" x="255.5" y="468.5"/>
	<text fill="black" font-family="sans-serif" font-size="	<text fill="black" font-family="sans-serif" font-size="13.33333333
	13.333333333333334" x="266.95833333333337" y="489.59375">	3333334" x="266.95833333333337" y="489.59375">
	Resource </text>	Resource </text>

	<text fill="black" font-family="sans-serif" font-size=" 13.333333333333334" x="276.11523437500006" y="505.1145833333333">	<text fill="black" font-family="sans-serif" font-size="13.33333333 3333334" x="276.11523437500006" y="505.1145833333333">
	Server </text>	Server </text>

	<path d="M56,-405.00000000000017 L56,0" fill="none" str	<path d="M56,-405.00000000000017 L56,0" fill="none" stroke="black"
	oke="black" stroke-width="1" transform="translate(350.5 468.5)"/>	stroke-width="1" transform="translate(350.5 468.5)"/>
	<rect fill="white" height="48" stroke="black" stroke-wi	<rect fill="white" height="48" stroke="black" stroke-width="1" wid
	dth="1" width="112" x="350.5" y="15.5"/>	th="112" x="350.5" y="15.5"/>
	<text fill="black" font-family="sans-serif" font-size="	<text fill="black" font-family="sans-serif" font-size="13.33333333
	13.333333333333334" x="362.00390625" y="37.03124999999985">	3333334" x="362.00390625" y="37.03124999999985">
	Authorization </text>	Authorization </text>

	<text fill="black" font-family="sans-serif" font-size=" 13.333333333333334" x="384.7936197916667" y="52.552083333333165">	<text fill="black" font-family="sans-serif" font-size="13.33333333 3333334" x="384.7936197916667" y="52.552083333333165">
	Server </text>	Server </text>

	<rect fill="white" height="48" stroke="black" stroke-wi	<rect fill="white" height="48" stroke="black" stroke-width="1" wid
	dth="1" width="112" x="350.5" y="468.5"/>	th="112" x="350.5" y="468.5"/>
	<text fill="black" font-family="sans-serif" font-size="	<text fill="black" font-family="sans-serif" font-size="13.33333333
	13.333333333333334" x="362.00390625" y="489.59375">	3333334" x="362.00390625" y="489.59375">
	Authorization </text>	Authorization </text>

	<text fill="black" font-family="sans-serif" font-size=" 13.333333333333334" x="384.7936197916667" y="505.1145833333333">	<text fill="black" font-family="sans-serif" font-size="13.33333333 3333334" x="384.7936197916667" y="505.1145833333333">
	Server </text>	Server </text>

	<rect fill="white" height="15.333333333333314" width="1	<rect fill="white" height="15.333333333333314" width="137.99479166
	37.99479166666669" x="129.25911458333337" y="76.8333333333332"/>	666669" x="129.25911458333337" y="76.8333333333332"/>
	<rect fill="white" height="15.333333333333314" width="1	<rect fill="white" height="15.333333333333314" width="147.43489583
	47.43489583333334" x="124.53906250000003" y="92.35416666666652"/>	333334" x="124.53906250000003" y="92.35416666666652"/>
	<text fill="black" font-family="sans-serif" font-size="	<text fill="black" font-family="sans-serif" font-size="13.33333333
	13.333333333333334" x="129.25911458333337" y="90.16666666666653">	3333334" x="129.25911458333337" y="90.16666666666653">
	1. Resource Request </text>	1. Resource Request </text>

	<text fill="black" font-family="sans-serif" font-size=" 13.333333333333334" x="124.53906250000003" y="105.68749999999984">	<text fill="black" font-family="sans-serif" font-size="13.33333333 3333334" x="124.53906250000003" y="105.68749999999984">
	Without Access Token </text>	Without Access Token </text>

	<path d="M-251.4641927083333,-360 L-53.02278645833337,-	<path d="M-251.4641927083333,-360 L-53.02278645833337,-360" fill="
	360" fill="none" stroke="black" stroke-width="1" transform="translate(350.5 468.	none" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
	5)"/>	<path d="M-54,-360 L-54,-360 L-62,-368 L-62,-360 L-62,-352 L-54,-3
	<path d="M-54,-360 L-54,-360 L-62,-368 L-62,-360 L-62,-	60" fill="black" stroke="black" stroke-width="1" transform="translate(350.5 468.
	352 L-54,-360" fill="black" stroke="black" stroke-width="1" transform="translate	5)"/>
	(350.5 468.5)"/>	<rect fill="white" height="15.333333333333314" width="147.08984375
	<rect fill="white" height="15.333333333333314" width="1	" x="124.71158854166669" y="122.2083333333332"/>
	47.08984375" x="124.71158854166669" y="122.2083333333332"/>	<text fill="black" font-family="sans-serif" font-size="13.33333333
	<text fill="black" font-family="sans-serif" font-size="	3333334" x="124.71158854166669" y="135.54166666666654">
	13.333333333333334" x="124.71158854166669" y="135.54166666666654">
	2. WWW-Authenticate </text>	2. WWW-Authenticate </text>

	<path d="M-251.4641927083333,-330 L-53.022786458333314,	<path d="M-251.4641927083333,-330 L-53.022786458333314,-330" fill=
	-330" fill="none" stroke="black" stroke-dasharray="5,3" stroke-width="1" transfo	"none" stroke="black" stroke-dasharray="5,3" stroke-width="1" transform="transla
	rm="translate(350.5 468.5)"/>	te(350.5 468.5)"/>
	<path d="M-251,-330 L-251,-330 L-243,-338 L-243,-330 L-	<path d="M-251,-330 L-251,-330 L-243,-338 L-243,-330 L-243,-322 L-
	243,-322 L-251,-330" fill="black" stroke="black" stroke-width="1" transform="tra	251,-330" fill="black" stroke="black" stroke-width="1" transform="translate(350.
	nslate(350.5 468.5)"/>	5 468.5)"/>
	<rect fill="white" height="15.333333333333314" width="1	<rect fill="white" height="15.333333333333314" width="143.18359375
	43.18359375" x="126.66471354166669" y="152.0624999999999"/>	" x="126.66471354166669" y="152.0624999999999"/>
	<text fill="black" font-family="sans-serif" font-size="	<text fill="black" font-family="sans-serif" font-size="13.33333333
	13.333333333333334" x="126.66471354166669" y="165.39583333333323">	3333334" x="126.66471354166669" y="165.39583333333323">
	3. Fetch RS Metadata </text>	3. Fetch RS Metadata </text>

	<path d="M-251.4641927083333,-300 L-53.022786458333314,	<path d="M-251.4641927083333,-300 L-53.022786458333314,-300" fill=
	-300" fill="none" stroke="black" stroke-width="1" transform="translate(350.5 468	"none" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
	.5)"/>	<path d="M-54,-300 L-54,-300 L-62,-308 L-62,-300 L-62,-292 L-54,-3
	<path d="M-54,-300 L-54,-300 L-62,-308 L-62,-300 L-62,-	00" fill="black" stroke="black" stroke-width="1" transform="translate(350.5 468.
	292 L-54,-300" fill="black" stroke="black" stroke-width="1" transform="translate	5)"/>
	(350.5 468.5)"/>	<rect fill="white" height="15.333333333333314" width="170.93750000
	<rect fill="white" height="15.333333333333314" width="1	000003" x="112.78776041666671" y="181.91666666666657"/>
	70.93750000000003" x="112.78776041666671" y="181.91666666666657"/>	<text fill="black" font-family="sans-serif" font-size="13.33333333
	<text fill="black" font-family="sans-serif" font-size="	3333334" x="112.78776041666671" y="195.24999999999991">
	13.333333333333334" x="112.78776041666671" y="195.24999999999991">
	4. RS Metadata Response </text>	4. RS Metadata Response </text>

	<path d="M-251.4641927083333,-270 L-53.02278645833326,-	<path d="M-251.4641927083333,-270 L-53.02278645833326,-270" fill="
	270" fill="none" stroke="black" stroke-dasharray="5,3" stroke-width="1" transfor	none" stroke="black" stroke-dasharray="5,3" stroke-width="1" transform="translat
	m="translate(350.5 468.5)"/>	e(350.5 468.5)"/>
	<path d="M-251,-270 L-251,-270 L-243,-278 L-243,-270 L-	<path d="M-251,-270 L-251,-270 L-243,-278 L-243,-270 L-243,-262 L-
	243,-262 L-251,-270" fill="black" stroke="black" stroke-width="1" transform="tra	251,-270" fill="black" stroke="black" stroke-width="1" transform="translate(350.
	nslate(350.5 468.5)"/>	5 468.5)"/>
	<path d="M-340,-257 L-340,-257 L-172,-257 L-164,-249 L-	<path d="M-340,-257 L-340,-257 L-172,-257 L-164,-249 L-164,-209 L-
	164,-209 L-340,-209 L-340,-257" fill="white" stroke="black" stroke-width="1" tra	340,-209 L-340,-257" fill="white" stroke="black" stroke-width="1" transform="tra
	nsform="translate(350.5 468.5)"/>	nslate(350.5 468.5)"/>
	<path d="M-171.5592447916666,-256.72916666666674 L-171.	<path d="M-171.5592447916666,-256.72916666666674 L-171.55924479166
	5592447916666,-248.72916666666674 L-163.5592447916666,-248.72916666666674" fill=	66,-248.72916666666674 L-163.5592447916666,-248.72916666666674" fill="none" stro
	"none" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>	ke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
	<text fill="black" font-family="sans-serif" font-size="	<text fill="black" font-family="sans-serif" font-size="13.33333333
	13.333333333333334" x="15.882812500000057" y="232.86458333333326">	3333334" x="15.882812500000057" y="232.86458333333326">
	5. Validate RS Metadata, </text>	5. Validate RS Metadata, </text>

	<text fill="black" font-family="sans-serif" font-size=" 13.333333333333334" x="15.882812500000057" y="248.3854166666666">	<text fill="black" font-family="sans-serif" font-size="13.33333333 3333334" x="15.882812500000057" y="248.3854166666666">
	Build AS Metadata URL </text>	Build AS Metadata URL </text>

	<rect fill="white" height="15.333333333333371" width="1	<rect fill="white" height="15.333333333333371" width="143.04036458
	43.04036458333337" x="181.07552083333337" y="272.66666666666663"/>	333337" x="181.07552083333337" y="272.66666666666663"/>
	<text fill="black" font-family="sans-serif" font-size="	<text fill="black" font-family="sans-serif" font-size="13.33333333
	13.333333333333334" x="181.07552083333337" y="285.99999999999994">	3333334" x="181.07552083333337" y="285.99999999999994">
	6. Fetch AS Metadata </text>	6. Fetch AS Metadata </text>

	<path d="M-251.46419270833326,-179 L55.65559895833337,-	<path d="M-251.46419270833326,-179 L55.65559895833337,-179" fill="
	179" fill="none" stroke="black" stroke-width="1" transform="translate(350.5 468.	none" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
	5)"/>	<path d="M55,-179 L55,-179 L47,-187 L47,-179 L47,-171 L55,-179" fi
	<path d="M55,-179 L55,-179 L47,-187 L47,-179 L47,-171 L	ll="black" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
	55,-179" fill="black" stroke="black" stroke-width="1" transform="translate(350.5	<rect fill="white" height="15.333333333333314" width="170.79427083
	468.5)"/>	333337" x="167.19856770833337" y="302.5208333333333"/>
	<rect fill="white" height="15.333333333333314" width="1	<text fill="black" font-family="sans-serif" font-size="13.33333333
	70.79427083333337" x="167.19856770833337" y="302.5208333333333"/>	3333334" x="167.19856770833337" y="315.85416666666663">
	<text fill="black" font-family="sans-serif" font-size="
	13.333333333333334" x="167.19856770833337" y="315.85416666666663">
	7. AS Metadata Response </text>	7. AS Metadata Response </text>

	<path d="M-251.46419270833326,-149 L55.65559895833337,-	<path d="M-251.46419270833326,-149 L55.65559895833337,-149" fill="
	149" fill="none" stroke="black" stroke-dasharray="5,3" stroke-width="1" transfor	none" stroke="black" stroke-dasharray="5,3" stroke-width="1" transform="translat
	m="translate(350.5 468.5)"/>	e(350.5 468.5)"/>
	<path d="M-251,-149 L-251,-149 L-243,-157 L-243,-149 L-	<path d="M-251,-149 L-251,-149 L-243,-157 L-243,-149 L-243,-141 L-
	243,-141 L-251,-149" fill="black" stroke="black" stroke-width="1" transform="tra	251,-149" fill="black" stroke="black" stroke-width="1" transform="translate(350.
	nslate(350.5 468.5)"/>	5 468.5)"/>
	<path d="M-257,-136 L-257,-136 L54,-136 L62,-128 L62,-8	<path d="M-257,-136 L-257,-136 L54,-136 L62,-128 L62,-89 L-257,-89
	9 L-257,-89 L-257,-136" fill="white" stroke="black" stroke-width="1" transform="	L-257,-136" fill="white" stroke="black" stroke-width="1" transform="translate(3
	translate(350.5 468.5)"/>	50.5 468.5)"/>
	<path d="M53.65559895833337,-136.125 L53.65559895833337	<path d="M53.65559895833337,-136.125 L53.65559895833337,-128.125 L
	,-128.125 L61.65559895833337,-128.125" fill="none" stroke="black" stroke-width="	61.65559895833337,-128.125" fill="none" stroke="black" stroke-width="1" transfor
	1" transform="translate(350.5 468.5)"/>	m="translate(350.5 468.5)"/>
	<text fill="black" font-family="sans-serif" font-size="	<text fill="black" font-family="sans-serif" font-size="13.33333333
	13.333333333333334" x="152.48828125000006" y="353.46874999999994">	3333334" x="152.48828125000006" y="353.46874999999994">
	8-9. OAuth Authorization Flow </text>	8-9. OAuth Authorization Flow </text>

	<text fill="black" font-family="sans-serif" font-size=" 13.333333333333334" x="152.48828125000006" y="368.9895833333333">	<text fill="black" font-family="sans-serif" font-size="13.33333333 3333334" x="152.48828125000006" y="368.9895833333333">
	Client Obtains Access Token </text>	Client Obtains Access Token </text>

	<rect fill="white" height="15.333333333333314" width="1	<rect fill="white" height="15.333333333333314" width="146.47786458
	46.47786458333331" x="125.01757812500006" y="393.2708333333333"/>	333331" x="125.01757812500006" y="393.2708333333333"/>
	<rect fill="white" height="15.333333333333371" width="1	<rect fill="white" height="15.333333333333371" width="123.32031250
	23.32031250000003" x="136.5963541666667" y="408.79166666666663"/>	000003" x="136.5963541666667" y="408.79166666666663"/>
	<text fill="black" font-family="sans-serif" font-size="	<text fill="black" font-family="sans-serif" font-size="13.33333333
	13.333333333333334" x="125.01757812500006" y="406.60416666666663">	3333334" x="125.01757812500006" y="406.60416666666663">
	10. Resource Request </text>	10. Resource Request </text>

	<text fill="black" font-family="sans-serif" font-size="	<text fill="black" font-family="sans-serif" font-size="13.33333333
	13.333333333333334" x="136.5963541666667" y="422.12499999999994">	3333334" x="136.5963541666667" y="422.12499999999994">
	with Access Token </text>	With Access Token </text>
	<path d="M-251.46419270833326,-43 L-53.02278645833326,-	<path d="M-251.46419270833326,-43 L-53.02278645833326,-43" fill="n
	43" fill="none" stroke="black" stroke-width="1" transform="translate(350.5 468.5	one" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
	)"/>	<path d="M-54,-43 L-54,-43 L-62,-51 L-62,-43 L-62,-35 L-54,-43" fi
	<path d="M-54,-43 L-54,-43 L-62,-51 L-62,-43 L-62,-35 L	ll="black" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
	-54,-43" fill="black" stroke="black" stroke-width="1" transform="translate(350.5	<rect fill="white" height="15.333333333333371" width="156.35416666
	468.5)"/>	666669" x="120.07942708333337" y="438.6458333333333"/>
	<rect fill="white" height="15.333333333333371" width="1	<text fill="black" font-family="sans-serif" font-size="13.33333333
	56.35416666666669" x="120.07942708333337" y="438.6458333333333"/>	3333334" x="120.07942708333337" y="451.97916666666663">
	<text fill="black" font-family="sans-serif" font-size="
	13.333333333333334" x="120.07942708333337" y="451.97916666666663">
	11. Resource Response </text>	11. Resource Response </text>

	<path d="M-251.46419270833326,-13 L-53.022786458333314,	<path d="M-251.46419270833326,-13 L-53.022786458333314,-13" fill="
	-13" fill="none" stroke="black" stroke-dasharray="5,3" stroke-width="1" transfor	none" stroke="black" stroke-dasharray="5,3" stroke-width="1" transform="translat
	m="translate(350.5 468.5)"/>	e(350.5 468.5)"/>
	<path d="M-251,-13 L-251,-13 L-243,-21 L-243,-13 L-243,	<path d="M-251,-13 L-251,-13 L-243,-21 L-243,-13 L-243,-5 L-251,-1
	-5 L-251,-13" fill="black" stroke="black" stroke-width="1" transform="translate(	3" fill="black" stroke="black" stroke-width="1" transform="translate(350.5 468.5
	350.5 468.5)"/>	)"/>
	</svg>	</svg>
		</artwork>
	</artwork>	<artwork type="ascii-art" name="sequence.txt"><![CDATA[
	<artwork type="ascii-art" name="sequence.txt"><![CDATA[
	+----------+ +----------+ +---------------+	+----------+ +----------+ +---------------+
	\| Client \| \| Resource \| \| Authorization \|	\| Client \| \| Resource \| \| Authorization \|
	\| \| \| Server \| \| Server \|	\| \| \| Server \| \| Server \|
	+----+-----+ +----+-----+ +-------+-------+	+----+-----+ +----+-----+ +-------+-------+
	\| \| \|	\| \| \|
	\| 1. Resource Request \| \|	\| 1. Resource Request \| \|
	\| ----------------------> \| \|	\| ----------------------> \| \|
	\| Without Access Token \| \|	\| Without Access Token \| \|
	\| \| \|	\| \| \|
	\| \| \|	\| \| \|

	skipping to change at line 828 ¶	skipping to change at line 769 ¶
	+-+-------------------------+------------------+-+	+-+-------------------------+------------------+-+
	\| \| \|	\| \| \|
	\| 10. Resource Request \| \|	\| 10. Resource Request \| \|
	\| ----------------------> \| \|	\| ----------------------> \| \|
	\| With Access Token \| \|	\| With Access Token \| \|
	\| \| \|	\| \| \|
	\| \| \|	\| \| \|
	\| 11. Resource Response \| \|	\| 11. Resource Response \| \|
	\| <---------------------- \| \|	\| <---------------------- \| \|
	\| \| \|	\| \| \|

		+----+-----+ +----+-----+ +-------+-------+
		\| Client \| \| Resource \| \| Authorization \|
		\| \| \| Server \| \| Server \|
		+----------+ +----------+ +---------------+
	]]></artwork>	]]></artwork>

	</artset>	</artset>
	</figure>	</figure>
		<ol spacing="normal" type="1"><li>
	</t>	<t>
	<t>
	<list style="numbers">
	<t>
	The client makes a request to a protected resource without presenting an access token.	The client makes a request to a protected resource without presenting an access token.

	</t>	</t>
	<t>	</li>
	The resource server responds with a <spanx style="verb">WWW-Authentic	<li>
	ate</spanx> header including the URL of the protected resource metadata.	<t>
	</t>	The resource server responds with a <tt>WWW-Authenticate</tt> header
	<t>	including the URL of the protected resource metadata.
		</t>
		</li>
		<li>
		<t>
	The client fetches the protected resource metadata from this URL.	The client fetches the protected resource metadata from this URL.

	</t>	</t>
	<t>	</li>
		<li>
		<t>
	The resource server responds with the protected resource metadata	The resource server responds with the protected resource metadata
	according to <xref target="PRConfigurationResponse"/>.	according to <xref target="PRConfigurationResponse"/>.

	</t>	</t>
	<t>	</li>
		<li>
		<t>
	The client validates the protected resource metadata,	The client validates the protected resource metadata,

	as described in <xref target="PRConfigurationValidation"/>.	as described in <xref target="PRConfigurationValidation"/>,
	</t>	and builds the authorization server metadata URL from an issuer
	<t>	identifier in the resource metadata according to <xref target="RFC84
	The client builds the authorization server metadata URL from an issue	14"/>.
	r identifier in the resource metadata according to <xref target="RFC8414"/>	</t>
	and makes a request to fetch the authorization server metadata.	</li>
	</t>	<li>
	<t>	<t>
		The client makes a request to fetch the authorization server metadata
		.
		</t>
		</li>
		<li>
		<t>
	The authorization server responds with the authorization server metad ata document according to <xref target="RFC8414"/>.	The authorization server responds with the authorization server metad ata document according to <xref target="RFC8414"/>.

	</t>	</t>
	<t>	</li>
		<li>
		<t>
	The client directs the user agent to the authorization server to begi n the authorization flow.	The client directs the user agent to the authorization server to begi n the authorization flow.

	</t>	</t>
	<t>	</li>
		<li>
		<t>
	The authorization exchange is completed and the authorization server returns an access token to the client.	The authorization exchange is completed and the authorization server returns an access token to the client.

	</t>	</t>
	<t>	</li>
		<li>
		<t>
	The client repeats the resource request from step 1, presenting the n ewly obtained access token.	The client repeats the resource request from step 1, presenting the n ewly obtained access token.

	</t>	</t>
	<t>	</li>
		<li>
		<t>
	The resource server returns the requested protected resource.	The resource server returns the requested protected resource.

	</t>	</t>
	</list>	</li>
	</t>	</ol>
		<section anchor="WWW-Authenticate-Response">
	<section anchor="WWW-Authenticate-Response" title="WWW-Authenticate Respon	<name>WWW-Authenticate Response</name>
	se">	<t>
	<t>
	This specification introduces a new parameter in the	This specification introduces a new parameter in the

	<spanx style="verb">WWW-Authenticate</spanx> HTTP response header field	<tt>WWW-Authenticate</tt> HTTP response header field
	to indicate the protected resource metadata URL:	to indicate the protected resource metadata URL:

	<list style='hanging'>	</t>
	<t hangText='resource_metadata:'>	<dl newline="true" spacing="normal">
	<vspace/>	<dt>resource_metadata:</dt>
		<dd>
	The URL of the protected resource metadata.	The URL of the protected resource metadata.

	</t>	</dd>
	</list>	</dl>
	</t>	<t keepWithNext="true">The response below is an example of a <tt>WWW-Aut
	<t>	henticate</tt> header that includes the resource identifier.</t>
	<figure>	<sourcecode type="http-message"><![CDATA[
	<preamble>The response below is an example of a <spanx style="verb">W	HTTP/1.1 401 Unauthorized
	WW-Authenticate</spanx> header that includes the resource identifier.</preamble>	WWW-Authenticate: Bearer resource_metadata=
		"https://resource.example.com/.well-known/oauth-protected-resource"
	<artwork><![CDATA[	]]></sourcecode>
	HTTP/1.1 400 Bad Request	<t>
	WWW-Authenticate: Bearer error="invalid_request",	The HTTP status code in the example response above
	error_description="No access token was provided in this request",	is defined by <xref target="RFC6750"/>.
	resource_metadata=	</t>
	"https://resource.example.com/.well-known/oauth-protected-resource"	<t>
	]]></artwork>	This parameter <bcp14>MAY</bcp14> also be used in
	</figure>	<tt>WWW-Authenticate</tt> responses using
	</t>	<tt>authorization</tt> schemes other than
	<t>	<tt>"Bearer"</tt> <xref target="RFC6750"/>,
	The HTTP status code and error string in the example response above	such as the <tt>DPoP</tt> scheme
	are defined by <xref target="RFC6750"/>.
	</t>
	<t>
	This parameter MAY also be used in
	<spanx style="verb">WWW-Authenticate</spanx> responses using
	<spanx style="verb">Authorization</spanx> schemes other than
	<spanx style="verb">Bearer</spanx> <xref target="RFC6750"/>,
	such as the <spanx style="verb">DPoP</spanx> scheme
	defined by <xref target="RFC9449"/>.	defined by <xref target="RFC9449"/>.

	</t>	</t>
	<t>	<t>
	The <spanx style="verb">resource_metadata</spanx> parameter MAY be comb	The <tt>resource_metadata</tt> parameter <bcp14>MAY</bcp14> be combined
	ined with other parameters defined in other extensions,	with other parameters defined in other extensions,
	such as the <spanx style="verb">max_age</spanx> parameter defined by <x	such as the <tt>max_age</tt> parameter defined by <xref target="RFC9470
	ref target="RFC9470"/>.	"/>.
	</t>	</t>
	</section>	</section>

		<section anchor="changes">
	<section anchor="changes" title="Changes to Resource Metadata">	<name>Changes to Resource Metadata</name>
	<t>	<t>
	At any point, for any reason determined by the resource server,	At any point, for any reason determined by the resource server,

	the protected resource MAY respond with a new <spanx style="verb">WWW-A uthenticate</spanx> challenge	the protected resource <bcp14>MAY</bcp14> respond with a new <tt>WWW-Au thenticate</tt> challenge
	that includes a value for the protected resource metadata URL to indica te that its metadata may have changed.	that includes a value for the protected resource metadata URL to indica te that its metadata may have changed.

	If the client receives such a <spanx style="verb">WWW-Authenticate</spa	If the client receives such a <tt>WWW-Authenticate</tt> response,
	nx> response,	it <bcp14>SHOULD</bcp14> retrieve the updated protected resource metada
	it SHOULD retrieve the updated protected resource metadata	ta
	and use the new metadata values obtained, after validating them	and use the new metadata values obtained, after validating them
	as described in <xref target="PRConfigurationValidation"/>.	as described in <xref target="PRConfigurationValidation"/>.
	Among other things,	Among other things,
	this enables a resource server to change which authorization servers it uses without any other coordination with clients.	this enables a resource server to change which authorization servers it uses without any other coordination with clients.

	</t>	</t>
	</section>	</section>

		<section anchor="assumptions">
		<name>Client Identifier and Client Authentication</name>
		<t>
		The way in which the client identifier is established at the authorizat
		ion server is out of scope for this specification.
		</t>
		<t>


	<section anchor="assumptions" title="Client Identifier and Client Authenti	This specification is intended to be deployed in scenarios where the cl
	cation">	ient has no prior knowledge about the resource server
	<t>	and where the resource server might or might not have prior knowledge a
	The way in which the client identifier is established at the authorizat	bout the client.
	ion server is out of scope of this specification.	</t>
	</t>	<t>
	<t>
	This specification is intended to be deployed in scenarios where the cl
	ient has no prior knowledge about the resource server,
	and the resource server might or might not have prior knowledge about t
	he client.
	</t>
	<t>
	There are some existing methods by which an unrecognized client can mak e use of an authorization server,	There are some existing methods by which an unrecognized client can mak e use of an authorization server,
	such as using Dynamic Client Registration <xref target="RFC7591"/>	such as using Dynamic Client Registration <xref target="RFC7591"/>
	to register the client prior to initiating the authorization flow.	to register the client prior to initiating the authorization flow.
	Future OAuth extensions might define alternatives, such as using URLs t o identify clients.	Future OAuth extensions might define alternatives, such as using URLs t o identify clients.

	</t>	</t>
	</section>	</section>

		<section anchor="compatibility">
	<section anchor="compatibility" title="Compatibility with Other Authentica	<name>Compatibility with Other Authentication Methods</name>
	tion Methods">	<t>
	<t>	Resource servers <bcp14>MAY</bcp14> return other <tt>WWW-Authenticate</
	Resource servers MAY return other <spanx style="verb">WWW-Authenticate<	tt> headers indicating various authentication schemes.
	/spanx> headers indicating various authentication schemes.	This allows the resource server to support clients that may or may not
	This allows the resource server to support clients that may or may not	implement this specification
	implement this specification,
	and allows clients to choose their preferred authentication scheme.	and allows clients to choose their preferred authentication scheme.

	</t>	</t>
	</section>	</section>


	</section>	</section>

		<section anchor="StringOps">
	<section anchor="StringOps" title="String Operations">	<name>String Operations</name>

	<t>	<t>
	Processing some OAuth 2.0 messages requires comparing	Processing some OAuth 2.0 messages requires comparing
	values in the messages to known values. For example, the	values in the messages to known values. For example, the
	member names in the metadata response might be	member names in the metadata response might be

	compared to specific member names such as <spanx	compared to specific member names such as <tt>resource</tt>. Comparing U
	style="verb">resource</spanx>. Comparing Unicode <xref target="UNICODE"/	nicode strings <xref target="UNICODE"/>,
	> strings,
	however, has significant security implications.	however, has significant security implications.
	</t>	</t>
	<t>	<t>
	Therefore, comparisons between JSON strings and other Unicode	Therefore, comparisons between JSON strings and other Unicode

	strings MUST be performed as specified below:	strings <bcp14>MUST</bcp14> be performed as specified below:

	<list style="numbers">


		</t>
		<ol spacing="normal" type="1"><li>
	<t>	<t>

	Remove any JSON applied escaping to produce an array of	Remove any JSON-applied escaping to produce an array of
	Unicode code points.	Unicode code points.

	</t>	</t>
		</li>
		<li>
	<t>	<t>

	Unicode Normalization <xref target="USA15"/> MUST NOT	Unicode Normalization <xref target="USA15"/> <bcp14>MUST NOT</bcp14>
	be applied at any point to either the JSON string or to	be applied at any point to either the JSON string or
	the string it is to be compared against.	the string it is to be compared against.

	</t>	</t>
		</li>
		<li>
	<t>	<t>

	Comparisons between the two strings MUST be performed as a	Comparisons between the two strings <bcp14>MUST</bcp14> be performed
	Unicode code point to code point equality comparison.	as a
	</t>	Unicode code-point-to-code-point equality comparison.
		</t>
	</list>	</li>
	</t>	</ol>
	<t>	<t>

	Note that this is the same equality comparison procedure described in	Note that this is the same equality comparison procedure as that describe
	Section 8.3 of <xref target="RFC8259"/>.	d in
		<xref section="8.3" sectionFormat="of" target="RFC8259"/>.
	</t>	</t>


	</section>	</section>

		<section anchor="Security">
	<section anchor="Security" title="Security Considerations">	<name>Security Considerations</name>
		<section anchor="TLSRequirements">
	<section anchor="TLSRequirements" title="TLS Requirements">	<name>TLS Requirements</name>
	<t>	<t>
	Implementations MUST support TLS.	Implementations <bcp14>MUST</bcp14> support TLS.
	They MUST follow the guidance in	They <bcp14>MUST</bcp14> follow the guidance in
	BCP 195 <xref target="RFC8996"/> <xref target="RFC9325"/>,	<xref target="BCP195"/>,
	which provides recommendations and requirements	which provides recommendations and requirements
	for improving the security of deployed services that use TLS.	for improving the security of deployed services that use TLS.

	</t>	</t>
	<t>	<t>
	Use of TLS at the protected resource metadata URLs	The use of TLS at the protected resource metadata URLs
	protects against information disclosure and tampering.	protects against information disclosure and tampering.

	</t>	</t>
	</section>	</section>

		<section anchor="Scopes">
	<section anchor="Scopes" title="Scopes">	<name>Scopes</name>
	<t>	<t>
	The <spanx style="verb">scopes_supported<	The <tt>scopes_supported</tt> parameter i
	/spanx> parameter is the list of scopes the resource server is willing to disclo	s the list of scopes the resource server is willing to disclose that it supports
	se that it supports. It is not meant to indicate that an OAuth client should req	. It is not meant to indicate that an OAuth client should request all scopes in
	uest all scopes in the list. The client SHOULD still follow OAuth best practices	the list. The client <bcp14>SHOULD</bcp14> still follow OAuth best practices and
	and request tokens with as limited scope as possible for the given operation, a	request tokens with as limited a scope as possible for the given operation, as
	s described in Section 2.3 of OAuth 2.0 Security Best Current Practice <xref tar	described in
	get="I-D.ietf-oauth-security-topics"/>.	<xref section="2.3" sectionFormat="of" target="RFC9700">"Best Current Practice f
	</t>	or OAuth 2.0 Security"</xref>.
		</t>
	</section>	</section>

		<section anchor="Impersonation">
	<section anchor="Impersonation" title="Impersonation Attacks">	<name>Impersonation Attacks</name>
	<t>	<t>
	TLS certificate checking MUST be performed by the client	TLS certificate checking <bcp14>MUST</bcp14> be performed by the client
	as described in <xref target="RFC9525"/>	as described in <xref target="RFC9525"/>
	when making a protected resource metadata request.	when making a protected resource metadata request.
	Checking that the server certificate is valid for the resource identifi er URL	Checking that the server certificate is valid for the resource identifi er URL

	prevents man-in-middle and DNS-based attacks.	prevents adversary-in-the-middle and DNS-based attacks.
	These attacks could cause a client to be tricked into using an attacker 's	These attacks could cause a client to be tricked into using an attacker 's
	resource server, which would enable impersonation of the legitimate pro tected resource.	resource server, which would enable impersonation of the legitimate pro tected resource.
	If an attacker can accomplish this, they can access the resources	If an attacker can accomplish this, they can access the resources

	that the affected client has access to	that the affected client has access to,
	using the protected resource that they are impersonating.	using the protected resource that they are impersonating.

	</t>	</t>
	<t>	<t>
	An attacker may also attempt to impersonate a protected resource by pub lishing	An attacker may also attempt to impersonate a protected resource by pub lishing

	a metadata document that contains a <spanx style="verb">resource</spanx	a metadata document that contains a <tt>resource</tt> metadata paramete
	> metadata parameter	r
	using the resource identifier URL of the protected resource being imper	using the resource identifier URL of the protected resource being imper
	sonated,	sonated
	but containing information of the attacker's choosing.	but that contains information of the attacker's choosing.
	This would enable it to impersonate that protected resource, if accepte d by the client.	This would enable it to impersonate that protected resource, if accepte d by the client.

	To prevent this, the client MUST ensure that the resource identifier UR L it is using	To prevent this, the client <bcp14>MUST</bcp14> ensure that the resourc e identifier URL it is using
	as the prefix for the metadata request exactly matches the value of	as the prefix for the metadata request exactly matches the value of

	the <spanx style="verb">resource</spanx> metadata parameter	the <tt>resource</tt> metadata parameter
	in the protected resource metadata document received by the client,	in the protected resource metadata document received by the client,
	as described in <xref target="PRConfigurationValidation"/>.	as described in <xref target="PRConfigurationValidation"/>.

	</t>	</t>
	</section>	</section>

		<section anchor="AudienceRestriction">
	<section anchor="AudienceRestriction" title="Audience-Restricted Access To	<name>Audience-Restricted Access Tokens</name>
	kens">	<t>
	<t>
	If a client expects to interact with multiple resource servers, t he client	If a client expects to interact with multiple resource servers, t he client

	SHOULD request audience-restricted access tokens using <xref targ	<bcp14>SHOULD</bcp14> request audience-restricted access tokens u
	et="RFC8707"/>,	sing <xref target="RFC8707"/>,
	and the authorization server SHOULD support audience-restricted a	and the authorization server <bcp14>SHOULD</bcp14> support audien
	ccess tokens.	ce-restricted access tokens.
	</t>	</t>
	<t>	<t>
	Without audience-restricted access tokens, a malicious resource s erver (RS1) may be	Without audience-restricted access tokens, a malicious resource s erver (RS1) may be

	able to use the <spanx style="verb">WWW-Authenticate</spanx> head er to get a client	able to use the <tt>WWW-Authenticate</tt> header to get a client
	to request an access token with a scope used by a legitimate reso urce server (RS2), and	to request an access token with a scope used by a legitimate reso urce server (RS2), and

	after the client sends a request to RS1, then RS1 could re-use th	after the client sends a request to RS1, then RS1 could reuse the
	e access token at RS2.	access token at RS2.
	</t>	</t>
	<t>	<t>
	While this attack is not explicitly enabled by this specification	While this attack is not explicitly enabled by this specification
	, and is possible in	and is possible in
	a plain OAuth 2.0 deployment, it is made somewhat more likely by the use of	a plain OAuth 2.0 deployment, it is made somewhat more likely by the use of

	dynamically-configured clients. As such, the use	dynamically configured clients. As such, the use
	of audience-restricted access tokens and Resource Indicators <xre f target="RFC8707"/>	of audience-restricted access tokens and Resource Indicators <xre f target="RFC8707"/>

	is RECOMMENDED when using the features in this specification.	is <bcp14>RECOMMENDED</bcp14> when using the features in this spe
	</t>	cification.
		</t>
	</section>	</section>

		<section anchor="StandardFormat">
	<section anchor="StandardFormat" title="Publishing Metadata in a Standard	<name>Publishing Metadata in a Standard Format</name>
	Format">	<t>
	<t>
	Publishing information about the protected resource in a standard forma t	Publishing information about the protected resource in a standard forma t
	makes it easier for both legitimate clients and attackers	makes it easier for both legitimate clients and attackers
	to use the protected resource.	to use the protected resource.

	Whether a protected resource publishes its metadata in an ad-hoc manner	Whether a protected resource publishes its metadata in an ad hoc manner
	or in the standard format defined by this specification,	or in the standard format defined by this specification,
	the same defenses against attacks that might be mounted	the same defenses against attacks that might be mounted
	that use this information should be applied.	that use this information should be applied.

	</t>	</t>
	</section>	</section>

		<section anchor="AuthorizationServers">
	<section anchor="AuthorizationServers" title="Authorization Servers">	<name>Authorization Servers</name>
	<t>	<t>
	To support use cases in which the set of legitimate authorization serve rs	To support use cases in which the set of legitimate authorization serve rs
	to use with the protected resource is enumerable,	to use with the protected resource is enumerable,

	this specification defines the <spanx style="verb">authorization_server s</spanx>	this specification defines the <tt>authorization_servers</tt>
	metadata parameter, which enables explicitly listing them.	metadata parameter, which enables explicitly listing them.
	Note that if the set of legitimate protected resources	Note that if the set of legitimate protected resources
	to use with an authorization server is also enumerable,	to use with an authorization server is also enumerable,
	lists in the protected resource metadata and authorization server metad ata	lists in the protected resource metadata and authorization server metad ata
	should be cross-checked against one another for consistency	should be cross-checked against one another for consistency
	when these lists are used by the application profile.	when these lists are used by the application profile.

	</t>	</t>
	<t>	<t>
	Secure determination of appropriate authorization servers	Secure determination of appropriate authorization servers
	to use with a protected resource for all use cases	to use with a protected resource for all use cases

	is out of scope of this specification.	is out of scope for this specification.
	This specification assumes that the client has a means of determining	This specification assumes that the client has a means of determining
	appropriate authorization servers to use with a protected resource	appropriate authorization servers to use with a protected resource
	and that the client is using the correct metadata	and that the client is using the correct metadata
	for each protected resource.	for each protected resource.
	Implementers need to be aware that if an inappropriate authorization se rver	Implementers need to be aware that if an inappropriate authorization se rver

	is used by the client, that an attacker may be able to act as	is used by the client, an attacker may be able to act as
	a man-in-the-middle proxy to a valid authorization server without	an adversary-in-the-middle proxy to a valid authorization server withou
		t
	it being detected by the authorization server or the client.	it being detected by the authorization server or the client.

	</t>	</t>
	<t>	<t>
	The ways to determine the appropriate authorization servers to use	The ways to determine the appropriate authorization servers to use

	with a protected resource are in general, application-dependent.	with a protected resource are, in general, application dependent.
	For instance, some protected resources are used with	For instance, some protected resources are used with a
	a fixed authorization server or set of authorization servers,	fixed authorization server or a set of authorization servers,
	the locations of which may be well known,	the locations of which may be known via out-of-band mechanisms.
	or which could be published as metadata values by the protected resourc	Alternatively, as described in this specification, the locations
	e.	of the authorization servers could be published by the protected
		resource as metadata values.
	In other cases, the set of authorization servers that can be used with	In other cases, the set of authorization servers that can be used with

	a protected resource can by dynamically changed	a protected resource can be dynamically changed
	by administrative actions	by administrative actions
	or by changes to the set of authorization servers adhering to a trust f ramework.	or by changes to the set of authorization servers adhering to a trust f ramework.
	Many other means of determining appropriate associations between	Many other means of determining appropriate associations between
	protected resources and authorization servers are also possible.	protected resources and authorization servers are also possible.

	</t>	</t>
	</section>	</section>

		<section anchor="SSRF">
	<section anchor="SSRF" title="Server-Side Request Forgery (SSRF)">	<name>Server-Side Request Forgery (SSRF)</name>
	<t>	<t>
	The OAuth client is expected to fetch the	The OAuth client is expected to fetch the
	authorization server metadata based on the value of the issuer in the resource	authorization server metadata based on the value of the issuer in the resource
	server metadata. Since this specification enables clients to interoperate with R	server metadata. Since this specification enables clients to interoperate with R
	Ss and ASs it has no prior knowledge of, this opens a risk for SSRF attacks by m	Ss and ASes it has no prior knowledge of, this opens a risk for Server-Side Requ
	alicious users or malicious resource servers. Clients SHOULD take appropriate pr	est Forgery (SSRF) attacks by malicious users or malicious resource servers. Cli
	ecautions against SSRF attacks, such as blocking requests to internal IP address	ents <bcp14>SHOULD</bcp14> take appropriate precautions against SSRF attacks, su
	ranges. Further recommendations can be found in the OWASP SSRF Prevention Cheat	ch as blocking requests to internal IP address ranges. Further recommendations c
	Sheet <xref target="OWASP.SSRF"/>.	an be found in the Open Worldwide Application Security Project (OWASP) SSRF Prev
	</t>	ention Cheat Sheet <xref target="OWASP.SSRF"/>.
		</t>
	</section>	</section>

		<section anchor="phishing">
	<section anchor="phishing" title="Phishing">	<name>Phishing</name>
	<t>	<t>
	This specification may be deployed in a scenario where the desire d HTTP resource is identified by a user-selected URL. If this resource is malici ous or compromised, it could mislead the user into revealing their account crede ntials or authorizing unwanted access to OAuth-controlled capabilities. This ris k is reduced, but not eliminated, by following best practices for OAuth user int erfaces, such as providing clear notice to the user, displaying the authorizatio n server's domain name, supporting origin-bound phishing-resistant authenticator s, supporting the use of password managers, and applying heuristic checks such a s domain reputation.	This specification may be deployed in a scenario where the desire d HTTP resource is identified by a user-selected URL. If this resource is malici ous or compromised, it could mislead the user into revealing their account crede ntials or authorizing unwanted access to OAuth-controlled capabilities. This ris k is reduced, but not eliminated, by following best practices for OAuth user int erfaces, such as providing clear notice to the user, displaying the authorizatio n server's domain name, supporting origin-bound phishing-resistant authenticator s, supporting the use of password managers, and applying heuristic checks such a s domain reputation.

	</t>	</t>
	</section>	</section>

		<section anchor="UnsignedMetadata">
	<section anchor="UnsignedMetadata"	<name>Differences Between Unsigned and Signed Metadata</name>
	title="Differences between Unsigned and Signed Metadata">	<t>
	<t>	Unsigned metadata is integrity protected by the use of TLS at the site
	Unsigned metadata is integrity protected by use of TLS at the site
	where it is hosted.	where it is hosted.
	This means that its security is dependent upon the Internet	This means that its security is dependent upon the Internet

	Public Key Infrastructure (PKI) <xref target="RFC9525"/>.	Public Key Infrastructure using X.509 (PKIX), as described in <xref tar get="RFC9525"/>.
	Signed metadata is additionally integrity protected by the JWS signatur e	Signed metadata is additionally integrity protected by the JWS signatur e
	applied by the issuer, which is not dependent upon the Internet PKI.	applied by the issuer, which is not dependent upon the Internet PKI.

	</t>	</t>
	<t>	<t>
	When using unsigned metadata, the party issuing the metadata	When using unsigned metadata, the party issuing the metadata
	is the protected resource itself, which is represented by the	is the protected resource itself, which is represented by the

	<spanx style="verb">resource</spanx> value in the metadata.	<tt>resource</tt> value in the metadata,
	Whereas, when using signed metadata, the party issuing the metadata	whereas when using signed metadata, the party issuing the metadata
	is represented by the <spanx style="verb">iss</spanx> (issuer) claim	is represented by the <tt>iss</tt> (issuer) claim
	in the signed metadata.	in the signed metadata.
	When using signed metadata, applications can make trust decisions	When using signed metadata, applications can make trust decisions
	based on the issuer that performed the signing --	based on the issuer that performed the signing --
	information that is not available when using unsigned metadata.	information that is not available when using unsigned metadata.
	How these trust decisions are made is out of scope for this specificati on.	How these trust decisions are made is out of scope for this specificati on.

	</t>	</t>
	</section>	</section>

		<section anchor="caching">
	<section anchor="caching" title="Metadata Caching">	<name>Metadata Caching</name>
	<t>	<t>
	Protected resource metadata is retrieved using an HTTP	Protected resource metadata is retrieved using an HTTP

	<spanx style="verb">GET</spanx> request,	<tt>GET</tt> request,
	as specified in <xref target="PRConfigurationRequest"/>.	as specified in <xref target="PRConfigurationRequest"/>.

	Normal HTTP caching behaviors apply, meaning that the GET may retrieve	Normal HTTP caching behaviors apply, meaning that the <tt>GET</tt> requ est may retrieve
	a cached copy of the content, rather than the latest copy.	a cached copy of the content, rather than the latest copy.

	Implementations should utlize HTTP caching directives such as	Implementations should utilize HTTP caching directives such as
	<spanx style="verb">Cache-Control</spanx>	<tt>Cache-Control</tt>
	with <spanx style="verb">max-age</spanx>,	with <tt>max-age</tt>,
	as defined in <xref target="RFC7234"/>,	as defined in <xref target="RFC9111"/>,
	to enable caching of retrieved metadata for appropriate time periods.	to enable caching of retrieved metadata for appropriate time periods.

	</t>	</t>
	</section>	</section>


	</section>	</section>

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

	<t>
	The following registration procedure is used for the
	registry established by this specification.
	</t>
	<t>	<t>

	Values are registered on a Specification Required <xref target="RFC8126"/	Values are registered via Specification Required <xref target="RFC8126"/>
	>	.
	basis after a two-week review period on the oauth-ext-review@ietf.org	Registration requests should be sent to <oauth-ext-review@ietf.org&gt
	mailing list, on the advice of one or more Designated Experts.	;
		to initiate a two-week review period.
	However, to allow for the allocation of values prior to publication	However, to allow for the allocation of values prior to publication
	of the final version of a specification,	of the final version of a specification,

	the Designated Experts may approve registration once they are satisfied	the designated experts may approve registration once they are satisfied
	that the specification will be completed and published.	that the specification will be completed and published.
	However, if the specification is not completed and published	However, if the specification is not completed and published

	in a timely manner, as determined by the Designated Experts,	in a timely manner, as determined by the designated experts,
	the Designated Experts may request that IANA withdraw the registration.	the designated experts may request that IANA withdraw the registration.
	</t>	</t>
	<t>	<t>
	Registration requests sent to the mailing list for review should use	Registration requests sent to the mailing list for review should use
	an appropriate subject	an appropriate subject
	(e.g., "Request to register OAuth Protected Resource Metadata: example").	(e.g., "Request to register OAuth Protected Resource Metadata: example").

	</t>	</t>
	<t>	<t>

	Within the review period, the Designated Experts will either approve or	Within the review period, the designated experts will either approve or
	deny the registration request, communicating this decision to the review list and IANA.	deny the registration request, communicating this decision to the review list and IANA.
	Denials should include an explanation and, if applicable, suggestions as to how to make	Denials should include an explanation and, if applicable, suggestions as to how to make

	the request successful.	the request successful. If the designated experts are not responsive,
	The IANA escalation process is followed when the Designated Experts	the registration requesters should contact IANA to escalate the process.
	are not responsive within 14 days.
	</t>	</t>
	<t>	<t>

	Criteria that should be applied by the Designated Experts includes	Designated experts should apply the following criteria when reviewing
	determining whether the proposed registration duplicates existing functio	proposed registrations: They must be unique -- that is, they should not
	nality,	duplicate existing functionality; they are likely generally applicable,
	determining whether it is likely to be of general applicability	as opposed to being used for a single application; and they are clear
	or whether it is useful only for a single application,	and fit the purpose of the registry.
	and whether the registration makes sense.
	</t>	</t>
	<t>	<t>

	IANA must only accept registry updates from the Designated Experts and sh ould direct	IANA must only accept registry updates from the designated experts and sh ould direct
	all requests for registration to the review mailing list.	all requests for registration to the review mailing list.
	</t>	</t>


	<t>	<t>

	It is suggested that multiple Designated Experts be appointed who are abl	In order to enable broadly informed review of registration decisions, there shou
	e to	ld be multiple designated experts to represent the perspectives of different app
	represent the perspectives of different applications using this specifica	lications using this specification.
	tion,	In cases where registration may be perceived as a conflict of interest fo
	in order to enable broadly-informed review of registration decisions.	r a particular expert,
	In cases where a registration decision could be perceived as	that expert should defer to the judgment of the other experts.
	creating a conflict of interest for a particular Expert,
	that Expert should defer to the judgment of the other Experts.
	</t>	</t>

	<t>	<t>
	The reason for the use of the mailing list is to enable	The mailing list is used to enable
	public review of registration requests, enabling both Designated Experts	public review of registration requests, which enables both designated ex
		perts
	and other interested parties to provide feedback on proposed registratio ns.	and other interested parties to provide feedback on proposed registratio ns.

	The reason to allow the Designated Experts to	Designated experts may allocate values prior to publication of the
	allocate values prior to publication as a final specification is to enab	final specification. This allows authors to receive guidance from
	le	the designated experts early, so any identified issues can be fixed
	giving authors of specifications proposing registrations	before the final specification is published.
	the benefit of review by the Designated Experts	</t>
	before the specification is completely done,	<section anchor="PRMetadataReg">
	so that if problems are identified, the authors can iterate and fix them	<name>OAuth Protected Resource Metadata Registry</name>
	before publication of the final specification.	<t>
	</t>

	<section title="OAuth Protected Resource Metadata Registry" anchor="PRMeta
	dataReg">
	<t>
	This specification establishes the	This specification establishes the

	IANA "OAuth Protected Resource Metadata" registry	"OAuth Protected Resource Metadata" registry
	for OAuth 2.0 protected resource metadata names.	for OAuth 2.0 protected resource metadata names.
	The registry records the protected resource metadata parameter	The registry records the protected resource metadata parameter
	and a reference to the specification that defines it.	and a reference to the specification that defines it.

	</t>	</t>
		<section anchor="PRMetadataTemplate">
	<section title="Registration Template" anchor="PRMetadataTemplate">	<name>Registration Template</name>
	<t>	<dl newline="true" spacing="normal">
	<list style='hanging'>	<dt>Metadata Name:</dt>
	<t hangText='Metadata Name:'>	<dd>
	<vspace/>
	The name requested (e.g., "resource").	The name requested (e.g., "resource").

	This name is case-sensitive.	This name is case sensitive.
	Names may not match other registered names in a case-insensitive manner	Names may not match other registered names in a case-insensitive manner

	unless the Designated Experts state that there is a compelling re ason	unless the designated experts state that there is a compelling re ason
	to allow an exception.	to allow an exception.

	</t>	</dd>
	<t hangText='Metadata Description:'>	<dt>Metadata Description:</dt>
	<vspace/>	<dd>
	Brief description of the metadata (e.g., "Resource identifier UR L").	Brief description of the metadata (e.g., "Resource identifier UR L").

	</t>	</dd>
	<t hangText='Change Controller:'>	<dt>Change Controller:</dt>
	<vspace/>	<dd>
	For IETF stream RFCs, list the "IETF".	For IETF Stream RFCs, list "IETF".
	For others, give the name of the responsible party.	For others, give the name of the responsible party.
	Other details (e.g., postal address, email address, home page URI ) may also be included.	Other details (e.g., postal address, email address, home page URI ) may also be included.

	</t>	</dd>
	<t hangText='Specification Document(s):'>	<dt>Specification Document(s):</dt>
	<vspace/>	<dd>
	Reference to the document or documents that specify the paramete r,	Reference to the document or documents that specify the paramete r,
	preferably including URIs that	preferably including URIs that
	can be used to retrieve copies of the documents.	can be used to retrieve copies of the documents.
	An indication of the relevant	An indication of the relevant
	sections may also be included but is not required.	sections may also be included but is not required.

	</t>	</dd>
	</list>	</dl>
	</t>
	</section>	</section>

		<section anchor="PRMetadataContents">
		<name>Initial Registry Contents</name>
		<dl spacing="compact" newline="false">
		<dt>Metadata Name:</dt><dd><tt>resource</tt></dd>
		<dt>Metadata Description:</dt><dd> Protected resource's resource
		identifier URL</dd>
		<dt>Change Controller:</dt><dd>IETF</dd>
		<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> o
		f RFC 9728</dd>
		</dl>
		<dl spacing="compact" newline="false">
		<dt>Metadata Name:</dt><dd><tt>authorization_servers</tt></dd>
		<dt>Metadata Description:</dt><dd>JSON array containing a list of
		OAuth authorization server issuer identifiers</dd>
		<dt>Change Controller:</dt><dd>IETF</dd>
		<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> o
		f RFC 9728</dd>
		</dl>
		<dl spacing="compact" newline="false">
		<dt>Metadata Name:</dt><dd><tt>jwks_uri</tt></dd>
		<dt>Metadata Description:</dt><dd>URL of the protected resource's
		JWK Set document</dd>
		<dt>Change Controller:</dt><dd>IETF</dd>
		<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> o
		f RFC 9728</dd>
		</dl>
		<dl spacing="compact" newline="false">
		<dt>Metadata Name:</dt><dd><tt>scopes_supported</tt></dd>
		<dt>Metadata Description:</dt><dd>JSON array containing a list of
		the OAuth 2.0 scope values that are used in authorization
		requests to request access to this protected resource</dd>
		<dt>Change Controller:</dt><dd>IETF</dd>
		<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> o
		f RFC 9728</dd>
		</dl>
		<dl spacing="compact" newline="false">
		<dt>Metadata Name:</dt><dd><tt>bearer_methods_supported</tt></dd>
		<dt>Metadata Description:</dt><dd>JSON array containing a list of
		the OAuth 2.0 bearer token presentation methods that this
		protected resource supports</dd>
		<dt>Change Controller:</dt><dd>IETF</dd>
		<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> o
		f RFC 9728</dd>
		</dl>
		<dl spacing="compact" newline="false">
		<dt>Metadata Name:</dt><dd><tt>resource_signing_alg_values_supported
		</tt></dd>
		<dt>Metadata Description:</dt><dd>JSON array containing a list of
		the JWS signing algorithms (<tt>alg</tt> values) supported by the
		protected resource for signed content</dd>
		<dt>Change Controller:</dt><dd>IETF</dd>
		<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> o
		f RFC 9728</dd>
		</dl>
		<dl spacing="compact" newline="false">
		<dt>Metadata Name:</dt><dd><tt>resource_name</tt></dd>
		<dt>Metadata Description:</dt><dd>Human-readable name of the
		protected resource</dd>
		<dt>Change Controller:</dt><dd>IETF</dd>
		<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> o
		f RFC 9728</dd>
		</dl>
		<dl spacing="compact" newline="false">
		<dt>Metadata Name:</dt><dd><tt>resource_documentation</tt></dd>
		<dt>Metadata Description:</dt><dd>URL of a page containing
		human-readable information that developers might want or need to
		know when using the protected resource</dd>
		<dt>Change Controller:</dt><dd>IETF</dd>
		<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> o
		f RFC 9728</dd>
		</dl>
		<dl spacing="compact" newline="false">
		<dt>Metadata Name:</dt><dd><tt>resource_policy_uri</tt></dd>
		<dt>Metadata Description:</dt><dd>URL of a page containing
		human-readable information about the protected resource's
		requirements on how the client can use the data provided by the
		protected resource</dd>
		<dt>Change Controller:</dt><dd>IETF</dd>
		<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> o
		f RFC 9728</dd>
		</dl>
		<dl spacing="compact" newline="false">
		<dt>Metadata Name:</dt><dd><tt>resource_tos_uri</tt></dd>
		<dt>Metadata Description:</dt><dd>URL of a page containing
		human-readable information about the protected resource's terms of
		service</dd>
		<dt>Change Controller:</dt><dd>IETF</dd>
		<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> o
		f RFC 9728</dd>
		</dl>
		<dl spacing="compact" newline="false">
		<dt>Metadata Name:</dt><dd><tt>tls_client_certificate_bound_access_t
		okens</tt></dd>
		<dt>Metadata Description:</dt><dd>Boolean value indicating
		protected resource support for mutual-TLS client certificate-bound
		access tokens</dd>
		<dt>Change Controller:</dt><dd>IETF</dd>
		<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> o
		f RFC 9728</dd>
		</dl>
		<dl spacing="compact" newline="false">
		<dt>Metadata Name:</dt><dd><tt>authorization_details_types_supported<
		/tt></dd>
		<dt>Metadata Description:</dt><dd>JSON array containing a list of
		the authorization details <tt>type</tt> values supported by the
		resource server when the <tt>authorization_details</tt> request
		parameter is used</dd>
		<dt>Change Controller:</dt><dd>IETF</dd>
		<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of
		RFC 9728</dd>
		</dl>


	<section title="Initial Registry Contents" anchor="PRMetadataContents">	<dl spacing="compact" newline="false">
	<t> <?rfc subcompact="yes"?>	<dt>Metadata Name:</dt><dd><tt>dpop_signing_alg_values_supported</tt
	<list style='symbols'>	></dd>
	<t>	<dt>Metadata Description:</dt><dd>JSON array containing a list of
	Metadata Name: <spanx style="verb">resource</spanx>	the JWS <tt>alg</tt> values supported by the resource server for val
	</t>	idating
	<t>	DPoP proof JWTs</dd>
	Metadata Description:	<dt>Change Controller:</dt><dd>IETF</dd>
	Protected resource's resource identifier URL	<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> o
	</t>	f RFC 9728</dd>
	<t>	</dl>
	Change Controller: IETF	<dl spacing="compact" newline="false">
	</t>	<dt>Metadata Name:</dt><dd><tt>dpop_bound_access_tokens_required</tt
	<t>	></dd>
	Specification Document(s): <xref target="PRMetadata"/> of [[ thi	<dt>Metadata Description:</dt><dd>Boolean value specifying
	s specification ]]	whether the protected resource always requires the use of
	</t>	DPoP-bound access tokens</dd>
	</list>	<dt>Change Controller:</dt><dd>IETF</dd>
	</t>	<dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> o
	<t>	f RFC 9728</dd>
	<list style='symbols'>	</dl>
	<t>	<dl spacing="compact" newline="false">
	Metadata Name: <spanx style="verb">authorization_servers</spanx>	<dt>Metadata Name:</dt><dd><tt>signed_metadata</tt></dd>
	</t>	<dt>Metadata Description:</dt><dd>Signed JWT containing metadata
	<t>	parameters about the protected resource as claims</dd>
	Metadata Description:	<dt>Change Controller:</dt><dd>IETF</dd>
	JSON array containing a list of OAuth authorization server issuer	<dt>Specification Document(s):</dt><dd><xref target="SignedMetadata"/
	identifiers	> of RFC 9728</dd>
	</t>	</dl>
	<t>	</section>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="PRMetadata"/> of [[ thi
	s specification ]]
	</t>
	</list>
	</t>
	<t>
	<list style='symbols'>
	<t>
	Metadata Name: <spanx style="verb">jwks_uri</spanx>
	</t>
	<t>
	Metadata Description:
	URL of the protected resource's JWK Set document
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="PRMetadata"/> of [[ thi
	s specification ]]
	</t>
	</list>
	</t>
	<t>
	<list style='symbols'>
	<t>
	Metadata Name: <spanx style="verb">scopes_supported</spanx>
	</t>
	<t>
	Metadata Description:
	JSON array containing a list of the OAuth 2.0
	<spanx style="verb">scope</spanx> values that
	are used in authorization requests to request access to this prot
	ected resource
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="PRMetadata"/> of [[ thi
	s specification ]]
	</t>
	</list>
	</t>
	<t>
	<list style='symbols'>
	<t>
	Metadata Name: <spanx style="verb">bearer_methods_supported</spa
	nx>
	</t>
	<t>
	Metadata Description:
	JSON array containing a list of the OAuth 2.0 Bearer Token
	presentation methods that this protected resource supports
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="PRMetadata"/> of [[ thi
	s specification ]]
	</t>
	</list>
	</t>
	<t>
	<list style='symbols'>
	<t>
	Metadata Name: <spanx style="verb">resource_signing_alg_values_s
	upported</spanx>
	</t>
	<t>
	Metadata Description:
	JSON array containing a list of the JWS signing algorithms
	(<spanx style="verb">alg</spanx> values)
	supported by the protected resource
	for signed content
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="PRMetadata"/> of [[ thi
	s specification ]]
	</t>
	</list>
	</t>
	<t>
	<list style='symbols'>
	<t>
	Metadata Name: <spanx style="verb">resource_name</spanx>
	</t>
	<t>
	Metadata Description:
	Human-readable name of the protected resource
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="PRMetadata"/> of [[ thi
	s specification ]]
	</t>
	</list>
	</t>
	<t>
	<list style='symbols'>
	<t>
	Metadata Name: <spanx style="verb">resource_documentation</spanx
	>
	</t>
	<t>
	Metadata Description:
	URL of a page containing human-readable information that
	developers might want or need to know when using the protected re
	source
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="PRMetadata"/> of [[ thi
	s specification ]]
	</t>
	</list>
	</t>
	<t>
	<list style='symbols'>
	<t>
	Metadata Name: <spanx style="verb">resource_policy_uri</spanx>
	</t>
	<t>
	Metadata Description:
	URL of a page containing human-readable information
	about the protected resource's requirements on how
	the client can use the data provided by the protected resource
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="PRMetadata"/> of [[ thi
	s specification ]]
	</t>
	</list>
	</t>
	<t>
	<list style='symbols'>
	<t>
	Metadata Name: <spanx style="verb">resource_tos_uri</spanx>
	</t>
	<t>
	Metadata Description:
	URL of a page containing human-readable information
	about the protected resource's terms of service
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="PRMetadata"/> of [[ thi
	s specification ]]
	</t>
	</list>
	</t>
	<t>
	<list style='symbols'>
	<t>
	Metadata Name: <spanx style="verb">tls_client_certificate_bound_
	access_tokens</spanx>
	</t>
	<t>
	Metadata Description:
	Boolean value indicating protected resource support for
	mutual-TLS client certificate-bound access tokens
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="PRMetadata"/> of [[ thi
	s specification ]]
	</t>
	</list>
	</t>
	<t>
	<list style='symbols'>
	<t>
	Metadata Name: <spanx style="verb">authorization_details_types_su
	pported</spanx>
	</t>
	<t>
	Metadata Description:
	JSON array containing a list of the authorization details
	<spanx style="verb">type</spanx> values supported by the resource
	server
	when the <spanx style="verb">authorization_details</spanx>
	request parameter is used
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="PRMetadata"/> of [[ this
	specification ]]
	</t>
	</list>
	</t>
	<t>
	<list style='symbols'>
	<t>
	Metadata Name: <spanx style="verb">dpop_signing_alg_values_suppo
	rted</spanx>
	</t>
	<t>
	Metadata Description:
	JSON array containing a list of the JWS alg values
	supported by the resource server for validating DPoP proof JWTs
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="PRMetadata"/> of [[ thi
	s specification ]]
	</t>
	</list>
	</t>
	<t>
	<list style='symbols'>
	<t>
	Metadata Name: <spanx style="verb">dpop_bound_access_tokens_requ
	ired</spanx>
	</t>
	<t>
	Metadata Description:
	Boolean value specifying whether the protected resource
	always requires the use of DPoP-bound access tokens
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="PRMetadata"/> of [[ thi
	s specification ]]
	</t>
	</list>
	</t>
	<t>
	<list style='symbols'>
	<t>
	Metadata Name: signed_metadata
	</t>
	<t>
	Metadata Description:
	Signed JWT containing metadata parameters about the protected res
	ource as claims
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="SignedMetadata"/> of [[
	this specification ]]
	</t>
	</list>
	</t>
	</section>
	<?rfc subcompact="no"?>
	</section>	</section>

		<section anchor="ASMetadataReg">
	<section title="OAuth Authorization Server Metadata Registry" anchor="ASMe	<name>OAuth Authorization Server Metadata Registry</name>
	tadataReg">	<t>
	<t>	IANA has registered the following authorization server metadata paramet
	The following authorization server metadata parameter	er
	is registered in the IANA	in the
	"OAuth Authorization Server Metadata" registry established in	"OAuth Authorization Server Metadata" registry established in

	<xref target="RFC8414">OAuth 2.0 Authorization Server Metadata</xref>.	"<xref target="RFC8414" format="title"/>" <xref target="RFC8414" format="default
	</t>	"/>.
		</t>
	<section title="Registry Contents" anchor="ASMetadataContents">	<section anchor="ASMetadataContents">
	<t>	<name>Registry Contents</name>
	<?rfc subcompact="yes"?>	<dl spacing="compact" newline="false">
	<list style='symbols'>	<dt>Metadata Name:</dt><dd><tt>protected_resources</tt></dd>
	<t>	<dt>Metadata Description:</dt><dd>JSON array containing a list of
	Metadata Name: <spanx style="verb">protected_resources</spanx>	resource identifiers for OAuth protected resources</dd>
	</t>	<dt>Change Controller:</dt><dd>IETF</dd>
	<t>	<dt>Specification Document(s):</dt><dd><xref target="ASMetadata"/> o
	Metadata Description:	f RFC 9728</dd>
	JSON array containing a list of resource identifiers for OAuth pr	</dl>
	otected resources	</section>
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Specification Document(s): <xref target="ASMetadata"/> of [[ thi
	s specification ]]
	</t>
	</list>
	</t>
	</section>
	<?rfc subcompact="no"?>
	</section>	</section>

		<section anchor="WellKnownRegistry">
	<section anchor="WellKnownRegistry" title="Well-Known URI Registry">	<name>Well-Known URIs Registry</name>
	<t>	<t>
	This specification registers the well-known URI defined in	This specification registers the well-known URI defined in

	<xref target="PRConfig"/> in the IANA	<xref target="PRConfig"/> in the
	"Well-Known URIs" registry <xref target="IANA.well-known"/>.	"Well-Known URIs" registry <xref target="IANA.well-known"/>.

	</t>	</t>
		<section anchor="WellKnownContents">
	<section anchor='WellKnownContents' title='Registry Contents'>	<name>Registry Contents</name>
	<t> <?rfc subcompact="yes"?>	<dl spacing="compact" newline="false">
	<list style='symbols'>	<dt>URI Suffix:</dt><dd><tt>oauth-protected-resource</tt></dd>
	<t>	<dt>Reference:</dt><dd><xref target="PRConfig"/> of RFC 9728</dd>
	URI Suffix: <spanx style="verb">oauth-protected-resource</spanx>	<dt>Status:</dt><dd>permanent</dd>
	</t>	<dt>Change Controller:</dt><dd>IETF</dd>
	<t>	<dt>Related Information:</dt><dd>(none)</dd>
	Reference: <xref target="PRConfig"/> of [[ this specification ]]	</dl>
	</t>	</section>
	<t>
	Status: permanent
	</t>
	<t>
	Change Controller: IETF
	</t>
	<t>
	Related Information: (none)
	</t>
	</list>
	</t>
	</section>
	<?rfc subcompact="no"?>

	</section>	</section>


	</section>	</section>
	</middle>	</middle>


	<back>	<back>

	<references title="Normative References">
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
	9.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.564
	6.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.674
	9.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.675
	0.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.723
	4.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.759
	1.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.812
	6.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
	4.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.825
	9.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.841
	4.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.861
	5.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.870
	5.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.870
	7.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.899
	6.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.911
	0.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.932
	5.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.939
	6.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.944
	9.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.952
	5.xml"/>

	<reference anchor="USA15" target="https://www.unicode.org/reports/tr15/">
	<front>
	<title>Unicode Normalization Forms</title>

	<author fullname="Mark Davis" initials="M." surname="Davis">
	</author>

	<author fullname="Ken Whistler" initials="K." surname="Whistler">
	</author>

	<date day="1" month="June" year="2015" />
	</front>

	<seriesInfo name="Unicode Standard Annex" value="15" />
	</reference>

	<reference anchor="JWT" target="https://tools.ietf.org/html/rfc7519">
	<front>
	<title>JSON Web Token (JWT)</title>

	<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	<organization abbrev="Microsoft">Microsoft</organization>
	</author>

	<author fullname="John Bradley" initials="J." surname="Bradley">
	<organization abbrev="Ping Identity">Ping Identity</organization>
	</author>

	<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	<organization abbrev="NRI">Nomura Research Institute, Ltd.</organiza
	tion>
	</author>

	<date month="May" year="2015" />
	</front>

	<seriesInfo name="RFC" value="7519"/>
	<seriesInfo name="DOI" value="10.17487/RFC7519"/>
	</reference>

	<reference anchor="JWS" target="https://tools.ietf.org/html/rfc7515">
	<front>
	<title>JSON Web Signature (JWS)</title>

	<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	<organization abbrev="Microsoft">Microsoft</organization>
	</author>

	<author fullname="John Bradley" initials="J." surname="Bradley">
	<organization abbrev="Ping Identity">Ping Identity</organization>
	</author>

	<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	<organization abbrev="NRI">Nomura Research Institute, Ltd.</organiza
	tion>
	</author>

	<date month="May" year="2015" />
	</front>

	<seriesInfo name="RFC" value="7515"/>
	<seriesInfo name="DOI" value="10.17487/RFC7515"/>
	</reference>

	<reference anchor="JWE" target="https://tools.ietf.org/html/rfc7516">
	<front>
	<title>JSON Web Encryption (JWE)</title>

	<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	<organization>Microsoft</organization>
	</author>

	<author fullname="Joe Hildebrand" initials="J." surname="Hildebrand">
	<organization>Cisco Systems, Inc.</organization>
	</author>

	<date month="May" year="2015" />
	</front>

	<seriesInfo name="RFC" value="7516"/>
	<seriesInfo name="DOI" value="10.17487/RFC7516"/>
	</reference>

	<reference anchor="JWA" target="https://tools.ietf.org/html/rfc7518">
	<front>
	<title>JSON Web Algorithms (JWA)</title>

	<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	<organization abbrev="Microsoft">Microsoft</organization>
	</author>

	<date month="May" year="2015" />
	</front>

	<seriesInfo name="RFC" value="7518"/>
	<seriesInfo name="DOI" value="10.17487/RFC7518"/>
	</reference>

	<reference anchor="JWK" target="https://tools.ietf.org/html/rfc7517">
	<front>
	<title>JSON Web Key (JWK)</title>

	<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	<organization>Microsoft</organization>
	</author>

	<date month="May" year="2015" />
	</front>

	<seriesInfo name="RFC" value="7517"/>
	<seriesInfo name="DOI" value="10.17487/RFC7517"/>
	</reference>

	<reference anchor="UNICODE" target="https://www.unicode.org/versions/lates
	t/">
	<front>
	<title abbrev="Unicode">The Unicode Standard</title>
	<author>
	<organization>The Unicode Consortium</organization>
	<address />
	</author>
	<date />
	</front>
	<!--
	Note that this reference is to the latest version of Unicode,
	rather than to a specific release. It is not expected that future chan
	ges in
	the UNICODE specification will impact the syntax of JSON or the UTF-8 e
	ncoding.
	-->
	</reference>

	<reference anchor="IANA.Language"
	target="https://www.iana.org/assignments/language-subtag-regist
	ry">
	<front>
	<title>Language Subtag Registry</title>
	<author>
	<organization>IANA</organization>
	</author>
	<date/>
	</front>
	</reference>

	</references>

	<references title="Informative References">

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.703
	3.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.862
	0.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.947
	0.xml"/>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.dr
	aft-ietf-oauth-security-topics-29.xml"/>

	<reference anchor="OpenID.Discovery" target="https://openid.net/specs/open
	id-connect-discovery-1_0.html">
	<front>
	<title>OpenID Connect Discovery 1.0</title>


	<author fullname="Nat Sakimura" initials="N." surname="Sakimura">	<displayreference target="RFC7518" to="JWA"/>
	<organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</or	<displayreference target="RFC7516" to="JWE"/>
	ganization>	<displayreference target="RFC7517" to="JWK"/>
	</author>	<displayreference target="RFC7515" to="JWS"/>
		<displayreference target="RFC7519" to="JWT"/>


	<author fullname="John Bradley" initials="J." surname="Bradley">	<references>
	<organization abbrev="Yubico (was at Ping Identity)">Yubico</organiza	<name>References</name>
	tion>	<references>
	</author>	<name>Normative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		119.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
		047.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		749.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		750.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		111.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		591.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		126.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		174.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		259.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		414.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		615.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		705.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		707.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		110.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		396.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		449.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		525.xml"/>


	<author fullname="Michael B. Jones" initials="M.B." surname="Jones">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
	<organization abbrev="Self-Issued Consulting (was at Microsoft)">Self	0195.xml"/>
	-Issued Consulting</organization>
	</author>


	<author fullname="Edmund Jay" initials="E." surname="Jay">	<reference anchor="USA15" target="https://www.unicode.org/reports/tr15/"
	<organization abbrev="Illumila">Illumila</organization>	>
		<front>
		<title>Unicode Normalization Forms</title>
		<author fullname="Ken Whistler" initials="K." surname="Whistler" rol
		e="editor">
	</author>	</author>

		<date day="14" month="August" year="2024"/>
	<date day="15" month="December" year="2023"/>	</front>
	</front>	<seriesInfo name="Unicode Standard Annex" value="#15"/>
	</reference>	</reference>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	<reference anchor="IANA.well-known" target="https://www.iana.org/assignmen	519.xml"/>
	ts/well-known-uris">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	<front>	515.xml"/>
	<title>Well-Known URIs</title>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	<author>	516.xml"/>
	<organization>IANA</organization>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	</author>	518.xml"/>
	<date/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	</front>	517.xml"/>
	</reference>	<reference anchor="UNICODE" target="https://www.unicode.org/versions/lat
		est/">
	<reference anchor="IANA.JOSE" target="https://www.iana.org/assignments/jos	<front>
	e">	<title abbrev="Unicode">The Unicode Standard</title>
	<front>	<author>
	<title>JSON Object Signing and Encryption (JOSE)</title>	<organization>The Unicode Consortium</organization>
	<author>	<address/>
	<organization>IANA</organization>	</author>
	</author>	<date/>
	<date/>	</front>
	</front>
	</reference>	</reference>

		<reference anchor="IANA.Language" target="https://www.iana.org/assignmen
		ts/language-subtag-registry">
		<front>
		<title>Language Subtag Registry</title>
		<author>
		<organization>IANA</organization>
		</author>
		<date/>
		</front>
		</reference>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		033.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		620.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		470.xml"/>


	<reference anchor="OWASP.SSRF" target="https://cheatsheetseries.owasp.org/	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html">	700.xml"/>
	<front>
	<title>OWASP SSRF Prevention Cheat Sheet</title>
	<author>
	<organization>OWASP</organization>
	</author>
	</front>
	</reference>


	<reference anchor="FAPI.MessageSigning" target="https://openid.net/specs/f	<reference anchor="OpenID.Discovery" target="https://openid.net/specs/op
	api-2_0-message-signing.html">	enid-connect-discovery-1_0.html">
	<front>	<front>
	<title>FAPI 2.0 Message Signing</title>	<title>OpenID Connect Discovery 1.0 incorporating errata set 2</titl
	<author fullname="Dave Tonge" initials="D." surname="Tonge">	e>
	<organization abbrev="Moneyhub">Moneyhub Financial Techno	<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	logy</organization>	<organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting<
	</author>	/organization>
	<author fullname="Daniel Fett" initials="D." surname="Fett">	</author>
	<organization>Authlete</organization>	<author fullname="John Bradley" initials="J." surname="Bradley">
	</author>	<organization abbrev="Yubico (was at Ping Identity)">Yubico</organ
	<date day="24" month="March" year="2023" />	ization>
	</front>	</author>
	</reference>	<author fullname="Michael B. Jones" initials="M." surname="Jones">
		<organization abbrev="Self-Issued Consulting (was at Microsoft)">S
		elf-Issued Consulting</organization>
		</author>
		<author fullname="Edmund Jay" initials="E." surname="Jay">
		<organization abbrev="Illumila">Illumila</organization>
		</author>
		<date day="15" month="December" year="2023"/>
		</front>
		</reference>
		<reference anchor="IANA.well-known" target="https://www.iana.org/assignm
		ents/well-known-uris">
		<front>
		<title>Well-Known URIs</title>
		<author>
		<organization>IANA</organization>
		</author>
		<date/>
		</front>
		</reference>


		<reference anchor="IANA.JOSE" target="https://www.iana.org/assignments/j
		ose">
		<front>
		<title>JSON Web Signature and Encryption Algorithms</title>
		<author>
		<organization>IANA</organization>
		</author>
		<date/>
		</front>
		</reference>
		<reference anchor="OWASP.SSRF" target="https://cheatsheetseries.owasp.or
		g/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html">
		<front>
		<title>OWASP Server-Side Request Forgery Prevention Cheat Sheet</tit
		le>
		<author>
		<organization>OWASP Foundation</organization>
		</author>
		</front>
		</reference>
		<reference anchor="FAPI.MessageSigning" target="https://openid.net/specs
		/fapi-2_0-message-signing.html">
		<front>
		<title>FAPI 2.0 Message Signing (Draft)</title>
		<author fullname="Dave Tonge" initials="D." surname="Tonge">
		<organization abbrev="Moneyhub">Moneyhub Financial Technology</org
		anization>
		</author>
		<author fullname="Daniel Fett" initials="D." surname="Fett">
		<organization>Authlete</organization>
		</author>
		<date day="24" month="March" year="2023"/>
		</front>
		</reference>
		</references>
	</references>	</references>

		<section anchor="Acknowledgements" numbered="false">
	<section anchor="Acknowledgements" title="Acknowledgements">	<name>Acknowledgements</name>
		<t>The authors of this specification would like to thank the attendees
	<t>	of the IETF 115 OAuth and HTTP API Working Group meetings and the
	The authors of this specification would like to thank the attendees of th	attendees of subsequent OAuth Working Group meetings for their input on
	e IETF 115 OAuth and HTTP API Working Group meetings	this specification. We would also like to thank <contact
	and the attendees of subsequent OAuth Working Group meetings for their in	fullname="Amanda Baber"/>, <contact fullname="Mike Bishop"/>, <contact
	put on this specification.	fullname="Ralph Bragg"/>, <contact fullname="Brian Campbell"/>, <contact
	We would would also like to thank	fullname="Deb Cooley"/>, <contact fullname="Gabriel Corona"/>, <contact fu
	Amanda Baber,	llname="Roman Danyliw"/>,
	Mike Bishop,	<contact fullname="Vladimir Dzhuvinov"/>,
	Ralph Bragg,	<contact fullname="George Fletcher"/>, <contact fullname="Arnt
	Brian Campbell,	Gulbrandsen"/>, <contact fullname="Pieter Kasselman"/>, <contact
	Deb Cooley,	fullname="Murray Kucherawy"/>, <contact fullname="David Mandelberg"/>,
	Roman Danyliw,	<contact fullname="Tony Nadalin"/>, <contact fullname="Francesca
	Gabriel Corona,	Palombini"/>, <contact fullname="John Scudder"/>, <contact
	Vladimir Dzhuvinov,	fullname="Rifaat Shekh-Yusef"/>, <contact fullname="Filip Skokan"/>,
	George Fletcher,	<contact fullname="Orie Steele"/>, <contact fullname="Atul
	Arnt Gulbrandsen,	Tulshibagwale"/>, <contact fullname="Éric Vyncke"/>, <contact
	Pieter Kasselman,	fullname="Paul Wouters"/>, and <contact fullname="Bo Wu"/> for their
	Murray Kucherawy,	contributions to the specification.
	David Mandelberg,	</t>
	Tony Nadalin,
	Francesca Palombini,
	John Scudder,
	Rifaat Shekh-Yusef,
	Filip Skokan,
	Orie Steele,
	Atul Tulshibagwale,
	Éric Vyncke,
	Paul Wouters,
	and
	Bo Wu
	for their contributions to the specification.
	</t>
	</section>

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

	<t>
	-13
	<list style="symbols">
	<t>
	Described motivations for the IANA registration procedure,
	per additional comments by Murray Kucherawy.
	</t>
	</list>
	</t>

	<t>
	-12
	<list style="symbols">
	<t>
	Incorporated responses to IESG review comments by John Scudder,
	Murray Kucherawy, Francesca Palombini, and Éric Vyncke.
	The IANA registration procedure was updated per the discussion
	on the IESG telechat.
	</t>
	</list>
	</t>

	<t>
	-11
	<list style="symbols">
	<t>
	Incorporated responses to HttpDir review comments by Mike Bishop.
	</t>
	<t>
	Incorporated responses to IESG review comments by Roman Danyliw.
	</t>
	<t>
	Incorporated responses to IESG review comments by Orie Steele.
	Particularly, the specification now allows resource identifiers
	to contain a query component (but still discourages it).
	</t>
	<t>
	Consistently use the term "metadata parameter".
	The terms "metadata value" and "claim" were previously
	inconsistently used for the same thing.
	</t>
	</list>
	</t>

	<t>
	-10
	<list style="symbols">
	<t>
	Added metadata parameter declaring RAR types supported.
	</t>
	</list>
	</t>

	<t>
	-09
	<list style="symbols">
	<t>
	Added metadata values declaring support for DPoP
	and mutual-TLS client certificate-bound access tokens.
	</t>
	<t>
	Added missing word caught during IANA review.
	</t>
	<t>
	Addressed ART, SecDir, and OpsDir review comments by
	Arnt Gulbrandsen, David Mandelberg, and Bo Wu,
	resulting in the following changes.
	</t>
	<t>
	Added step numbers to sequence diagram.
	</t>
	<t>
	Defined meaning of omitting
	<spanx style="verb">bearer_methods_supported</spanx>
	metadata parameter.
	</t>
	<t>
	Added internationalization of human-readable metadata values
	using the mechanism from <xref target="RFC7591"/>.
	</t>
	<t>
	Added <spanx style="verb">resource_name</spanx> metadata parameter,
	paralleling <spanx style="verb">client_name</spanx> in <xref target="
	RFC7591"/>.
	</t>
	<t>
	Added Security Considerations section on metadata caching.
	</t>
	<t>
	Used and referenced Resource Identifier definition.
	</t>
	<t>
	Added motivating example of an email client to intro.
	</t>
	</list>
	</t>

	<t>
	-08
	<list style="symbols">
	<t>
	Added Security Considerations about the differences between
	unsigned and signed metadata, as suggested by Deb Cooley.
	</t>
	<t>
	Updated obsolete references.
	</t>
	</list>
	</t>

	<t>
	-07
	<list style="symbols">
	<t>
	Removed extraneous paragraph about downgrade attacks discussing
	an issue that's already addressed elsewhere in the specification.
	</t>
	</list>
	</t>

	<t>
	-06
	<list style="symbols">
	<t>
	Addressed shepherd review comments by Rifaat Shekh-Yusef.
	</t>
	</list>
	</t>

	<t>
	-05
	<list style="symbols">
	<t>
	Added SVG diagram
	</t>
	</list>
	</t>

	<t>
	-04
	<list style="symbols">
	<t>
	Applied working group last call suggestions by
	Atul Tulshibagwale.
	</t>
	<t>
	Better described the purpose of
	<spanx style="verb">resource_signing_alg_values_supported</spanx> and
	removed <spanx style="verb">resource_encryption_alg_values_supported<
	/spanx> and
	<spanx style="verb">resource_encryption_enc_values_supported</spanx>,
	per WGLC comments by Vladimir Dzhuvinov and Brian Campbell.
	</t>
	<t>
	Applied suggestions by Pieter Kasselman.
	</t>
	</list>
	</t>

	<t>
	-03
	<list style="symbols">
	<t>
	Applied correction by Filip Skokan.
	</t>
	</list>
	</t>

	<t>
	-02
	<list style="symbols">
	<t>
	Switched from concatenating .well-known to the end of the resource id
	entifier
	to inserting it between the host and path components of it.
	</t>
	<t>
	Have WWW-Authenticate return <spanx style="verb">resource_metadata</s
	panx> rather than <spanx style="verb">resource</spanx>.
	</t>
	</list>
	</t>

	<t>
	-01
	<list style="symbols">
	<t>
	Renamed scopes_provided to scopes_supported.
	</t>
	<t>
	Added security consideration for scopes_supported.
	</t>
	<t>
	Use BCP 195 for TLS recommendations.
	</t>
	<t>
	Clarified that resource metadata can be used by clients and authoriza
	tion servers.
	</t>
	<t>
	Updated references.
	</t>
	<t>
	Added security consideration recommending audience-restricted access
	tokens.
	</t>
	<t>
	Mention FAPI Message Signing as a use case for publishing signing key
	s.
	</t>
	</list>
	</t>

	<t>
	-00
	<list style="symbols">
	<t>
	Initial working group version based on draft-jones-oauth-resource-met
	adata-04.
	</t>
	</list>
	</t>

	</section>	</section>


	</back>	</back>
	</rfc>	</rfc>

End of changes. 274 change blocks.
	1795 lines changed or deleted	1209 lines changed or added
This html diff was produced by rfcdiff 1.48.