<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-oauth-resource-metadata-13" number="9728" submissionType="IETF" updates="" obsoletes="" consensus="true" ipr="trust200902" tocInclude="true" tocDepth="5" symRefs="true" sortRefs="true" xml:lang="en" prepTime="2025-04-23T11:47:39" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata-13" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9728" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="OAuth 2.0 Protected Resource Metadata">OAuth 2.0 Protected Resource Metadata</title>
    <seriesInfo name="RFC" value="9728" stream="IETF"/>
    <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
      <organization showOnFrontPage="true">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 showOnFrontPage="true">Independent Identity, Inc.</organization>
      <address>
        <email>phil.hunt@yahoo.com</email>
      </address>
    </author>
    <author fullname="Aaron Parecki" initials="A." surname="Parecki">
      <organization showOnFrontPage="true">Okta</organization>
      <address>
        <email>aaron@parecki.com</email>
        <uri>https://aaronparecki.com/</uri>
      </address>
    </author>
    <date month="04" 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 pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
	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>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9728" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-notation-and-c">Requirements Notation and Conventions</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protected-resource-metadata">Protected Resource Metadata</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-human-readable-resource-met">Human-Readable Resource Metadata</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-signed-protected-resource-m">Signed Protected Resource Metadata</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-obtaining-protected-resourc">Obtaining Protected Resource Metadata</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protected-resource-metadata-">Protected Resource Metadata Request</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protected-resource-metadata-r">Protected Resource Metadata Response</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protected-resource-metadata-v">Protected Resource Metadata Validation</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authorization-server-metada">Authorization Server Metadata</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-www-authenticate-for">Use of WWW-Authenticate for Protected Resource Metadata</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-www-authenticate-response">WWW-Authenticate Response</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-to-resource-metadat">Changes to Resource Metadata</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-client-identifier-and-clien">Client Identifier and Client Authentication</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-compatibility-with-other-au">Compatibility with Other Authentication Methods</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-string-operations">String Operations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tls-requirements">TLS Requirements</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scopes">Scopes</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-impersonation-attacks">Impersonation Attacks</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-audience-restricted-access-">Audience-Restricted Access Tokens</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-publishing-metadata-in-a-st">Publishing Metadata in a Standard Format</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.6">
                <t indent="0" pn="section-toc.1-1.7.2.6.1"><xref derivedContent="7.6" format="counter" sectionFormat="of" target="section-7.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authorization-servers">Authorization Servers</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.7">
                <t indent="0" pn="section-toc.1-1.7.2.7.1"><xref derivedContent="7.7" format="counter" sectionFormat="of" target="section-7.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-server-side-request-forgery">Server-Side Request Forgery (SSRF)</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.8">
                <t indent="0" pn="section-toc.1-1.7.2.8.1"><xref derivedContent="7.8" format="counter" sectionFormat="of" target="section-7.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-phishing">Phishing</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.9">
                <t indent="0" pn="section-toc.1-1.7.2.9.1"><xref derivedContent="7.9" format="counter" sectionFormat="of" target="section-7.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-differences-between-unsigne">Differences Between Unsigned and Signed Metadata</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.10">
                <t indent="0" pn="section-toc.1-1.7.2.10.1"><xref derivedContent="7.10" format="counter" sectionFormat="of" target="section-7.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-metadata-caching">Metadata Caching</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-oauth-protected-resource-me">OAuth Protected Resource Metadata Registry</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2.1.2">
                  <li pn="section-toc.1-1.8.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.8.2.1.2.1.1"><xref derivedContent="8.1.1" format="counter" sectionFormat="of" target="section-8.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registration-template">Registration Template</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.8.2.1.2.2.1"><xref derivedContent="8.1.2" format="counter" sectionFormat="of" target="section-8.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-initial-registry-contents">Initial Registry Contents</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-oauth-authorization-server-">OAuth Authorization Server Metadata Registry</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2.2.2">
                  <li pn="section-toc.1-1.8.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.8.2.2.2.1.1"><xref derivedContent="8.2.1" format="counter" sectionFormat="of" target="section-8.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registry-contents">Registry Contents</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-well-known-uris-registry">Well-Known URIs Registry</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2.3.2">
                  <li pn="section-toc.1-1.8.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.8.2.3.2.1.1"><xref derivedContent="8.3.1" format="counter" sectionFormat="of" target="section-8.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registry-contents-2">Registry Contents</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="Introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
	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 are intentionally as parallel as possible to
	(1) <xref target="RFC7591" format="default" sectionFormat="of" derivedContent="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 (2) "<xref target="RFC8414" format="title" sectionFormat="of" derivedContent="OAuth 2.0 Authorization Server Metadata"/>" <xref target="RFC8414" format="default" sectionFormat="of" derivedContent="RFC8414"/>,
	which enables a client to obtain metadata about
	an OAuth 2.0 authorization server.
      </t>
      <t indent="0" pn="section-1-2">
	The means by which the client obtains the location
	of the protected resource
	is out of scope 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" format="default" sectionFormat="of" derivedContent="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" format="default" sectionFormat="of" derivedContent="RFC7033">WebFinger discovery</xref>
	(in a manner related to the description in <xref target="OpenID.Discovery" section="2" relative="#IssuerDiscovery" format="default" sectionFormat="of" derivedLink="https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery" derivedContent="OpenID.Discovery"/>) 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 indent="0" pn="section-1-3">
	The metadata for a protected resource
	is retrieved from a well-known location as a JSON <xref target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259"/> document,
	which declares information about its capabilities and, optionally, its relationships with other services.
	This process is described in <xref target="PRConfig" format="default" sectionFormat="of" derivedContent="Section 3"/>.
      </t>
      <t indent="0" pn="section-1-4">
	This metadata can 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="RFC7519" format="default" sectionFormat="of" derivedContent="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" format="default" sectionFormat="of" derivedContent="RFC7591"/>.
      </t>
      <t indent="0" pn="section-1-5">
	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 describes
	the protected resource but that is not actually authoritative for
	the protected resource, as described in <xref target="Impersonation" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.
      </t>
      <t indent="0" pn="section-1-6">
	<xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> 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, such as the <tt>jwks_uri</tt> (see <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/>),
              may be used with other specifications; for example, the public keys
              published in the <tt>jwks_uri</tt> can be used to verify the signed
              resource responses, as described in <xref target="FAPI.MessageSigning" format="default" sectionFormat="of" derivedContent="FAPI.MessageSigning"/>.
      </t>
      <t indent="0" pn="section-1-7">
	<xref target="WWW-Authenticate" format="default" sectionFormat="of" derivedContent="Section 5"/> describes the use of
	<tt>WWW-Authenticate</tt> by protected resources
	to dynamically inform clients of
	the URL of their protected resource metadata.
	This use of <tt>WWW-Authenticate</tt> can indicate that
	the protected resource metadata may have changed.
      </t>
      <section anchor="rnc" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-requirements-notation-and-c">Requirements Notation and Conventions</name>
        <t indent="0" pn="section-1.1-1">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
        <t indent="0" pn="section-1.1-2">
	  All applications of <xref target="RFC7515" format="default" sectionFormat="of" derivedContent="JWS">JSON Web Signature (JWS) data structures</xref>
	  and <xref target="RFC7516" format="default" sectionFormat="of" derivedContent="JWE">JSON Web Encryption (JWE) data 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" numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-1.2-1">
	  This specification uses the terms "access token", "authorization code",
	  "authorization server",
	  "client", "client authentication", "client identifier",
	  "protected resource", and
	  "resource server"
	  defined by <xref target="RFC6749" format="default" sectionFormat="of" derivedContent="RFC6749">OAuth 2.0</xref>, and
	  the terms "Claim Name" and "JSON Web Token (JWT)"
	  defined by "<xref target="RFC7519" format="title" sectionFormat="of" derivedContent="JSON Web Token (JWT)"/>" <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/>.
        </t>
        <t indent="0" pn="section-1.2-2">
	  This specification defines the following term:
        </t>
        <dl newline="true" spacing="normal" indent="3" pn="section-1.2-3">
          <dt pn="section-1.2-3.1">Resource Identifier:</dt>
          <dd pn="section-1.2-3.2">
	      The protected resource's resource identifier, which is a URL that
	      uses the <tt>https</tt> scheme and has no fragment component.
	      As specified in <xref section="2" sectionFormat="of" target="RFC8707" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8707#section-2" derivedContent="RFC8707"/>, it also <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
	      <tt>.well-known</tt> location
	      <xref target="RFC8615" format="default" sectionFormat="of" derivedContent="RFC8615"/>
	      derived from this resource identifier,
	      as described in <xref target="PRConfig" format="default" sectionFormat="of" derivedContent="Section 3"/>.
	    </dd>
        </dl>
      </section>
    </section>
    <section anchor="PRMetadata" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-protected-resource-metadata">Protected Resource Metadata</name>
      <t indent="0" pn="section-2-1">
	Protected resources can have metadata describing their configuration.
	The following protected resource metadata parameters
	are used by this specification and are registered in the
	"OAuth Protected Resource Metadata" registry
	established in <xref target="PRMetadataReg" format="default" sectionFormat="of" derivedContent="Section 8.1"/>:

      </t>
      <dl newline="true" spacing="normal" indent="3" pn="section-2-2">
        <dt pn="section-2-2.1">resource</dt>
        <dd pn="section-2-2.2">
          <bcp14>REQUIRED</bcp14>.
	    The protected resource's resource identifier,
	    as defined in <xref target="Terminology" format="default" sectionFormat="of" derivedContent="Section 1.2"/>.
	  </dd>
        <dt pn="section-2-2.3">authorization_servers</dt>
        <dd pn="section-2-2.4">
          <bcp14>OPTIONAL</bcp14>.
	    JSON array containing a list of OAuth authorization server issuer identifiers,
	    as defined in <xref target="RFC8414" format="default" sectionFormat="of" derivedContent="RFC8414"/>,
	    for authorization servers that can be used with this protected resource.
	    Protected resources <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.
	  </dd>
        <dt pn="section-2-2.5">jwks_uri</dt>
        <dd pn="section-2-2.6">
          <bcp14>OPTIONAL</bcp14>.
	    URL of the protected resource's JSON Web Key (JWK) Set <xref target="RFC7517" format="default" sectionFormat="of" derivedContent="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 <bcp14>MUST</bcp14> use the <tt>https</tt> scheme.
	    When both signing and encryption keys are made available,
	    a <tt>use</tt> (public key use) parameter
	    value is <bcp14>REQUIRED</bcp14> for all keys in the referenced JWK Set
	    to indicate each key's intended usage.
	  </dd>
        <dt pn="section-2-2.7">scopes_supported</dt>
        <dd pn="section-2-2.8">
          <bcp14>RECOMMENDED</bcp14>.
	    JSON array containing a list of scope values, as defined in <xref target="RFC6749" format="default" sectionFormat="of" derivedContent="RFC6749">OAuth          
2.0</xref>, that
	    are used in authorization requests to request access to this protected resource.
	    Protected resources <bcp14>MAY</bcp14> choose not to advertise some scope values supported
	    even when this parameter is used.
	  </dd>
        <dt pn="section-2-2.9">bearer_methods_supported</dt>
        <dd pn="section-2-2.10">
          <bcp14>OPTIONAL</bcp14>.
	    JSON array containing a list of the supported methods of sending an
	    OAuth 2.0 bearer token <xref target="RFC6750" format="default" sectionFormat="of" derivedContent="RFC6750"/> to the protected resource.
	    Defined values are
	    <tt>["header", "body", "query"]</tt>,
	    corresponding to Sections <xref section="2.1" sectionFormat="bare" target="RFC6750" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6750#section-2.1" derivedContent="RFC6750"/>, <xref section="2.2" sectionFormat="bare" target="RFC6750" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6750#section-2.2" derivedContent="RFC6750"/>, and <xref section="2.3" sectionFormat="bare" target="RFC6750" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6750#section-2.3" derivedContent="RFC6750"/> of <xref target="RFC6750" format="default" sectionFormat="of" derivedContent="RFC6750"/>.
	    The empty array <tt>[]</tt> 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.
	  </dd>
        <dt pn="section-2-2.11">resource_signing_alg_values_supported</dt>
        <dd pn="section-2-2.12">
          <bcp14>OPTIONAL</bcp14>.
	    JSON array containing a list of the JWS <xref target="RFC7515" format="default" sectionFormat="of" derivedContent="JWS"/> signing algorithms
	    (<tt>alg</tt> values) <xref target="RFC7518" format="default" sectionFormat="of" derivedContent="JWA"/>
	    supported by the protected resource for signing resource responses,
	    for instance,
	    as described in <xref target="FAPI.MessageSigning" format="default" sectionFormat="of" derivedContent="FAPI.MessageSigning"/>.
	    No default algorithms are implied if this entry is omitted.
	    The value <tt>none</tt> <bcp14>MUST NOT</bcp14> be used.
	  </dd>
        <dt pn="section-2-2.13">resource_name</dt>
        <dd pn="section-2-2.14">
	    Human-readable name of the protected resource
	    intended for display to the end user.
	    It is <bcp14>RECOMMENDED</bcp14> that protected resource metadata include this field.
	    The value of this field <bcp14>MAY</bcp14> be internationalized,
	    as described in <xref target="HumanReadableMetadata" format="default" sectionFormat="of" derivedContent="Section 2.1"/>.
	  </dd>
        <dt pn="section-2-2.15">resource_documentation</dt>
        <dd pn="section-2-2.16">
          <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 <bcp14>MAY</bcp14> be internationalized,
	    as described in <xref target="HumanReadableMetadata" format="default" sectionFormat="of" derivedContent="Section 2.1"/>.
	  </dd>
        <dt pn="section-2-2.17">resource_policy_uri</dt>
        <dd pn="section-2-2.18">
          <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 <bcp14>MAY</bcp14> be internationalized,
	    as described in <xref target="HumanReadableMetadata" format="default" sectionFormat="of" derivedContent="Section 2.1"/>.
	  </dd>
        <dt pn="section-2-2.19">resource_tos_uri</dt>
        <dd pn="section-2-2.20">
          <bcp14>OPTIONAL</bcp14>.
	    URL of a page containing human-readable information
	    about the protected resource's terms of service.
	    The value of this field <bcp14>MAY</bcp14> be internationalized,
	    as described in <xref target="HumanReadableMetadata" format="default" sectionFormat="of" derivedContent="Section 2.1"/>.
	  </dd>
        <dt pn="section-2-2.21">tls_client_certificate_bound_access_tokens</dt>
        <dd pn="section-2-2.22">
          <bcp14>OPTIONAL</bcp14>.
	    Boolean value indicating protected resource support for
	    mutual-TLS client certificate-bound access tokens
	    <xref target="RFC8705" format="default" sectionFormat="of" derivedContent="RFC8705"/>.
	    If omitted, the default value is false.
	  </dd>
        <dt pn="section-2-2.23">authorization_details_types_supported</dt>
        <dd pn="section-2-2.24">
          <bcp14>OPTIONAL</bcp14>.
	    JSON array containing a list of the authorization details
	    <tt>type</tt> values supported by the resource server
	    when the <tt>authorization_details</tt>
	    request parameter <xref target="RFC9396" format="default" sectionFormat="of" derivedContent="RFC9396"/> is used.
	  </dd>
        <dt pn="section-2-2.25">dpop_signing_alg_values_supported</dt>
        <dd pn="section-2-2.26">
          <bcp14>OPTIONAL</bcp14>.
	    JSON array containing a list of the JWS <tt>alg</tt> values
	    (from the "JSON Web Signature and Encryption Algorithms" registry
	    <xref target="IANA.JOSE" format="default" sectionFormat="of" derivedContent="IANA.JOSE"/>)
	    supported by the resource server for validating
	    Demonstrating Proof of Possession (DPoP) proof JWTs <xref target="RFC9449" format="default" sectionFormat="of" derivedContent="RFC9449"/>.
	  </dd>
        <dt pn="section-2-2.27">dpop_bound_access_tokens_required</dt>
        <dd pn="section-2-2.28">
          <bcp14>OPTIONAL</bcp14>.
	    Boolean value specifying whether the protected resource always requires
	    the use of DPoP-bound access tokens <xref target="RFC9449" format="default" sectionFormat="of" derivedContent="RFC9449"/>.
	    If omitted, the default value is false.
	  </dd>
      </dl>
      <t indent="0" pn="section-2-3">
	Additional protected resource metadata parameters <bcp14>MAY</bcp14> also be used.
      </t>
      <section anchor="HumanReadableMetadata" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-human-readable-resource-met">Human-Readable Resource Metadata</name>
        <t indent="0" pn="section-2.1-1">
	  Human-readable resource metadata values
	  and resource metadata values that reference human-readable content
	  <bcp14>MAY</bcp14> be represented in multiple languages and scripts.
	  For example, the values of fields such as
	  <tt>resource_name</tt>,
	  <tt>resource_documentation</tt>,
	  <tt>resource_tos_uri</tt>, and
	  <tt>resource_policy_uri</tt>
	  might have multiple locale-specific metadata values
	  to facilitate use in different locations.
        </t>
        <t indent="0" pn="section-2.1-2">
	  To specify the languages and scripts, language tags <xref target="BCP47" format="default" sectionFormat="of" derivedContent="BCP47"/>
	  are added to resource metadata parameter names,
	  delimited by a <tt>#</tt> character.
	  Since member names as discussed in <xref target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259">JSON</xref> are case sensitive,
	  it is <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" format="default" sectionFormat="of" derivedContent="IANA.Language">"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 language tag values are case insensitive per <xref target="BCP47" format="default" sectionFormat="of" derivedContent="BCP47"/>,
	  implementations <bcp14>SHOULD</bcp14> interpret the language tag values supplied
	  in a case-insensitive manner.
	  Per the recommendations in <xref target="BCP47" format="default" sectionFormat="of" derivedContent="BCP47"/>, language tag values used in
	  metadata parameter names should only be as specific as is necessary.
	  For instance, using <tt>fr</tt> might be sufficient
	  in many contexts, rather than <tt>fr-CA</tt>
	  or <tt>fr-FR</tt>.
        </t>
        <t indent="0" pn="section-2.1-3">
	  For example, a resource could represent its name in English as
	  <tt>"resource_name#en": "My Resource"</tt>
	  and its name in Italian as
	  <tt>"resource_name#it": "La mia bella risorsa"</tt>
	  within its metadata.
	  Any or all of these names <bcp14>MAY</bcp14> be displayed to the end user,
	  choosing which names to display based on system configuration,
	  user preferences, or other factors.
        </t>
        <t indent="0" pn="section-2.1-4">
	  If any human-readable field is sent without a language tag,
	  parties using it <bcp14>MUST NOT</bcp14> make any assumptions about the language,
	  character set, or script of the string value, and the string value
	  <bcp14>MUST</bcp14> be used as is wherever it is presented in a user interface.
	  To facilitate interoperability, it is <bcp14>RECOMMENDED</bcp14> that
	  each kind of human-readable metadata provided include
	  an instance of its metadata parameter without any language tags
	  in addition to any language-specific parameters, and it is <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" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-signed-protected-resource-m">Signed Protected Resource Metadata</name>
        <t indent="0" pn="section-2.2-1">
	  In addition to JSON elements, metadata values <bcp14>MAY</bcp14> also be provided
	  as a <tt>signed_metadata</tt> value,
	  which is a JSON Web Token (JWT) <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="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" format="default" sectionFormat="of" derivedContent="Section 2"/>.
	  The signed metadata <bcp14>MUST</bcp14> be digitally signed or MACed
	  (protected with a Message Authentication Code) using a <xref target="RFC7515" format="default" sectionFormat="of" derivedContent="JWS">JSON Web Signature (JWS)</xref>
	  and <bcp14>MUST</bcp14> contain an <tt>iss</tt> (issuer) claim
	  denoting the party attesting to the claims in the signed metadata.
	  Consumers of the metadata <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
	  <bcp14>MUST</bcp14> take precedence over the corresponding values conveyed using plain JSON elements.
        </t>
        <t indent="0" pn="section-2.2-2">
	  Signed metadata is included in the protected resource metadata JSON object
	  using this <bcp14>OPTIONAL</bcp14> metadata parameter:
        </t>
        <dl newline="true" spacing="normal" indent="3" pn="section-2.2-3">
          <dt pn="section-2.2-3.1">signed_metadata</dt>
          <dd pn="section-2.2-3.2">
	      A JWT containing metadata parameters about the protected resource as claims.
	      This is a string value consisting of the entire signed JWT.
	      A <tt>signed_metadata</tt>
	      parameter <bcp14>SHOULD NOT</bcp14> appear as a claim in the JWT;
	      it is <bcp14>RECOMMENDED</bcp14> to reject any metadata in which this occurs.
	    </dd>
        </dl>
      </section>
    </section>
    <section anchor="PRConfig" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-obtaining-protected-resourc">Obtaining Protected Resource Metadata</name>
      <t indent="0" pn="section-3-1">
	Protected resources supporting metadata
	<bcp14>MUST</bcp14> make a JSON document containing metadata as specified in <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/>
	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
	<tt>/.well-known/oauth-protected-resource</tt>.
	The syntax and semantics of <tt>.well-known</tt>
	are defined in <xref target="RFC8615" format="default" sectionFormat="of" derivedContent="RFC8615"/>.
	The well-known URI path suffix used <bcp14>MUST</bcp14> be registered in the 
	"Well-Known URIs" registry <xref target="IANA.well-known" format="default" sectionFormat="of" derivedContent="IANA.well-known"/>.
	Examples of this construction can be found in <xref target="PRConfigurationRequest" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.
      </t>
      <t indent="0" pn="section-3-2">
	The term "application", as used below (and as used in <xref target="RFC8414" format="default" sectionFormat="of" derivedContent="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 indent="0" pn="section-3-3">
	Different applications utilizing OAuth protected resources in application-specific ways
	<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
	and there are Example-specific metadata values that it needs to publish,
	then it might register and use the
	<tt>example-protected-resource</tt> URI path suffix and publish
	the metadata document at the URL formed by inserting
	<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
	<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 indent="0" pn="section-3-4">
	An OAuth 2.0 application using this specification <bcp14>MUST</bcp14> specify
	what well-known URI suffix it will use for this purpose.
	The same protected resource <bcp14>MAY</bcp14> choose to publish its metadata at multiple
	well-known locations derived from its resource identifier --
	for example, publishing metadata at both
	<tt>/.well-known/example-protected-resource</tt> and
	<tt>/.well-known/oauth-protected-resource</tt>.
      </t>
      <section anchor="PRConfigurationRequest" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-protected-resource-metadata-">Protected Resource Metadata Request</name>
        <t indent="0" pn="section-3.1-1">
	  A protected resource metadata document <bcp14>MUST</bcp14> be queried using an HTTP
	  <tt>GET</tt> request at the previously specified URL.
        </t>
        <t indent="0" pn="section-3.1-2">
	  The consumer of the metadata would make the following request when the
	  resource identifier is <tt>https://resource.example.com</tt>
	  and the well-known URI path suffix is <tt>oauth-protected-resource</tt>
	  to obtain the metadata,
	  since the resource identifier contains no path component:
        </t>
        <sourcecode type="http-message" markers="false" pn="section-3.1-3">
  GET /.well-known/oauth-protected-resource HTTP/1.1
  Host: resource.example.com
</sourcecode>
        <t indent="0" pn="section-3.1-4">
	  If the resource identifier value contains a path or query component,
	  any terminating slash (<tt>/</tt>) following the host component
	  <bcp14>MUST</bcp14> be removed before inserting
	  <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 <tt>https://resource.example.com/resource1</tt>
	  and the well-known URI path suffix is <tt>oauth-protected-resource</tt>
	  to obtain the metadata,
	  since the resource identifier contains a path component:
        </t>
        <sourcecode type="http-message" markers="false" pn="section-3.1-5">
  GET /.well-known/oauth-protected-resource/resource1 HTTP/1.1
  Host: resource.example.com
</sourcecode>
        <t indent="0" pn="section-3.1-6">
	  Using path components enables supporting multiple resources per host.
	  This is required in some multi-tenant hosting configurations.
	  This use of <tt>.well-known</tt> is for supporting
	  multiple resources per host; unlike its use in
	  <xref target="RFC8615" format="default" sectionFormat="of" derivedContent="RFC8615"/>, it does not provide
	  general information about the host.
        </t>
      </section>
      <section anchor="PRConfigurationResponse" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-protected-resource-metadata-r">Protected Resource Metadata Response</name>
        <t indent="0" pn="section-3.2-1">
	  The response is a set of metadata parameters about the protected resource's
	  configuration.
	  A successful response <bcp14>MUST</bcp14> use the 200 OK HTTP status code and return
	  a JSON object using the <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" format="default" sectionFormat="of" derivedContent="Section 2"/>.
	  Additional metadata parameters <bcp14>MAY</bcp14> be defined and used;
	  any metadata parameters that are not understood <bcp14>MUST</bcp14> be ignored.
        </t>
        <t indent="0" pn="section-3.2-2">
	  Parameters with multiple values are represented as JSON arrays.
	  Parameters with zero values <bcp14>MUST</bcp14> be omitted from the response.
        </t>
        <t indent="0" pn="section-3.2-3">
	  An error response uses the applicable HTTP status code value.
        </t>
        <t keepWithNext="true" indent="0" pn="section-3.2-4">The following is a non-normative example response:</t>
        <sourcecode type="http-message" markers="false" pn="section-3.2-5">
  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"
  }
</sourcecode>
      </section>
      <section anchor="PRConfigurationValidation" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-protected-resource-metadata-v">Protected Resource Metadata Validation</name>
        <t indent="0" pn="section-3.3-1">
	  The <tt>resource</tt> value returned <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 <bcp14>MUST NOT</bcp14> be used.
        </t>
        <t indent="0" pn="section-3.3-2">
	  If the protected resource metadata was retrieved from a URL
	  returned by the protected resource via the <tt>WWW-Authenticate</tt>
          <tt>resource_metadata</tt> parameter, then
	  the <tt>resource</tt> value returned <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 <bcp14>MUST NOT</bcp14> be used.
        </t>
        <t indent="0" pn="section-3.3-3">
	  These validation actions can thwart impersonation attacks,
	  as described in <xref target="Impersonation" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.
        </t>
        <t indent="0" pn="section-3.3-4">
	  The recipient <bcp14>MUST</bcp14> validate that any signed metadata was signed
	  by a key belonging to the issuer and that the signature is valid.
	  If the signature does not validate or the issuer is not trusted,
	  the recipient <bcp14>SHOULD</bcp14> treat this as an error condition.
        </t>
      </section>
    </section>
    <section anchor="ASMetadata" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-authorization-server-metada">Authorization Server Metadata</name>
      <t indent="0" pn="section-4-1">
	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
	<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 indent="0" pn="section-4-2">
	The following authorization server metadata parameter
	is defined by this specification and is registered in the 
	"OAuth Authorization Server Metadata" registry established in
"<xref target="RFC8414" format="title" sectionFormat="of" derivedContent="OAuth 2.0 Authorization Server Metadata"/>" <xref target="RFC8414" format="default" sectionFormat="of" derivedContent="RFC8414"/>.

      </t>
      <dl newline="true" spacing="normal" indent="3" pn="section-4-3">
        <dt pn="section-4-3.1">protected_resources</dt>
        <dd pn="section-4-3.2">
          <bcp14>OPTIONAL</bcp14>.
	    JSON array containing a list of resource identifiers for OAuth protected resources
	    that can be used with this authorization server.
	    Authorization servers <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.
	  </dd>
      </dl>
    </section>
    <section anchor="WWW-Authenticate" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-use-of-www-authenticate-for">Use of WWW-Authenticate for Protected Resource Metadata</name>
      <t indent="0" pn="section-5-1">
	A protected resource <bcp14>MAY</bcp14> use the <tt>WWW-Authenticate</tt>
        HTTP response header field, as discussed in <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="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" format="default" sectionFormat="of" derivedContent="Section 3"/>.
	The client might then, for instance, determine what authorization server to use for the resource
	based on protected resource metadata retrieved.
      </t>
      <t indent="0" pn="section-5-2">
	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>
      <figure align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-sequence-diagram">Sequence Diagram</name>
        <artset pn="section-5-3.1">
          <artwork type="svg" name="sequence.svg" align="left" pn="section-5-3.1.1">
			<svg xmlns="http://www.w3.org/2000/svg" baseProfile="tiny" height="550" version="1.2" viewBox="0 0 478 550" 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 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" align="left" pn="section-5-3.1.2">
     +----------+              +----------+    +---------------+
     |  Client  |              | Resource |    | Authorization |
     |          |              |  Server  |    |    Server     |
     +----+-----+              +----+-----+    +-------+-------+
          |                         |                  |
          |  1. Resource Request    |                  |
          | ----------------------&gt; |                  |
          |  Without Access Token   |                  |
          |                         |                  |
          |                         |                  |
          |   2. WWW-Authenticate   |                  |
          | &lt;---------------------- |                  |
          |                         |                  |
          |                         |                  |
          |   3. Fetch RS Metadata  |                  |
          | ----------------------&gt; |                  |
          |                         |                  |
          |                         |                  |
          | 4. RS Metadata Response |                  |
          | &lt;---------------------- |                  |
          |                         |                  |
+---------+---------------+         |                  |
| 5. Validate RS Metadata |         |                  |
| Build AS Metadata URL   |         |                  |
+---------+---------------+         |                  |
          |                         |                  |
          |   6. Fetch AS Metadata  |                  |
          | ------------------------+----------------&gt; |
          |                         |                  |
          |                         |                  |
          | 7. AS Metadata Response |                  |
          | &lt;-----------------------+----------------- |
          |                         |                  |
        +-+-------------------------+------------------+-+
        |       8-9. OAuth Authorization Code Flow       |
        |            Client Obtains Access Token         |
        +-+-------------------------+------------------+-+
          |                         |                  |
          |  10. Resource Request   |                  |
          | ----------------------&gt; |                  |
          |  With Access Token      |                  |
          |                         |                  |
          |                         |                  |
          |  11. Resource Response  |                  |
          | &lt;---------------------- |                  |
          |                         |                  |
     +----+-----+              +----+-----+    +-------+-------+
     |  Client  |              | Resource |    | Authorization |
     |          |              |  Server  |    |    Server     |
     +----------+              +----------+    +---------------+
</artwork>
        </artset>
      </figure>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5-4"><li pn="section-5-4.1" derivedCounter="1.">
          <t indent="0" pn="section-5-4.1.1">
	    The client makes a request to a protected resource without presenting an access token.
          </t>
        </li>
        <li pn="section-5-4.2" derivedCounter="2.">
          <t indent="0" pn="section-5-4.2.1">
	    The resource server responds with a <tt>WWW-Authenticate</tt> header including the URL of the protected resource metadata.
          </t>
        </li>
        <li pn="section-5-4.3" derivedCounter="3.">
          <t indent="0" pn="section-5-4.3.1">
	    The client fetches the protected resource metadata from this URL.
          </t>
        </li>
        <li pn="section-5-4.4" derivedCounter="4.">
          <t indent="0" pn="section-5-4.4.1">
	    The resource server responds with the protected resource metadata
	    according to <xref target="PRConfigurationResponse" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.
          </t>
        </li>
        <li pn="section-5-4.5" derivedCounter="5.">
          <t indent="0" pn="section-5-4.5.1">
	    The client validates the protected resource metadata,
	    as described in <xref target="PRConfigurationValidation" format="default" sectionFormat="of" derivedContent="Section 3.3"/>,
            and builds the authorization server metadata URL from an issuer
            identifier in the resource metadata according to <xref target="RFC8414" format="default" sectionFormat="of" derivedContent="RFC8414"/>.
          </t>
        </li>
        <li pn="section-5-4.6" derivedCounter="6.">
          <t indent="0" pn="section-5-4.6.1">
	    The client makes a request to fetch the authorization server metadata.
          </t>
        </li>
        <li pn="section-5-4.7" derivedCounter="7.">
          <t indent="0" pn="section-5-4.7.1">
	    The authorization server responds with the authorization server metadata document according to <xref target="RFC8414" format="default" sectionFormat="of" derivedContent="RFC8414"/>.
          </t>
        </li>
        <li pn="section-5-4.8" derivedCounter="8.">
          <t indent="0" pn="section-5-4.8.1">
	    The client directs the user agent to the authorization server to begin the authorization flow.
          </t>
        </li>
        <li pn="section-5-4.9" derivedCounter="9.">
          <t indent="0" pn="section-5-4.9.1">
	    The authorization exchange is completed and the authorization server returns an access token to the client.
          </t>
        </li>
        <li pn="section-5-4.10" derivedCounter="10.">
          <t indent="0" pn="section-5-4.10.1">
	    The client repeats the resource request from step 1, presenting the newly obtained access token.
          </t>
        </li>
        <li pn="section-5-4.11" derivedCounter="11.">
          <t indent="0" pn="section-5-4.11.1">
	    The resource server returns the requested protected resource.
          </t>
        </li>
      </ol>
      <section anchor="WWW-Authenticate-Response" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-www-authenticate-response">WWW-Authenticate Response</name>
        <t indent="0" pn="section-5.1-1">
	  This specification introduces a new parameter in the
	  <tt>WWW-Authenticate</tt> HTTP response header field
	  to indicate the protected resource metadata URL:
        </t>
        <dl newline="true" spacing="normal" indent="3" pn="section-5.1-2">
          <dt pn="section-5.1-2.1">resource_metadata:</dt>
          <dd pn="section-5.1-2.2">
		The URL of the protected resource metadata.
	      </dd>
        </dl>
        <t keepWithNext="true" indent="0" pn="section-5.1-3">The response below is an example of a <tt>WWW-Authenticate</tt> header that includes the resource identifier.</t>
        <sourcecode type="http-message" markers="false" pn="section-5.1-4">
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata=
  "https://resource.example.com/.well-known/oauth-protected-resource"
</sourcecode>
        <t indent="0" pn="section-5.1-5">
	  The HTTP status code in the example response above
	  is defined by <xref target="RFC6750" format="default" sectionFormat="of" derivedContent="RFC6750"/>.
        </t>
        <t indent="0" pn="section-5.1-6">
	  This parameter <bcp14>MAY</bcp14> also be used in
	  <tt>WWW-Authenticate</tt> responses using
	  <tt>authorization</tt> schemes other than
	  <tt>"Bearer"</tt> <xref target="RFC6750" format="default" sectionFormat="of" derivedContent="RFC6750"/>,
	  such as the <tt>DPoP</tt> scheme
	  defined by <xref target="RFC9449" format="default" sectionFormat="of" derivedContent="RFC9449"/>.
        </t>
        <t indent="0" pn="section-5.1-7">
	  The <tt>resource_metadata</tt> parameter <bcp14>MAY</bcp14> be combined with other parameters defined in other extensions,
	  such as the <tt>max_age</tt> parameter defined by <xref target="RFC9470" format="default" sectionFormat="of" derivedContent="RFC9470"/>.
        </t>
      </section>
      <section anchor="changes" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-changes-to-resource-metadat">Changes to Resource Metadata</name>
        <t indent="0" pn="section-5.2-1">
	  At any point, for any reason determined by the resource server,
	  the protected resource <bcp14>MAY</bcp14> respond with a new <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 <tt>WWW-Authenticate</tt> response,
	  it <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" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.
	  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" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-client-identifier-and-clien">Client Identifier and Client Authentication</name>
        <t indent="0" pn="section-5.3-1">
	  The way in which the client identifier is established at the authorization server is out of scope for this specification.
        </t>
        <t indent="0" pn="section-5.3-2">


	  This specification is intended to be deployed in scenarios where the client has no prior knowledge about the resource server
	  and where the resource server might or might not have prior knowledge about the client.
        </t>
        <t indent="0" pn="section-5.3-3">
	  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" format="default" sectionFormat="of" derivedContent="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" numbered="true" removeInRFC="false" toc="include" pn="section-5.4">
        <name slugifiedName="name-compatibility-with-other-au">Compatibility with Other Authentication Methods</name>
        <t indent="0" pn="section-5.4-1">
	  Resource servers <bcp14>MAY</bcp14> return other <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
	  and allows clients to choose their preferred authentication scheme.
        </t>
      </section>
    </section>
    <section anchor="StringOps" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-string-operations">String Operations</name>
      <t indent="0" pn="section-6-1">
	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 <tt>resource</tt>.  Comparing Unicode strings <xref target="UNICODE" format="default" sectionFormat="of" derivedContent="UNICODE"/>,
	however, has significant security implications.
      </t>
      <t indent="0" pn="section-6-2">
	Therefore, comparisons between JSON strings and other Unicode
	strings <bcp14>MUST</bcp14> be performed as specified below:

      </t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-6-3"><li pn="section-6-3.1" derivedCounter="1.">
          <t indent="0" pn="section-6-3.1.1">
	    Remove any JSON-applied escaping to produce an array of
	    Unicode code points.
          </t>
        </li>
        <li pn="section-6-3.2" derivedCounter="2.">
          <t indent="0" pn="section-6-3.2.1">
	    Unicode Normalization <xref target="USA15" format="default" sectionFormat="of" derivedContent="USA15"/> <bcp14>MUST NOT</bcp14>
	    be applied at any point to either the JSON string or
	    the string it is to be compared against.
          </t>
        </li>
        <li pn="section-6-3.3" derivedCounter="3.">
          <t indent="0" pn="section-6-3.3.1">
	    Comparisons between the two strings <bcp14>MUST</bcp14> be performed as a
	    Unicode code-point-to-code-point equality comparison.
          </t>
        </li>
      </ol>
      <t indent="0" pn="section-6-4">
	Note that this is the same equality comparison procedure as that described in
	<xref section="8.3" sectionFormat="of" target="RFC8259" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8259#section-8.3" derivedContent="RFC8259"/>.
      </t>
    </section>
    <section anchor="Security" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <section anchor="TLSRequirements" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-tls-requirements">TLS Requirements</name>
        <t indent="0" pn="section-7.1-1">
	  Implementations <bcp14>MUST</bcp14> support TLS.
	  They <bcp14>MUST</bcp14> follow the guidance in
	  <xref target="BCP195" format="default" sectionFormat="of" derivedContent="BCP195"/>,
	  which provides recommendations and requirements
	  for improving the security of deployed services that use TLS.
        </t>
        <t indent="0" pn="section-7.1-2">
	  The use of TLS at the protected resource metadata URLs
	  protects against information disclosure and tampering.
        </t>
      </section>
      <section anchor="Scopes" numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
        <name slugifiedName="name-scopes">Scopes</name>
        <t indent="0" pn="section-7.2-1">
					The <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 <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 
<xref section="2.3" sectionFormat="of" target="RFC9700" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9700#section-2.3" derivedContent="RFC9700">"Best Current Practice for OAuth 2.0 Security"</xref>.
        </t>
      </section>
      <section anchor="Impersonation" numbered="true" removeInRFC="false" toc="include" pn="section-7.3">
        <name slugifiedName="name-impersonation-attacks">Impersonation Attacks</name>
        <t indent="0" pn="section-7.3-1">
	  TLS certificate checking <bcp14>MUST</bcp14> be performed by the client
	  as described in <xref target="RFC9525" format="default" sectionFormat="of" derivedContent="RFC9525"/>
	  when making a protected resource metadata request.
	  Checking that the server certificate is valid for the resource identifier URL
	  prevents 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,
	  using the protected resource that they are impersonating.
        </t>
        <t indent="0" pn="section-7.3-2">
	  An attacker may also attempt to impersonate a protected resource by publishing
	  a metadata document that contains a <tt>resource</tt> metadata parameter
	  using the resource identifier URL of the protected resource being impersonated
	  but 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 <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 <tt>resource</tt> metadata parameter
	  in the protected resource metadata document received by the client,
	  as described in <xref target="PRConfigurationValidation" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.
        </t>
      </section>
      <section anchor="AudienceRestriction" numbered="true" removeInRFC="false" toc="include" pn="section-7.4">
        <name slugifiedName="name-audience-restricted-access-">Audience-Restricted Access Tokens</name>
        <t indent="0" pn="section-7.4-1">
      		If a client expects to interact with multiple resource servers, the client
      		<bcp14>SHOULD</bcp14> request audience-restricted access tokens using <xref target="RFC8707" format="default" sectionFormat="of" derivedContent="RFC8707"/>,
      		and the authorization server <bcp14>SHOULD</bcp14> support audience-restricted access tokens.
        </t>
        <t indent="0" pn="section-7.4-2">
      		Without audience-restricted access tokens, a malicious resource server (RS1) may be
      		able to use the <tt>WWW-Authenticate</tt> header to get a client
      		to request an access token with a scope used by a legitimate resource server (RS2), and
      		after the client sends a request to RS1, then RS1 could reuse the access token at RS2.
        </t>
        <t indent="0" pn="section-7.4-3">
      		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" format="default" sectionFormat="of" derivedContent="RFC8707"/>
      		is <bcp14>RECOMMENDED</bcp14> when using the features in this specification.
        </t>
      </section>
      <section anchor="StandardFormat" numbered="true" removeInRFC="false" toc="include" pn="section-7.5">
        <name slugifiedName="name-publishing-metadata-in-a-st">Publishing Metadata in a Standard Format</name>
        <t indent="0" pn="section-7.5-1">
	  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" numbered="true" removeInRFC="false" toc="include" pn="section-7.6">
        <name slugifiedName="name-authorization-servers">Authorization Servers</name>
        <t indent="0" pn="section-7.6-1">
	  To support use cases in which the set of legitimate authorization servers
	  to use with the protected resource is enumerable,
	  this specification defines the <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 indent="0" pn="section-7.6-2">
	  Secure determination of appropriate authorization servers
	  to use with a protected resource for all use cases
	  is out of scope 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, an attacker may be able to act as
	  an adversary-in-the-middle proxy to a valid authorization server without
	  it being detected by the authorization server or the client.
        </t>
        <t indent="0" pn="section-7.6-3">
	  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 a set of authorization servers,
          the locations of which may be known via out-of-band mechanisms.
          Alternatively, as described in this specification, the locations
          of the authorization servers could be published by the protected
          resource as metadata values.
	  In other cases, the set of authorization servers that can be used with
	  a protected resource can 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" numbered="true" removeInRFC="false" toc="include" pn="section-7.7">
        <name slugifiedName="name-server-side-request-forgery">Server-Side Request Forgery (SSRF)</name>
        <t indent="0" pn="section-7.7-1">
					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 ASes it has no prior knowledge of, this opens a risk for Server-Side Request Forgery (SSRF) attacks by malicious users or malicious resource servers. Clients <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 Open Worldwide Application Security Project (OWASP) SSRF Prevention Cheat Sheet <xref target="OWASP.SSRF" format="default" sectionFormat="of" derivedContent="OWASP.SSRF"/>.
        </t>
      </section>
      <section anchor="phishing" numbered="true" removeInRFC="false" toc="include" pn="section-7.8">
        <name slugifiedName="name-phishing">Phishing</name>
        <t indent="0" pn="section-7.8-1">
      		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" numbered="true" removeInRFC="false" toc="include" pn="section-7.9">
        <name slugifiedName="name-differences-between-unsigne">Differences Between Unsigned and Signed Metadata</name>
        <t indent="0" pn="section-7.9-1">
	  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 using X.509 (PKIX), as described in <xref target="RFC9525" format="default" sectionFormat="of" derivedContent="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 indent="0" pn="section-7.9-2">
	  When using unsigned metadata, the party issuing the metadata
	  is the protected resource itself, which is represented by the
	  <tt>resource</tt> value in the metadata,
	  whereas when using signed metadata, the party issuing the metadata
	  is represented by the <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" numbered="true" removeInRFC="false" toc="include" pn="section-7.10">
        <name slugifiedName="name-metadata-caching">Metadata Caching</name>
        <t indent="0" pn="section-7.10-1">
	  Protected resource metadata is retrieved using an HTTP
	  <tt>GET</tt> request,
	  as specified in <xref target="PRConfigurationRequest" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.
	  Normal HTTP caching behaviors apply, meaning that the <tt>GET</tt> request may retrieve
	  a cached copy of the content, rather than the latest copy.
	  Implementations should utilize HTTP caching directives such as
	  <tt>Cache-Control</tt>
	  with <tt>max-age</tt>,
	  as defined in <xref target="RFC9111" format="default" sectionFormat="of" derivedContent="RFC9111"/>,
	  to enable caching of retrieved metadata for appropriate time periods.
        </t>
      </section>
    </section>
    <section anchor="IANA" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">
	Values are registered via Specification Required <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.
        Registration requests should be sent to &lt;oauth-ext-review@ietf.org&gt;
	to initiate a two-week review period.
	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 indent="0" pn="section-8-2">
	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 indent="0" pn="section-8-3">
	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.    If the designated experts are not responsive, the registration requesters should contact IANA to escalate the process. 
      </t>
      <t indent="0" pn="section-8-4">
        Designated experts should apply the following criteria when reviewing
        proposed registrations: They must be unique -- that is, they should not 
        duplicate existing functionality; they are likely generally applicable, 
        as opposed to being used for a single application; and they are clear 
        and fit the purpose of the registry.
      </t>
      <t indent="0" pn="section-8-5">
	IANA must only accept registry updates from the designated experts and should direct
	all requests for registration to the review mailing list.
      </t>
      <t indent="0" pn="section-8-6">
In order to enable broadly informed review of registration decisions, there should be multiple designated experts to represent the perspectives of different applications using this specification.  
	In cases where registration may be perceived as a conflict of interest for a particular expert,
	that expert should defer to the judgment of the other experts.
      </t>
      <t indent="0" pn="section-8-7">
	 The mailing list is used to enable
	 public review of registration requests, which enables both designated experts
	 and other interested parties to provide feedback on proposed registrations.
         Designated experts may allocate values prior to publication of the 
         final specification.  This allows authors to receive guidance from 
         the designated experts early, so any identified issues can be fixed 
         before the final specification is published.
      </t>
      <section anchor="PRMetadataReg" numbered="true" removeInRFC="false" toc="include" pn="section-8.1">
        <name slugifiedName="name-oauth-protected-resource-me">OAuth Protected Resource Metadata Registry</name>
        <t indent="0" pn="section-8.1-1">
	  This specification establishes the
	  "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 anchor="PRMetadataTemplate" numbered="true" removeInRFC="false" toc="include" pn="section-8.1.1">
          <name slugifiedName="name-registration-template">Registration Template</name>
          <dl newline="true" spacing="normal" indent="3" pn="section-8.1.1-1">
            <dt pn="section-8.1.1-1.1">Metadata Name:</dt>
            <dd pn="section-8.1.1-1.2">
                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.
              </dd>
            <dt pn="section-8.1.1-1.3">Metadata Description:</dt>
            <dd pn="section-8.1.1-1.4">
                Brief description of the metadata (e.g., "Resource identifier URL").
              </dd>
            <dt pn="section-8.1.1-1.5">Change Controller:</dt>
            <dd pn="section-8.1.1-1.6">
                For IETF Stream RFCs, list "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.
              </dd>
            <dt pn="section-8.1.1-1.7">Specification Document(s):</dt>
            <dd pn="section-8.1.1-1.8">
                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.
              </dd>
          </dl>
        </section>
        <section anchor="PRMetadataContents" numbered="true" removeInRFC="false" toc="include" pn="section-8.1.2">
          <name slugifiedName="name-initial-registry-contents">Initial Registry Contents</name>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-1">
            <dt pn="section-8.1.2-1.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-1.2">
              <tt>resource</tt></dd>
            <dt pn="section-8.1.2-1.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-1.4"> Protected resource's resource
            identifier URL</dd>
            <dt pn="section-8.1.2-1.5">Change Controller:</dt>
            <dd pn="section-8.1.2-1.6">IETF</dd>
            <dt pn="section-8.1.2-1.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-1.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-2">
            <dt pn="section-8.1.2-2.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-2.2">
              <tt>authorization_servers</tt></dd>
            <dt pn="section-8.1.2-2.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-2.4">JSON array containing a list of
            OAuth authorization server issuer identifiers</dd>
            <dt pn="section-8.1.2-2.5">Change Controller:</dt>
            <dd pn="section-8.1.2-2.6">IETF</dd>
            <dt pn="section-8.1.2-2.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-2.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-3">
            <dt pn="section-8.1.2-3.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-3.2">
              <tt>jwks_uri</tt></dd>
            <dt pn="section-8.1.2-3.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-3.4">URL of the protected resource's
            JWK Set document</dd>
            <dt pn="section-8.1.2-3.5">Change Controller:</dt>
            <dd pn="section-8.1.2-3.6">IETF</dd>
            <dt pn="section-8.1.2-3.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-3.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-4">
            <dt pn="section-8.1.2-4.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-4.2">
              <tt>scopes_supported</tt></dd>
            <dt pn="section-8.1.2-4.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-4.4">JSON array containing a list of
            the OAuth 2.0 scope values that are used in authorization
            requests to request access to this protected resource</dd>
            <dt pn="section-8.1.2-4.5">Change Controller:</dt>
            <dd pn="section-8.1.2-4.6">IETF</dd>
            <dt pn="section-8.1.2-4.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-4.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-5">
            <dt pn="section-8.1.2-5.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-5.2">
              <tt>bearer_methods_supported</tt></dd>
            <dt pn="section-8.1.2-5.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-5.4">JSON array containing a list of
            the OAuth 2.0 bearer token presentation methods that this
            protected resource supports</dd>
            <dt pn="section-8.1.2-5.5">Change Controller:</dt>
            <dd pn="section-8.1.2-5.6">IETF</dd>
            <dt pn="section-8.1.2-5.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-5.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-6">
            <dt pn="section-8.1.2-6.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-6.2">
              <tt>resource_signing_alg_values_supported</tt></dd>
            <dt pn="section-8.1.2-6.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-6.4">JSON array containing a list of
            the JWS signing algorithms (<tt>alg</tt> values) supported by the
            protected resource for signed content</dd>
            <dt pn="section-8.1.2-6.5">Change Controller:</dt>
            <dd pn="section-8.1.2-6.6">IETF</dd>
            <dt pn="section-8.1.2-6.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-6.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-7">
            <dt pn="section-8.1.2-7.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-7.2">
              <tt>resource_name</tt></dd>
            <dt pn="section-8.1.2-7.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-7.4">Human-readable name of the
            protected resource</dd>
            <dt pn="section-8.1.2-7.5">Change Controller:</dt>
            <dd pn="section-8.1.2-7.6">IETF</dd>
            <dt pn="section-8.1.2-7.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-7.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-8">
            <dt pn="section-8.1.2-8.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-8.2">
              <tt>resource_documentation</tt></dd>
            <dt pn="section-8.1.2-8.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-8.4">URL of a page containing
            human-readable information that developers might want or need to
            know when using the protected resource</dd>
            <dt pn="section-8.1.2-8.5">Change Controller:</dt>
            <dd pn="section-8.1.2-8.6">IETF</dd>
            <dt pn="section-8.1.2-8.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-8.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-9">
            <dt pn="section-8.1.2-9.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-9.2">
              <tt>resource_policy_uri</tt></dd>
            <dt pn="section-8.1.2-9.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-9.4">URL of a page containing
            human-readable information about the protected resource's
            requirements on how the client can use the data provided by the
            protected resource</dd>
            <dt pn="section-8.1.2-9.5">Change Controller:</dt>
            <dd pn="section-8.1.2-9.6">IETF</dd>
            <dt pn="section-8.1.2-9.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-9.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-10">
            <dt pn="section-8.1.2-10.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-10.2">
              <tt>resource_tos_uri</tt></dd>
            <dt pn="section-8.1.2-10.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-10.4">URL of a page containing
            human-readable information about the protected resource's terms of
            service</dd>
            <dt pn="section-8.1.2-10.5">Change Controller:</dt>
            <dd pn="section-8.1.2-10.6">IETF</dd>
            <dt pn="section-8.1.2-10.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-10.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-11">
            <dt pn="section-8.1.2-11.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-11.2">
              <tt>tls_client_certificate_bound_access_tokens</tt></dd>
            <dt pn="section-8.1.2-11.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-11.4">Boolean value indicating
            protected resource support for mutual-TLS client certificate-bound
            access tokens</dd>
            <dt pn="section-8.1.2-11.5">Change Controller:</dt>
            <dd pn="section-8.1.2-11.6">IETF</dd>
            <dt pn="section-8.1.2-11.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-11.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-12">
            <dt pn="section-8.1.2-12.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-12.2">
              <tt>authorization_details_types_supported</tt></dd>
            <dt pn="section-8.1.2-12.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-12.4">JSON array containing a list of
	    the authorization details <tt>type</tt> values supported by the
	    resource server when the <tt>authorization_details</tt> request
	    parameter is used</dd>
            <dt pn="section-8.1.2-12.5">Change Controller:</dt>
            <dd pn="section-8.1.2-12.6">IETF</dd>
            <dt pn="section-8.1.2-12.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-12.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-13">
            <dt pn="section-8.1.2-13.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-13.2">
              <tt>dpop_signing_alg_values_supported</tt></dd>
            <dt pn="section-8.1.2-13.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-13.4">JSON array containing a list of
            the JWS <tt>alg</tt> values supported by the resource server for validating
            DPoP proof JWTs</dd>
            <dt pn="section-8.1.2-13.5">Change Controller:</dt>
            <dd pn="section-8.1.2-13.6">IETF</dd>
            <dt pn="section-8.1.2-13.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-13.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-14">
            <dt pn="section-8.1.2-14.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-14.2">
              <tt>dpop_bound_access_tokens_required</tt></dd>
            <dt pn="section-8.1.2-14.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-14.4">Boolean value specifying
            whether the protected resource always requires the use of
            DPoP-bound access tokens</dd>
            <dt pn="section-8.1.2-14.5">Change Controller:</dt>
            <dd pn="section-8.1.2-14.6">IETF</dd>
            <dt pn="section-8.1.2-14.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-14.8">
              <xref target="PRMetadata" format="default" sectionFormat="of" derivedContent="Section 2"/> of RFC 9728</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.1.2-15">
            <dt pn="section-8.1.2-15.1">Metadata Name:</dt>
            <dd pn="section-8.1.2-15.2">
              <tt>signed_metadata</tt></dd>
            <dt pn="section-8.1.2-15.3">Metadata Description:</dt>
            <dd pn="section-8.1.2-15.4">Signed JWT containing metadata
	    parameters about the protected resource as claims</dd>
            <dt pn="section-8.1.2-15.5">Change Controller:</dt>
            <dd pn="section-8.1.2-15.6">IETF</dd>
            <dt pn="section-8.1.2-15.7">Specification Document(s):</dt>
            <dd pn="section-8.1.2-15.8">
              <xref target="SignedMetadata" format="default" sectionFormat="of" derivedContent="Section 2.2"/> of RFC 9728</dd>
          </dl>
        </section>
      </section>
      <section anchor="ASMetadataReg" numbered="true" removeInRFC="false" toc="include" pn="section-8.2">
        <name slugifiedName="name-oauth-authorization-server-">OAuth Authorization Server Metadata Registry</name>
        <t indent="0" pn="section-8.2-1">
	  IANA has registered the following authorization server metadata parameter
	  in the
	  "OAuth Authorization Server Metadata" registry established in
"<xref target="RFC8414" format="title" sectionFormat="of" derivedContent="OAuth 2.0 Authorization Server Metadata"/>" <xref target="RFC8414" format="default" sectionFormat="of" derivedContent="RFC8414"/>.
        </t>
        <section anchor="ASMetadataContents" numbered="true" removeInRFC="false" toc="include" pn="section-8.2.1">
          <name slugifiedName="name-registry-contents">Registry Contents</name>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.2.1-1">
            <dt pn="section-8.2.1-1.1">Metadata Name:</dt>
            <dd pn="section-8.2.1-1.2">
              <tt>protected_resources</tt></dd>
            <dt pn="section-8.2.1-1.3">Metadata Description:</dt>
            <dd pn="section-8.2.1-1.4">JSON array containing a list of
            resource identifiers for OAuth protected resources</dd>
            <dt pn="section-8.2.1-1.5">Change Controller:</dt>
            <dd pn="section-8.2.1-1.6">IETF</dd>
            <dt pn="section-8.2.1-1.7">Specification Document(s):</dt>
            <dd pn="section-8.2.1-1.8">
              <xref target="ASMetadata" format="default" sectionFormat="of" derivedContent="Section 4"/> of RFC 9728</dd>
          </dl>
        </section>
      </section>
      <section anchor="WellKnownRegistry" numbered="true" removeInRFC="false" toc="include" pn="section-8.3">
        <name slugifiedName="name-well-known-uris-registry">Well-Known URIs Registry</name>
        <t indent="0" pn="section-8.3-1">
	  This specification registers the well-known URI defined in
	  <xref target="PRConfig" format="default" sectionFormat="of" derivedContent="Section 3"/> in the 
	  "Well-Known URIs" registry <xref target="IANA.well-known" format="default" sectionFormat="of" derivedContent="IANA.well-known"/>.
        </t>
        <section anchor="WellKnownContents" numbered="true" removeInRFC="false" toc="include" pn="section-8.3.1">
          <name slugifiedName="name-registry-contents-2">Registry Contents</name>
          <dl spacing="compact" newline="false" indent="3" pn="section-8.3.1-1">
            <dt pn="section-8.3.1-1.1">URI Suffix:</dt>
            <dd pn="section-8.3.1-1.2">
              <tt>oauth-protected-resource</tt></dd>
            <dt pn="section-8.3.1-1.3">Reference:</dt>
            <dd pn="section-8.3.1-1.4">
              <xref target="PRConfig" format="default" sectionFormat="of" derivedContent="Section 3"/> of RFC 9728</dd>
            <dt pn="section-8.3.1-1.5">Status:</dt>
            <dd pn="section-8.3.1-1.6">permanent</dd>
            <dt pn="section-8.3.1-1.7">Change Controller:</dt>
            <dd pn="section-8.3.1-1.8">IETF</dd>
            <dt pn="section-8.3.1-1.9">Related Information:</dt>
            <dd pn="section-8.3.1-1.10">(none)</dd>
          </dl>
        </section>
      </section>
    </section>
  </middle>
  <back>
    <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 pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <referencegroup anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195" derivedAnchor="BCP195">
          <reference anchor="RFC8996" target="https://www.rfc-editor.org/info/rfc8996" quoteTitle="true">
            <front>
              <title>Deprecating TLS 1.0 and TLS 1.1</title>
              <author fullname="K. Moriarty" initials="K." surname="Moriarty"/>
              <author fullname="S. Farrell" initials="S." surname="Farrell"/>
              <date month="March" year="2021"/>
              <abstract>
                <t indent="0">This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.</t>
                <t indent="0">This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.</t>
                <t indent="0">This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="195"/>
            <seriesInfo name="RFC" value="8996"/>
            <seriesInfo name="DOI" value="10.17487/RFC8996"/>
          </reference>
          <reference anchor="RFC9325" target="https://www.rfc-editor.org/info/rfc9325" quoteTitle="true">
            <front>
              <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
              <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
              <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
              <author fullname="T. Fossati" initials="T." surname="Fossati"/>
              <date month="November" year="2022"/>
              <abstract>
                <t indent="0">Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.</t>
                <t indent="0">RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="195"/>
            <seriesInfo name="RFC" value="9325"/>
            <seriesInfo name="DOI" value="10.17487/RFC9325"/>
          </reference>
        </referencegroup>
        <referencegroup anchor="BCP47" target="https://www.rfc-editor.org/info/bcp47" derivedAnchor="BCP47">
          <reference anchor="RFC4647" target="https://www.rfc-editor.org/info/rfc4647" quoteTitle="true">
            <front>
              <title>Matching of Language Tags</title>
              <author fullname="A. Phillips" initials="A." role="editor" surname="Phillips"/>
              <author fullname="M. Davis" initials="M." role="editor" surname="Davis"/>
              <date month="September" year="2006"/>
              <abstract>
                <t indent="0">This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="47"/>
            <seriesInfo name="RFC" value="4647"/>
            <seriesInfo name="DOI" value="10.17487/RFC4647"/>
          </reference>
          <reference anchor="RFC5646" target="https://www.rfc-editor.org/info/rfc5646" quoteTitle="true">
            <front>
              <title>Tags for Identifying Languages</title>
              <author fullname="A. Phillips" initials="A." role="editor" surname="Phillips"/>
              <author fullname="M. Davis" initials="M." role="editor" surname="Davis"/>
              <date month="September" year="2009"/>
              <abstract>
                <t indent="0">This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="47"/>
            <seriesInfo name="RFC" value="5646"/>
            <seriesInfo name="DOI" value="10.17487/RFC5646"/>
          </reference>
        </referencegroup>
        <reference anchor="IANA.Language" target="https://www.iana.org/assignments/language-subtag-registry" quoteTitle="true" derivedAnchor="IANA.Language">
          <front>
            <title>Language Subtag Registry</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC7518" target="https://www.rfc-editor.org/info/rfc7518" quoteTitle="true" derivedAnchor="JWA">
          <front>
            <title>JSON Web Algorithms (JWA)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="May" year="2015"/>
            <abstract>
              <t indent="0">This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7518"/>
          <seriesInfo name="DOI" value="10.17487/RFC7518"/>
        </reference>
        <reference anchor="RFC7516" target="https://www.rfc-editor.org/info/rfc7516" quoteTitle="true" derivedAnchor="JWE">
          <front>
            <title>JSON Web Encryption (JWE)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Hildebrand" initials="J." surname="Hildebrand"/>
            <date month="May" year="2015"/>
            <abstract>
              <t indent="0">JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7516"/>
          <seriesInfo name="DOI" value="10.17487/RFC7516"/>
        </reference>
        <reference anchor="RFC7517" target="https://www.rfc-editor.org/info/rfc7517" quoteTitle="true" derivedAnchor="JWK">
          <front>
            <title>JSON Web Key (JWK)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="May" year="2015"/>
            <abstract>
              <t indent="0">A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7517"/>
          <seriesInfo name="DOI" value="10.17487/RFC7517"/>
        </reference>
        <reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7515" quoteTitle="true" derivedAnchor="JWS">
          <front>
            <title>JSON Web Signature (JWS)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <date month="May" year="2015"/>
            <abstract>
              <t indent="0">JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7515"/>
          <seriesInfo name="DOI" value="10.17487/RFC7515"/>
        </reference>
        <reference anchor="RFC7519" target="https://www.rfc-editor.org/info/rfc7519" quoteTitle="true" derivedAnchor="JWT">
          <front>
            <title>JSON Web Token (JWT)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <date month="May" year="2015"/>
            <abstract>
              <t indent="0">JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7519"/>
          <seriesInfo name="DOI" value="10.17487/RFC7519"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC6749" target="https://www.rfc-editor.org/info/rfc6749" quoteTitle="true" derivedAnchor="RFC6749">
          <front>
            <title>The OAuth 2.0 Authorization Framework</title>
            <author fullname="D. Hardt" initials="D." role="editor" surname="Hardt"/>
            <date month="October" year="2012"/>
            <abstract>
              <t indent="0">The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6749"/>
          <seriesInfo name="DOI" value="10.17487/RFC6749"/>
        </reference>
        <reference anchor="RFC6750" target="https://www.rfc-editor.org/info/rfc6750" quoteTitle="true" derivedAnchor="RFC6750">
          <front>
            <title>The OAuth 2.0 Authorization Framework: Bearer Token Usage</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="D. Hardt" initials="D." surname="Hardt"/>
            <date month="October" year="2012"/>
            <abstract>
              <t indent="0">This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6750"/>
          <seriesInfo name="DOI" value="10.17487/RFC6750"/>
        </reference>
        <reference anchor="RFC7591" target="https://www.rfc-editor.org/info/rfc7591" quoteTitle="true" derivedAnchor="RFC7591">
          <front>
            <title>OAuth 2.0 Dynamic Client Registration Protocol</title>
            <author fullname="J. Richer" initials="J." role="editor" surname="Richer"/>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="M. Machulak" initials="M." surname="Machulak"/>
            <author fullname="P. Hunt" initials="P." surname="Hunt"/>
            <date month="July" year="2015"/>
            <abstract>
              <t indent="0">This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7591"/>
          <seriesInfo name="DOI" value="10.17487/RFC7591"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" quoteTitle="true" derivedAnchor="RFC8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
            <date month="December" year="2017"/>
            <abstract>
              <t indent="0">JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t indent="0">This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </reference>
        <reference anchor="RFC8414" target="https://www.rfc-editor.org/info/rfc8414" quoteTitle="true" derivedAnchor="RFC8414">
          <front>
            <title>OAuth 2.0 Authorization Server Metadata</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <date month="June" year="2018"/>
            <abstract>
              <t indent="0">This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8414"/>
          <seriesInfo name="DOI" value="10.17487/RFC8414"/>
        </reference>
        <reference anchor="RFC8615" target="https://www.rfc-editor.org/info/rfc8615" quoteTitle="true" derivedAnchor="RFC8615">
          <front>
            <title>Well-Known Uniform Resource Identifiers (URIs)</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="May" year="2019"/>
            <abstract>
              <t indent="0">This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
              <t indent="0">In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8615"/>
          <seriesInfo name="DOI" value="10.17487/RFC8615"/>
        </reference>
        <reference anchor="RFC8705" target="https://www.rfc-editor.org/info/rfc8705" quoteTitle="true" derivedAnchor="RFC8705">
          <front>
            <title>OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens</title>
            <author fullname="B. Campbell" initials="B." surname="Campbell"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <author fullname="T. Lodderstedt" initials="T." surname="Lodderstedt"/>
            <date month="February" year="2020"/>
            <abstract>
              <t indent="0">This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8705"/>
          <seriesInfo name="DOI" value="10.17487/RFC8705"/>
        </reference>
        <reference anchor="RFC8707" target="https://www.rfc-editor.org/info/rfc8707" quoteTitle="true" derivedAnchor="RFC8707">
          <front>
            <title>Resource Indicators for OAuth 2.0</title>
            <author fullname="B. Campbell" initials="B." surname="Campbell"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="February" year="2020"/>
            <abstract>
              <t indent="0">This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8707"/>
          <seriesInfo name="DOI" value="10.17487/RFC8707"/>
        </reference>
        <reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9110" quoteTitle="true" derivedAnchor="RFC9110">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t indent="0">This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="RFC9111" target="https://www.rfc-editor.org/info/rfc9111" quoteTitle="true" derivedAnchor="RFC9111">
          <front>
            <title>HTTP Caching</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</t>
              <t indent="0">This document obsoletes RFC 7234.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="98"/>
          <seriesInfo name="RFC" value="9111"/>
          <seriesInfo name="DOI" value="10.17487/RFC9111"/>
        </reference>
        <reference anchor="RFC9396" target="https://www.rfc-editor.org/info/rfc9396" quoteTitle="true" derivedAnchor="RFC9396">
          <front>
            <title>OAuth 2.0 Rich Authorization Requests</title>
            <author fullname="T. Lodderstedt" initials="T." surname="Lodderstedt"/>
            <author fullname="J. Richer" initials="J." surname="Richer"/>
            <author fullname="B. Campbell" initials="B." surname="Campbell"/>
            <date month="May" year="2023"/>
            <abstract>
              <t indent="0">This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9396"/>
          <seriesInfo name="DOI" value="10.17487/RFC9396"/>
        </reference>
        <reference anchor="RFC9449" target="https://www.rfc-editor.org/info/rfc9449" quoteTitle="true" derivedAnchor="RFC9449">
          <front>
            <title>OAuth 2.0 Demonstrating Proof of Possession (DPoP)</title>
            <author fullname="D. Fett" initials="D." surname="Fett"/>
            <author fullname="B. Campbell" initials="B." surname="Campbell"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="T. Lodderstedt" initials="T." surname="Lodderstedt"/>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="D. Waite" initials="D." surname="Waite"/>
            <date month="September" year="2023"/>
            <abstract>
              <t indent="0">This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9449"/>
          <seriesInfo name="DOI" value="10.17487/RFC9449"/>
        </reference>
        <reference anchor="RFC9525" target="https://www.rfc-editor.org/info/rfc9525" quoteTitle="true" derivedAnchor="RFC9525">
          <front>
            <title>Service Identity in TLS</title>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <author fullname="R. Salz" initials="R." surname="Salz"/>
            <date month="November" year="2023"/>
            <abstract>
              <t indent="0">Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions.</t>
              <t indent="0">This document obsoletes RFC 6125.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9525"/>
          <seriesInfo name="DOI" value="10.17487/RFC9525"/>
        </reference>
        <reference anchor="UNICODE" target="https://www.unicode.org/versions/latest/" quoteTitle="true" derivedAnchor="UNICODE">
          <front>
            <title abbrev="Unicode">The Unicode Standard</title>
            <author>
              <organization showOnFrontPage="true">The Unicode Consortium</organization>
              <address/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="USA15" target="https://www.unicode.org/reports/tr15/" quoteTitle="true" derivedAnchor="USA15">
          <front>
            <title>Unicode Normalization Forms</title>
            <author fullname="Ken Whistler" initials="K." surname="Whistler" role="editor">
	  </author>
            <date day="14" month="August" year="2024"/>
          </front>
          <seriesInfo name="Unicode Standard Annex" value="#15"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="FAPI.MessageSigning" target="https://openid.net/specs/fapi-2_0-message-signing.html" quoteTitle="true" derivedAnchor="FAPI.MessageSigning">
          <front>
            <title>FAPI 2.0 Message Signing (Draft)</title>
            <author fullname="Dave Tonge" initials="D." surname="Tonge">
              <organization abbrev="Moneyhub" showOnFrontPage="true">Moneyhub Financial Technology</organization>
            </author>
            <author fullname="Daniel Fett" initials="D." surname="Fett">
              <organization showOnFrontPage="true">Authlete</organization>
            </author>
            <date day="24" month="March" year="2023"/>
          </front>
        </reference>
        <reference anchor="IANA.JOSE" target="https://www.iana.org/assignments/jose" quoteTitle="true" derivedAnchor="IANA.JOSE">
          <front>
            <title>JSON Web Signature and Encryption Algorithms</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="IANA.well-known" target="https://www.iana.org/assignments/well-known-uris" quoteTitle="true" derivedAnchor="IANA.well-known">
          <front>
            <title>Well-Known URIs</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="OpenID.Discovery" target="https://openid.net/specs/openid-connect-discovery-1_0.html" quoteTitle="true" derivedAnchor="OpenID.Discovery">
          <front>
            <title>OpenID Connect Discovery 1.0 incorporating errata set 2</title>
            <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
              <organization abbrev="NAT.Consulting (was at NRI)" showOnFrontPage="true">NAT.Consulting</organization>
            </author>
            <author fullname="John Bradley" initials="J." surname="Bradley">
              <organization abbrev="Yubico (was at Ping Identity)" showOnFrontPage="true">Yubico</organization>
            </author>
            <author fullname="Michael B. Jones" initials="M." surname="Jones">
              <organization abbrev="Self-Issued Consulting (was at Microsoft)" showOnFrontPage="true">Self-Issued Consulting</organization>
            </author>
            <author fullname="Edmund Jay" initials="E." surname="Jay">
              <organization abbrev="Illumila" showOnFrontPage="true">Illumila</organization>
            </author>
            <date day="15" month="December" year="2023"/>
          </front>
        </reference>
        <reference anchor="OWASP.SSRF" target="https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html" quoteTitle="true" derivedAnchor="OWASP.SSRF">
          <front>
            <title>OWASP Server-Side Request Forgery Prevention Cheat Sheet</title>
            <author>
              <organization showOnFrontPage="true">OWASP Foundation</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC7033" target="https://www.rfc-editor.org/info/rfc7033" quoteTitle="true" derivedAnchor="RFC7033">
          <front>
            <title>WebFinger</title>
            <author fullname="P. Jones" initials="P." surname="Jones"/>
            <author fullname="G. Salgueiro" initials="G." surname="Salgueiro"/>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Smarr" initials="J." surname="Smarr"/>
            <date month="September" year="2013"/>
            <abstract>
              <t indent="0">This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7033"/>
          <seriesInfo name="DOI" value="10.17487/RFC7033"/>
        </reference>
        <reference anchor="RFC8620" target="https://www.rfc-editor.org/info/rfc8620" quoteTitle="true" derivedAnchor="RFC8620">
          <front>
            <title>The JSON Meta Application Protocol (JMAP)</title>
            <author fullname="N. Jenkins" initials="N." surname="Jenkins"/>
            <author fullname="C. Newman" initials="C." surname="Newman"/>
            <date month="July" year="2019"/>
            <abstract>
              <t indent="0">This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8620"/>
          <seriesInfo name="DOI" value="10.17487/RFC8620"/>
        </reference>
        <reference anchor="RFC9470" target="https://www.rfc-editor.org/info/rfc9470" quoteTitle="true" derivedAnchor="RFC9470">
          <front>
            <title>OAuth 2.0 Step Up Authentication Challenge Protocol</title>
            <author fullname="V. Bertocci" initials="V." surname="Bertocci"/>
            <author fullname="B. Campbell" initials="B." surname="Campbell"/>
            <date month="September" year="2023"/>
            <abstract>
              <t indent="0">It is not uncommon for resource servers to require different authentication strengths or recentness according to the characteristics of a request. This document introduces a mechanism that resource servers can use to signal to a client that the authentication event associated with the access token of the current request does not meet its authentication requirements and, further, how to meet them. This document also codifies a mechanism for a client to request that an authorization server achieve a specific authentication strength or recentness when processing an authorization request.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9470"/>
          <seriesInfo name="DOI" value="10.17487/RFC9470"/>
        </reference>
        <reference anchor="RFC9700" target="https://www.rfc-editor.org/info/rfc9700" quoteTitle="true" derivedAnchor="RFC9700">
          <front>
            <title>Best Current Practice for OAuth 2.0 Security</title>
            <author fullname="T. Lodderstedt" initials="T." surname="Lodderstedt"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="A. Labunets" initials="A." surname="Labunets"/>
            <author fullname="D. Fett" initials="D." surname="Fett"/>
            <date month="January" year="2025"/>
            <abstract>
              <t indent="0">This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="240"/>
          <seriesInfo name="RFC" value="9700"/>
          <seriesInfo name="DOI" value="10.17487/RFC9700"/>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">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 also like to thank <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="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
        <organization showOnFrontPage="true">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 showOnFrontPage="true">Independent Identity, Inc.</organization>
        <address>
          <email>phil.hunt@yahoo.com</email>
        </address>
      </author>
      <author fullname="Aaron Parecki" initials="A." surname="Parecki">
        <organization showOnFrontPage="true">Okta</organization>
        <address>
          <email>aaron@parecki.com</email>
          <uri>https://aaronparecki.com/</uri>
        </address>
      </author>
    </section>
  </back>
</rfc>
