<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd"> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-oauth-resource-metadata-13" ipr="trust200902">

  <?rfc toc="yes" ?>
  <?rfc tocdepth="5" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc strict="yes" ?>
  <?rfc compact='yes' ?>
  <?rfc subcompact='no' ?> number="9728" submissionType="IETF" updates="" obsoletes="" consensus="true" ipr="trust200902" tocInclude="true" tocDepth="5" symRefs="true" sortRefs="true" version="3" xml:lang="en">

  <front>
    <title abbrev="OAuth 2.0 Protected Resource Metadata">OAuth 2.0 Protected Resource Metadata</title>
    <seriesInfo name="RFC" value="9728"/>
    <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
      <organization>Self-Issued Consulting</organization>
      <address>
        <email>michael_b_jones@hotmail.com</email>
        <uri>https://self-issued.info/</uri>
      </address>
    </author>
    <author fullname="Phil Hunt" initials="P." surname="Hunt">
      <organization>Independent Identity, Inc.</organization>
      <address>
        <email>phil.hunt@yahoo.com</email>
      </address>
    </author>
    <author fullname="Aaron Parecki" initials="A." surname="Parecki">
      <organization>Okta</organization>
      <address>
        <email>aaron@parecki.com</email>
        <uri>https://aaronparecki.com/</uri>
      </address>
    </author>
    <date day="15" month="October" year="2024" />

    <area>Security</area>
    <workgroup>OAuth Working Group</workgroup> month="April" year="2025"/>
    <area>SEC</area>
    <workgroup>oauth</workgroup>

    <keyword>OAuth</keyword>
    <keyword>Discovery</keyword>
    <keyword>Metadata</keyword>
    <keyword>Discovery Metadata</keyword>
    <keyword>Configuration Information</keyword>
    <keyword>Resource Server</keyword>
    <keyword>Protected Resource</keyword>
    <keyword>Resource Identifier</keyword>
    <keyword>JavaScript Object Notation</keyword>
    <keyword>JSON</keyword>
    <keyword>JSON Web Token</keyword>
    <keyword>JWT</keyword>
    <abstract>
      <t>
	This specification defines a metadata format that
	an OAuth 2.0 client or authorization server can use to obtain
	the information needed to interact with
	an OAuth 2.0 protected resource.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction"> anchor="Introduction">
      <name>Introduction</name>
      <t>
	This specification defines a metadata format
	enabling OAuth 2.0 clients and authorization servers to obtain information needed
	to interact with an OAuth 2.0 protected resource.
	The structure and content of this specification is are intentionally as parallel as possible to that of
	<xref
	(1)&nbsp;<xref target="RFC7591">"OAuth 2.0 Dynamic Client Registration Protocol"</xref>,
	which enables a client to provide metadata about itself
	to an OAuth 2.0 authorization server and to (2)&nbsp;"<xref target="RFC8414" format="title"/>" <xref target="RFC8414">OAuth 2.0 Authorization Server Metadata</xref>, target="RFC8414" format="default"/>,
	which enables a client to obtain metadata about
	an OAuth 2.0 authorization server.
      </t>
      <t>
	The means by which the client obtains the location
	of the protected resource
	is out of scope of for this document.
	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 enter
	the URL of their <xref target="RFC8620">JMAP</xref> server. target="RFC8620">JSON Meta Application Protocol (JMAP) server</xref>.
	In other cases, it may be dynamically discovered;
	for example, a user could enter their email address into an email client,
	the client could perform <xref target="RFC7033">WebFinger</xref> discovery target="RFC7033">WebFinger discovery</xref>
	(in a manner related to the description in Section 2 of <xref target="OpenID.Discovery">"OpenID Connect Discovery 1.0"</xref>) target="OpenID.Discovery" section="2" relative="#IssuerDiscovery"/>) to find the resource server, and the client could then fetch the resource server metadata
	to find the authorization server to use to obtain authorization
	to access the user's email.
      </t>
      <t>
	The metadata for a protected resource
	is retrieved from a well-known location as a JSON <xref target="RFC8259"/> document,
	which declares information about its capabilities and and, optionally, its relationships to with other services.
	This process is described in <xref target="PRConfig"/>.
      </t>
      <t>
	This metadata can either be communicated either in a self-asserted fashion or as
	a set of signed metadata values represented as claims
	in a JSON Web Token (JWT) <xref target="JWT"/>. target="RFC7519"/>.
	In the JWT case, the issuer is vouching for
	the validity of the data about the protected resource.
	This is analogous to the role that the Software Statement software statement
	plays in OAuth Dynamic Client Registration <xref target="RFC7591"/>.
      </t>
      <t>
	Each protected resource publishing metadata about itself makes its own
	metadata document available at a well-known location
	deterministically derived from the protected resource's URL,
	even when the resource server implements multiple protected resources.
	This prevents attackers from publishing metadata that supposedly describing describes
	the protected resource, resource but that is not actually authoritative for
	the protected resource, as described in <xref target="Impersonation"/>.
      </t>
      <t>
	<xref target="PRMetadata"/> defines metadata parameters that a protected
	      resource can publish, which includes things like which scopes are
	      supported, how a client can present an access token, and more.
	      These values values, such as the <tt>jwks_uri</tt> (see <xref target="PRMetadata"/>),
              may be used by with other specifications, such as specifications; for example, the <spanx style="verb">jwks_uri</spanx>
	      used to publish public keys
              published in the resource server uses <tt>jwks_uri</tt> can be used to sign verify the signed
              resource responses, for instance, as described in <xref target="FAPI.MessageSigning"/>.
      </t>
      <t>
	<xref target="WWW-Authenticate"/> describes the use of
	<spanx style="verb">WWW-Authenticate</spanx>
	<tt>WWW-Authenticate</tt> by protected resources
	to dynamically inform clients of
	the URL of their protected resource metadata.
	This use of <spanx style="verb">WWW-Authenticate</spanx> <tt>WWW-Authenticate</tt> can indicate that
	the protected resource metadata may have changed.
      </t>
      <section anchor="rnc" title="Requirements anchor="rnc">
        <name>Requirements Notation and Conventions"> Conventions</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in
	  BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>

         <t>
	  All uses applications of <xref target="JWS">JSON target="RFC7515">JSON Web Signature (JWS)</xref> (JWS) data structures</xref>
	  and <xref target="JWE">JSON target="RFC7516">JSON Web Encryption (JWE)</xref> (JWE) data structures structures</xref>
	  as discussed in this specification utilize
	  the JWS Compact Serialization or the JWE Compact Serialization;
	  the JWS JSON Serialization and the JWE JSON Serialization are not used.
	  Choosing a single serialization is intended to facilitate interoperability.
        </t>
      </section>
      <section anchor="Terminology" title="Terminology"> anchor="Terminology">
        <name>Terminology</name>
        <t>
	  This specification uses the terms "Access Token", "Authorization Code",
	  "Authorization Endpoint", "Authorization Grant", "Authorization Server",
	  "Client", "Client Authentication", "Client Identifier", "Client Secret",
	  "Grant Type", "Protected Resource", "Redirection URI", "Refresh Token",
	  "Resource Owner", "Resource Server", "Response Type", "access token", "authorization code",
	  "authorization server",
	  "client", "client authentication", "client identifier",
	  "protected resource", and "Token Endpoint"
	  "resource server"
	  defined by <xref target="RFC6749">OAuth 2.0</xref>, and
	  the terms "Claim Name", "Claim Value", Name" and "JSON Web Token (JWT)"
	  defined by "<xref target="RFC7519" format="title"/>" <xref target="JWT">JSON Web Token (JWT)</xref>. target="RFC7519" format="default"/>.
        </t>
        <t>
	  This specification defines the following term:
	  <list style='hanging'>
	    <t hangText='Resource Identifier:'>
	      <vspace/>
        </t>
        <dl newline="true" spacing="normal">
          <dt>Resource Identifier:</dt>
          <dd>
	      The Protected protected resource's resource identifier, which is a URL that
	      uses the <spanx style="verb">https</spanx> <tt>https</tt> scheme and has no fragment component.
	      As specified in Section 2 of <xref section="2" sectionFormat="of" target="RFC8707"/>, it also SHOULD NOT <bcp14>SHOULD NOT</bcp14> include
	      a query component, but it is recognized that there are cases that make
	      a query component a useful and necessary part of a resource identifier.
	      Protected resource metadata is published at a
	      <spanx style="verb">.well-known</spanx>
	      <tt>.well-known</tt> location
	      <xref target="RFC8615"/>
	      derived from this resource identifier,
	      as described in <xref target="PRConfig"/>.
	    </t>
	  </list>
	</t>
	    </dd>
        </dl>
      </section>
    </section>
    <section anchor="PRMetadata" title="Protected anchor="PRMetadata">
      <name>Protected Resource Metadata"> Metadata</name>
      <t>
	Protected resources can have metadata describing their configuration.
	The following protected resource metadata parameters
	are used by this specification and are registered in the IANA
	"OAuth Protected Resource Metadata" registry
	established in <xref target="PRMetadataReg"/>:

	<list style="hanging">

	  <t hangText="resource">
	    <vspace/>
	    REQUIRED.

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

	  <t hangText="authorization_servers">
	    <vspace/>
	    OPTIONAL.
	  </dd>
        <dt>authorization_servers</dt>
        <dd>
	    <bcp14>OPTIONAL</bcp14>.
	    JSON array containing a list of OAuth authorization server issuer identifiers,
	    as defined in <xref target="RFC8414"/>,
	    for authorization servers that can be used with this protected resource.
	    Protected resources MAY <bcp14>MAY</bcp14> choose not to advertise some supported authorization servers
	    even when this parameter is used.
	    In some use cases, the set of authorization servers will not be enumerable,
	    in which case this metadata parameter would not be used.
	  </t>

	  <t hangText="jwks_uri">
	    <vspace/>
	    OPTIONAL.
	  </dd>
        <dt>jwks_uri</dt>
        <dd>
	    <bcp14>OPTIONAL</bcp14>.
	    URL of the protected resource's JSON Web Key (JWK) Set <xref target="JWK"/> target="RFC7517"/> document.
	    This contains public keys belonging to the protected resource, such as
	    signing key(s) that the resource server uses to sign resource responses.
	    This URL MUST <bcp14>MUST</bcp14> use the <spanx style="verb">https</spanx> <tt>https</tt> scheme.
	    When both signing and encryption keys are made available,
	    a <spanx style="verb">use</spanx> <tt>use</tt> (public key use) parameter
	    value is REQUIRED <bcp14>REQUIRED</bcp14> for all keys in the referenced JWK Set
	    to indicate each key's intended usage.
	  </t>

	  <t hangText="scopes_supported">
	    <vspace/>
	    RECOMMENDED.
	  </dd>
        <dt>scopes_supported</dt>
        <dd>
	    <bcp14>RECOMMENDED</bcp14>.
	    JSON array containing a list of the scope values, as defined in <xref target="RFC6749">OAuth 2.0</xref> <spanx style="verb">scope</spanx> values
2.0</xref>, that
	    are used in authorization requests to request access to this protected resource.
	    Protected resources MAY <bcp14>MAY</bcp14> choose not to advertise some scope values supported
	    even when this parameter is used.
	  </t>

	  <t hangText="bearer_methods_supported">
	    <vspace/>
	    OPTIONAL.
	  </dd>
        <dt>bearer_methods_supported</dt>
        <dd>
	    <bcp14>OPTIONAL</bcp14>.
	    JSON array containing a list of the supported methods of sending an
	    OAuth 2.0 Bearer Token bearer token <xref target="RFC6750"/> to the protected resource.
	    Defined values are
	    <spanx style="verb">["header",
	    <tt>["header", "body", "query"]</spanx>, "query"]</tt>,
	    corresponding to Sections 2.1, 2.2, <xref section="2.1" sectionFormat="bare" target="RFC6750"/>, <xref section="2.2" sectionFormat="bare" target="RFC6750"/>, and 2.3 <xref section="2.3" sectionFormat="bare" target="RFC6750"/> of RFC 6750. <xref target="RFC6750"/>.
	    The empty array <spanx style="verb">[]</spanx> <tt>[]</tt> can be used
	    to indicate that no Bearer bearer methods are supported.
	    If this entry is omitted,
	    no default Bearer bearer methods supported are implied,
	    nor does its absence indicate that they are not supported.
	  </t>

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

          <t hangText="resource_name">
	    <vspace/>
	  </dd>
        <dt>resource_name</dt>
        <dd>
	    Human-readable name of the protected resource
	    intended for display to the end-user. end user.
	    It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that protected resource metadata includes include this field.
	    The value of this field MAY <bcp14>MAY</bcp14> be internationalized,
	    as described in <xref target="HumanReadableMetadata"/>.
	  </t>

	  <t hangText="resource_documentation">
	    <vspace/>
	    OPTIONAL.
	  </dd>
        <dt>resource_documentation</dt>
        <dd>
	    <bcp14>OPTIONAL</bcp14>.
	    URL of a page containing human-readable information that
	    developers might want or need to know when using the protected resource.
	    The value of this field MAY <bcp14>MAY</bcp14> be internationalized,
	    as described in <xref target="HumanReadableMetadata"/>.
	  </t>

	  <t hangText="resource_policy_uri">
	    <vspace/>
	    OPTIONAL.
	  </dd>
        <dt>resource_policy_uri</dt>
        <dd>
	    <bcp14>OPTIONAL</bcp14>.
	    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.
	    The value of this field MAY <bcp14>MAY</bcp14> be internationalized,
	    as described in <xref target="HumanReadableMetadata"/>.
	  </t>

	  <t hangText="resource_tos_uri">
	    <vspace/>
	    OPTIONAL.
	  </dd>
        <dt>resource_tos_uri</dt>
        <dd>
	    <bcp14>OPTIONAL</bcp14>.
	    URL of a page containing human-readable information
	    about the protected resource's terms of service.
	    The value of this field MAY <bcp14>MAY</bcp14> be internationalized,
	    as described in <xref target="HumanReadableMetadata"/>.
	  </t>

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

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

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

	  <t hangText="dpop_bound_access_tokens_required">
	    <vspace/>
	    OPTIONAL.
	    A boolean
	  </dd>
        <dt>dpop_bound_access_tokens_required</dt>
        <dd>
	    <bcp14>OPTIONAL</bcp14>.
	    Boolean value specifying whether the protected resource always requires
	    the use of DPoP-bound access tokens <xref target="RFC9449"/>.
	    If omitted, the default value is false.
	  </t>

	</list>
      </t>
	  </dd>
      </dl>
      <t>
	Additional protected resource metadata parameters MAY <bcp14>MAY</bcp14> also be used.
      </t>
      <section anchor="HumanReadableMetadata"
	       title="Human-Readable anchor="HumanReadableMetadata">
        <name>Human-Readable Resource Metadata"> Metadata</name>
        <t>
	  Human-readable resource metadata values
	  and resource metadata values that reference human-readable content
	  MAY
	  <bcp14>MAY</bcp14> be represented in multiple languages and scripts.
	  For example, the values of fields such as
	  <spanx style="verb">resource_name</spanx>,
	  <spanx style="verb">resource_documentation</spanx>,
	  <spanx style="verb">resource_tos_uri</spanx>,
	  <tt>resource_name</tt>,
	  <tt>resource_documentation</tt>,
	  <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
	  to facilitate use in different locations.
        </t>
        <t>
	  To specify the languages and scripts, <xref target="RFC5646">BCP 47</xref> language tags <xref target="BCP47"/>
	  are added to resource metadata parameter names,
	  delimited by a <spanx style="verb">#</spanx> <tt>#</tt> character.
	  Since <xref target="RFC8259">JSON</xref> member names as discussed in <xref target="RFC8259">JSON</xref> are case sensitive,
	  it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that language tag values used in Claim Names be spelled
	  using the character case with which they are registered in the
	  <xref target="IANA.Language">"IANA Language Subtag" registry</xref>. target="IANA.Language">"Language Subtag Registry"</xref>.
	  In particular, normally normally, language names are spelled with lowercase
	  characters, region names are spelled with uppercase characters,
	  and languages are spelled with mixed-case characters.
	  However, since BCP 47 language tag values are case-insensitive, case insensitive per <xref target="BCP47"/>,
	  implementations SHOULD <bcp14>SHOULD</bcp14> interpret the language tag values supplied
	  in a case insensitive case-insensitive manner.
	  Per the recommendations in BCP 47, <xref target="BCP47"/>, language tag values used in
	  metadata parameter names should only be as specific as is necessary.
	  For instance, using <spanx style="verb">fr</spanx> <tt>fr</tt> might be sufficient
	  in many contexts, rather than <spanx style="verb">fr-CA</spanx> <tt>fr-CA</tt>
	  or <spanx style="verb">fr-FR</spanx>. <tt>fr-FR</tt>.
        </t>
        <t>
	  For example, a resource could represent its name in English as
	  <spanx style="verb">"resource_name#en":
	  <tt>"resource_name#en": "My Resource"</spanx> Resource"</tt>
	  and its name in Italian as
	  <spanx style="verb">"resource_name#it":
	  <tt>"resource_name#it": "La mia bella risorsa"</spanx> risorsa"</tt>
	  within its metadata.
	  Any or all of these names MAY <bcp14>MAY</bcp14> be displayed to the end-user, end user,
	  choosing which names to display based on system configuration,
	  user preferences, or other factors.
        </t>
        <t>
	  If any human-readable field is sent without a language tag,
	  parties using it MUST NOT <bcp14>MUST NOT</bcp14> make any assumptions about the language,
	  character set, or script of the string value, and the string value
	  MUST
	  <bcp14>MUST</bcp14> be used as is wherever it is presented in a user interface.
	  To facilitate interoperability, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that
	  each kind of human-readable metadata provided includes include
	  an instance of its metadata parameter without any language tags
	  in addition to any language-specific parameters, and it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that
	  any human-readable fields sent without language tags contain values
	  suitable for display on a wide variety of systems.
        </t>
      </section>
      <section anchor="SignedMetadata" title="Signed anchor="SignedMetadata">
        <name>Signed Protected Resource Metadata"> Metadata</name>
        <t>
	  In addition to JSON elements, metadata values MAY <bcp14>MAY</bcp14> also be provided
	  as a <spanx style="verb">signed_metadata</spanx> <tt>signed_metadata</tt> value,
	  which is a JSON Web Token (JWT) <xref target="JWT"/> target="RFC7519"/>
	  that asserts metadata values about the protected resource as a bundle.
	  A set of metadata parameters that can be used in signed metadata as claims
	  are defined in <xref target="PRMetadata"/>.
	  The signed metadata MUST <bcp14>MUST</bcp14> be digitally signed or MACed
	  (protected with a Message Authentication Code) using a <xref target="JWS">JSON target="RFC7515">JSON Web Signature (JWS)</xref>
	  and MUST <bcp14>MUST</bcp14> contain an <spanx style="verb">iss</spanx> <tt>iss</tt> (issuer) claim
	  denoting the party attesting to the claims in the signed metadata.
	  Consumers of the metadata MAY <bcp14>MAY</bcp14> ignore the signed metadata
	  if they do not support this feature.
	  If the consumer of the metadata supports signed metadata,
	  metadata values conveyed in the signed metadata
	  MUST
	  <bcp14>MUST</bcp14> take precedence over the corresponding values conveyed using plain JSON elements.
        </t>
        <t>
	  Signed metadata is included in the protected resource metadata JSON object
	  using this OPTIONAL <bcp14>OPTIONAL</bcp14> metadata parameter:
	  <list style="hanging">

	    <t hangText="signed_metadata">
	      <vspace/>
        </t>
        <dl newline="true" spacing="normal">
          <dt>signed_metadata</dt>
          <dd>
	      A JWT containing metadata parameters about the protected resource as claims.
	      This is a string value consisting of the entire signed JWT.
	      A <spanx style="verb">signed_metadata</spanx> <tt>signed_metadata</tt>
	      parameter SHOULD NOT <bcp14>SHOULD NOT</bcp14> appear as a claim in the JWT;
	      it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to reject any metadata in which this occurs.
	    </t>

	  </list>
	</t>
	    </dd>
        </dl>
      </section>
    </section>
    <section anchor="PRConfig"
             title="Obtaining anchor="PRConfig">
      <name>Obtaining Protected Resource Metadata"> Metadata</name>
      <t>
	Protected resources supporting metadata
	MUST
	<bcp14>MUST</bcp14> make a JSON document containing metadata as specified in <xref target="PRMetadata"/>
	available at a URL formed by
	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.
	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> <tt>.well-known</tt>
	are defined in <xref target="RFC8615"/>.
	The well-known URI path suffix used MUST <bcp14>MUST</bcp14> be registered in the IANA
	"Well-Known URIs" registry <xref target="IANA.well-known"/>.
	Examples of this construction can be found in <xref target="PRConfigurationRequest"/>.
      </t>
      <t>
	The term "application", as used below (and as used in <xref target="RFC8414"/>),
	encompasses all the components used to accomplish the task for the use case.
	That can include OAuth clients, authorization servers, protected resources,
	and non-OAuth components, inclusive of the code running in each of them.
	Applications are built to solve particular problems
	and may utilize many components and services.
      </t>
      <t>
	Different applications utilizing OAuth protected resources in application-specific ways
	MAY
	<bcp14>MAY</bcp14> define and register different well-known URI path suffixes
	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, way
	and there are Example-specific metadata values that it needs to publish,
	then it might register and use the
	<spanx style="verb">example-protected-resource</spanx>
	<tt>example-protected-resource</tt> URI path suffix and publish
	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
	protected resource's resource identifier.
	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,
	and not register an application-specific one.
      </t>
      <t>
	An OAuth 2.0 application using this specification MUST <bcp14>MUST</bcp14> specify
	what well-known URI suffix it will use for this purpose.
	The same protected resource MAY <bcp14>MAY</bcp14> choose to publish its metadata at multiple
	well-known locations derived from its resource identifier, identifier --
	for example, publishing metadata at both
	<spanx style="verb">/.well-known/example-protected-resource</spanx>
	<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>
      <section anchor="PRConfigurationRequest"
	       title="Protected anchor="PRConfigurationRequest">
        <name>Protected Resource Metadata Request"> Request</name>
        <t>
	  A protected resource metadata document MUST <bcp14>MUST</bcp14> be queried using an HTTP
	  <spanx style="verb">GET</spanx>
	  <tt>GET</tt> request at the previously specified URL.
        </t>
        <t>
	  The consumer of the metadata would make the following request when the
	  resource identifier is <spanx style="verb">https://resource.example.com</spanx> <tt>https://resource.example.com</tt>
	  and the well-known URI path suffix is <spanx style="verb">oauth-protected-resource</spanx> <tt>oauth-protected-resource</tt>
	  to obtain the metadata,
	  since the resource identifier contains no path component:
        </t>
        <t>
	  <figure>
            <artwork><![CDATA[
        <sourcecode type="http-message"><![CDATA[
  GET /.well-known/oauth-protected-resource HTTP/1.1
  Host: resource.example.com
]]></artwork>
          </figure>
	</t>
]]></sourcecode>
        <t>
	  If the resource identifier value contains a path or query component,
	  any terminating <spanx style="verb">/</spanx> slash (<tt>/</tt>) following the host component
	  MUST
	  <bcp14>MUST</bcp14> be removed before inserting
	  <spanx style="verb">/.well-known/</spanx>
	  <tt>/.well-known/</tt> and the well-known URI path suffix
	  between the host component and the path and/or query components.
	  The consumer of the metadata would make the following request when the
	  resource identifier is <spanx style="verb">https://resource.example.com/resource1</spanx> <tt>https://resource.example.com/resource1</tt>
	  and the well-known URI path suffix is <spanx style="verb">oauth-protected-resource</spanx> <tt>oauth-protected-resource</tt>
	  to obtain the metadata,
	  since the resource identifier contains a path component:
        </t>
        <t>
	  <figure>
            <artwork><![CDATA[
        <sourcecode type="http-message"><![CDATA[
  GET /.well-known/oauth-protected-resource/resource1 HTTP/1.1
  Host: resource.example.com
]]></artwork>
          </figure>
	</t>
]]></sourcecode>
        <t>
	  Using path components enables supporting multiple resources per host.
	  This is required in some multi-tenant hosting configurations.
	  This use of <spanx style="verb">.well-known</spanx> <tt>.well-known</tt> is for supporting
	  multiple resources per host; unlike its use in
	  <xref target="RFC8615"/>, it does not provide
	  general information about the host.
        </t>
      </section>
      <section anchor="PRConfigurationResponse"
	       title="Protected anchor="PRConfigurationResponse">
        <name>Protected Resource Metadata Response"> Response</name>
        <t>
	  The response is a set of metadata parameters about the protected resource's
	  configuration.
	  A successful response MUST <bcp14>MUST</bcp14> use the 200 OK HTTP status code and return
	  a JSON object using the <spanx style="verb">application/json</spanx> <tt>application/json</tt> content type
	  that contains a set of metadata parameters as its members
	  that are a subset of the metadata parameters defined in
	  <xref target="PRMetadata"/>.
	  Additional metadata parameters MAY <bcp14>MAY</bcp14> be defined and used;
	  any metadata parameters that are not understood MUST <bcp14>MUST</bcp14> be ignored.
        </t>
        <t>
	  Parameters with multiple values are represented as JSON arrays.
	  Parameters with zero values MUST <bcp14>MUST</bcp14> be omitted from the response.
        </t>
        <t>
	  An error response uses the applicable HTTP status code value.
        </t>
        <t>
	  <figure>
	    <preamble>The
        <t keepWithNext="true">The following is a non-normative example response:</preamble>

            <artwork><![CDATA[ response:</t>
        <sourcecode type="http-message"><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: application/json

  {
   "resource":
     "https://resource.example.com",
   "authorization_servers":
     ["https://as1.example.com",
      "https://as2.example.net"],
   "bearer_methods_supported":
     ["header", "body"],
   "scopes_supported":
     ["profile", "email", "phone"],
   "resource_documentation":
     "https://resource.example.com/resource_documentation.html"
  }
]]></artwork>
          </figure>
	</t>
]]></sourcecode>
      </section>
      <section anchor="PRConfigurationValidation"
	       title="Protected anchor="PRConfigurationValidation">
        <name>Protected Resource Metadata Validation"> Validation</name>
        <t>
	  The <spanx style="verb">resource</spanx> <tt>resource</tt> value returned MUST <bcp14>MUST</bcp14> be identical to
	  the protected resource's resource identifier value into which
	  the well-known URI path suffix was inserted to create the URL
	  used to retrieve the metadata.
	  If these values are not identical, the data contained in the response MUST NOT <bcp14>MUST NOT</bcp14> be used.
        </t>
        <t>
	  If the protected resource metadata was retrieved from a URL
	  returned by the protected resource via the <spanx style="verb">WWW-Authenticate</spanx>
	  <spanx style="verb">resource_metadata</spanx> <tt>WWW-Authenticate</tt>
          <tt>resource_metadata</tt> parameter, then
	  the <spanx style="verb">resource</spanx> <tt>resource</tt> value returned MUST <bcp14>MUST</bcp14> be identical to
	  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 MUST NOT <bcp14>MUST NOT</bcp14> be used.
        </t>
        <t>
	  These validation actions can thwart impersonation attacks,
	  as described in <xref target="Impersonation"/>.
        </t>
        <t>
	  The recipient MUST <bcp14>MUST</bcp14> validate that any signed metadata was signed
	  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,
	  the recipient SHOULD <bcp14>SHOULD</bcp14> treat this as an error condition.
        </t>
      </section>
    </section>
    <section anchor="ASMetadata" title="Authorization anchor="ASMetadata">
      <name>Authorization Server Metadata"> Metadata</name>
      <t>
	To support use cases in which the set of legitimate protected resources
	to use with the authorization server is enumerable,
	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 resources.
	Note that if the set of legitimate authorization servers
	to use with a protected resource is also enumerable,
	lists in the authorization server metadata and protected resource metadata
	should be cross-checked against one another for consistency
	when these lists are used by the application profile.
      </t>
      <t>
	The following authorization server metadata parameter
	is defined by this specification and is registered in the IANA
	"OAuth Authorization Server Metadata" registry established in
	<xref target="RFC8414">OAuth 2.0 Authorization Server Metadata</xref>.

	<list style="hanging">

	  <t hangText="protected_resources">
	    <vspace/>
	    OPTIONAL.
"<xref target="RFC8414" format="title"/>" <xref target="RFC8414" format="default"/>.

      </t>
      <dl newline="true" spacing="normal">
        <dt>protected_resources</dt>
        <dd>
	    <bcp14>OPTIONAL</bcp14>.
	    JSON array containing a list of resource identifiers for OAuth protected resources
	    for protected resources
	    that can be used with this authorization server.
	    Authorization servers MAY <bcp14>MAY</bcp14> choose not to advertise some supported protected resources
	    even when this parameter is used.
	    In some use cases, the set of protected resources will not be enumerable,
	    in which case this metadata parameter will not be present.
	  </t>

	</list>
      </t>
	  </dd>
      </dl>
    </section>
    <section anchor="WWW-Authenticate" title="Use anchor="WWW-Authenticate">
      <name>Use of WWW-Authenticate for Protected Resource Metadata"> Metadata</name>
      <t>
	A protected resource MAY <bcp14>MAY</bcp14> use the <spanx style="verb">WWW-Authenticate</spanx>
	<xref target="RFC9110"/> <tt>WWW-Authenticate</tt>
        HTTP response header field field, as discussed in <xref target="RFC9110"/>,
	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 might then, for instance, determine what authorization server to use for the resource
	based on protected resource metadata retrieved.
      </t>
      <t>
	A typical end-to-end flow doing so is as follows.
	Note that while this example uses the OAuth 2.0 Authorization Code authorization code flow,
	a similar sequence could also be implemented with any other OAuth flow.
      </t>

	<!--
			 Diagram Source:
	     https://www.websequencediagrams.com/?lz=cGFydGljaXBhbnQgQ2xpZW50CgAHDCJSZXNvdXJjZVxuU2VydmVyIiBhcyBSUwAXDkF1dGhvcml6YXRpb24AHQ1BUwoKAFEGLT5SUzogMS4gAEoIIFJlcXVlc3RcbldpdGhvdXQgQWNjZXNzIFRva2VuClJTLS0-AIEMBjogMi4gV1dXLUF1dGhlbnRpY2F0ZQBKDTMuIEZldGNoIFJTIE1ldGFkYXRhADQONC4AEAwgUmVzcG9uc2UKbm90ZSBvdmVyAIF3BzogNS4gVmFsaWRhdGUAQwwsXG5CdWlsZCBBADwLVVJMAIFWCUFTOiA2AIEACAAaCwpBAIE-DDcuADQNAG8ZLCBBUzogOC05LiBPQXV0aCAAglcNIEZsb3dcbgCDKwYgT2J0YWlucwCCMg4AgmkNMACCYxR3aXRoAIJZGzEAgx4OAIIpBw&s=default
	-->
      <t>
      <figure>
        <name>Sequence Diagram</name>
        <artset>
          <artwork type="svg" name="sequence.svg">
			<svg xmlns="http://www.w3.org/2000/svg" baseProfile="tiny" height="550" version="1.2" viewBox="0 0 478 550" width="478" xmlns="http://www.w3.org/2000/svg"> width="478">
              <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-width="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>
              <rect fill="white" height="48" stroke="black" stroke-width="1" width="62" x="67.5" y="468.5"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="79.23567708333343" y="497.35416666666663">
			    Client  </text>
              <path d="M-53,-405.00000000000017 L-53,0" fill="none" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <rect fill="white" height="48" stroke="black" stroke-width="1" width="85" x="255.5" y="15.5"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="266.95833333333337" y="37.03124999999985">
			    Resource  </text>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="276.11523437500006" y="52.552083333333165">
			    Server  </text>
              <rect fill="white" height="48" stroke="black" stroke-width="1" width="85" x="255.5" y="468.5"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="266.95833333333337" y="489.59375">
			    Resource  </text>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="276.11523437500006" y="505.1145833333333">
			    Server  </text>
              <path d="M56,-405.00000000000017 L56,0" fill="none" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <rect fill="white" height="48" stroke="black" stroke-width="1" width="112" x="350.5" y="15.5"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="362.00390625" y="37.03124999999985">
			    Authorization  </text>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="384.7936197916667" y="52.552083333333165">
			    Server  </text>
              <rect fill="white" height="48" stroke="black" stroke-width="1" width="112" x="350.5" y="468.5"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="362.00390625" y="489.59375">
			    Authorization  </text>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="384.7936197916667" y="505.1145833333333">
			    Server  </text>
              <rect fill="white" height="15.333333333333314" width="137.99479166666669" x="129.25911458333337" y="76.8333333333332"/>
              <rect fill="white" height="15.333333333333314" width="147.43489583333334" x="124.53906250000003" y="92.35416666666652"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="129.25911458333337" y="90.16666666666653">
			    1. Resource Request  </text>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="124.53906250000003" y="105.68749999999984">
			    Without Access Token  </text>
              <path d="M-251.4641927083333,-360 L-53.02278645833337,-360" fill="none" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <path d="M-54,-360 L-54,-360 L-62,-368 L-62,-360 L-62,-352 L-54,-360" fill="black" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <rect fill="white" height="15.333333333333314" width="147.08984375" x="124.71158854166669" y="122.2083333333332"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="124.71158854166669" y="135.54166666666654">
			    2. WWW-Authenticate  </text>
              <path d="M-251.4641927083333,-330 L-53.022786458333314,-330" fill="none" stroke="black" stroke-dasharray="5,3" stroke-width="1" transform="translate(350.5 468.5)"/>
              <path d="M-251,-330 L-251,-330 L-243,-338 L-243,-330 L-243,-322 L-251,-330" fill="black" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <rect fill="white" height="15.333333333333314" width="143.18359375" x="126.66471354166669" y="152.0624999999999"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="126.66471354166669" y="165.39583333333323">
			    3. Fetch RS Metadata  </text>
              <path d="M-251.4641927083333,-300 L-53.022786458333314,-300" fill="none" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <path d="M-54,-300 L-54,-300 L-62,-308 L-62,-300 L-62,-292 L-54,-300" fill="black" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <rect fill="white" height="15.333333333333314" width="170.93750000000003" x="112.78776041666671" y="181.91666666666657"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="112.78776041666671" y="195.24999999999991">
			    4. RS Metadata Response  </text>
              <path d="M-251.4641927083333,-270 L-53.02278645833326,-270" fill="none" stroke="black" stroke-dasharray="5,3" stroke-width="1" transform="translate(350.5 468.5)"/>
              <path d="M-251,-270 L-251,-270 L-243,-278 L-243,-270 L-243,-262 L-251,-270" fill="black" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <path d="M-340,-257 L-340,-257 L-172,-257 L-164,-249 L-164,-209 L-340,-209 L-340,-257" fill="white" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <path d="M-171.5592447916666,-256.72916666666674 L-171.5592447916666,-248.72916666666674 L-163.5592447916666,-248.72916666666674" fill="none" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="15.882812500000057" y="232.86458333333326">
			    5. Validate RS Metadata,  </text>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="15.882812500000057" y="248.3854166666666">
			    Build AS Metadata URL  </text>
              <rect fill="white" height="15.333333333333371" width="143.04036458333337" x="181.07552083333337" y="272.66666666666663"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="181.07552083333337" y="285.99999999999994">
			    6. Fetch AS Metadata  </text>
              <path d="M-251.46419270833326,-179 L55.65559895833337,-179" fill="none" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <path d="M55,-179 L55,-179 L47,-187 L47,-179 L47,-171 L55,-179" fill="black" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <rect fill="white" height="15.333333333333314" width="170.79427083333337" x="167.19856770833337" y="302.5208333333333"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="167.19856770833337" y="315.85416666666663">
			    7. AS Metadata Response  </text>
              <path d="M-251.46419270833326,-149 L55.65559895833337,-149" fill="none" stroke="black" stroke-dasharray="5,3" stroke-width="1" transform="translate(350.5 468.5)"/>
              <path d="M-251,-149 L-251,-149 L-243,-157 L-243,-149 L-243,-141 L-251,-149" fill="black" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <path d="M-257,-136 L-257,-136 L54,-136 L62,-128 L62,-89 L-257,-89 L-257,-136" fill="white" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <path d="M53.65559895833337,-136.125 L53.65559895833337,-128.125 L61.65559895833337,-128.125" fill="none" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="152.48828125000006" y="353.46874999999994">
			    8-9. OAuth Authorization Flow  </text>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="152.48828125000006" y="368.9895833333333">
			    Client Obtains Access Token  </text>
              <rect fill="white" height="15.333333333333314" width="146.47786458333331" x="125.01757812500006" y="393.2708333333333"/>
              <rect fill="white" height="15.333333333333371" width="123.32031250000003" x="136.5963541666667" y="408.79166666666663"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="125.01757812500006" y="406.60416666666663">
			    10. Resource Request  </text>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="136.5963541666667" y="422.12499999999994">
			    with
			    With Access Token  </text>
              <path d="M-251.46419270833326,-43 L-53.02278645833326,-43" fill="none" 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" fill="black" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
              <rect fill="white" height="15.333333333333371" width="156.35416666666669" x="120.07942708333337" y="438.6458333333333"/>
              <text fill="black" font-family="sans-serif" font-size="13.333333333333334" x="120.07942708333337" y="451.97916666666663">
			    11. Resource Response  </text>
              <path d="M-251.46419270833326,-13 L-53.022786458333314,-13" fill="none" stroke="black" stroke-dasharray="5,3" stroke-width="1" transform="translate(350.5 468.5)"/>
              <path d="M-251,-13 L-251,-13 L-243,-21 L-243,-13 L-243,-5 L-251,-13" fill="black" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
            </svg>
          </artwork>
          <artwork type="ascii-art" name="sequence.txt"><![CDATA[
     +----------+              +----------+    +---------------+
     |  Client  |              | Resource |    | Authorization |
     |          |              |  Server  |    |    Server     |
     +----+-----+              +----+-----+    +-------+-------+
          |                         |                  |
          |  1. Resource Request    |                  |
          | ----------------------> |                  |
          |  Without Access Token   |                  |
          |                         |                  |
          |                         |                  |
          |   2. WWW-Authenticate   |                  |
          | <---------------------- |                  |
          |                         |                  |
          |                         |                  |
          |   3. Fetch RS Metadata  |                  |
          | ----------------------> |                  |
          |                         |                  |
          |                         |                  |
          | 4. RS Metadata Response |                  |
          | <---------------------- |                  |
          |                         |                  |
+---------+---------------+         |                  |
| 5. Validate RS Metadata |         |                  |
| Build AS Metadata URL   |         |                  |
+---------+---------------+         |                  |
          |                         |                  |
          |   6. Fetch AS Metadata  |                  |
          | ------------------------+----------------> |
          |                         |                  |
          |                         |                  |
          | 7. AS Metadata Response |                  |
          | <-----------------------+----------------- |
          |                         |                  |
        +-+-------------------------+------------------+-+
        |       8-9. OAuth Authorization Code Flow       |
        |            Client Obtains Access Token         |
        +-+-------------------------+------------------+-+
          |                         |                  |
          |  10. Resource Request   |                  |
          | ----------------------> |                  |
          |  With Access Token      |                  |
          |                         |                  |
          |                         |                  |
          |  11. Resource Response  |                  |
          | <---------------------- |                  |
          |                         |                  |
     +----+-----+              +----+-----+    +-------+-------+
     |  Client  |              | Resource |    | Authorization |
     |          |              |  Server  |    |    Server     |
     +----------+              +----------+    +---------------+
]]></artwork>
        </artset>
      </figure>

      </t>
      <t>
	<list style="numbers">
      <ol spacing="normal" type="1"><li>
          <t>
	    The client makes a request to a protected resource without presenting an access token.
          </t>
        </li>
        <li>
          <t>
	    The resource server responds with a <spanx style="verb">WWW-Authenticate</spanx> <tt>WWW-Authenticate</tt> header including the URL of the protected resource metadata.
          </t>
        </li>
        <li>
          <t>
	    The client fetches the protected resource metadata from this URL.
          </t>
        </li>
        <li>
          <t>
	    The resource server responds with the protected resource metadata
	    according to <xref target="PRConfigurationResponse"/>.
          </t>
        </li>
        <li>
          <t>
	    The client validates the protected resource metadata,
	    as described in <xref target="PRConfigurationValidation"/>.
	  </t>
	  <t>
	    The client target="PRConfigurationValidation"/>,
            and builds the authorization server metadata URL from an issuer
            identifier in the resource metadata according to <xref target="RFC8414"/>
	    and target="RFC8414"/>.
          </t>
        </li>
        <li>
          <t>
	    The client makes a request to fetch the authorization server metadata.
          </t>
        </li>
        <li>
          <t>
	    The authorization server responds with the authorization server metadata document according to <xref target="RFC8414"/>.
          </t>
        </li>
        <li>
          <t>
	    The client directs the user agent to the authorization server to begin the authorization flow.
          </t>
        </li>
        <li>
          <t>
	    The authorization exchange is completed and the authorization server returns an access token to the client.
          </t>
        </li>
        <li>
          <t>
	    The client repeats the resource request from step 1, presenting the newly obtained access token.
          </t>
        </li>
        <li>
          <t>
	    The resource server returns the requested protected resource.
          </t>
	</list>
      </t>
        </li>
      </ol>
      <section anchor="WWW-Authenticate-Response" title="WWW-Authenticate Response"> anchor="WWW-Authenticate-Response">
        <name>WWW-Authenticate Response</name>
        <t>
	  This specification introduces a new parameter in the
	  <spanx style="verb">WWW-Authenticate</spanx>
	  <tt>WWW-Authenticate</tt> HTTP response header field
	  to indicate the protected resource metadata URL:
            <list style='hanging'>
              <t hangText='resource_metadata:'>
                <vspace/>
        </t>
        <dl newline="true" spacing="normal">
          <dt>resource_metadata:</dt>
          <dd>
		The URL of the protected resource metadata.
	      </t>
	    </list>
	</t>
	<t>
	  <figure>
	    <preamble>The
	      </dd>
        </dl>
        <t keepWithNext="true">The response below is an example of a <spanx style="verb">WWW-Authenticate</spanx> <tt>WWW-Authenticate</tt> header that includes the resource identifier.</preamble>

	    <artwork><![CDATA[ identifier.</t>
        <sourcecode type="http-message"><![CDATA[
HTTP/1.1 400 Bad Request 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_request",
    error_description="No access token was provided in this request", resource_metadata=
  "https://resource.example.com/.well-known/oauth-protected-resource"
]]></artwork>
	  </figure>
	</t>
]]></sourcecode>
        <t>
	  The HTTP status code and error string in the example response above
	  are
	  is defined by <xref target="RFC6750"/>.
        </t>
        <t>
	  This parameter MAY <bcp14>MAY</bcp14> also be used in
	  <spanx style="verb">WWW-Authenticate</spanx>
	  <tt>WWW-Authenticate</tt> responses using
	  <spanx style="verb">Authorization</spanx>
	  <tt>authorization</tt> schemes other than
	  <spanx style="verb">Bearer</spanx>
	  <tt>"Bearer"</tt> <xref target="RFC6750"/>,
	  such as the <spanx style="verb">DPoP</spanx> <tt>DPoP</tt> scheme
	  defined by <xref target="RFC9449"/>.
        </t>
        <t>
	  The <spanx style="verb">resource_metadata</spanx> <tt>resource_metadata</tt> parameter MAY <bcp14>MAY</bcp14> be combined with other parameters defined in other extensions,
	  such as the <spanx style="verb">max_age</spanx> <tt>max_age</tt> parameter defined by <xref target="RFC9470"/>.
        </t>
      </section>
      <section anchor="changes" title="Changes anchor="changes">
        <name>Changes to Resource Metadata"> Metadata</name>
        <t>
	  At any point, for any reason determined by the resource server,
	  the protected resource MAY <bcp14>MAY</bcp14> respond with a new <spanx style="verb">WWW-Authenticate</spanx> <tt>WWW-Authenticate</tt> challenge
	  that includes a value for the protected resource metadata URL to indicate that its metadata may have changed.
	  If the client receives such a <spanx style="verb">WWW-Authenticate</spanx> <tt>WWW-Authenticate</tt> response,
	  it SHOULD <bcp14>SHOULD</bcp14> retrieve the updated protected resource metadata
	  and use the new metadata values obtained, after validating them
	  as described in <xref target="PRConfigurationValidation"/>.
	  Among other things,
	  this enables a resource server to change which authorization servers it uses without any other coordination with clients.
        </t>
      </section>
      <section anchor="assumptions" title="Client anchor="assumptions">
        <name>Client Identifier and Client Authentication"> Authentication</name>
        <t>
	  The way in which the client identifier is established at the authorization server is out of scope of for this specification.
        </t>
        <t>

	  This specification is intended to be deployed in scenarios where the client has no prior knowledge about the resource server, server
	  and where the resource server might or might not have prior knowledge about the client.
        </t>
        <t>
	  There are some existing methods by which an unrecognized client can make use of an authorization server,
	  such as using Dynamic Client Registration <xref target="RFC7591"/>
	  to register the client prior to initiating the authorization flow.
	  Future OAuth extensions might define alternatives, such as using URLs to identify clients.
        </t>
      </section>
      <section anchor="compatibility" title="Compatibility anchor="compatibility">
        <name>Compatibility with Other Authentication Methods"> Methods</name>
        <t>
	  Resource servers MAY <bcp14>MAY</bcp14> return other <spanx style="verb">WWW-Authenticate</spanx> <tt>WWW-Authenticate</tt> headers indicating various authentication schemes.
	  This allows the resource server to support clients that may or may not implement this specification, specification
	  and allows clients to choose their preferred authentication scheme.
        </t>
      </section>
    </section>
    <section anchor="StringOps" title="String Operations"> anchor="StringOps">
      <name>String Operations</name>
      <t>
	Processing some OAuth 2.0 messages requires comparing
	values in the messages to known values. For example, the
	member names in the metadata response might be
	compared to specific member names such as <spanx
	style="verb">resource</spanx>. <tt>resource</tt>.  Comparing Unicode strings <xref target="UNICODE"/> strings, target="UNICODE"/>,
	however, has significant security implications.
      </t>
      <t>
	Therefore, comparisons between JSON strings and other Unicode
	strings MUST <bcp14>MUST</bcp14> be performed as specified below:

	<list style="numbers">

      </t>
      <ol spacing="normal" type="1"><li>
          <t>
	    Remove any JSON applied JSON-applied escaping to produce an array of
	    Unicode code points.
          </t>
        </li>
        <li>
          <t>
	    Unicode Normalization <xref target="USA15"/> MUST NOT <bcp14>MUST NOT</bcp14>
	    be applied at any point to either the JSON string or to
	    the string it is to be compared against.
          </t>
        </li>
        <li>
          <t>
	    Comparisons between the two strings MUST <bcp14>MUST</bcp14> be performed as a
	    Unicode code point to code point code-point-to-code-point equality comparison.
          </t>

        </list>
      </t>
        </li>
      </ol>
      <t>
	Note that this is the same equality comparison procedure as that described in
	Section 8.3 of
	<xref section="8.3" sectionFormat="of" target="RFC8259"/>.
      </t>
    </section>
    <section anchor="Security" title="Security Considerations"> anchor="Security">
      <name>Security Considerations</name>
      <section anchor="TLSRequirements" title="TLS Requirements"> anchor="TLSRequirements">
        <name>TLS Requirements</name>
        <t>
	  Implementations MUST <bcp14>MUST</bcp14> support TLS.
	  They MUST <bcp14>MUST</bcp14> follow the guidance in
	  BCP 195 <xref target="RFC8996"/>
	  <xref target="RFC9325"/>, target="BCP195"/>,
	  which provides recommendations and requirements
	  for improving the security of deployed services that use TLS.
        </t>
        <t>
	  Use
	  The use of TLS at the protected resource metadata URLs
	  protects against information disclosure and tampering.
        </t>
      </section>
      <section anchor="Scopes" title="Scopes"> anchor="Scopes">
        <name>Scopes</name>
        <t>
					The <spanx style="verb">scopes_supported</spanx> <tt>scopes_supported</tt> parameter is the list of scopes the resource server is willing to disclose that it supports. It is not meant to indicate that an OAuth client should request all scopes in the list. The client SHOULD <bcp14>SHOULD</bcp14> still follow OAuth best practices and request tokens with as limited a scope as possible for the given operation, as described in Section 2.3 of OAuth 2.0 Security Best
<xref section="2.3" sectionFormat="of" target="RFC9700">"Best Current Practice <xref target="I-D.ietf-oauth-security-topics"/>. for OAuth 2.0 Security"</xref>.
        </t>
      </section>
      <section anchor="Impersonation" title="Impersonation Attacks"> anchor="Impersonation">
        <name>Impersonation Attacks</name>
        <t>
	  TLS certificate checking MUST <bcp14>MUST</bcp14> be performed by the client
	  as described in <xref target="RFC9525"/>
	  when making a protected resource metadata request.
	  Checking that the server certificate is valid for the resource identifier URL
	  prevents man-in-middle adversary-in-the-middle and DNS-based attacks.
	  These attacks could cause a client to be tricked into using an attacker's
	  resource server, which would enable impersonation of the legitimate protected resource.
	  If an attacker can accomplish this, they can access the resources
	  that the affected client has access to to,
	  using the protected resource that they are impersonating.
        </t>
        <t>
	  An attacker may also attempt to impersonate a protected resource by publishing
	  a metadata document that contains a <spanx style="verb">resource</spanx> <tt>resource</tt> metadata parameter
	  using the resource identifier URL of the protected resource being impersonated, impersonated
	  but containing that contains information of the attacker's choosing.
	  This would enable it to impersonate that protected resource, if accepted by the client.
	  To prevent this, the client MUST <bcp14>MUST</bcp14> ensure that the resource identifier URL it is using
	  as the prefix for the metadata request exactly matches the value of
	  the <spanx style="verb">resource</spanx> <tt>resource</tt> metadata parameter
	  in the protected resource metadata document received by the client,
	  as described in <xref target="PRConfigurationValidation"/>.
        </t>
      </section>
      <section anchor="AudienceRestriction" title="Audience-Restricted anchor="AudienceRestriction">
        <name>Audience-Restricted Access Tokens"> Tokens</name>
        <t>
      		If a client expects to interact with multiple resource servers, the client
      		SHOULD
      		<bcp14>SHOULD</bcp14> request audience-restricted access tokens using <xref target="RFC8707"/>,
      		and the authorization server SHOULD <bcp14>SHOULD</bcp14> support audience-restricted access tokens.
        </t>
        <t>
      		Without audience-restricted access tokens, a malicious resource server (RS1) may be
      		able to use the <spanx style="verb">WWW-Authenticate</spanx> <tt>WWW-Authenticate</tt> header to get a client
      		to request an access token with a scope used by a legitimate resource server (RS2), and
      		after the client sends a request to RS1, then RS1 could re-use reuse the access token at RS2.
        </t>
        <t>
      		While this attack is not explicitly enabled by this specification, specification and is possible in
      		a plain OAuth 2.0 deployment, it is made somewhat more likely by the use of
      		dynamically-configured
      		dynamically configured clients. As such, the use
      		of audience-restricted access tokens and Resource Indicators <xref target="RFC8707"/>
      		is RECOMMENDED <bcp14>RECOMMENDED</bcp14> when using the features in this specification.
        </t>
      </section>
      <section anchor="StandardFormat" title="Publishing anchor="StandardFormat">
        <name>Publishing Metadata in a Standard Format"> Format</name>
        <t>
	  Publishing information about the protected resource in a standard format
	  makes it easier for both legitimate clients and attackers
	  to use the protected resource.
	  Whether a protected resource publishes its metadata in an ad-hoc ad hoc manner
	  or in the standard format defined by this specification,
	  the same defenses against attacks that might be mounted
	  that use this information should be applied.
        </t>
      </section>
      <section anchor="AuthorizationServers" title="Authorization Servers"> anchor="AuthorizationServers">
        <name>Authorization Servers</name>
        <t>
	  To support use cases in which the set of legitimate authorization servers
	  to use with the protected resource is enumerable,
	  this specification defines the <spanx style="verb">authorization_servers</spanx> <tt>authorization_servers</tt>
	  metadata parameter, which enables explicitly listing them.
	  Note that if the set of legitimate protected resources
	  to use with an authorization server is also enumerable,
	  lists in the protected resource metadata and authorization server metadata
	  should be cross-checked against one another for consistency
	  when these lists are used by the application profile.
        </t>
        <t>
	  Secure determination of appropriate authorization servers
	  to use with a protected resource for all use cases
	  is out of scope of for this specification.
	  This specification assumes that the client has a means of determining
	  appropriate authorization servers to use with a protected resource
	  and that the client is using the correct metadata
	  for each protected resource.
	  Implementers need to be aware that if an inappropriate authorization server
	  is used by the client, that an attacker may be able to act as
	  a man-in-the-middle
	  an adversary-in-the-middle proxy to a valid authorization server without
	  it being detected by the authorization server or the client.
        </t>
        <t>
	  The ways to determine the appropriate authorization servers to use
	  with a protected resource are are, in general, application-dependent. application dependent.
          For instance, some protected resources are used with a
          fixed authorization server or a set of authorization servers,
          the locations of which may be well known,
	  or which known via out-of-band mechanisms.
          Alternatively, as described in this specification, the locations
          of the authorization servers could be published as metadata values by the protected resource.
          resource as metadata values.
	  In other cases, the set of authorization servers that can be used with
	  a protected resource can by be dynamically changed
	  by administrative actions
	  or by changes to the set of authorization servers adhering to a trust framework.
	  Many other means of determining appropriate associations between
	  protected resources and authorization servers are also possible.
        </t>
      </section>
      <section anchor="SSRF" title="Server-Side anchor="SSRF">
        <name>Server-Side Request Forgery (SSRF)"> (SSRF)</name>
        <t>
					The OAuth client is expected to fetch the authorization server metadata based on the value of the issuer in the resource server metadata. Since this specification enables clients to interoperate with RSs and ASs ASes it has no prior knowledge of, this opens a risk for SSRF Server-Side Request Forgery (SSRF) attacks by malicious users or malicious resource servers. Clients SHOULD <bcp14>SHOULD</bcp14> take appropriate precautions against SSRF attacks, such as blocking requests to internal IP address ranges. Further recommendations can be found in the OWASP Open Worldwide Application Security Project (OWASP) SSRF Prevention Cheat Sheet <xref target="OWASP.SSRF"/>.
        </t>
      </section>
      <section anchor="phishing" title="Phishing"> anchor="phishing">
        <name>Phishing</name>
        <t>
      		This specification may be deployed in a scenario where the desired HTTP resource is identified by a user-selected URL. If this resource is malicious or compromised, it could mislead the user into revealing their account credentials or authorizing unwanted access to OAuth-controlled capabilities. This risk is reduced, but not eliminated, by following best practices for OAuth user interfaces, such as providing clear notice to the user, displaying the authorization server's domain name, supporting origin-bound phishing-resistant authenticators, supporting the use of password managers, and applying heuristic checks such as domain reputation.
        </t>
      </section>
      <section anchor="UnsignedMetadata"
	       title="Differences between anchor="UnsignedMetadata">
        <name>Differences Between Unsigned and Signed Metadata"> Metadata</name>
        <t>
	  Unsigned metadata is integrity protected by the use of TLS at the site
	  where it is hosted.
	  This means that its security is dependent upon the Internet
	  Public Key Infrastructure (PKI) using X.509 (PKIX), as described in <xref target="RFC9525"/>.
	  Signed metadata is additionally integrity protected by the JWS signature
	  applied by the issuer, which is not dependent upon the Internet PKI.
        </t>
        <t>
	  When using unsigned metadata, the party issuing the metadata
	  is the protected resource itself, which is represented by the
	  <spanx style="verb">resource</spanx>
	  <tt>resource</tt> value in the metadata.
	  Whereas, metadata,
	  whereas when using signed metadata, the party issuing the metadata
	  is represented by the <spanx style="verb">iss</spanx> <tt>iss</tt> (issuer) claim
	  in the signed metadata.
	  When using signed metadata, applications can make trust decisions
	  based on the issuer that performed the signing --
	  information that is not available when using unsigned metadata.
	  How these trust decisions are made is out of scope for this specification.
        </t>
      </section>
      <section anchor="caching" title="Metadata Caching"> anchor="caching">
        <name>Metadata Caching</name>
        <t>
	  Protected resource metadata is retrieved using an HTTP
	  <spanx style="verb">GET</spanx>
	  <tt>GET</tt> request,
	  as specified in <xref target="PRConfigurationRequest"/>.
	  Normal HTTP caching behaviors apply, meaning that the GET <tt>GET</tt> request may retrieve
	  a cached copy of the content, rather than the latest copy.
	  Implementations should utlize utilize HTTP caching directives such as
	  <spanx style="verb">Cache-Control</spanx>
	  <tt>Cache-Control</tt>
	  with <spanx style="verb">max-age</spanx>, <tt>max-age</tt>,
	  as defined in <xref target="RFC7234"/>, target="RFC9111"/>,
	  to enable caching of retrieved metadata for appropriate time periods.
        </t>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations">

      <t>
	The following registration procedure is used for the
	registry established by this specification.
      </t> anchor="IANA">
      <name>IANA Considerations</name>
      <t>
	Values are registered on a via Specification Required <xref target="RFC8126"/>
	basis after target="RFC8126"/>.
        Registration requests should be sent to &lt;oauth-ext-review@ietf.org&gt;
	to initiate a two-week review period on the oauth-ext-review@ietf.org
	mailing list, on the advice of one or more Designated Experts. period.
	However, to allow for the allocation of values prior to publication
	of the final version of a specification,
	the Designated Experts designated experts may approve registration once they are satisfied
	that the specification will be completed and published.
	However, if the specification is not completed and published
	in a timely manner, as determined by the Designated Experts, designated experts,
	the Designated Experts designated experts may request that IANA withdraw the registration.
      </t>
      <t>
	Registration requests sent to the mailing list for review should use
	an appropriate subject
	(e.g., "Request to register OAuth Protected Resource Metadata: example").
      </t>
      <t>
	Within the review period, the Designated Experts designated experts will either approve or
	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
	the request successful.
	The IANA escalation process is followed when    If the Designated Experts designated experts are not responsive within 14 days.
      </t>
      <t>
	Criteria that responsive, the registration requesters should be applied by contact IANA to escalate the process.
      </t>
      <t>
        Designated Experts includes
	determining whether experts should apply the following criteria when reviewing
        proposed registration duplicates registrations: They must be unique -- that is, they should not
        duplicate existing functionality,
	determining whether it is functionality; they are likely generally applicable,
        as opposed to be of general applicability
	or whether it is useful only being used for a single application, application; and whether they are clear
        and fit the registration makes sense. purpose of the registry.
      </t>
      <t>
	IANA must only accept registry updates from the Designated Experts designated experts and should direct
	all requests for registration to the review mailing list.
      </t>

      <t>
	It is suggested that multiple Designated Experts
In order to enable broadly informed review of registration decisions, there should be appointed who are able multiple designated experts to represent the perspectives of different applications using this specification,
	in order to enable broadly-informed review of registration decisions. specification.
	In cases where a registration decision could may be perceived as
	creating a conflict of interest for a particular Expert, expert,
	that Expert expert should defer to the judgment of the other Experts. experts.
      </t>
      <t>
	 The reason for the use of the mailing list is used to enable
	 public review of registration requests, enabling which enables both Designated Experts designated experts
	 and other interested parties to provide feedback on proposed registrations.
	 The reason to allow the
         Designated Experts to experts may allocate values prior to publication as a final specification is to enable
	 giving authors of specifications proposing registrations the benefit of review by the Designated Experts
	 before
         final specification.  This allows authors to receive guidance from
         the specification is completely done, designated experts early, so that if problems are identified, the authors any identified issues can iterate and fix them be fixed
         before publication of the final specification. specification is published.
      </t>
      <section title="OAuth anchor="PRMetadataReg">
        <name>OAuth Protected Resource Metadata Registry" anchor="PRMetadataReg"> Registry</name>
        <t>
	  This specification establishes the
	  IANA
	  "OAuth Protected Resource Metadata" registry
	  for OAuth 2.0 protected resource metadata names.
	  The registry records the protected resource metadata parameter
	  and a reference to the specification that defines it.
        </t>
        <section title="Registration Template" anchor="PRMetadataTemplate">
          <t>
            <list style='hanging'>
              <t hangText='Metadata Name:'>
                <vspace/>
          <name>Registration Template</name>
          <dl newline="true" spacing="normal">
            <dt>Metadata Name:</dt>
            <dd>
                The name requested (e.g., "resource").
		This name is case-sensitive. case sensitive.
		Names may not match other registered names in a case-insensitive manner
		unless the Designated Experts designated experts state that there is a compelling reason
		to allow an exception.
              </t>
              <t hangText='Metadata Description:'>
                <vspace/>
              </dd>
            <dt>Metadata Description:</dt>
            <dd>
                Brief description of the metadata (e.g., "Resource identifier URL").
              </t>
              <t hangText='Change Controller:'>
                <vspace/>
              </dd>
            <dt>Change Controller:</dt>
            <dd>
                For IETF stream Stream RFCs, list the "IETF".
		For others, give the name of the responsible party.
		Other details (e.g., postal address, email address, home page URI) may also be included.
              </t>
              <t hangText='Specification Document(s):'>
                <vspace/>
              </dd>
            <dt>Specification Document(s):</dt>
            <dd>
                Reference to the document or documents that specify the parameter,
		preferably including URIs that
                can be used to retrieve copies of the documents.
		An indication of the relevant
                sections may also be included but is not required.
              </t>
            </list>
          </t>
              </dd>
          </dl>
        </section>
        <section title="Initial Registry Contents" anchor="PRMetadataContents">
          <t> <?rfc subcompact="yes"?>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">resource</spanx>
              </t>
              <t>
                Metadata Description:
          <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
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref URL</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">authorization_servers</spanx>
              </t>
              <t>
                Metadata Description:
		JSON 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
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref identifiers</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">jwks_uri</spanx>
              </t>
              <t>
                Metadata Description:
		URL 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
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref document</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">scopes_supported</spanx>
              </t>
              <t>
                Metadata Description:
		JSON 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
		<spanx style="verb">scope</spanx> scope values that are used in authorization
            requests to request access to this protected resource
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref resource</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">bearer_methods_supported</spanx>
              </t>
              <t>
                Metadata Description:
		JSON 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 bearer token presentation methods that this
            protected resource supports
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref supports</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">resource_signing_alg_values_supported</spanx>
              </t>
              <t>
                Metadata Description:
		JSON 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
		(<spanx style="verb">alg</spanx> (<tt>alg</tt> values) supported by the
            protected resource for signed content
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref content</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">resource_name</spanx>
              </t>
              <t>
                Metadata Description:
		Human-readable 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
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref resource</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">resource_documentation</spanx>
              </t>
              <t>
                Metadata Description:
		URL 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
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref resource</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">resource_policy_uri</spanx>
              </t>
              <t>
                Metadata Description:
		URL 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
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref resource</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">resource_tos_uri</spanx>
              </t>
              <t>
                Metadata Description:
		URL 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
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref
            service</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this 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 RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false">
            <dt>Metadata Name:</dt><dd><tt>tls_client_certificate_bound_access_tokens</tt></dd>
            <dt>Metadata Description:</dt><dd>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 tokens</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Metadata Name: <spanx style="verb">authorization_details_types_supported</spanx>
	      </t>
	      <t>
		Metadata Description:
		JSON 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
		<spanx style="verb">type</spanx> <tt>type</tt> values supported by the
	    resource server when the <spanx style="verb">authorization_details</spanx> <tt>authorization_details</tt> request
	    parameter is used
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Specification Document(s): <xref used</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this specification ]]
	      </t>
	    </list>
	  </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">dpop_signing_alg_values_supported</spanx>
              </t>
              <t>
                Metadata Description:
		JSON RFC 9728</dd>
          </dl>

          <dl spacing="compact" newline="false">
            <dt>Metadata Name:</dt><dd><tt>dpop_signing_alg_values_supported</tt></dd>
            <dt>Metadata Description:</dt><dd>JSON array containing a list of
            the JWS alg <tt>alg</tt> values supported by the resource server for validating
            DPoP proof JWTs
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref JWTs</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">dpop_bound_access_tokens_required</spanx>
              </t>
              <t>
                Metadata Description:
		Boolean RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false">
            <dt>Metadata Name:</dt><dd><tt>dpop_bound_access_tokens_required</tt></dd>
            <dt>Metadata Description:</dt><dd>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 tokens</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Metadata Name: signed_metadata
	      </t>
	      <t>
		Metadata Description:
		Signed RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false">
	    <dt>Metadata Name:</dt><dd><tt>signed_metadata</tt></dd>
	    <dt>Metadata Description:</dt><dd>Signed JWT containing metadata
	    parameters about the protected resource as claims
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Specification Document(s): <xref claims</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Specification Document(s):</dt><dd><xref target="SignedMetadata"/> of [[ this specification ]]
	      </t>
	    </list>
	  </t> RFC 9728</dd>
          </dl>
        </section>
	<?rfc subcompact="no"?>
      </section>
      <section title="OAuth anchor="ASMetadataReg">
        <name>OAuth Authorization Server Metadata Registry" anchor="ASMetadataReg"> Registry</name>
        <t>
	  The
	  IANA has registered the following authorization server metadata parameter
	  is registered
	  in the IANA
	  "OAuth Authorization Server Metadata" registry established in
"<xref target="RFC8414" format="title"/>" <xref target="RFC8414">OAuth 2.0 Authorization Server Metadata</xref>. target="RFC8414" format="default"/>.
        </t>
        <section title="Registry Contents" anchor="ASMetadataContents">
          <t>
	    <?rfc subcompact="yes"?>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">protected_resources</spanx>
              </t>
              <t>
                Metadata Description:
		JSON
          <name>Registry Contents</name>
          <dl spacing="compact" newline="false">
            <dt>Metadata Name:</dt><dd><tt>protected_resources</tt></dd>
            <dt>Metadata Description:</dt><dd>JSON array containing a list of
            resource identifiers for OAuth protected resources
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref resources</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Specification Document(s):</dt><dd><xref target="ASMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t> RFC 9728</dd>
          </dl>
        </section>
	<?rfc subcompact="no"?>
      </section>
      <section anchor="WellKnownRegistry" title="Well-Known URI Registry"> anchor="WellKnownRegistry">
        <name>Well-Known URIs Registry</name>
        <t>
	  This specification registers the well-known URI defined in
	  <xref target="PRConfig"/> in the IANA
	  "Well-Known URIs" registry <xref target="IANA.well-known"/>.
        </t>
        <section anchor='WellKnownContents' title='Registry Contents'>
	  <t> <?rfc subcompact="yes"?>
            <list style='symbols'>
	      <t>
		URI Suffix: <spanx style="verb">oauth-protected-resource</spanx>
	      </t>
	      <t>
		Reference: <xref anchor="WellKnownContents">
          <name>Registry Contents</name>
          <dl spacing="compact" newline="false">
	    <dt>URI Suffix:</dt><dd><tt>oauth-protected-resource</tt></dd>
	    <dt>Reference:</dt><dd><xref target="PRConfig"/> of [[ this specification ]]
	      </t>
	      <t>
		Status: permanent
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Related Information: (none)
	      </t>
	    </list>
	  </t> RFC 9728</dd>
	    <dt>Status:</dt><dd>permanent</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Related Information:</dt><dd>(none)</dd>
          </dl>
        </section>
	<?rfc subcompact="no"?>
      </section>
    </section>
  </middle>
  <back>
    <references title="Normative References">

    <displayreference target="RFC7518" to="JWA"/>
    <displayreference target="RFC7516" to="JWE"/>
    <displayreference target="RFC7517" to="JWK"/>
    <displayreference target="RFC7515" to="JWS"/>
    <displayreference target="RFC7519" to="JWT"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5646.xml"/> href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.047.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7234.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9111.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7591.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8414.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8615.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8705.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8707.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9396.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9449.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9525.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0195.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"> surname="Whistler" role="editor">
	  </author>
            <date day="1" month="June" year="2015" /> day="14" month="August" year="2024"/>
          </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.</organization>
          </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.</organization>
          </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"/> value="#15"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7516.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7517.xml"/>
        <reference anchor="UNICODE" target="https://www.unicode.org/versions/latest/">
          <front>
            <title abbrev="Unicode">The Unicode Standard</title>
            <author>
              <organization>The Unicode Consortium</organization>
	    <address />
              <address/>
            </author>
	  <date />
            <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 changes in
	  the UNICODE specification will impact the syntax of JSON or the UTF-8 encoding.
	-->
      </reference>
        <reference anchor="IANA.Language" target="https://www.iana.org/assignments/language-subtag-registry">
          <front>
            <title>Language Subtag Registry</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
      </references>

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

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

        <reference anchor="OpenID.Discovery" target="https://openid.net/specs/openid-connect-discovery-1_0.html">
          <front>
            <title>OpenID Connect Discovery 1.0</title> 1.0 incorporating errata set 2</title>
            <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
              <organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization>
            </author>
            <author fullname="John Bradley" initials="J." surname="Bradley">
              <organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
            </author>
            <author fullname="Michael B. Jones" initials="M.B." initials="M." surname="Jones">
              <organization abbrev="Self-Issued Consulting (was at Microsoft)">Self-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/assignments/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/jose">
          <front>
            <title>JSON Object Signing Web Signature and Encryption (JOSE)</title> Algorithms</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="OWASP.SSRF" target="https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html">
          <front>
            <title>OWASP SSRF Server-Side Request Forgery Prevention Cheat Sheet</title>
            <author>
      			<organization>OWASP</organization>
              <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</title> Signing (Draft)</title>
            <author fullname="Dave Tonge" initials="D." surname="Tonge">
              <organization abbrev="Moneyhub">Moneyhub Financial Technology</organization>
            </author>
            <author fullname="Daniel Fett" initials="D." surname="Fett">
              <organization>Authlete</organization>
            </author>
            <date day="24" month="March" year="2023" /> year="2023"/>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" title="Acknowledgements">

      <t>
	The numbered="false">
      <name>Acknowledgements</name>
      <t>The authors of this specification would like to thank the attendees
      of the IETF 115 OAuth and HTTP API Working Group meetings and the
      attendees of subsequent OAuth Working Group meetings for their input on
      this specification.  We would would also like to thank
	Amanda Baber,
	Mike Bishop,
	Ralph Bragg,
	Brian Campbell,
	Deb Cooley,
	Roman Danyliw,
	Gabriel Corona,
	Vladimir Dzhuvinov,
	George Fletcher,
	Arnt Gulbrandsen,
	Pieter Kasselman,
	Murray Kucherawy,
	David Mandelberg,
	Tony Nadalin,
	Francesca Palombini,
	John Scudder,
	Rifaat Shekh-Yusef,
	Filip Skokan,
	Orie Steele,
	Atul Tulshibagwale,
	Éric Vyncke,
	Paul Wouters,
	and
	Bo Wu <contact
      fullname="Amanda Baber"/>, <contact fullname="Mike Bishop"/>, <contact
      fullname="Ralph Bragg"/>, <contact fullname="Brian Campbell"/>, <contact
      fullname="Deb Cooley"/>, <contact fullname="Gabriel Corona"/>, <contact fullname="Roman Danyliw"/>,
      <contact fullname="Vladimir Dzhuvinov"/>,
      <contact fullname="George Fletcher"/>, <contact fullname="Arnt
      Gulbrandsen"/>, <contact fullname="Pieter Kasselman"/>, <contact
      fullname="Murray Kucherawy"/>, <contact fullname="David Mandelberg"/>,
      <contact fullname="Tony Nadalin"/>, <contact fullname="Francesca
      Palombini"/>, <contact fullname="John Scudder"/>, <contact
      fullname="Rifaat Shekh-Yusef"/>, <contact fullname="Filip Skokan"/>,
      <contact fullname="Orie Steele"/>, <contact fullname="Atul
      Tulshibagwale"/>, <contact fullname="Éric Vyncke"/>, <contact
      fullname="Paul Wouters"/>, and <contact fullname="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 identifier
	    to inserting it between the host and path components of it.
	  </t>
	  <t>
	    Have WWW-Authenticate return <spanx style="verb">resource_metadata</spanx> 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 authorization 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 keys.
	  </t>
	</list>
      </t>

      <t>
	-00
        <list style="symbols">
	  <t>
	    Initial working group version based on draft-jones-oauth-resource-metadata-04.
	  </t>
	</list>
</t>
    </section>
  </back>
</rfc>