draft-ietf-oauth-resource-metadata.xml

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

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

  <?rfc toc="yes" ?>
  <?rfc tocdepth="5" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc strict="yes" ?>
  <?rfc compact='yes' ?>
  <?rfc subcompact='no' ?>

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

    <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>

    <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">
      <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 intentionally as parallel as possible to that of
	<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
	<xref target="RFC8414">OAuth 2.0 Authorization Server Metadata</xref>,
	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 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.
	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
	(in a manner related to the description in Section 2 of
	<xref target="OpenID.Discovery">"OpenID Connect Discovery 1.0"</xref>)
	to find the resource server, 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 optionally, its relationships to other services.
	This process is described in <xref target="PRConfig"/>.
      </t>
      <t>
	This metadata can either be communicated 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"/>.
	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
	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 supposedly describing
	the protected 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 may be used by other specifications, such as the <spanx style="verb">jwks_uri</spanx>
	      used to publish public keys the resource server uses to sign
	      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> by protected resources
	to dynamically inform clients of
	the URL of their protected resource metadata.
	This use of <spanx style="verb">WWW-Authenticate</spanx> can indicate that
	the protected resource metadata may have changed.
      </t>
      <section anchor="rnc" title="Requirements Notation and Conventions">
	<t>
	  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL"
	  in this document are to be interpreted as described in
	  BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	  when, and only when, they appear in all capitals, as shown here.
	</t>

	<t>
	  All uses of <xref target="JWS">JSON Web Signature (JWS)</xref>
	  and <xref target="JWE">JSON Web Encryption (JWE)</xref>
	  data structures 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">
	<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", and "Token Endpoint"
	  defined by <xref target="RFC6749">OAuth 2.0</xref>,
	  the terms "Claim Name", "Claim Value", and "JSON Web Token (JWT)"
	  defined by <xref target="JWT">JSON Web Token (JWT)</xref>.
	</t>
	<t>
	  This specification defines the following term:
	  <list style='hanging'>
	    <t hangText='Resource Identifier:'>
	      <vspace/>
	      The Protected resource's resource identifier, which is a URL that
	      uses the <spanx style="verb">https</spanx> scheme and has no fragment component.
	      As in Section 2 of <xref target="RFC8707"/>, it also SHOULD NOT 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> location
	      <xref target="RFC8615"/>
	      derived from this resource identifier,
	      as described in <xref target="PRConfig"/>.
	    </t>
	  </list>
	</t>
      </section>
    </section>

    <section anchor="PRMetadata" title="Protected Resource Metadata">
      <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.
	    The protected resource's Resource Identifier,
	    as defined in <xref target="Terminology"/>.
	  </t>

	  <t hangText="authorization_servers">
	    <vspace/>
	    OPTIONAL.
	    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 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.
	    URL of the protected resource's JSON Web Key (JWK) Set <xref target="JWK"/> 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 use the <spanx style="verb">https</spanx> scheme.
	    When both signing and encryption keys are made available,
	    a <spanx style="verb">use</spanx> (public key use) parameter
	    value is REQUIRED for all keys in the referenced JWK Set
	    to indicate each key's intended usage.
	  </t>

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

	  <t hangText="bearer_methods_supported">
	    <vspace/>
	    OPTIONAL.
	    JSON array containing a list of the supported methods of sending an
	    OAuth 2.0 Bearer Token <xref target="RFC6750"/> to the protected resource.
	    Defined values are
	    <spanx style="verb">["header", "body", "query"]</spanx>,
	    corresponding to Sections 2.1, 2.2, and 2.3 of RFC 6750.
	    The empty array <spanx style="verb">[]</spanx> can be used
	    to indicate that no Bearer methods are supported.
	    If this entry is omitted,
	    no default 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.
	    JSON array containing a list of the JWS <xref target="JWS" /> signing algorithms
	    (<spanx style="verb">alg</spanx> values) <xref target="JWA" />
	    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 be used.
	  </t>

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

	  <t hangText="resource_documentation">
	    <vspace/>
	    OPTIONAL.
	    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 be internationalized,
	    as described in <xref target="HumanReadableMetadata"/>.
	  </t>

	  <t hangText="resource_policy_uri">
	    <vspace/>
	    OPTIONAL.
	    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 be internationalized,
	    as described in <xref target="HumanReadableMetadata"/>.
	  </t>

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

	  <t hangText="tls_client_certificate_bound_access_tokens">
	    <vspace/>
	    OPTIONAL.
	    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 JSON array containing a list of the authorization details
	    <spanx style="verb">type</spanx> values supported by the resource server
	    when the <spanx style="verb">authorization_details</spanx>
	    request parameter <xref target="RFC9396"/> is used.
	  </t>

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

	  <t hangText="dpop_bound_access_tokens_required">
	    <vspace/>
	    OPTIONAL.
	    A 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>
      <t>
	Additional protected resource metadata parameters MAY also be used.
      </t>

      <section anchor="HumanReadableMetadata"
	       title="Human-Readable Resource Metadata">
	<t>
	  Human-readable resource metadata values
	  and resource metadata values that reference human-readable content
	  MAY 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>, and
	  <spanx style="verb">resource_policy_uri</spanx>
	  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 are added to resource metadata parameter names,
	  delimited by a <spanx style="verb">#</spanx> character.
	  Since <xref target="RFC8259">JSON</xref> member names are case sensitive,
	  it is RECOMMENDED 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>.
	  In particular, 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,
	  implementations SHOULD interpret the language tag values supplied
	  in a case insensitive manner.
	  Per the recommendations in BCP 47, language tag values used in
	  metadata parameter names should only be as specific as necessary.
	  For instance, using <spanx style="verb">fr</spanx> might be sufficient
	  in many contexts, rather than <spanx style="verb">fr-CA</spanx>
	  or <spanx style="verb">fr-FR</spanx>.
	</t>
	<t>
	  For example, a resource could represent its name in English as
	  <spanx style="verb">"resource_name#en": "My Resource"</spanx>
	  and its name in Italian as
	  <spanx style="verb">"resource_name#it": "La mia bella risorsa"</spanx>
	  within its metadata.
	  Any or all of these names MAY be displayed to the 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 make any assumptions about the language,
	  character set, or script of the string value, and the string value
	  MUST be used as is wherever it is presented in a user interface.
	  To facilitate interoperability, it is RECOMMENDED that
	  each kind of human-readable metadata provided includes
	  an instance of its metadata parameter without any language tags
	  in addition to any language-specific parameters, and it is RECOMMENDED 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 Protected Resource Metadata">
	<t>
	  In addition to JSON elements, metadata values MAY also be provided
	  as a <spanx style="verb">signed_metadata</spanx> value,
	  which is a JSON Web Token (JWT) <xref target="JWT"/>
	  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 be digitally signed or MACed
	  using <xref target="JWS">JSON Web Signature (JWS)</xref>
	  and MUST contain an <spanx style="verb">iss</spanx> (issuer) claim
	  denoting the party attesting to the claims in the signed metadata.
	  Consumers of the metadata MAY 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 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 metadata parameter:
	  <list style="hanging">

	    <t hangText="signed_metadata">
	      <vspace/>
	      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>
	      parameter SHOULD NOT appear as a claim in the JWT;
	      it is RECOMMENDED to reject any metadata in which this occurs.
	    </t>

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

    </section>

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

      <t>
	Protected resources supporting metadata
	MUST 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>.
	The syntax and semantics of <spanx style="verb">.well-known</spanx>
	are defined in <xref target="RFC8615"/>.
	The well-known URI path suffix used MUST 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 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,
	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> URI path suffix and publish
	the metadata document at the URL formed by inserting
	<spanx style="verb">/.well-known/example-protected-resource</spanx>
	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>,
	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 specify
	what well-known URI suffix it will use for this purpose.
	The same protected resource MAY choose to publish its metadata at multiple
	well-known locations derived from its resource identifier,
	for example, publishing metadata at both
	<spanx style="verb">/.well-known/example-protected-resource</spanx> and
	<spanx style="verb">/.well-known/oauth-protected-resource</spanx>.
      </t>

      <section anchor="PRConfigurationRequest"
	       title="Protected Resource Metadata Request">
        <t>
	  A protected resource metadata document MUST be queried using an HTTP
	  <spanx style="verb">GET</spanx> 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>
	  and the well-known URI path suffix is <spanx style="verb">oauth-protected-resource</spanx>
	  to obtain the metadata,
	  since the resource identifier contains no path component:
	</t>
        <t>
	  <figure>
            <artwork><![CDATA[
  GET /.well-known/oauth-protected-resource HTTP/1.1
  Host: resource.example.com
]]></artwork>
          </figure>
	</t>

	<t>
	  If the resource identifier value contains a path or query component,
	  any terminating <spanx style="verb">/</spanx> following the host component
	  MUST be removed before inserting
	  <spanx style="verb">/.well-known/</spanx> 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>
	  and the well-known URI path suffix is <spanx style="verb">oauth-protected-resource</spanx>
	  to obtain the metadata,
	  since the resource identifier contains a path component:
	</t>
        <t>
	  <figure>
            <artwork><![CDATA[
  GET /.well-known/oauth-protected-resource/resource1 HTTP/1.1
  Host: resource.example.com
]]></artwork>
          </figure>
	</t>

	<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> 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 Resource Metadata Response">
        <t>
	  The response is a set of metadata parameters about the protected resource's
	  configuration.
	  A successful response MUST use the 200 OK HTTP status code and return
	  a JSON object using the <spanx style="verb">application/json</spanx> 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 be defined and used;
	  any metadata parameters that are not understood MUST be ignored.
	</t>
        <t>
	  Parameters with multiple values are represented as JSON arrays.
	  Parameters with zero values MUST be omitted from the response.
	</t>
	<t>
	  An error response uses the applicable HTTP status code value.
	</t>
        <t>
	  <figure>
	    <preamble>The following is a non-normative example response:</preamble>

            <artwork><![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>
      </section>

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

        <t>
	  The <spanx style="verb">resource</spanx> value returned MUST 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 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> parameter, then
	  the <spanx style="verb">resource</spanx> value returned MUST 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 be used.
	</t>
	<t>
	  These validation actions can thwart impersonation attacks,
	  as described in <xref target="Impersonation"/>.
	</t>
	<t>
	  The recipient MUST 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 treat this as an error condition.
	</t>
      </section>
    </section>

    <section anchor="ASMetadata" title="Authorization Server Metadata">
      <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>,
	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.
	    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 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>
    </section>

    <section anchor="WWW-Authenticate" title="Use of WWW-Authenticate for Protected Resource Metadata">
      <t>
	A protected resource MAY use the <spanx style="verb">WWW-Authenticate</spanx>
	<xref target="RFC9110"/> HTTP response header field
	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 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 baseProfile="tiny" height="550" version="1.2" viewBox="0 0 478 550" width="478" xmlns="http://www.w3.org/2000/svg">
			  <path d="M-252,-405.0000000000001 L-252,0" fill="none" stroke="black" stroke-width="1" transform="translate(350.5 468.5)"/>
			  <rect fill="white" height="48" stroke="black" stroke-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 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  |                  |
          | <---------------------- |                  |
          |                         |                  |
]]></artwork>
  </artset>
</figure>

      </t>
      <t>
	<list style="numbers">
	  <t>
	    The client makes a request to a protected resource without presenting an access token.
	  </t>
	  <t>
	    The resource server responds with a <spanx style="verb">WWW-Authenticate</spanx> header including the URL of the protected resource metadata.
	  </t>
	  <t>
	    The client fetches the protected resource metadata from this URL.
	  </t>
	  <t>
	    The resource server responds with the protected resource metadata
	    according to <xref target="PRConfigurationResponse"/>.
	  </t>
	  <t>
	    The client validates the protected resource metadata,
	    as described in <xref target="PRConfigurationValidation"/>.
	  </t>
	  <t>
	    The client builds the authorization server metadata URL from an issuer identifier in the resource metadata according to <xref target="RFC8414"/>
	    and makes a request to fetch the authorization server metadata.
	  </t>
	  <t>
	    The authorization server responds with the authorization server metadata document according to <xref target="RFC8414"/>.
	  </t>
	  <t>
	    The client directs the user agent to the authorization server to begin the authorization flow.
	  </t>
	  <t>
	    The authorization exchange is completed and the authorization server returns an access token to the client.
	  </t>
	  <t>
	    The client repeats the resource request from step 1, presenting the newly obtained access token.
	  </t>
	  <t>
	    The resource server returns the requested protected resource.
	  </t>
	</list>
      </t>

      <section anchor="WWW-Authenticate-Response" title="WWW-Authenticate Response">
	<t>
	  This specification introduces a new parameter in the
	  <spanx style="verb">WWW-Authenticate</spanx> HTTP response header field
	  to indicate the protected resource metadata URL:
            <list style='hanging'>
              <t hangText='resource_metadata:'>
                <vspace/>
		The URL of the protected resource metadata.
	      </t>
	    </list>
	</t>
	<t>
	  <figure>
	    <preamble>The response below is an example of a <spanx style="verb">WWW-Authenticate</spanx> header that includes the resource identifier.</preamble>

	    <artwork><![CDATA[
  HTTP/1.1 400 Bad Request
  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>
	<t>
	  The HTTP status code and error string in the example response above
	  are defined by <xref target="RFC6750"/>.
	</t>
	<t>
	  This parameter MAY also be used in
	  <spanx style="verb">WWW-Authenticate</spanx> responses using
	  <spanx style="verb">Authorization</spanx> schemes other than
	  <spanx style="verb">Bearer</spanx> <xref target="RFC6750"/>,
	  such as the <spanx style="verb">DPoP</spanx> scheme
	  defined by <xref target="RFC9449"/>.
	</t>
	<t>
	  The <spanx style="verb">resource_metadata</spanx> parameter MAY be combined with other parameters defined in other extensions,
	  such as the <spanx style="verb">max_age</spanx> parameter defined by <xref target="RFC9470"/>.
	</t>
      </section>

      <section anchor="changes" title="Changes to Resource Metadata">
	<t>
	  At any point, for any reason determined by the resource server,
	  the protected resource MAY respond with a new <spanx style="verb">WWW-Authenticate</spanx> 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> response,
	  it SHOULD 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 Identifier and Client Authentication">
	<t>
	  The way in which the client identifier is established at the authorization server is out of scope of this specification.
	</t>
	<t>
	  This specification is intended to be deployed in scenarios where the client has no prior knowledge about the resource server,
	  and 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 with Other Authentication Methods">
	<t>
	  Resource servers MAY return other <spanx style="verb">WWW-Authenticate</spanx> headers indicating various authentication schemes.
	  This allows the resource server to support clients that may or may not implement this specification,
	  and allows clients to choose their preferred authentication scheme.
	</t>
      </section>

    </section>

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

      <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>.  Comparing Unicode <xref target="UNICODE"/> strings,
	however, has significant security implications.
      </t>
      <t>
	Therefore, comparisons between JSON strings and other Unicode
	strings MUST be performed as specified below:

	<list style="numbers">

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

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

    </section>

    <section anchor="Security" title="Security Considerations">

      <section anchor="TLSRequirements" title="TLS Requirements">
	<t>
	  Implementations MUST support TLS.
	  They MUST follow the guidance in
	  BCP 195 <xref target="RFC8996"/> <xref target="RFC9325"/>,
	  which provides recommendations and requirements
	  for improving the security of deployed services that use TLS.
	</t>
	<t>
	  Use of TLS at the protected resource metadata URLs
	  protects against information disclosure and tampering.
	</t>
      </section>

      <section anchor="Scopes" title="Scopes">
      	<t>
					The <spanx style="verb">scopes_supported</spanx> 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 still follow OAuth best practices and request tokens with as limited scope as possible for the given operation, as described in Section 2.3 of OAuth 2.0 Security Best Current Practice <xref target="I-D.ietf-oauth-security-topics"/>.
      	</t>
      </section>

      <section anchor="Impersonation" title="Impersonation Attacks">
	<t>
	  TLS certificate checking MUST 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 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
	  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> metadata parameter
	  using the resource identifier URL of the protected resource being impersonated,
	  but containing 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 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> 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 Access Tokens">
      	<t>
      		If a client expects to interact with multiple resource servers, the client
      		SHOULD request audience-restricted access tokens using <xref target="RFC8707"/>,
      		and the authorization server SHOULD 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> 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 the access token at RS2.
      	</t>
      	<t>
      		While this attack is not explicitly enabled by this specification, and is possible in
      		a plain OAuth 2.0 deployment, it is made somewhat more likely by the use of
      		dynamically-configured clients. As such, the use
      		of audience-restricted access tokens and Resource Indicators <xref target="RFC8707"/>
      		is RECOMMENDED when using the features in this specification.
      	</t>
      </section>

      <section anchor="StandardFormat" title="Publishing Metadata in a Standard Format">
	<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 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">
	<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>
	  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 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 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 in general, application-dependent.
	  For instance, some protected resources are used with
	  a fixed authorization server or set of authorization servers,
	  the locations of which may be well known,
	  or which could be published as metadata values by the protected resource.
	  In other cases, the set of authorization servers that can be used with
	  a protected resource can by 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 Request Forgery (SSRF)">
      	<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 it has no prior knowledge of, this opens a risk for SSRF attacks by malicious users or malicious resource servers. Clients SHOULD take appropriate precautions against SSRF attacks, such as blocking requests to internal IP address ranges. Further recommendations can be found in the OWASP SSRF Prevention Cheat Sheet <xref target="OWASP.SSRF"/>.
				</t>
      </section>

      <section anchor="phishing" title="Phishing">
      	<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 Unsigned and Signed Metadata">
	<t>
	  Unsigned metadata is integrity protected by use of TLS at the site
	  where it is hosted.
	  This means that its security is dependent upon the Internet
	  Public Key Infrastructure (PKI) <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> value in the metadata.
	  Whereas, when using signed metadata, the party issuing the metadata
	  is represented by the <spanx style="verb">iss</spanx> (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">
	<t>
	  Protected resource metadata is retrieved using an HTTP
	  <spanx style="verb">GET</spanx> request,
	  as specified in <xref target="PRConfigurationRequest"/>.
	  Normal HTTP caching behaviors apply, meaning that the GET may retrieve
	  a cached copy of the content, rather than the latest copy.
	  Implementations should utlize HTTP caching directives such as
	  <spanx style="verb">Cache-Control</spanx>
	  with <spanx style="verb">max-age</spanx>,
	  as defined in <xref target="RFC7234"/>,
	  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>
      <t>
	Values are registered on a Specification Required <xref target="RFC8126"/>
	basis after a two-week review period on the oauth-ext-review@ietf.org
	mailing list, on the advice of one or more Designated Experts.
	However, to allow for the allocation of values prior to publication
	of the final version of a specification,
	the 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,
	the 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 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 the Designated Experts
	are not responsive within 14 days.
      </t>
      <t>
	Criteria that should be applied by the Designated Experts includes
	determining whether the proposed registration duplicates existing functionality,
	determining whether it is likely to be of general applicability
	or whether it is useful only for a single application,
	and whether the registration makes sense.
      </t>
      <t>
	IANA must only accept registry updates from the Designated Experts and should direct
	all requests for registration to the review mailing list.
      </t>
      <t>
	It is suggested that multiple Designated Experts be appointed who are able to
	represent the perspectives of different applications using this specification,
	in order to enable broadly-informed review of registration decisions.
	In cases where a registration decision could be perceived as
	creating a conflict of interest for a particular Expert,
	that Expert should defer to the judgment of the other Experts.
      </t>
       <t>
	 The reason for the use of the mailing list is to enable
	 public review of registration requests, enabling both Designated Experts
	 and other interested parties to provide feedback on proposed registrations.
	 The reason to allow the Designated Experts to
	 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 the specification is completely done,
	 so that if problems are identified, the authors can iterate and fix them
	 before publication of the final specification.
       </t>

      <section title="OAuth Protected Resource Metadata Registry" anchor="PRMetadataReg">
	<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/>
                The name requested (e.g., "resource").
		This name is case-sensitive.
		Names may not match other registered names in a case-insensitive manner
		unless the Designated Experts state that there is a compelling reason
		to allow an exception.
              </t>
              <t hangText='Metadata Description:'>
                <vspace/>
                Brief description of the metadata (e.g., "Resource identifier URL").
              </t>
              <t hangText='Change Controller:'>
                <vspace/>
                For IETF 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/>
                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>
        </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:
		Protected resource's resource identifier URL
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">authorization_servers</spanx>
              </t>
              <t>
                Metadata Description:
		JSON array containing a list of OAuth authorization server issuer identifiers
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">jwks_uri</spanx>
              </t>
              <t>
                Metadata Description:
		URL of the protected resource's JWK Set document
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">scopes_supported</spanx>
              </t>
              <t>
                Metadata Description:
		JSON array containing a list of the OAuth 2.0
		<spanx style="verb">scope</spanx> values that
		are used in authorization requests to request access to this protected resource
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">bearer_methods_supported</spanx>
              </t>
              <t>
                Metadata Description:
		JSON array containing a list of the OAuth 2.0 Bearer Token
		presentation methods that this protected resource supports
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="PRMetadata"/> of [[ 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 array containing a list of the JWS signing algorithms
		(<spanx style="verb">alg</spanx> values)
		supported by the protected resource
		for signed content
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">resource_name</spanx>
              </t>
              <t>
                Metadata Description:
		Human-readable name of the protected resource
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">resource_documentation</spanx>
              </t>
              <t>
                Metadata Description:
		URL of a page containing human-readable information that
		developers might want or need to know when using the protected resource
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">resource_policy_uri</spanx>
              </t>
              <t>
                Metadata Description:
		URL of a page containing human-readable information
		about the protected resource's requirements on how
		the client can use the data provided by the protected resource
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">resource_tos_uri</spanx>
              </t>
              <t>
                Metadata Description:
		URL of a page containing human-readable information
		about the protected resource's terms of service
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="PRMetadata"/> of [[ 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 value indicating protected resource support for
		mutual-TLS client certificate-bound access tokens
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="PRMetadata"/> of [[ 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 array containing a list of the authorization details
		<spanx style="verb">type</spanx> values supported by the resource server
		when the <spanx style="verb">authorization_details</spanx>
		request parameter is used
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Specification Document(s): <xref target="PRMetadata"/> of [[ this specification ]]
	      </t>
	    </list>
	  </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">dpop_signing_alg_values_supported</spanx>
              </t>
              <t>
                Metadata Description:
		JSON array containing a list of the JWS alg values
		supported by the resource server for validating DPoP proof JWTs
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="PRMetadata"/> of [[ 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 value specifying whether the protected resource
		always requires the use of DPoP-bound access tokens
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="PRMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Metadata Name: signed_metadata
	      </t>
	      <t>
		Metadata Description:
		Signed JWT containing metadata parameters about the protected resource as claims
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Specification Document(s): <xref target="SignedMetadata"/> of [[ this specification ]]
	      </t>
	    </list>
	  </t>
	</section>
	<?rfc subcompact="no"?>
      </section>

      <section title="OAuth Authorization Server Metadata Registry" anchor="ASMetadataReg">
	<t>
	  The following authorization server metadata parameter
	  is registered in the IANA
	  "OAuth Authorization Server Metadata" registry established in
	  <xref target="RFC8414">OAuth 2.0 Authorization Server Metadata</xref>.
	</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 array containing a list of resource identifiers for OAuth protected resources
              </t>
              <t>
                Change Controller: IETF
              </t>
              <t>
                Specification Document(s): <xref target="ASMetadata"/> of [[ this specification ]]
              </t>
            </list>
          </t>
	</section>
	<?rfc subcompact="no"?>
      </section>

      <section anchor="WellKnownRegistry" title="Well-Known URI Registry">
	<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 target="PRConfig"/> of [[ this specification ]]
	      </t>
	      <t>
		Status: permanent
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Related Information: (none)
	      </t>
	    </list>
	  </t>
	</section>
	<?rfc subcompact="no"?>

      </section>

    </section>
  </middle>

  <back>
    <references title="Normative References">
      <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"/>
      <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"/>
      <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"/>

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

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

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

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

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

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

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

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

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NRI">Nomura Research Institute, Ltd.</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"/>
      </reference>

      <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 />
	  </author>
	  <date />
	</front>
	<!--
	  Note that this reference is to the latest version of Unicode,
	  rather than to a specific release.  It is not expected that future 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">

      <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"/>

      <reference anchor="OpenID.Discovery" target="https://openid.net/specs/openid-connect-discovery-1_0.html">
	<front>
	  <title>OpenID Connect Discovery 1.0</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." 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 and Encryption (JOSE)</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 Prevention Cheat Sheet</title>
      		<author>
      			<organization>OWASP</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>
      		<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" />
      	</front>
      </reference>

    </references>

    <section anchor="Acknowledgements" title="Acknowledgements">

      <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
	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>