<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-gnap-resource-servers-09" number="9767" updates="" obsoletes="" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" prepTime="2025-04-22T17:09:30" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-gnap-resource-servers-09" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9767" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="GNAP RS Connections">Grant Negotiation and Authorization Protocol Resource Server Connections</title>
    <seriesInfo name="RFC" value="9767" stream="IETF"/>
    <author initials="J." surname="Richer" fullname="Justin Richer" role="editor">
      <organization showOnFrontPage="true">Bespoke Engineering</organization>
      <address>
        <email>ietf@justin.richer.org</email>
        <uri>https://bspk.io/</uri>
      </address>
    </author>
    <author initials="F." surname="Imbault" fullname="Fabien Imbault">
      <organization showOnFrontPage="true">acert.io</organization>
      <address>
        <email>fabien.imbault@acert.io</email>
        <uri>https://acert.io/</uri>
      </address>
    </author>
    <date month="04" year="2025"/>
    <area>SEC</area>
    <workgroup>gnap</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of
software (the client) and conveying the results and artifacts of that delegation
to the software. This extension defines methods for resource servers (RSs) to connect with authorization servers (ASs) in an interoperable fashion.</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/rfc9767" 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-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-access-tokens">Access Tokens</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-general-purpose-access-toke">General-Purpose Access Token Model</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.1.2">
                  <li pn="section-toc.1-1.2.2.1.2.1">
                    <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.2.1.1"><xref derivedContent="2.1.1" format="counter" sectionFormat="of" target="section-2.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-value">Value</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.2.1"><xref derivedContent="2.1.2" format="counter" sectionFormat="of" target="section-2.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-issuer">Issuer</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.3.1"><xref derivedContent="2.1.3" format="counter" sectionFormat="of" target="section-2.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-audience">Audience</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.4.1"><xref derivedContent="2.1.4" format="counter" sectionFormat="of" target="section-2.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-binding">Key Binding</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.1.2.5">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.5.1"><xref derivedContent="2.1.5" format="counter" sectionFormat="of" target="section-2.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-flags">Flags</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.1.2.6">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.6.1"><xref derivedContent="2.1.6" format="counter" sectionFormat="of" target="section-2.1.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-access-rights">Access Rights</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.1.2.7">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.7.1"><xref derivedContent="2.1.7" format="counter" sectionFormat="of" target="section-2.1.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-time-validity-window">Time Validity Window</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.1.2.8">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.8.1"><xref derivedContent="2.1.8" format="counter" sectionFormat="of" target="section-2.1.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-identifier">Token Identifier</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.1.2.9">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.9.1"><xref derivedContent="2.1.9" format="counter" sectionFormat="of" target="section-2.1.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authorizing-resource-owner">Authorizing Resource Owner</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.1.2.10">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.10.1"><xref derivedContent="2.1.10" format="counter" sectionFormat="of" target="section-2.1.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-end-user">End User</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.1.2.11">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.11.1"><xref derivedContent="2.1.11" format="counter" sectionFormat="of" target="section-2.1.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-client-instance">Client Instance</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.1.2.12">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.12.1"><xref derivedContent="2.1.12" format="counter" sectionFormat="of" target="section-2.1.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-label">Label</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.1.2.13">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.13.1"><xref derivedContent="2.1.13" format="counter" sectionFormat="of" target="section-2.1.13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-parent-grant-request">Parent Grant Request</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.1.2.14">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.14.1"><xref derivedContent="2.1.14" format="counter" sectionFormat="of" target="section-2.1.14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-as-specific-access-tokens">AS-Specific Access Tokens</xref></t>
                  </li>
                </ul>
              </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-access-token-formats">Access Token Formats</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-resource-server-facing-api">Resource-Server-Facing API</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-rs-facing-as-discovery">RS-Facing AS Discovery</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-protecting-rs-requests-to-t">Protecting RS Requests to the AS</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-token-introspection">Token Introspection</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registering-a-resource-set">Registering a Resource Set</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-error-responses">Error Responses</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-deriving-a-downstream-token">Deriving a Downstream Token</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-iana-considerations">IANA Considerations</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-well-known-uris">Well-Known URIs</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-gnap-grant-request-paramete">GNAP Grant Request Parameters</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-gnap-token-formats">GNAP Token Formats</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.3.2">
                  <li pn="section-toc.1-1.5.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derivedContent="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registry-template">Registry Template</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derivedContent="5.3.2" format="counter" sectionFormat="of" target="section-5.3.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.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-gnap-token-introspection-re">GNAP Token Introspection Request</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.4.2">
                  <li pn="section-toc.1-1.5.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.4.2.1.1"><xref derivedContent="5.4.1" format="counter" sectionFormat="of" target="section-5.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registry-template-2">Registry Template</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.4.2.2.1"><xref derivedContent="5.4.2" format="counter" sectionFormat="of" target="section-5.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-initial-registry-contents-2">Initial Registry Contents</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.5">
                <t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent="5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gnap-token-introspection-res">GNAP Token Introspection Response</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.5.2">
                  <li pn="section-toc.1-1.5.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.5.2.1.1"><xref derivedContent="5.5.1" format="counter" sectionFormat="of" target="section-5.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registry-template-3">Registry Template</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.5.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.5.2.2.1"><xref derivedContent="5.5.2" format="counter" sectionFormat="of" target="section-5.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-initial-registry-contents-3">Initial Registry Contents</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.6">
                <t indent="0" pn="section-toc.1-1.5.2.6.1"><xref derivedContent="5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gnap-resource-set-registrat">GNAP Resource Set Registration Request Parameters</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.6.2">
                  <li pn="section-toc.1-1.5.2.6.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.6.2.1.1"><xref derivedContent="5.6.1" format="counter" sectionFormat="of" target="section-5.6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registry-template-4">Registry Template</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.6.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.6.2.2.1"><xref derivedContent="5.6.2" format="counter" sectionFormat="of" target="section-5.6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-initial-registry-contents-4">Initial Registry Contents</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.7">
                <t indent="0" pn="section-toc.1-1.5.2.7.1"><xref derivedContent="5.7" format="counter" sectionFormat="of" target="section-5.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gnap-resource-set-registrati">GNAP Resource Set Registration Response Parameters</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.7.2">
                  <li pn="section-toc.1-1.5.2.7.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.7.2.1.1"><xref derivedContent="5.7.1" format="counter" sectionFormat="of" target="section-5.7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registry-template-5">Registry Template</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.7.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.7.2.2.1"><xref derivedContent="5.7.2" format="counter" sectionFormat="of" target="section-5.7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-initial-registry-contents-5">Initial Registry Contents</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.8">
                <t indent="0" pn="section-toc.1-1.5.2.8.1"><xref derivedContent="5.8" format="counter" sectionFormat="of" target="section-5.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gnap-rs-facing-discovery-do">GNAP RS-Facing Discovery Document Fields</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.8.2">
                  <li pn="section-toc.1-1.5.2.8.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.8.2.1.1"><xref derivedContent="5.8.1" format="counter" sectionFormat="of" target="section-5.8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registry-template-6">Registry Template</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.8.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.8.2.2.1"><xref derivedContent="5.8.2" format="counter" sectionFormat="of" target="section-5.8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-initial-registry-contents-6">Initial Registry Contents</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.9">
                <t indent="0" pn="section-toc.1-1.5.2.9.1"><xref derivedContent="5.9" format="counter" sectionFormat="of" target="section-5.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gnap-rs-facing-error-codes">GNAP RS-Facing Error Codes</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.9.2">
                  <li pn="section-toc.1-1.5.2.9.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.9.2.1.1"><xref derivedContent="5.9.1" format="counter" sectionFormat="of" target="section-5.9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registration-template">Registration Template</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.9.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.9.2.2.1"><xref derivedContent="5.9.2" format="counter" sectionFormat="of" target="section-5.9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-initial-contents">Initial Contents</xref></t>
                  </li>
                </ul>
              </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-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tls-protection-in-transit">TLS Protection in Transit</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-validation">Token Validation</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-caching-token-validation-re">Caching Token Validation Result</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-proof-validation">Key Proof Validation</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-exfiltration">Token Exfiltration</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.6">
                <t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent="6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-reuse-by-an-rs">Token Reuse by an RS</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.7">
                <t indent="0" pn="section-toc.1-1.6.2.7.1"><xref derivedContent="6.7" format="counter" sectionFormat="of" target="section-6.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-format-considerations">Token Format Considerations</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.8">
                <t indent="0" pn="section-toc.1-1.6.2.8.1"><xref derivedContent="6.8" format="counter" sectionFormat="of" target="section-6.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-oversharing-token-contents">Oversharing Token Contents</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.9">
                <t indent="0" pn="section-toc.1-1.6.2.9.1"><xref derivedContent="6.9" format="counter" sectionFormat="of" target="section-6.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-resource-references">Resource References</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.10">
                <t indent="0" pn="section-toc.1-1.6.2.10.1"><xref derivedContent="6.10" format="counter" sectionFormat="of" target="section-6.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-token-reissuance-from-an-un">Token Reissuance from an Untrusted AS</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.11">
                <t indent="0" pn="section-toc.1-1.6.2.11.1"><xref derivedContent="6.11" format="counter" sectionFormat="of" target="section-6.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introspection-of-token-keys">Introspection of Token Keys</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.12">
                <t indent="0" pn="section-toc.1-1.6.2.12.1"><xref derivedContent="6.12" format="counter" sectionFormat="of" target="section-6.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-rs-registration-and-managem">RS Registration and Management</xref></t>
              </li>
            </ul>
          </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-privacy-considerations">Privacy 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-token-contents">Token Contents</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-token-use-disclosure-throug">Token Use Disclosure through Introspection</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-mapping-a-user-to-an-as">Mapping a User to an AS</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-references">References</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-normative-references">Normative References</xref></t>
              </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-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.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.10">
            <t indent="0" pn="section-toc.1-1.10.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">The core GNAP specification <xref target="RFC9635" format="default" sectionFormat="of" derivedContent="GNAP"/> defines distinct roles for the authorization
server (AS) and the resource server (RS). However, the core specification
does not define how the RS gets answers to important questions, such as whether
a given access token is still valid or what set of access rights the access
token is approved for.</t>
      <t indent="0" pn="section-1-2">While it's possible for the AS and RS to be tightly coupled, such as a single
deployed server with a shared storage system, GNAP does not presume or require
such a tight coupling. It is increasingly common for the AS and RS to be run
and managed separately, particularly in cases where a single AS protects multiple
RSs simultaneously.</t>
      <t indent="0" pn="section-1-3">This specification defines a set of RS-facing APIs that an AS can make
available for advanced loosely coupled deployments. Additionally, this document
defines a general-purpose model for access tokens, which can be used in
structured, formatted access tokens or in token introspection responses.
This specification also defines a method
for an RS to derive a downstream token for calling another chained RS.</t>
      <t indent="0" pn="section-1-4">The means for the authorization server to issue the
access token to the client instance and the means for the client instance
to present the access token to the resource server are subjects of the
core GNAP specification <xref target="RFC9635" format="default" sectionFormat="of" derivedContent="GNAP"/>.</t>
      <section anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-terminology">Terminology</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">This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and other elements. Some examples use a single trailing backslash <tt>\</tt> to indicate line wrapping for long values, as per <xref target="RFC8792" format="default" sectionFormat="of" derivedContent="RFC8792"/>. The <tt>\</tt> character and leading spaces on wrapped lines are not part of the value.</t>
        <t indent="0" pn="section-1.1-3">Terminology specific to GNAP is defined in the terminology
        section of the core specification; see <xref target="RFC9635" sectionFormat="of" section="1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-1.1" derivedContent="GNAP"/>. The following protocol roles are defined:
        authorization server, client, end user, resource owner, and resource server. The following protocol
        elements are defined: access token, attribute, grant,
        privilege, protected resource, right, subject, and subject
        information. The same definitions are used in this
        document.</t>
      </section>
    </section>
    <section anchor="structure" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-access-tokens">Access Tokens</name>
      <t indent="0" pn="section-2-1">Access tokens are used as a mechanism for an AS to provide a
      client instance limited access to an RS.  These access tokens
      are artifacts representing a particular set of access rights
      granted to the client instance to act on behalf of the RO. While
      the format of access tokens varies in different systems (see
      discussion in <xref target="token-format" format="default" sectionFormat="of" derivedContent="Section 2.2"/>), the concept of an
      access token is consistent across all GNAP systems.</t>
      <section anchor="general-purpose-access-token-model" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-general-purpose-access-toke">General-Purpose Access Token Model</name>
        <t indent="0" pn="section-2.1-1">The core GNAP specification <xref target="RFC9635" format="default" sectionFormat="of" derivedContent="GNAP"/>
        focuses on the relationship between the client and the
        AS. Since the access token is opaque to the client, the core
        specification does not define a token model. However, the AS
        will need to create tokens, and the RS will need to understand
        tokens. To facilitate a level of structural interoperability,
        a common access token model is presented here.  Access tokens
        represent a common set of aspects across different GNAP
        deployments. This list is not intended to be universal or
        comprehensive but rather serves as guidance to implementers in
        developing data structures and associated systems across a
        GNAP deployment. These data structures are communicated
        between the AS and RS by using either a structured token or an
        API-like mechanism such as token introspection (see <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/>).</t>
        <t indent="0" pn="section-2.1-2">This general-purpose data model does not assume either
        approach; in fact, both approaches can be used together to
        convey different pieces of information. Where possible,
        mappings to the JSON Web Token (JWT) <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/>
        standard format are provided for each item in the model.</t>
        <section anchor="value" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.1">
          <name slugifiedName="name-value">Value</name>
          <t indent="0" pn="section-2.1.1-1">All access tokens have a <em>value</em>, which is the string that is passed on the wire between parties.
In order for different access tokens to be differentiated at runtime, the value of a token needs to be unique
within a security domain (such as all systems controlled by an AS). Otherwise, two separate tokens would be confused for each other, which would lead to security issues.
The AS chooses the value, which can be structured (see <xref target="token-format" format="default" sectionFormat="of" derivedContent="Section 2.2"/>) or unstructured. When the token is
structured, the token value also has a <em>format</em> known to the AS and RS, and the other items
in this token model are contained within the token's value in some fashion.
When the token is unstructured, the values are usually retrieved by the RS using a service
	  such as token introspection described in <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.</t>
          <t indent="0" pn="section-2.1.1-2">The access token value is conveyed in the <tt>value</tt> field of an <tt>access_token</tt> response; see <xref section="3.2" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-3.2" derivedContent="GNAP"/>.</t>
          <t indent="0" pn="section-2.1.1-3">The format and content of the access token value is opaque to the client software.
While the client software needs to be able to carry and present the access token
value, the client software is never expected nor intended to be able to understand
the token value itself.</t>
          <t indent="0" pn="section-2.1.1-4">If structured tokens like those in <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/> are used, the value of the token might not be stored by the AS. Instead,
a token identifier can be used along with protection by an AS-generated signature to validate and
identify an individual token.</t>
        </section>
        <section anchor="issuer" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.2">
          <name slugifiedName="name-issuer">Issuer</name>
          <t indent="0" pn="section-2.1.2-1">The access token is issued by the AS as defined in <xref target="RFC9635" format="default" sectionFormat="of" derivedContent="GNAP"/>. The AS will
need to identify itself in order to allow an RS to recognize tokens that the AS has issued, particularly
in cases where tokens from multiple different ASs could be presented to the same RS.</t>
          <t indent="0" pn="section-2.1.2-2">This information is not usually conveyed directly to the client instance, since the client instance should know this information based on where it receives the token from.</t>
          <t indent="0" pn="section-2.1.2-3">In the payload of a JSON Web Token <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/> or a token introspection response, this corresponds to the <tt>iss</tt> claim.</t>
        </section>
        <section anchor="audience" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.3">
          <name slugifiedName="name-audience">Audience</name>
          <t indent="0" pn="section-2.1.3-1">The access token is intended for use at one or more RSs. The AS can list a token's intended RSs to allow each RS to ensure that the RS is not receiving a token intended for someone else.
The AS and RS have to agree on the nature of any audience identifiers represented by the token,
but the URIs of the RS are a common pattern.</t>
          <t indent="0" pn="section-2.1.3-2">In the payload of a JSON Web Token <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/> or token introspection response, this corresponds to the <tt>aud</tt> claim.</t>
          <t indent="0" pn="section-2.1.3-3">In cases where more complex access is required, the <tt>location</tt> field of objects in the <tt>access</tt>
array can also convey audience information.
In such cases, the client instance might need to know the audience information in order to differentiate between
possible RSs to present the token to.</t>
        </section>
        <section anchor="key-binding" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.4">
          <name slugifiedName="name-key-binding">Key Binding</name>
          <t indent="0" pn="section-2.1.4-1">Access tokens in GNAP are bound to the client instance's registered or presented key, except in
cases where the access token is a bearer token. For all tokens bound to a key, the AS and RS need to
be able to identify which key the token is bound to; otherwise, an attacker could substitute their
own key during presentation of the token. In the case of an asymmetric algorithm, the
AS and RS need to know only the public key, while the client instance will also need to know the private
key in order to present the token. In the case of a symmetric algorithm, all parties
will need to either know or be able to derive the shared key.</t>
          <t indent="0" pn="section-2.1.4-2">The source of this key information can vary depending on deployment decisions. For example, an AS
could decide that all tokens issued to a client instance are always bound to that client instance's current key.
When the key needs to be dereferenced, the AS looks up the client instance to which the token was issued
and finds the key information there. Alternatively, the AS could bind each token to a specific key that is managed separately from client instance
information. In such a case, the AS determines the key information directly. This approach allows the client
instance to use a different key for each request or allows the AS to issue a key for the client instance
to use with the particular token.</t>
          <t indent="0" pn="section-2.1.4-3">In all cases, the key binding also includes a proofing mechanism, along with any parameters needed for that
mechanism such as a signing or digest algorithm. If such information is not included with the proofing key, an attacker could
present a token with a seemingly valid key using an insecure and incorrect proofing mechanism.</t>
          <t indent="0" pn="section-2.1.4-4">This value is conveyed to the client instance in the <tt>key</tt> field of the <tt>access_token</tt> response in <xref section="3.2" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-3.2" derivedContent="GNAP"/>.
Since the common case is that the token is bound to the client instance's registered key, this field can be omitted in this case
since the client will be aware of its own key.</t>
          <t indent="0" pn="section-2.1.4-5">In the payload of a JSON Web Token <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/>, this corresponds to the <tt>cnf</tt> (confirmation) claim. In a token introspection response, this corresponds to the <tt>key</tt> claim.</t>
          <t indent="0" pn="section-2.1.4-6">In the case of a bearer token, all parties need to know that a token has no key bound to it and will therefore reject any attempts to use the bearer token with a key in an undefined way.</t>
        </section>
        <section anchor="flags" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.5">
          <name slugifiedName="name-flags">Flags</name>
          <t indent="0" pn="section-2.1.5-1">GNAP access tokens can have multiple associated data
          flags that indicate special processing or considerations for
          a token. For example, the data flags can indicate whether
          a token is a bearer token or should be expected to be
          durable across grant updates.</t>
          <t indent="0" pn="section-2.1.5-2">The client can request a set of flags using the <tt>flags</tt> field of the <tt>access_token</tt> grant request parameter in <xref section="2.1.1" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-2.1.1" derivedContent="GNAP"/>.</t>
          <t indent="0" pn="section-2.1.5-3">These flags are conveyed from the AS to the client in the <tt>flags</tt> field of the <tt>access_token</tt> section of the grant response in <xref section="3.2" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-3.2" derivedContent="GNAP"/>.</t>
          <t indent="0" pn="section-2.1.5-4">For token introspection, flags are returned in the <tt>flags</tt> field of the response.</t>
        </section>
        <section anchor="access-rights" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.6">
          <name slugifiedName="name-access-rights">Access Rights</name>
          <t indent="0" pn="section-2.1.6-1">Access tokens are tied to a limited set of access rights. These rights specify in some detail what the token
can be used for, how it can be used, and where it can be used. The internal structure of access rights is detailed in <xref section="8" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-8" derivedContent="GNAP"/>.</t>
          <t indent="0" pn="section-2.1.6-2">The access rights associated with an access token are calculated from the rights available to the client
instance making the request, the rights available to be approved by the RO, the rights actually approved
by the RO, and the rights corresponding to the RS in question. The rights for a specific access token
are a subset of the overall rights in a grant request.</t>
          <t indent="0" pn="section-2.1.6-3">These rights are requested by the client instance in the <tt>access</tt> field of the <tt>access_token</tt> request; see <xref section="2.1" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-2.1" derivedContent="GNAP"/>.</t>
          <t indent="0" pn="section-2.1.6-4">The rights associated with an issued access token are conveyed to the client instance in the <tt>access</tt> field of the <tt>access_token</tt> response in <xref section="3.2" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-3.2" derivedContent="GNAP"/>.</t>
          <t indent="0" pn="section-2.1.6-5">In token introspection responses, access rights correspond to the <tt>access</tt> claim.</t>
        </section>
        <section anchor="time-validity-window" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.7">
          <name slugifiedName="name-time-validity-window">Time Validity Window</name>
          <t indent="0" pn="section-2.1.7-1">The access token can be limited to a certain time window outside of which it is no longer
valid for use at an RS. This window can be explicitly bounded by an expiration time and a
not-before time, or it could be calculated based on the issuance time of the token. For example,
an RS could decide that it will accept tokens for most calls within an hour of a token's
issuance, but only within five minutes of the token's issuance for certain high-value calls.</t>
          <t indent="0" pn="section-2.1.7-2">Since access tokens could be revoked at any time for any reason outside of a client instance's control,
the client instance often does not know or concern itself with the validity time window of
an access token. However, this information can be made available to it by using the <tt>expires_in</tt> field
of an access token response; see <xref section="3.2" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-3.2" derivedContent="GNAP"/>.</t>
          <t indent="0" pn="section-2.1.7-3">The issuance time of the token is conveyed in the <tt>iat</tt> claim in the payload of a JSON Web Token <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/> or a token introspection response.</t>
          <t indent="0" pn="section-2.1.7-4">The expiration time of a token, after which it is to be rejected, is conveyed in the <tt>exp</tt> claim in the payload of a JSON Web Token <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/> or a token introspection response.</t>
          <t indent="0" pn="section-2.1.7-5">The starting time of a token's validity window, before which it is to be rejected, is conveyed in the <tt>nbf</tt> claim in the payload of a JSON Web Token <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/> or a token introspection response.</t>
        </section>
        <section anchor="token-identifier" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.8">
          <name slugifiedName="name-token-identifier">Token Identifier</name>
          <t indent="0" pn="section-2.1.8-1">Individual access tokens often need a unique internal identifier to allow the AS to differentiate
between multiple separate tokens. This value of the token can often be used as the
identifier, but in some cases, a separate identifier is used.</t>
          <t indent="0" pn="section-2.1.8-2">This separate identifier can be conveyed in the <tt>jti</tt> claim in the payload of a JSON Web Token <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/> or a token introspection response.</t>
          <t indent="0" pn="section-2.1.8-3">This identifier is not usually exposed to the client instance using the token, because the client
instance only needs to use the token by value.</t>
        </section>
        <section anchor="authorizing-resource-owner" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.9">
          <name slugifiedName="name-authorizing-resource-owner">Authorizing Resource Owner</name>
          <t indent="0" pn="section-2.1.9-1">Access tokens are approved on behalf of a resource owner (RO). The identity of this RO can be used by
the RS to determine exactly which resource to access or which kinds of access to allow. For example,
an access token used to access identity information can hold a user identifier to allow the RS to
determine which profile information to return. The nature of this information is subject to agreement
by the AS and RS.</t>
          <t indent="0" pn="section-2.1.9-2">This corresponds to the <tt>sub</tt> claim in the payload of a JSON Web Token <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/> or a token introspection response.</t>
          <t indent="0" pn="section-2.1.9-3">Detailed RO information is not returned to the client instance
when an access token is requested alone, and in many cases, returning
this information to the client instance would be a privacy violation on the part of the AS. Since the
access token represents a specific delegated access, the client instance needs only to use the token
at its target RS. Following the profile example, the client instance does not need to know
the account identifier to get specific attributes about the account represented by the token.</t>
          <t indent="0" pn="section-2.1.9-4">GNAP does allow for the return of subject information separately from the access token, in the form
of identifiers and assertions. These values are returned directly to the client separately from any
access tokens that are requested, though it's common that they represent the same party.</t>
        </section>
        <section anchor="end-user" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.10">
          <name slugifiedName="name-end-user">End User</name>
          <t indent="0" pn="section-2.1.10-1">The end user is the party operating the client software. The client instance can facilitate the end user
interacting with the AS in order to determine the end user's identity, gather authorization, and provide
the results of that information back to the client instance.</t>
          <t indent="0" pn="section-2.1.10-2">In many instances, the end user is the same party as the resource owner. However, in some cases,
the two roles can be fulfilled by different people, where the RO is consulted asynchronously.
The token model should be able to reflect these kinds of situations by representing the end user
and RO separately.
For example, an end user can request a financial payment, but the RO is the holder of the account
that the payment would be withdrawn from. The RO would be consulted for approval by the AS outside
of the flow of the GNAP request. A token in such circumstances would need to show both the
RO and end user as separate entities.</t>
        </section>
        <section anchor="client-instance" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.11">
          <name slugifiedName="name-client-instance">Client Instance</name>
          <t indent="0" pn="section-2.1.11-1">Access tokens are issued to a specific client instance by the AS. The identity of this instance can
be used by the RS to allow specific kinds of access or other attributes about the access token.
For example, an AS that binds all access tokens issued to a particular client instance to that
client instance's most recent key rotation would need to be able to look up the client instance
in order to find the key binding detail.</t>
          <t indent="0" pn="section-2.1.11-2">This corresponds to the <tt>client_id</tt> claim in the payload of a JSON Web Token <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/> or the <tt>instance_id</tt> field of a token introspection response.</t>
          <t indent="0" pn="section-2.1.11-3">The client is not normally informed of this information separately, since a client instance can
usually correctly assume that it is the client instance to which a token that
it receives was issued.</t>
        </section>
        <section anchor="label" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.12">
          <name slugifiedName="name-label">Label</name>
          <t indent="0" pn="section-2.1.12-1">When multiple access tokens are requested or a client instance uses token labels, the parties
will need to keep track of which labels were applied to each individual token. Since labels can
be reused across different grant requests, the token label alone is not sufficient to
uniquely identify a given access token in a system. However, within the context of a grant
request, these labels are required to be unique.</t>
          <t indent="0" pn="section-2.1.12-2">A client instance can request a specific label using the <tt>label</tt> field of an <tt>access_token</tt> request; see <xref section="2.1" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-2.1" derivedContent="GNAP"/>.</t>
          <t indent="0" pn="section-2.1.12-3">The AS can inform the client instance of a token's label using the <tt>label</tt> field of an <tt>access_token</tt> response; see <xref section="3.2" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-3.2" derivedContent="GNAP"/>.</t>
          <t indent="0" pn="section-2.1.12-4">This corresponds to the <tt>label</tt> field of a token introspection response.</t>
        </section>
        <section anchor="parent-grant-request" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.13">
          <name slugifiedName="name-parent-grant-request">Parent Grant Request</name>
          <t indent="0" pn="section-2.1.13-1">All access tokens are issued in the context of a specific grant request from a client instance. The
grant request itself represents a unique tuple of:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.1.13-2">
            <li pn="section-2.1.13-2.1">
              <t indent="0" pn="section-2.1.13-2.1.1">The AS processing the grant request</t>
            </li>
            <li pn="section-2.1.13-2.2">
              <t indent="0" pn="section-2.1.13-2.2.1">The client instance making the grant request</t>
            </li>
            <li pn="section-2.1.13-2.3">
              <t indent="0" pn="section-2.1.13-2.3.1">The RO (or set of ROs) approving the grant request (or needing to approve it)</t>
            </li>
            <li pn="section-2.1.13-2.4">
              <t indent="0" pn="section-2.1.13-2.4.1">The access rights granted by the RO</t>
            </li>
            <li pn="section-2.1.13-2.5">
              <t indent="0" pn="section-2.1.13-2.5.1">The current state of the grant request, as defined in <xref section="1.5" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-1.5" derivedContent="GNAP"/></t>
            </li>
          </ul>
          <t indent="0" pn="section-2.1.13-3">The AS can use this information to tie common information to a specific token. For instance,
instead of specifying a client instance for every issued access token for a grant, the AS
can store the client information in the grant itself and look it up by reference from the
access token.</t>
          <t indent="0" pn="section-2.1.13-4">The AS can also use this information when a grant request is updated. For example, if the client
instance asks for a new access token from an existing grant, the AS can use this link to revoke
older non-durable access tokens that had been previously issued under the grant.</t>
          <t indent="0" pn="section-2.1.13-5">A client instance will have its own model of an ongoing grant request, especially if that
grant request can be continued using the API defined in <xref section="5" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-5" derivedContent="GNAP"/> where several
pieces of statefulness need to be kept in hand. The client instance might need to keep an
association with the grant request that issued the token in case the access token expires or
does not have sufficient access rights, so that the client instance can get a new access
token without having to restart the grant request process from scratch.</t>
          <t indent="0" pn="section-2.1.13-6">Since the grant itself does not need to be identified in any of the protocol messages, GNAP
does not define a specific grant identifier to be conveyed between any parties in the protocol.
Only the AS needs to keep an explicit connection between an issued access token and the
parent grant that issued it.</t>
        </section>
        <section anchor="as-specific-access-tokens" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.14">
          <name slugifiedName="name-as-specific-access-tokens">AS-Specific Access Tokens</name>
          <t indent="0" pn="section-2.1.14-1">When an access token is used for the grant continuation API defined in <xref section="5" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-5" derivedContent="GNAP"/> (the continuation access token),
the token management API defined in <xref section="6" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-6" derivedContent="GNAP"/> (the token management access token),
or the RS-facing API defined in <xref target="rs-facing-api" format="default" sectionFormat="of" derivedContent="Section 3"/> (the resource server management access token),
the AS <bcp14>MUST</bcp14> separate these access tokens from other access tokens used at one or more RSs. The AS can
do this through the use of a flag on the access token data structure, by using a special internal
access right, or any other means at its disposal. Just like other access tokens in GNAP,
the contents of these AS-specific access tokens are opaque to the software presenting the token.
	  Unlike other access tokens, the contents of these AS-specific access tokens are also opaque to the RS.</t>
          <t indent="0" pn="section-2.1.14-2">The client instance is given continuation access tokens only as part of the <tt>continue</tt> field
of the grant response in <xref section="3.1" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-3.1" derivedContent="GNAP"/>.
The client instance is given token management access tokens only as part of the <tt>manage</tt> field
of the grant response in <xref section="3.2.1" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-3.2.1" derivedContent="GNAP"/>.
The means by which the RS is given resource server management access tokens is out of
scope of this specification, but methods could include preconfiguration of the token value with
	  the RS software or granting the access token through a standard GNAP process.</t>
          <t indent="0" pn="section-2.1.14-3">For continuation access tokens and token management access tokens,
a client instance <bcp14>MUST</bcp14> take steps to differentiate these special-purpose access tokens from
access tokens used at one or more RSs.
To facilitate this, a client instance can store AS-specific access tokens separately from
other access tokens in order to keep them from being confused with each other and used at the
wrong endpoints.</t>
          <t indent="0" pn="section-2.1.14-4">An RS should never see an AS-specific access token presented, so any attempts to process one <bcp14>MUST</bcp14>
fail. When introspection is used, the AS <bcp14>MUST NOT</bcp14> return an <tt>active</tt> value of <tt>true</tt> for
AS-specific access tokens to the RS. If an AS implements its protected endpoints in such a way
that it uses token introspection internally, the AS <bcp14>MUST</bcp14> differentiate these AS-specific access tokens
from those issued for use at an external RS.</t>
        </section>
      </section>
      <section anchor="token-format" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-access-token-formats">Access Token Formats</name>
        <t indent="0" pn="section-2.2-1">When the AS issues an access token for use at an RS, the RS
needs to have some means of understanding what the access token is for
in order to determine how to respond to the request. The core GNAP
protocol makes neither assumptions nor demands on the format or contents
of the access token, and in fact, the token format and contents are opaque
to the client instance. However, such token formats can be the topic of agreements
between the AS and RS.</t>
        <t indent="0" pn="section-2.2-2">Self-contained structured token formats allow for the conveyance
of information between the AS and RS without requiring the RS to
call the AS at runtime as described in <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/>. Structured tokens
can also be used in combination with introspection, allowing the token itself
to carry one class of information and the introspection response to carry
another.</t>
        <t indent="0" pn="section-2.2-3">Some token formats, such as Macaroons <xref target="MACAROON" format="default" sectionFormat="of" derivedContent="MACAROON"/> and Biscuits <xref target="BISCUIT" format="default" sectionFormat="of" derivedContent="BISCUIT"/>, allow for
the RS to derive sub-tokens without having to call the AS
as described in <xref target="token-chaining" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
        <t indent="0" pn="section-2.2-4">The supported token formats can be communicated dynamically at runtime
between the AS and RS in several places:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-5">
          <li pn="section-2.2-5.1">
            <t indent="0" pn="section-2.2-5.1.1">The AS can declare its supported token formats as part of RS-facing discovery (<xref target="discovery" format="default" sectionFormat="of" derivedContent="Section 3.1"/>).</t>
          </li>
          <li pn="section-2.2-5.2">
            <t indent="0" pn="section-2.2-5.2.1">The RS can require a specific token format be used to access a registered resource set (<xref target="rs-register-resource-handle" format="default" sectionFormat="of" derivedContent="Section 3.4"/>).</t>
          </li>
          <li pn="section-2.2-5.3">
            <t indent="0" pn="section-2.2-5.3.1">The AS can return the token's format in an introspection response (<xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/>).</t>
          </li>
        </ul>
        <t indent="0" pn="section-2.2-6">In all places where the token format is listed explicitly, it <bcp14>MUST</bcp14> be one of the registered
values in the "GNAP Token Formats" registry <xref target="IANA-token-format" format="default" sectionFormat="of" derivedContent="Section 5.3"/>.</t>
      </section>
    </section>
    <section anchor="rs-facing-api" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-resource-server-facing-api">Resource-Server-Facing API</name>
      <t indent="0" pn="section-3-1">To facilitate runtime and dynamic connections with an RS, the AS can offer an
RS-facing API consisting of one or more of the following optional
pieces:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-2">
        <li pn="section-3-2.1">
          <t indent="0" pn="section-3-2.1.1">Discovery</t>
        </li>
        <li pn="section-3-2.2">
          <t indent="0" pn="section-3-2.2.1">Introspection</t>
        </li>
        <li pn="section-3-2.3">
          <t indent="0" pn="section-3-2.3.1">Token chaining</t>
        </li>
        <li pn="section-3-2.4">
          <t indent="0" pn="section-3-2.4.1">Resource reference registration</t>
        </li>
      </ul>
      <section anchor="discovery" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-rs-facing-as-discovery">RS-Facing AS Discovery</name>
        <t indent="0" pn="section-3.1-1">A GNAP AS offering RS-facing services can publish its features
on a well-known discovery document at the URL with the same
schema and authority as the grant request endpoint URL, at
the path <tt>/.well-known/gnap-as-rs</tt>.</t>
        <t indent="0" pn="section-3.1-2">The discovery response is a JSON document <xref target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259"/> consisting of a single JSON
	object with the following fields:</t>
        <dl spacing="normal" newline="false" indent="3" pn="section-3.1-3">
          <dt pn="section-3.1-3.1">grant_request_endpoint (string):</dt>
          <dd pn="section-3.1-3.2">
            <t indent="0" pn="section-3.1-3.2.1">The location of the AS's grant request endpoint defined by <xref section="9" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-9" derivedContent="GNAP"/>.
  This URL <bcp14>MUST</bcp14> be the same URL used by client instances in support of GNAP requests.
  The RS can use this to derive downstream access tokens, if supported by the AS.
  The location <bcp14>MUST</bcp14> be a URL <xref target="RFC3986" format="default" sectionFormat="of" derivedContent="RFC3986"/>
  with a scheme component that <bcp14>MUST</bcp14> be https, a host component, and (optionally)
  port, path, and query components and no fragment components.
  <bcp14>REQUIRED</bcp14>.
  See <xref target="token-chaining" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
          </dd>
          <dt pn="section-3.1-3.3">introspection_endpoint (string):</dt>
          <dd pn="section-3.1-3.4">
            <t indent="0" pn="section-3.1-3.4.1">The URL of the endpoint offering introspection.
  The location <bcp14>MUST</bcp14> be a URL <xref target="RFC3986" format="default" sectionFormat="of" derivedContent="RFC3986"/>
  with a scheme component that <bcp14>MUST</bcp14> be https, a host component, and (optionally)
  port, path, and query components and no fragment components.
  <bcp14>REQUIRED</bcp14> if the AS supports introspection. An absent value indicates that the AS does not support introspection.
  See <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.</t>
          </dd>
          <dt pn="section-3.1-3.5">token_formats_supported (array of strings):</dt>
          <dd pn="section-3.1-3.6">
            <t indent="0" pn="section-3.1-3.6.1">A list of token formats supported by this AS. The values in this list
  <bcp14>MUST</bcp14> be registered in the "GNAP Token Formats" registry per <xref target="IANA-token-format" format="default" sectionFormat="of" derivedContent="Section 5.3"/>.
  <bcp14>OPTIONAL</bcp14>.</t>
          </dd>
          <dt pn="section-3.1-3.7">resource_registration_endpoint (string):</dt>
          <dd pn="section-3.1-3.8">
            <t indent="0" pn="section-3.1-3.8.1">The URL of the endpoint offering resource registration.
  The location <bcp14>MUST</bcp14> be a URL <xref target="RFC3986" format="default" sectionFormat="of" derivedContent="RFC3986"/>
  with a scheme component that <bcp14>MUST</bcp14> be https, a host component, and (optionally)
  port, path, and query components and no fragment components.
  <bcp14>REQUIRED</bcp14> if the AS supports dynamic resource registration. An absent value indicates that the AS does not support this feature.
  See <xref target="rs-register-resource-handle" format="default" sectionFormat="of" derivedContent="Section 3.4"/>.</t>
          </dd>
          <dt pn="section-3.1-3.9">key_proofs_supported (array of strings):</dt>
          <dd pn="section-3.1-3.10">
            <t indent="0" pn="section-3.1-3.10.1">A list of the AS's supported key
  proofing mechanisms. The values of this list correspond to possible
  values of the <tt>proof</tt> field of the key section of the request.
  Values <bcp14>MUST</bcp14> be registered in the "GNAP Key Proofing Methods" registry established by <xref target="RFC9635" format="default" sectionFormat="of" derivedContent="GNAP"/>.
  <bcp14>OPTIONAL</bcp14>.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-3.1-4">Additional fields are defined in the "GNAP RS-Facing Discovery Document Fields" registry; see <xref target="IANA-rs-discovery" format="default" sectionFormat="of" derivedContent="Section 5.8"/>.</t>
      </section>
      <section anchor="authentication" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-protecting-rs-requests-to-t">Protecting RS Requests to the AS</name>
        <t indent="0" pn="section-3.2-1">Unless otherwise specified, the RS <bcp14>MUST</bcp14> protect its calls to the AS using any of the signature
methods defined in <xref section="7" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-7" derivedContent="GNAP"/>.</t>
        <t indent="0" pn="section-3.2-2">The RS <bcp14>MAY</bcp14> present its keys by reference or by value in
a similar fashion to a client instance calling the AS in the core protocol
of GNAP, as described in <xref section="7.1" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-7.1" derivedContent="GNAP"/>. In the protocols defined here,
this takes the form of the resource server identifying itself by using a <tt>key</tt> field or
by passing an instance identifier directly.</t>
        <sourcecode type="http-message" markers="false" pn="section-3.2-3">
POST /continue HTTP/1.1
Host: server.example.com
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=...
Signature: sig1=...
Content-Type: application/json

"resource_server": {
    "key": {
        "proof": "httpsig",
        "jwk": {
            "kty": "EC",
            "crv": "secp256k1",
            "kid": "2021-07-06T20:22:03Z",
            "x": "-J9OJIZj4nmopZbQN7T8xv3sbeS5-f_vBNSy_EHnBZc",
            "y": "sjrS51pLtu3P4LUTVvyAIxRfDV_be2RYpI5_f-Yjivw"
        }
    }
}
</sourcecode>
        <t indent="0" pn="section-3.2-4">or by reference:</t>
        <sourcecode type="http-message" markers="false" pn="section-3.2-5">
POST /continue HTTP/1.1
Host: server.example.com
Signature-Input: sig1=...
Signature: sig1=...
Content-Type: application/json

{
    "resource_server": "7C7C4AZ9KHRS6X63AJAO"
}
</sourcecode>
        <t indent="0" pn="section-3.2-6">The means by which an RS's keys are made known to the AS are out
of the scope of this specification.
The AS <bcp14>MAY</bcp14> require an RS to preregister its keys,
or it could allow calls from arbitrary keys in a trust-on-first-use
model.</t>
        <t indent="0" pn="section-3.2-7">The AS <bcp14>MAY</bcp14> issue access tokens, called "resource server management access tokens", to the RS to protect the RS-facing API endpoints.
If such tokens are issued, the RS <bcp14>MUST</bcp14> present them
to the RS-facing API endpoints along with the RS authentication.</t>
        <sourcecode type="http-message" markers="false" pn="section-3.2-8">
POST /continue HTTP/1.1
Host: server.example.com
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=...
Signature: sig1=...
Content-Type: application/json

{
    "resource_server": "7C7C4AZ9KHRS6X63AJAO"
}
</sourcecode>
      </section>
      <section anchor="introspection" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-token-introspection">Token Introspection</name>
        <t indent="0" pn="section-3.3-1">The AS issues access tokens representing a set of delegated access rights
to be used at one or more RSs. The AS can offer an introspection service
to allow an RS to validate that a given access token:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3-2">
          <li pn="section-3.3-2.1">
            <t indent="0" pn="section-3.3-2.1.1">has been issued by the AS</t>
          </li>
          <li pn="section-3.3-2.2">
            <t indent="0" pn="section-3.3-2.2.1">is valid at the current time</t>
          </li>
          <li pn="section-3.3-2.3">
            <t indent="0" pn="section-3.3-2.3.1">has not been revoked</t>
          </li>
          <li pn="section-3.3-2.4">
            <t indent="0" pn="section-3.3-2.4.1">is appropriate for the RS identified in the call</t>
          </li>
        </ul>
        <t indent="0" pn="section-3.3-3">When the RS receives an access token, it can call the introspection
endpoint at the AS to get token information.</t>
        <artset pn="section-3.3-4">
          <artwork type="svg" align="left" pn="section-3.3-4.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="160" width="328" viewBox="0 0 328 160" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
              <path d="M 8,32 L 8,144" fill="none" stroke="black"/>
              <path d="M 80,32 L 80,144" fill="none" stroke="black"/>
              <path d="M 144,32 L 144,144" fill="none" stroke="black"/>
              <path d="M 200,32 L 200,144" fill="none" stroke="black"/>
              <path d="M 264,32 L 264,112" fill="none" stroke="black"/>
              <path d="M 320,32 L 320,112" fill="none" stroke="black"/>
              <path d="M 8,32 L 80,32" fill="none" stroke="black"/>
              <path d="M 144,32 L 200,32" fill="none" stroke="black"/>
              <path d="M 264,32 L 320,32" fill="none" stroke="black"/>
              <path d="M 80,48 L 104,48" fill="none" stroke="black"/>
              <path d="M 120,48 L 136,48" fill="none" stroke="black"/>
              <path d="M 200,64 L 224,64" fill="none" stroke="black"/>
              <path d="M 240,64 L 256,64" fill="none" stroke="black"/>
              <path d="M 208,96 L 224,96" fill="none" stroke="black"/>
              <path d="M 240,96 L 264,96" fill="none" stroke="black"/>
              <path d="M 264,112 L 320,112" fill="none" stroke="black"/>
              <path d="M 88,128 L 104,128" fill="none" stroke="black"/>
              <path d="M 120,128 L 144,128" fill="none" stroke="black"/>
              <path d="M 8,144 L 80,144" fill="none" stroke="black"/>
              <path d="M 144,144 L 200,144" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="264,64 252,58.4 252,69.6" fill="black" transform="rotate(0,256,64)"/>
              <polygon class="arrowhead" points="216,96 204,90.4 204,101.6" fill="black" transform="rotate(180,208,96)"/>
              <polygon class="arrowhead" points="144,48 132,42.4 132,53.6" fill="black" transform="rotate(0,136,48)"/>
              <polygon class="arrowhead" points="96,128 84,122.4 84,133.6" fill="black" transform="rotate(180,88,128)"/>
              <g class="text">
                <text x="44" y="52">Client</text>
                <text x="112" y="52">1</text>
                <text x="172" y="52">RS</text>
                <text x="292" y="52">AS</text>
                <text x="44" y="68">Instance</text>
                <text x="232" y="68">2</text>
                <text x="232" y="100">3</text>
                <text x="112" y="132">4</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="left" pn="section-3.3-4.2">
+--------+       +------+       +------+
| Client +--(1)-&gt;|  RS  |       |  AS  |
|Instance|       |      +--(2)-&gt;|      |
|        |       |      |       |      |
|        |       |      |&lt;-(3)--+      |
|        |       |      |       +------+
|        |&lt;-(4)--+      |
+--------+       +------+
</artwork>
        </artset>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.3-5"><li pn="section-3.3-5.1" derivedCounter="1.">
            <t indent="0" pn="section-3.3-5.1.1">The client instance calls the RS with its access token.</t>
          </li>
          <li pn="section-3.3-5.2" derivedCounter="2.">
            <t indent="0" pn="section-3.3-5.2.1">The RS introspects the access token value at the AS.
 The RS signs the request with its own key (not the client instance's
 key or the token's key).</t>
          </li>
          <li pn="section-3.3-5.3" derivedCounter="3.">
            <t indent="0" pn="section-3.3-5.3.1">The AS validates the access token value and the RS's request
 and returns the introspection response for the token.</t>
          </li>
          <li pn="section-3.3-5.4" derivedCounter="4.">
            <t indent="0" pn="section-3.3-5.4.1">The RS fulfills the request from the client instance.</t>
          </li>
        </ol>
        <t indent="0" pn="section-3.3-6">The RS signs the request with its own key and sends the value of the access
token in the body of the request as a JSON object with the following members:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.3-7">
          <dt pn="section-3.3-7.1">access_token (string):</dt>
          <dd pn="section-3.3-7.2">
            <t indent="0" pn="section-3.3-7.2.1">The access token value presented to the RS by the client instance. <bcp14>REQUIRED</bcp14>.</t>
          </dd>
          <dt pn="section-3.3-7.3">proof (string):</dt>
          <dd pn="section-3.3-7.4">
            <t indent="0" pn="section-3.3-7.4.1">The proofing method used by the client instance to bind the token to the RS request.
  The value <bcp14>MUST</bcp14> be registered in the "GNAP Key Proofing Methods" registry. <bcp14>RECOMMENDED</bcp14>.</t>
          </dd>
          <dt pn="section-3.3-7.5">resource_server (object/string):</dt>
          <dd pn="section-3.3-7.6">
            <t indent="0" pn="section-3.3-7.6.1">The identification used to authenticate the resource server making this call, either
  by value or by reference as described in <xref target="authentication" format="default" sectionFormat="of" derivedContent="Section 3.2"/>. <bcp14>REQUIRED</bcp14>.</t>
          </dd>
          <dt pn="section-3.3-7.7">access (array of strings/objects):</dt>
          <dd pn="section-3.3-7.8">
            <t indent="0" pn="section-3.3-7.8.1">The minimum access rights required to fulfill the request. This <bcp14>MUST</bcp14> be in the
  format described in <xref section="8" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-8" derivedContent="GNAP"/>. <bcp14>OPTIONAL</bcp14>. </t>
          </dd>
        </dl>
        <t indent="0" pn="section-3.3-8">Additional fields are defined in the "GNAP Token Introspection Request" registry (<xref target="IANA-token-introspection-request" format="default" sectionFormat="of" derivedContent="Section 5.4"/>).</t>
        <sourcecode type="http-message" markers="false" pn="section-3.3-9">
POST /introspect HTTP/1.1
Host: server.example.com
Content-Type: application/json
Signature-Input: sig1=...
Signature: sig1=...
Digest: sha256=...

{
    "access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
    "proof": "httpsig",
    "resource_server": "7C7C4AZ9KHRS6X63AJAO"
}
</sourcecode>
        <t indent="0" pn="section-3.3-10">The AS <bcp14>MUST</bcp14> validate the access token value and determine if the token is active.
The parameters of the request provide a context for the AS to evaluate the access token,
and the AS <bcp14>MUST</bcp14> take all provided parameters into account when evaluating if the token is active.
If the AS is unable to process part of the request, such as not understanding part of
the <tt>access</tt> field presented, the AS <bcp14>MUST NOT</bcp14> indicate the token as active.</t>
        <t indent="0" pn="section-3.3-11">An active access token is defined as a token that is all of the following:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3-12">
          <li pn="section-3.3-12.1">
            <t indent="0" pn="section-3.3-12.1.1">was issued by the processing AS,</t>
          </li>
          <li pn="section-3.3-12.2">
            <t indent="0" pn="section-3.3-12.2.1">has not been revoked,</t>
          </li>
          <li pn="section-3.3-12.3">
            <t indent="0" pn="section-3.3-12.3.1">has not expired,</t>
          </li>
          <li pn="section-3.3-12.4">
            <t indent="0" pn="section-3.3-12.4.1">is bound using the <tt>proof</tt> method indicated,</t>
          </li>
          <li pn="section-3.3-12.5">
            <t indent="0" pn="section-3.3-12.5.1">is appropriate for presentation at the identified RS, and</t>
          </li>
          <li pn="section-3.3-12.6">
            <t indent="0" pn="section-3.3-12.6.1">is appropriate for the <tt>access</tt> indicated (if present).</t>
          </li>
        </ul>
        <t indent="0" pn="section-3.3-13">The AS responds with a data structure describing the token's
current state and any information the RS would need to validate the
token's presentation, such as its intended proofing mechanism and key
material.</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.3-14">
          <dt pn="section-3.3-14.1">active (boolean):</dt>
          <dd pn="section-3.3-14.2">
            <t indent="0" pn="section-3.3-14.2.1">If <tt>true</tt>, the access token presented is active,
  as defined above. If any of the criteria for an active token
  are not true, or if the AS is unable to make a
  determination (such as the token is not found), the value is
  set to <tt>false</tt> and other fields are omitted. <bcp14>REQUIRED</bcp14>.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-3.3-15">If the access token is active, additional fields from the single access token
response structure defined in <xref section="3.2.1" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-3.2.1" derivedContent="GNAP"/> are included. In
particular, these include the following:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.3-16">
          <dt pn="section-3.3-16.1">access (array of strings/objects):</dt>
          <dd pn="section-3.3-16.2">
            <t indent="0" pn="section-3.3-16.2.1">The access rights associated with this access token. This <bcp14>MUST</bcp14> be in the
  format described in <xref section="8" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-8" derivedContent="GNAP"/>.
  This array <bcp14>MAY</bcp14> be filtered or otherwise limited for consumption by the identified RS, including
  being an empty array, which indicates that the token has no explicit access rights that
  can be disclosed to the RS. <bcp14>REQUIRED</bcp14>.</t>
          </dd>
          <dt pn="section-3.3-16.3">key (object/string):</dt>
          <dd pn="section-3.3-16.4">
            <t indent="0" pn="section-3.3-16.4.1">if the token is bound. The key bound to the access token, to allow the RS
  to validate the signature of the request from the client instance. If the access
  token is a bearer token, this <bcp14>MUST NOT</bcp14> be included. <bcp14>REQUIRED</bcp14></t>
          </dd>
          <dt pn="section-3.3-16.5">flags (array of strings):</dt>
          <dd pn="section-3.3-16.6">
            <t indent="0" pn="section-3.3-16.6.1">The set of flags associated with the access token. <bcp14>OPTIONAL</bcp14>.</t>
          </dd>
          <dt pn="section-3.3-16.7">exp (integer):</dt>
          <dd pn="section-3.3-16.8">
            <t indent="0" pn="section-3.3-16.8.1">The timestamp after which this token is no longer valid.
  Expressed as integer seconds from UNIX Epoch. <bcp14>OPTIONAL</bcp14>.</t>
          </dd>
          <dt pn="section-3.3-16.9">iat (integer):</dt>
          <dd pn="section-3.3-16.10">
            <t indent="0" pn="section-3.3-16.10.1">The timestamp at which this token was issued by the AS.
  Expressed as integer seconds from UNIX Epoch. <bcp14>OPTIONAL</bcp14>.</t>
          </dd>
          <dt pn="section-3.3-16.11">nbf (integer):</dt>
          <dd pn="section-3.3-16.12">
            <t indent="0" pn="section-3.3-16.12.1">The timestamp before which this token is not valid.
  Expressed as integer seconds from UNIX Epoch. <bcp14>OPTIONAL</bcp14>.</t>
          </dd>
          <dt pn="section-3.3-16.13">aud (string or array of strings):</dt>
          <dd pn="section-3.3-16.14">
            <t indent="0" pn="section-3.3-16.14.1">Identifiers for the resource servers this token can be accepted at. <bcp14>OPTIONAL</bcp14>.</t>
          </dd>
          <dt pn="section-3.3-16.15">sub (string):</dt>
          <dd pn="section-3.3-16.16">
            <t indent="0" pn="section-3.3-16.16.1">Identifier of the resource owner who authorized this token. <bcp14>OPTIONAL</bcp14>.</t>
          </dd>
          <dt pn="section-3.3-16.17">iss (string):</dt>
          <dd pn="section-3.3-16.18">
            <t indent="0" pn="section-3.3-16.18.1">Grant endpoint URL of the AS that issued this token. <bcp14>REQUIRED</bcp14>.</t>
          </dd>
          <dt pn="section-3.3-16.19">instance_id (string):</dt>
          <dd pn="section-3.3-16.20">
            <t indent="0" pn="section-3.3-16.20.1">The instance identifier of the client instance that the token was issued to. <bcp14>OPTIONAL</bcp14>.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-3.3-17">Additional fields are defined in the "GNAP Token Introspection Response" registry (<xref target="IANA-token-introspection" format="default" sectionFormat="of" derivedContent="Section 5.5"/>).</t>
        <t indent="0" pn="section-3.3-18">The response <bcp14>MAY</bcp14> include any additional fields defined in an access
token response and <bcp14>MUST NOT</bcp14> include the access token <tt>value</tt> itself.</t>
        <sourcecode type="http-message" markers="false" pn="section-3.3-19">
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
    "active": true,
    "access": [
        "dolphin-metadata", "some other thing"
    ],
    "key": {
        "proof": "httpsig",
        "jwk": {
                "kty": "RSA",
                "e": "AQAB",
                "kid": "xyz-1",
                "alg": "RS256",
                "n": "kOB5rR4Jv0GMeL...."
        }
    }
}
</sourcecode>
        <t indent="0" pn="section-3.3-20">When processing the results of the introspection response, the RS <bcp14>MUST</bcp14> determine the
appropriate course of action. For instance, if the RS determines that the access token's
access rights are not sufficient for the request to which the token was attached, the RS
can return an error or a public resource, as appropriate for the RS.
In all cases, the final determination of the response is at the discretion of the RS.</t>
      </section>
      <section anchor="rs-register-resource-handle" numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-registering-a-resource-set">Registering a Resource Set</name>
        <t indent="0" pn="section-3.4-1">If the RS needs to, it can post a set of resources, as described in Section <xref target="RFC9635" sectionFormat="bare" section="8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-8" derivedContent="GNAP"/> ("Resource Access Rights") of <xref target="RFC9635" format="default" sectionFormat="of" derivedContent="GNAP"/>, to the AS's resource registration endpoint along with information about
what the RS will need to validate the request.</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.4-2">
          <dt pn="section-3.4-2.1">access (array of objects/strings):</dt>
          <dd pn="section-3.4-2.2">
            <t indent="0" pn="section-3.4-2.2.1">The list of access rights associated with the request in the format described
  in Section <xref target="RFC9635" sectionFormat="bare" section="8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-8" derivedContent="GNAP"/> ("Resource Access Rights") of <xref target="RFC9635" format="default" sectionFormat="of" derivedContent="GNAP"/>. <bcp14>REQUIRED</bcp14>. </t>
          </dd>
          <dt pn="section-3.4-2.3">resource_server (object/string):</dt>
          <dd pn="section-3.4-2.4">
            <t indent="0" pn="section-3.4-2.4.1"> The identification used to authenticate the resource server making this call, either
  by value or by reference as described in <xref target="authentication" format="default" sectionFormat="of" derivedContent="Section 3.2"/>. <bcp14>REQUIRED</bcp14>.</t>
          </dd>
          <dt pn="section-3.4-2.5">token_formats_supported (array of strings):</dt>
          <dd pn="section-3.4-2.6">
            <t indent="0" pn="section-3.4-2.6.1">The list of token formats that the RS is able to process.
  The values in this array <bcp14>MUST</bcp14> be registered in the "GNAP Token Formats" registry per <xref target="IANA-token-format" format="default" sectionFormat="of" derivedContent="Section 5.3"/>.
  If the field is omitted, the token format is at the discretion of the AS.
  If the AS does not support any of the requested
  token formats, the AS <bcp14>MUST</bcp14> return an error to the RS. <bcp14>OPTIONAL</bcp14>.</t>
          </dd>
          <dt pn="section-3.4-2.7">token_introspection_required (boolean):</dt>
          <dd pn="section-3.4-2.8">
            <t indent="0" pn="section-3.4-2.8.1"> If present and set to <tt>true</tt>, the RS expects to make a token introspection request as
  described in <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/>. If absent or set to <tt>false</tt>, the RS does not anticipate needing
  to make an introspection request for tokens relating to this resource set. If the AS does not
  support token introspection for this RS, the AS <bcp14>MUST</bcp14> return an error to the RS. <bcp14>OPTIONAL</bcp14>.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-3.4-3">Additional fields are defined in the "GNAP Resource Set Registration Request Parameters" registry (<xref target="IANA-resource-registration-request" format="default" sectionFormat="of" derivedContent="Section 5.6"/>).</t>
        <t indent="0" pn="section-3.4-4">The RS <bcp14>MUST</bcp14> identify itself with its own key and sign the
request.</t>
        <sourcecode type="http-message" markers="false" pn="section-3.4-5">
POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/json
Signature-Input: sig1=...
Signature: sig1=...
Digest: ...

{
    "access": [
        {
            "actions": [
                "read",
                "write",
                "dolphin"
            ],
            "locations": [
                "https://server.example.net/",
                "https://resource.local/other"
            ],
            "datatypes": [
                "metadata",
                "images"
            ]
        },
        "dolphin-metadata"
    ],
    "resource_server": "7C7C4AZ9KHRS6X63AJAO"

}
</sourcecode>
        <t indent="0" pn="section-3.4-6">The AS responds with a reference appropriate to represent the
resources list that the RS presented in its request as well as
any additional information the RS might need in future requests.</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.4-7">
          <dt pn="section-3.4-7.1">resource_reference (string):</dt>
          <dd pn="section-3.4-7.2">
            <t indent="0" pn="section-3.4-7.2.1">A single string representing the list of resources registered in the request.
  The RS <bcp14>MAY</bcp14> make this handle available to a client instance as part of a
  discovery response as described in <xref section="9.1" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-9.1" derivedContent="GNAP"/> or as
  documentation to client software developers. <bcp14>REQUIRED</bcp14>.</t>
          </dd>
          <dt pn="section-3.4-7.3">instance_id (string):</dt>
          <dd pn="section-3.4-7.4">
            <t indent="0" pn="section-3.4-7.4.1">An instance identifier that the RS can use to refer to itself in future calls to
  the AS, in lieu of sending its key by value. See <xref target="authentication" format="default" sectionFormat="of" derivedContent="Section 3.2"/>. <bcp14>OPTIONAL</bcp14>.</t>
          </dd>
          <dt pn="section-3.4-7.5">introspection_endpoint (string):</dt>
          <dd pn="section-3.4-7.6">
            <t indent="0" pn="section-3.4-7.6.1">The introspection endpoint of this AS that is used to allow the RS to perform token introspection. See <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/>. <bcp14>OPTIONAL</bcp14>.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-3.4-8">Additional fields are defined in the "GNAP Resource Set Registration Response Parameters" registry (<xref target="IANA-resource-registration-response" format="default" sectionFormat="of" derivedContent="Section 5.7"/>).</t>
        <sourcecode type="http-message" markers="false" pn="section-3.4-9">
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
    "resource_reference": "FWWIKYBQ6U56NL1"
}
</sourcecode>
        <t indent="0" pn="section-3.4-10">If a resource was previously registered, the AS <bcp14>MAY</bcp14> return the same resource reference
	value as in previous responses.</t>
        <t indent="0" pn="section-3.4-11">If the registration fails, the AS returns HTTP status code 400 (Bad Request) to the
RS, indicating that the registration was not successful.</t>
        <t indent="0" pn="section-3.4-12">The client instance can then use the <tt>resource_reference</tt> value as a string-type access
reference as defined in <xref section="8.1" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-8.1" derivedContent="GNAP"/>. This value <bcp14>MAY</bcp14> be combined with any other
additional access rights requested by the client instance.</t>
        <sourcecode type="json" markers="false" pn="section-3.4-13">
{
    "access_token": {
        "access": [
            "FWWIKYBQ6U56NL1",
            {
                "type": "photo-api",
                "actions": [
                    "read",
                    "write",
                    "dolphin"
                ],
                "locations": [
                    "https://server.example.net/",
                    "https://resource.local/other"
                ],
                "datatypes": [
                    "metadata",
                    "images"
                ]
            },
            "dolphin-metadata"
        ]
    },
    "client": "client-12351.bdxqf"
}
</sourcecode>
      </section>
      <section anchor="response-error" numbered="true" removeInRFC="false" toc="include" pn="section-3.5">
        <name slugifiedName="name-error-responses">Error Responses</name>
        <t indent="0" pn="section-3.5-1">In the case of an error from the RS-facing API, the AS responds to the RS with HTTP status code 400 (Bad Request) and a JSON object consisting of a single <tt>error</tt> field, which is either an object or a string.</t>
        <t indent="0" pn="section-3.5-2">When returned as a string, the error value is the error code:</t>
        <sourcecode type="json" markers="false" pn="section-3.5-3">
{
    error: "invalid_access"
}
</sourcecode>
        <t indent="0" pn="section-3.5-4">When returned as an object, the error object contains the following fields:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.5-5">
          <dt pn="section-3.5-5.1"><tt>code</tt> (string):</dt>
          <dd pn="section-3.5-5.2">
            <t indent="0" pn="section-3.5-5.2.1">A single ASCII error code defining the error.
<bcp14>REQUIRED</bcp14>.</t>
          </dd>
          <dt pn="section-3.5-5.3"><tt>description</tt> (string):</dt>
          <dd pn="section-3.5-5.4">
            <t indent="0" pn="section-3.5-5.4.1">A human-readable string description of the error intended for the
developer of the client.
<bcp14>OPTIONAL</bcp14>.</t>
          </dd>
        </dl>
        <sourcecode type="json" markers="false" pn="section-3.5-6">
{
  "error": {
    "code": "invalid_access",
    "description": "Access to 'foo' is not permitted for this RS."
  }
}
</sourcecode>
        <t indent="0" pn="section-3.5-7">This specification defines the following error code values:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.5-8">
          <dt pn="section-3.5-8.1"><tt>"invalid_request"</tt>:</dt>
          <dd pn="section-3.5-8.2">
            <t indent="0" pn="section-3.5-8.2.1">The request is missing a required parameter, includes an
  invalid parameter value, or is otherwise malformed.</t>
          </dd>
          <dt pn="section-3.5-8.3"><tt>"invalid_resource_server"</tt>:</dt>
          <dd pn="section-3.5-8.4">
            <t indent="0" pn="section-3.5-8.4.1">The request was made from an RS that was not recognized
  or allowed by the AS, or the RS's signature validation failed.</t>
          </dd>
          <dt pn="section-3.5-8.5"><tt>"invalid_access"</tt></dt>
          <dd pn="section-3.5-8.6">
            <t indent="0" pn="section-3.5-8.6.1">The RS is not permitted to register or introspect for the requested "access" value.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-3.5-9">Additional error codes can be defined in the "GNAP RS-Facing Error Codes" registry (<xref target="IANA-error-code" format="default" sectionFormat="of" derivedContent="Section 5.9"/>).</t>
      </section>
    </section>
    <section anchor="token-chaining" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-deriving-a-downstream-token">Deriving a Downstream Token</name>
      <t indent="0" pn="section-4-1">Some architectures require an RS to act as a client instance and use a derived access
token for a secondary RS. Since the RS is not the same entity that made the initial grant
request, the RS is not capable of referencing or modifying the existing grant. As such,
the RS needs to request or generate a new access token for its use at the secondary RS.
This internal secondary token is issued in the context of the incoming access token.</t>
      <t indent="0" pn="section-4-2">While it is possible to use a <xref target="structure" format="default" sectionFormat="of" derivedContent="Section 2">token format</xref> that allows for the
RS to generate its own secondary token,
the AS can allow the RS to request this secondary access token using the same
process used by the original client instance to request the primary access token. Since the
RS is acting as its own client instance from the perspective of GNAP, this process
uses the same grant endpoint, request structure, and response structure as a client
instance's request.</t>
      <artset pn="section-4-3">
        <artwork type="svg" align="left" pn="section-4-3.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="192" width="464" viewBox="0 0 464 192" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
            <path d="M 8,32 L 8,176" fill="none" stroke="black"/>
            <path d="M 80,32 L 80,176" fill="none" stroke="black"/>
            <path d="M 144,32 L 144,176" fill="none" stroke="black"/>
            <path d="M 208,32 L 208,176" fill="none" stroke="black"/>
            <path d="M 272,32 L 272,96" fill="none" stroke="black"/>
            <path d="M 328,32 L 328,96" fill="none" stroke="black"/>
            <path d="M 392,32 L 392,176" fill="none" stroke="black"/>
            <path d="M 456,32 L 456,176" fill="none" stroke="black"/>
            <path d="M 8,32 L 80,32" fill="none" stroke="black"/>
            <path d="M 144,32 L 208,32" fill="none" stroke="black"/>
            <path d="M 272,32 L 328,32" fill="none" stroke="black"/>
            <path d="M 392,32 L 456,32" fill="none" stroke="black"/>
            <path d="M 80,48 L 104,48" fill="none" stroke="black"/>
            <path d="M 120,48 L 136,48" fill="none" stroke="black"/>
            <path d="M 208,64 L 232,64" fill="none" stroke="black"/>
            <path d="M 248,64 L 264,64" fill="none" stroke="black"/>
            <path d="M 216,80 L 232,80" fill="none" stroke="black"/>
            <path d="M 248,80 L 272,80" fill="none" stroke="black"/>
            <path d="M 272,96 L 328,96" fill="none" stroke="black"/>
            <path d="M 208,128 L 304,128" fill="none" stroke="black"/>
            <path d="M 320,128 L 384,128" fill="none" stroke="black"/>
            <path d="M 216,144 L 304,144" fill="none" stroke="black"/>
            <path d="M 320,144 L 392,144" fill="none" stroke="black"/>
            <path d="M 88,160 L 104,160" fill="none" stroke="black"/>
            <path d="M 120,160 L 144,160" fill="none" stroke="black"/>
            <path d="M 8,176 L 80,176" fill="none" stroke="black"/>
            <path d="M 144,176 L 208,176" fill="none" stroke="black"/>
            <path d="M 392,176 L 456,176" fill="none" stroke="black"/>
            <polygon class="arrowhead" points="392,128 380,122.4 380,133.6" fill="black" transform="rotate(0,384,128)"/>
            <polygon class="arrowhead" points="272,64 260,58.4 260,69.6" fill="black" transform="rotate(0,264,64)"/>
            <polygon class="arrowhead" points="224,144 212,138.4 212,149.6" fill="black" transform="rotate(180,216,144)"/>
            <polygon class="arrowhead" points="224,80 212,74.4 212,85.6" fill="black" transform="rotate(180,216,80)"/>
            <polygon class="arrowhead" points="144,48 132,42.4 132,53.6" fill="black" transform="rotate(0,136,48)"/>
            <polygon class="arrowhead" points="96,160 84,154.4 84,165.6" fill="black" transform="rotate(180,88,160)"/>
            <g class="text">
              <text x="44" y="52">Client</text>
              <text x="112" y="52">1</text>
              <text x="176" y="52">RS1</text>
              <text x="300" y="52">AS</text>
              <text x="424" y="52">RS2</text>
              <text x="44" y="68">Instance</text>
              <text x="240" y="68">2</text>
              <text x="240" y="84">3</text>
              <text x="312" y="132">4</text>
              <text x="312" y="148">5</text>
              <text x="112" y="164">6</text>
            </g>
          </svg>
        </artwork>
        <artwork type="ascii-art" align="left" pn="section-4-3.2">
+--------+       +-------+       +------+       +-------+
| Client +--(1)-&gt;|  RS1  |       |  AS  |       |  RS2  |
|Instance|       |       +--(2)-&gt;|      |       |       |
|        |       |       |&lt;-(3)--+      |       |       |
|        |       |       |       +------+       |       |
|        |       |       |                      |       |
|        |       |       +-----------(4)-------&gt;|       |
|        |       |       |&lt;----------(5)--------+       |
|        |&lt;-(6)--+       |                      |       |
+--------+       +-------+                      +-------+
</artwork>
      </artset>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4-4"><li pn="section-4-4.1" derivedCounter="1.">
          <t indent="0" pn="section-4-4.1.1">The client instance calls RS1 with an access token.</t>
        </li>
        <li pn="section-4-4.2" derivedCounter="2.">
          <t indent="0" pn="section-4-4.2.1">RS1 presents that token to the AS to get a derived token
 for use at RS2. RS1 indicates that it has no ability
 to interact with the RO. Note that
 RS1 signs its request with its own key, not the token's
 key or the client instance's key.</t>
        </li>
        <li pn="section-4-4.3" derivedCounter="3.">
          <t indent="0" pn="section-4-4.3.1">The AS returns a derived token to RS1 for use at RS2.</t>
        </li>
        <li pn="section-4-4.4" derivedCounter="4.">
          <t indent="0" pn="section-4-4.4.1">RS1 calls RS2 with the token from (3).</t>
        </li>
        <li pn="section-4-4.5" derivedCounter="5.">
          <t indent="0" pn="section-4-4.5.1">RS2 fulfills the call from RS1.</t>
        </li>
        <li pn="section-4-4.6" derivedCounter="6.">
          <t indent="0" pn="section-4-4.6.1">RS1 fulfills the call from the original client instance.</t>
        </li>
      </ol>
      <t indent="0" pn="section-4-5">If the RS needs to derive a token from one presented to it, it can
request one from the AS by making a token request as described in
<xref target="RFC9635" format="default" sectionFormat="of" derivedContent="GNAP"/> and presenting the existing access token's
value in the "existing_access_token" field.</t>
      <t indent="0" pn="section-4-6">Since the RS is acting as a client instance,
the RS <bcp14>MUST</bcp14> identify itself with its own key in the <tt>client</tt> field and sign the
request just as any client instance would, as described in <xref target="authentication" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.
The AS <bcp14>MUST</bcp14> determine that the token being presented is appropriate for use
at the RS making the token chaining request.</t>
      <sourcecode type="http-message" markers="false" pn="section-4-7">
POST /tx HTTP/1.1
Host: server.example.com
Content-Type: application/json
Detached-JWS: ejy0...

{
  "access_token": {
      "access": [
          {
              "actions": [
                  "read",
                  "write",
                  "dolphin"
              ],
              "locations": [
                  "https://server.example.net/",
                  "https://resource.local/other"
              ],
              "datatypes": [
                  "metadata",
                  "images"
              ]
          },
          "dolphin-metadata"
      ]
  },
  "client": "7C7C4AZ9KHRS6X63AJAO",
  "existing_access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0"
}
</sourcecode>
      <t indent="0" pn="section-4-8">The AS responds with a token for the downstream RS2 as described in
<xref target="RFC9635" format="default" sectionFormat="of" derivedContent="GNAP"/>. The downstream RS2 could
repeat this process as necessary for calling further RSs.</t>
    </section>
    <section anchor="IANA" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-5-1">IANA has added values to existing registries and created five registries under the "Grant Negotiation and Authorization Protocol (GNAP)" registry group.</t>
      <section anchor="IANA-well-known" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-well-known-uris">Well-Known URIs</name>
        <t indent="0" pn="section-5.1-1">The "gnap-as-rs" URI suffix is registered in the "Well-Known URIs" registry to support RS-facing discovery of the AS.</t>
        <dl newline="false" spacing="compact" indent="3" pn="section-5.1-2">
          <dt pn="section-5.1-2.1">URI Suffix:</dt>
          <dd pn="section-5.1-2.2">gnap-as-rs</dd>
          <dt pn="section-5.1-2.3">Change Controller:</dt>
          <dd pn="section-5.1-2.4">IETF</dd>
          <dt pn="section-5.1-2.5">Specification Document:</dt>
          <dd pn="section-5.1-2.6">
            <xref target="discovery" format="default" sectionFormat="of" derivedContent="Section 3.1"/> of RFC 9767</dd>
          <dt pn="section-5.1-2.7">Status:</dt>
          <dd pn="section-5.1-2.8">Permanent</dd>
        </dl>
      </section>
      <section anchor="IANA-grant-request" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-gnap-grant-request-paramete">GNAP Grant Request Parameters</name>
        <t indent="0" pn="section-5.2-1">The following parameter is registered in the "GNAP Grant Request Parameters" registry:</t>
        <dl newline="false" spacing="compact" indent="3" pn="section-5.2-2">
          <dt pn="section-5.2-2.1">Name:</dt>
          <dd pn="section-5.2-2.2">
            <tt>existing_access_token</tt>
          </dd>
          <dt pn="section-5.2-2.3">Type:</dt>
          <dd pn="section-5.2-2.4">
            string
          </dd>
          <dt pn="section-5.2-2.5">Reference:</dt>
          <dd pn="section-5.2-2.6">
            <xref target="token-chaining" format="default" sectionFormat="of" derivedContent="Section 4"/> of RFC 9767
          </dd>
        </dl>
      </section>
      <section anchor="IANA-token-format" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-gnap-token-formats">GNAP Token Formats</name>
        <t indent="0" pn="section-5.3-1">This document defines a GNAP token format, for which IANA has created and maintains a new registry titled "GNAP Token Formats". Initial values for this registry are given in <xref target="IANA-token-format-contents" format="default" sectionFormat="of" derivedContent="Section 5.3.2"/>. Future assignments and modifications to existing assignment are to be made through the Specification Required registration policy <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.</t>
        <t indent="0" pn="section-5.3-2">The designated expert (DE) is expected to ensure that:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3-3">
          <li pn="section-5.3-3.1">
            <t indent="0" pn="section-5.3-3.1.1">all registrations follow the template presented in <xref target="IANA-token-format-template" format="default" sectionFormat="of" derivedContent="Section 5.3.1"/>.</t>
          </li>
          <li pn="section-5.3-3.2">
            <t indent="0" pn="section-5.3-3.2.1">the format's definition is sufficiently unique from other formats provided by existing parameters.</t>
          </li>
          <li pn="section-5.3-3.3">
            <t indent="0" pn="section-5.3-3.3.1">the format's definition specifies the format of the access token in sufficient detail to allow for the AS and RS to be able to communicate the token information.</t>
          </li>
        </ul>
        <section anchor="IANA-token-format-template" numbered="true" removeInRFC="false" toc="include" pn="section-5.3.1">
          <name slugifiedName="name-registry-template">Registry Template</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-5.3.1-1">
            <dt pn="section-5.3.1-1.1">Name:</dt>
            <dd pn="section-5.3.1-1.2">
              The name of the format.
            </dd>
            <dt pn="section-5.3.1-1.3">Status:</dt>
            <dd pn="section-5.3.1-1.4">
              Whether or not the format is in active use. Possible values are Active and Deprecated.
            </dd>
            <dt pn="section-5.3.1-1.5">Description:</dt>
            <dd pn="section-5.3.1-1.6">
              The human-readable description of the access token format.
            </dd>
            <dt pn="section-5.3.1-1.7">Reference:</dt>
            <dd pn="section-5.3.1-1.8">
              The specification that defines the token format.
            </dd>
          </dl>
        </section>
        <section anchor="IANA-token-format-contents" numbered="true" removeInRFC="false" toc="include" pn="section-5.3.2">
          <name slugifiedName="name-initial-registry-contents">Initial Registry Contents</name>
          <table align="center" pn="table-1">
            <name slugifiedName="name-initial-contents-of-the-gna">Initial Contents of the GNAP Token Formats Registry</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Name</th>
                <th align="left" colspan="1" rowspan="1">Status</th>
                <th align="left" colspan="1" rowspan="1">Description</th>
                <th align="left" colspan="1" rowspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">
                  <tt>jwt-signed</tt></td>
                <td align="left" colspan="1" rowspan="1">Active</td>
                <td align="left" colspan="1" rowspan="1">JSON Web Token, signed with JWS</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">
                  <tt>jwt-encrypted</tt></td>
                <td align="left" colspan="1" rowspan="1">Active</td>
                <td align="left" colspan="1" rowspan="1">JSON Web Token, encrypted with JWE</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="JWT"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">
                  <tt>macaroon</tt></td>
                <td align="left" colspan="1" rowspan="1">Active</td>
                <td align="left" colspan="1" rowspan="1">Macaroon</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="MACAROON" format="default" sectionFormat="of" derivedContent="MACAROON"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">
                  <tt>biscuit</tt></td>
                <td align="left" colspan="1" rowspan="1">Active</td>
                <td align="left" colspan="1" rowspan="1">Biscuit</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="BISCUIT" format="default" sectionFormat="of" derivedContent="BISCUIT"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">
                  <tt>zcap</tt></td>
                <td align="left" colspan="1" rowspan="1">Active</td>
                <td align="left" colspan="1" rowspan="1">ZCAP</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="ZCAPLD" format="default" sectionFormat="of" derivedContent="ZCAPLD"/></td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="IANA-token-introspection-request" numbered="true" removeInRFC="false" toc="include" pn="section-5.4">
        <name slugifiedName="name-gnap-token-introspection-re">GNAP Token Introspection Request</name>
        <t indent="0" pn="section-5.4-1">This document defines GNAP token introspection, for which IANA has created and maintains a new registry titled "GNAP Token Introspection Request". Initial values for this registry are given in <xref target="IANA-token-introspection-request-contents" format="default" sectionFormat="of" derivedContent="Section 5.4.2"/>. Future assignments and modifications to existing assignment are to be made through the Specification Required registration policy <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.</t>
        <t indent="0" pn="section-5.4-2">The DE is expected to ensure that:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.4-3">
          <li pn="section-5.4-3.1">
            <t indent="0" pn="section-5.4-3.1.1">all registrations follow the template presented in <xref target="IANA-token-introspection-request-template" format="default" sectionFormat="of" derivedContent="Section 5.4.1"/>.</t>
          </li>
          <li pn="section-5.4-3.2">
            <t indent="0" pn="section-5.4-3.2.1">the claim's definition is sufficiently orthogonal to other claims defined in the registry so as avoid overlapping functionality.</t>
          </li>
          <li pn="section-5.4-3.3">
            <t indent="0" pn="section-5.4-3.3.1">the claim's definition specifies the syntax and semantics of the claim in sufficient detail to allow for the AS and RS to be able to communicate the token values.</t>
          </li>
        </ul>
        <section anchor="IANA-token-introspection-request-template" numbered="true" removeInRFC="false" toc="include" pn="section-5.4.1">
          <name slugifiedName="name-registry-template-2">Registry Template</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-5.4.1-1">
            <dt pn="section-5.4.1-1.1">Name:</dt>
            <dd pn="section-5.4.1-1.2">
              The name of the claim.
            </dd>
            <dt pn="section-5.4.1-1.3">Type:</dt>
            <dd pn="section-5.4.1-1.4">
              The JSON data type of the claim value.
            </dd>
            <dt pn="section-5.4.1-1.5">Reference:</dt>
            <dd pn="section-5.4.1-1.6">
              The specification that defines the claim.
            </dd>
          </dl>
        </section>
        <section anchor="IANA-token-introspection-request-contents" numbered="true" removeInRFC="false" toc="include" pn="section-5.4.2">
          <name slugifiedName="name-initial-registry-contents-2">Initial Registry Contents</name>
          <t indent="0" pn="section-5.4.2-1">The table below contains the initial contents of the "GNAP Token Introspection Request" registry.</t>
          <table align="center" pn="table-2">
            <name slugifiedName="name-initial-contents-of-the-gnap">Initial Contents of the GNAP Token Introspection Request Registry</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Name</th>
                <th align="left" colspan="1" rowspan="1">Type</th>
                <th align="left" colspan="1" rowspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">access_token</td>
                <td align="left" colspan="1" rowspan="1">string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">proof</td>
                <td align="left" colspan="1" rowspan="1">string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">resource_server</td>
                <td align="left" colspan="1" rowspan="1">object/string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">access</td>
                <td align="left" colspan="1" rowspan="1">array of strings/objects</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="IANA-token-introspection" numbered="true" removeInRFC="false" toc="include" pn="section-5.5">
        <name slugifiedName="name-gnap-token-introspection-res">GNAP Token Introspection Response</name>
        <t indent="0" pn="section-5.5-1">This document defines GNAP token introspection, for which IANA has created and maintains a new registry titled "GNAP Token Introspection Response". Initial values for this registry are given in <xref target="IANA-token-introspection-contents" format="default" sectionFormat="of" derivedContent="Section 5.5.2"/>. Future assignments and modifications to existing assignment are to be made through the Specification Required registration policy <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.</t>
        <t indent="0" pn="section-5.5-2">The DE is expected to ensure that:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.5-3">
          <li pn="section-5.5-3.1">
            <t indent="0" pn="section-5.5-3.1.1">all registrations follow the template presented in <xref target="IANA-token-introspection-template" format="default" sectionFormat="of" derivedContent="Section 5.5.1"/>.</t>
          </li>
          <li pn="section-5.5-3.2">
            <t indent="0" pn="section-5.5-3.2.1">the claim's definition is sufficiently orthogonal to other claims defined in the registry so as avoid overlapping functionality.</t>
          </li>
          <li pn="section-5.5-3.3">
            <t indent="0" pn="section-5.5-3.3.1">the claim's definition specifies the syntax and semantics of the claim in sufficient detail to allow for the AS and RS to be able to communicate the token values.</t>
          </li>
        </ul>
        <section anchor="IANA-token-introspection-template" numbered="true" removeInRFC="false" toc="include" pn="section-5.5.1">
          <name slugifiedName="name-registry-template-3">Registry Template</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-5.5.1-1">
            <dt pn="section-5.5.1-1.1">Name:</dt>
            <dd pn="section-5.5.1-1.2">
              The name of the claim.
            </dd>
            <dt pn="section-5.5.1-1.3">Type:</dt>
            <dd pn="section-5.5.1-1.4">
              The JSON data type of the claim value.
            </dd>
            <dt pn="section-5.5.1-1.5">Reference:</dt>
            <dd pn="section-5.5.1-1.6">
              The specification that defines the claim.
            </dd>
          </dl>
        </section>
        <section anchor="IANA-token-introspection-contents" numbered="true" removeInRFC="false" toc="include" pn="section-5.5.2">
          <name slugifiedName="name-initial-registry-contents-3">Initial Registry Contents</name>
          <t indent="0" pn="section-5.5.2-1">The table below contains the initial contents of the "GNAP Token Introspection Response" registry.</t>
          <table align="center" pn="table-3">
            <name slugifiedName="name-initial-contents-of-the-gnap-">Initial Contents of the GNAP Token Introspection Response Registry</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Name</th>
                <th align="left" colspan="1" rowspan="1">Type</th>
                <th align="left" colspan="1" rowspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">active</td>
                <td align="left" colspan="1" rowspan="1">boolean</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">access</td>
                <td align="left" colspan="1" rowspan="1">array of strings/objects</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">key</td>
                <td align="left" colspan="1" rowspan="1">object/string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">flags</td>
                <td align="left" colspan="1" rowspan="1">array of strings</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">exp</td>
                <td align="left" colspan="1" rowspan="1">integer</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">iat</td>
                <td align="left" colspan="1" rowspan="1">integer</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">nbf</td>
                <td align="left" colspan="1" rowspan="1">integer</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">aud</td>
                <td align="left" colspan="1" rowspan="1">string or array of strings</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">sub</td>
                <td align="left" colspan="1" rowspan="1">string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">iss</td>
                <td align="left" colspan="1" rowspan="1">string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">instance_id</td>
                <td align="left" colspan="1" rowspan="1">string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> of RFC 9767</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="IANA-resource-registration-request" numbered="true" removeInRFC="false" toc="include" pn="section-5.6">
        <name slugifiedName="name-gnap-resource-set-registrat">GNAP Resource Set Registration Request Parameters</name>
        <t indent="0" pn="section-5.6-1">This document defines a means to register a resource set for a GNAP AS, for which IANA has created and maintains a new registry titled "GNAP Resource Set Registration Request Parameters". Initial values for this registry are given in <xref target="IANA-resource-registration-request-contents" format="default" sectionFormat="of" derivedContent="Section 5.6.2"/>. Future assignments and modifications to existing assignment are to be made through the Expert Review registration policy <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.</t>
        <t indent="0" pn="section-5.6-2">The DE is expected to ensure that:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.6-3">
          <li pn="section-5.6-3.1">
            <t indent="0" pn="section-5.6-3.1.1">all registrations follow the template presented in <xref target="IANA-resource-registration-request-template" format="default" sectionFormat="of" derivedContent="Section 5.6.1"/>.</t>
          </li>
          <li pn="section-5.6-3.2">
            <t indent="0" pn="section-5.6-3.2.1">the parameter's definition is sufficiently orthogonal to other parameters defined in the registry so as avoid overlapping functionality.</t>
          </li>
          <li pn="section-5.6-3.3">
            <t indent="0" pn="section-5.6-3.3.1">the parameter's definition specifies the syntax and semantics of the parameter in sufficient detail to allow for the AS and RS to be able to communicate the resource set.</t>
          </li>
        </ul>
        <section anchor="IANA-resource-registration-request-template" numbered="true" removeInRFC="false" toc="include" pn="section-5.6.1">
          <name slugifiedName="name-registry-template-4">Registry Template</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-5.6.1-1">
            <dt pn="section-5.6.1-1.1">Name:</dt>
            <dd pn="section-5.6.1-1.2">
              The name of the parameter.
            </dd>
            <dt pn="section-5.6.1-1.3">Type:</dt>
            <dd pn="section-5.6.1-1.4">
              The JSON data type of the parameter value.
            </dd>
            <dt pn="section-5.6.1-1.5">Reference:</dt>
            <dd pn="section-5.6.1-1.6">
              The specification that defines the token.
            </dd>
          </dl>
        </section>
        <section anchor="IANA-resource-registration-request-contents" numbered="true" removeInRFC="false" toc="include" pn="section-5.6.2">
          <name slugifiedName="name-initial-registry-contents-4">Initial Registry Contents</name>
          <t indent="0" pn="section-5.6.2-1">The table below contains the initial contents of the "GNAP Resource Set Registration Request Parameters" registry.</t>
          <table align="center" pn="table-4">
            <name slugifiedName="name-initial-contents-of-the-gnap-r">Initial Contents of the GNAP Resource Set Registration Request Parameters Registry</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Name</th>
                <th align="left" colspan="1" rowspan="1">Type</th>
                <th align="left" colspan="1" rowspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">access</td>
                <td align="left" colspan="1" rowspan="1">array of strings/objects</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="rs-register-resource-handle" format="default" sectionFormat="of" derivedContent="Section 3.4"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">resource_server</td>
                <td align="left" colspan="1" rowspan="1">object/string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="rs-register-resource-handle" format="default" sectionFormat="of" derivedContent="Section 3.4"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">token_formats_supported</td>
                <td align="left" colspan="1" rowspan="1">array of strings</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="rs-register-resource-handle" format="default" sectionFormat="of" derivedContent="Section 3.4"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">token_introspection_required</td>
                <td align="left" colspan="1" rowspan="1">boolean</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="rs-register-resource-handle" format="default" sectionFormat="of" derivedContent="Section 3.4"/> of RFC 9767</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="IANA-resource-registration-response" numbered="true" removeInRFC="false" toc="include" pn="section-5.7">
        <name slugifiedName="name-gnap-resource-set-registrati">GNAP Resource Set Registration Response Parameters</name>
        <t indent="0" pn="section-5.7-1">This document defines a means to register a resource set for a GNAP AS, for which IANA has created and maintains a new registry titled "GNAP Resource Set Registration Response Parameters". Initial values for this registry are given in <xref target="IANA-resource-registration-response-contents" format="default" sectionFormat="of" derivedContent="Section 5.7.2"/>. Future assignments and modifications to existing assignment are to be made through the Expert Review registration policy <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.</t>
        <t indent="0" pn="section-5.7-2">The DE is expected to ensure that:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.7-3">
          <li pn="section-5.7-3.1">
            <t indent="0" pn="section-5.7-3.1.1">all registrations follow the template presented in <xref target="IANA-resource-registration-response-template" format="default" sectionFormat="of" derivedContent="Section 5.7.1"/>.</t>
          </li>
          <li pn="section-5.7-3.2">
            <t indent="0" pn="section-5.7-3.2.1">the parameter's definition is sufficiently orthogonal to other claims defined in the registry so as avoid overlapping functionality.</t>
          </li>
          <li pn="section-5.7-3.3">
            <t indent="0" pn="section-5.7-3.3.1">the parameter's definition specifies the syntax and semantics of the claim in sufficient detail to allow for the AS and RS to be able to communicate the resource set.</t>
          </li>
        </ul>
        <section anchor="IANA-resource-registration-response-template" numbered="true" removeInRFC="false" toc="include" pn="section-5.7.1">
          <name slugifiedName="name-registry-template-5">Registry Template</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-5.7.1-1">
            <dt pn="section-5.7.1-1.1">Name:</dt>
            <dd pn="section-5.7.1-1.2">
              The name of the parameter.
            </dd>
            <dt pn="section-5.7.1-1.3">Type:</dt>
            <dd pn="section-5.7.1-1.4">
              The JSON data type of the parameter value.
            </dd>
            <dt pn="section-5.7.1-1.5">Reference:</dt>
            <dd pn="section-5.7.1-1.6">
              The specification that defines the parameter.
            </dd>
          </dl>
        </section>
        <section anchor="IANA-resource-registration-response-contents" numbered="true" removeInRFC="false" toc="include" pn="section-5.7.2">
          <name slugifiedName="name-initial-registry-contents-5">Initial Registry Contents</name>
          <t indent="0" pn="section-5.7.2-1">The table below contains the initial contents of the "GNAP Resource Set Registration Response Parameters" registry.</t>
          <table align="center" pn="table-5">
            <name slugifiedName="name-initial-contents-of-the-gnap-re">Initial Contents of the GNAP Resource Set Registration Response Parameters Registry</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Name</th>
                <th align="left" colspan="1" rowspan="1">Type</th>
                <th align="left" colspan="1" rowspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">resource_reference</td>
                <td align="left" colspan="1" rowspan="1">string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="rs-register-resource-handle" format="default" sectionFormat="of" derivedContent="Section 3.4"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">instance_id</td>
                <td align="left" colspan="1" rowspan="1">string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="rs-register-resource-handle" format="default" sectionFormat="of" derivedContent="Section 3.4"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">introspection_endpoint</td>
                <td align="left" colspan="1" rowspan="1">string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="rs-register-resource-handle" format="default" sectionFormat="of" derivedContent="Section 3.4"/> of RFC 9767</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="IANA-rs-discovery" numbered="true" removeInRFC="false" toc="include" pn="section-5.8">
        <name slugifiedName="name-gnap-rs-facing-discovery-do">GNAP RS-Facing Discovery Document Fields</name>
        <t indent="0" pn="section-5.8-1">This document defines a means to for a GNAP AS to be discovered by a GNAP RS, for which IANA has created and maintains a new registry titled "GNAP RS-Facing Discovery Document Fields". Initial values for this registry are given in <xref target="IANA-rs-discovery-contents" format="default" sectionFormat="of" derivedContent="Section 5.8.2"/>. Future assignments and modifications to existing assignment are to be made through the Expert Review registration policy <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.</t>
        <t indent="0" pn="section-5.8-2">The DE is expected to ensure that:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.8-3">
          <li pn="section-5.8-3.1">
            <t indent="0" pn="section-5.8-3.1.1">all registrations follow the template presented in <xref target="IANA-rs-discovery-template" format="default" sectionFormat="of" derivedContent="Section 5.8.1"/>.</t>
          </li>
          <li pn="section-5.8-3.2">
            <t indent="0" pn="section-5.8-3.2.1">the field's definition is sufficiently orthogonal to other fields defined in the registry so as avoid overlapping functionality.</t>
          </li>
          <li pn="section-5.8-3.3">
            <t indent="0" pn="section-5.8-3.3.1">the field's definition specifies the syntax and semantics of the fields in sufficient detail to allow for the RS to be able to communicate with the AS.</t>
          </li>
        </ul>
        <section anchor="IANA-rs-discovery-template" numbered="true" removeInRFC="false" toc="include" pn="section-5.8.1">
          <name slugifiedName="name-registry-template-6">Registry Template</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-5.8.1-1">
            <dt pn="section-5.8.1-1.1">Name:</dt>
            <dd pn="section-5.8.1-1.2">
              The name of the field.
            </dd>
            <dt pn="section-5.8.1-1.3">Type:</dt>
            <dd pn="section-5.8.1-1.4">
              The JSON data type of the field value.
            </dd>
            <dt pn="section-5.8.1-1.5">Reference:</dt>
            <dd pn="section-5.8.1-1.6">
              The specification that defines the field.
            </dd>
          </dl>
        </section>
        <section anchor="IANA-rs-discovery-contents" numbered="true" removeInRFC="false" toc="include" pn="section-5.8.2">
          <name slugifiedName="name-initial-registry-contents-6">Initial Registry Contents</name>
          <t indent="0" pn="section-5.8.2-1">The table below contains the initial contents of the "GNAP RS-Facing Discovery Document Fields" registry.</t>
          <table align="center" pn="table-6">
            <name slugifiedName="name-initial-contents-of-the-gnap-rs">Initial Contents of the GNAP RS-Facing Discovery Document Fields Registry</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Name</th>
                <th align="left" colspan="1" rowspan="1">Type</th>
                <th align="left" colspan="1" rowspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">introspection_endpoint</td>
                <td align="left" colspan="1" rowspan="1">string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="discovery" format="default" sectionFormat="of" derivedContent="Section 3.1"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">token_formats_supported</td>
                <td align="left" colspan="1" rowspan="1">array of strings</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="discovery" format="default" sectionFormat="of" derivedContent="Section 3.1"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">resource_registration_endpoint</td>
                <td align="left" colspan="1" rowspan="1">string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="discovery" format="default" sectionFormat="of" derivedContent="Section 3.1"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">grant_request_endpoint</td>
                <td align="left" colspan="1" rowspan="1">string</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="discovery" format="default" sectionFormat="of" derivedContent="Section 3.1"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">key_proofs_supported</td>
                <td align="left" colspan="1" rowspan="1">array of strings</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="discovery" format="default" sectionFormat="of" derivedContent="Section 3.1"/> of RFC 9767</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="IANA-error-code" numbered="true" removeInRFC="false" toc="include" pn="section-5.9">
        <name slugifiedName="name-gnap-rs-facing-error-codes">GNAP RS-Facing Error Codes</name>
        <t indent="0" pn="section-5.9-1">This document defines a set of errors that the AS can return to the RS, for which IANA has created and maintains a new registry titled "GNAP RS-Facing Error Codes". Initial values for this registry are given in <xref target="IANA-error-code-contents" format="default" sectionFormat="of" derivedContent="Section 5.9.2"/>. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.</t>
        <t indent="0" pn="section-5.9-2">The DE is expected to ensure that:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.9-3">
          <li pn="section-5.9-3.1">
            <t indent="0" pn="section-5.9-3.1.1">all registrations follow the template presented in <xref target="IANA-error-code-template" format="default" sectionFormat="of" derivedContent="Section 5.9.1"/>.</t>
          </li>
          <li pn="section-5.9-3.2">
            <t indent="0" pn="section-5.9-3.2.1">the error response is sufficiently unique from other errors to provide actionable information to the client instance.</t>
          </li>
          <li pn="section-5.9-3.3">
            <t indent="0" pn="section-5.9-3.3.1">the definition of the error response specifies all conditions in which the error response is returned and what the client instance's expected action is.</t>
          </li>
        </ul>
        <section anchor="IANA-error-code-template" numbered="true" removeInRFC="false" toc="include" pn="section-5.9.1">
          <name slugifiedName="name-registration-template">Registration Template</name>
          <dl newline="false" spacing="compact" indent="3" pn="section-5.9.1-1">
            <dt pn="section-5.9.1-1.1">Error:</dt>
            <dd pn="section-5.9.1-1.2">
              A unique string code for the error.
            </dd>
            <dt pn="section-5.9.1-1.3">Reference:</dt>
            <dd pn="section-5.9.1-1.4">
              Reference to the document(s) that specifies the
  value, preferably including a URI that can be used
  to retrieve a copy of the document(s). An indication of the
  relevant sections may also be included but is not required.
            </dd>
          </dl>
        </section>
        <section anchor="IANA-error-code-contents" numbered="true" removeInRFC="false" toc="include" pn="section-5.9.2">
          <name slugifiedName="name-initial-contents">Initial Contents</name>
          <table align="center" pn="table-7">
            <name slugifiedName="name-initial-contents-of-the-gnap-rs-">Initial Contents of the GNAP RS-Facing Error Codes Registry</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Error</th>
                <th align="left" colspan="1" rowspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">invalid_request</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="response-error" format="default" sectionFormat="of" derivedContent="Section 3.5"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">invalid_resource_server</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="response-error" format="default" sectionFormat="of" derivedContent="Section 3.5"/> of RFC 9767</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">invalid_access</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="response-error" format="default" sectionFormat="of" derivedContent="Section 3.5"/> of RFC 9767</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
    </section>
    <section anchor="Security" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">In addition to the normative requirements in this document and in <xref target="RFC9635" format="default" sectionFormat="of" derivedContent="GNAP"/>, implementers are
strongly encouraged to consider the following additional security considerations in implementations
and deployments of GNAP.</t>
      <section anchor="security-tls" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-tls-protection-in-transit">TLS Protection in Transit</name>
        <t indent="0" pn="section-6.1-1">All requests in GNAP made over untrusted network connections have to be made over TLS as outlined in <xref target="BCP195" format="default" sectionFormat="of" derivedContent="BCP195"/>
to protect the contents of the request and response from manipulation and interception by an attacker.
This includes all requests from a client instance to the RS and all requests from the RS to an AS.</t>
      </section>
      <section anchor="security-token-validation" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-token-validation">Token Validation</name>
        <t indent="0" pn="section-6.2-1">The RS has a responsibility to validate the incoming access token in a manner consistent with its deployment.
For self-contained stateless tokens such as those described in <xref target="token-format" format="default" sectionFormat="of" derivedContent="Section 2.2"/>, this consists of actions such
as validating the token's signature and ensuring the relevant fields and results are appropriate for the
request being made. For reference-style tokens or tokens that are otherwise opaque to the RS, the token introspection
RS-facing API can be used to provide updated information about the state of the token, as described in <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.</t>
        <t indent="0" pn="section-6.2-2">The RS needs to validate that a token:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-3">
          <li pn="section-6.2-3.1">
            <t indent="0" pn="section-6.2-3.1.1">is intended for this RS (audience restriction)</t>
          </li>
          <li pn="section-6.2-3.2">
            <t indent="0" pn="section-6.2-3.2.1">is presented using the appropriate key for the token (see also <xref target="security-key-proof" format="default" sectionFormat="of" derivedContent="Section 6.4"/>)</t>
          </li>
          <li pn="section-6.2-3.3">
            <t indent="0" pn="section-6.2-3.3.1">identifies an appropriate subject to access the resource (usually this is the resource owner who authorized the token's issuance)</t>
          </li>
          <li pn="section-6.2-3.4">
            <t indent="0" pn="section-6.2-3.4.1">is issued by a trusted AS for this resource</t>
          </li>
        </ul>
        <t indent="0" pn="section-6.2-4">Even though key proofing mechanisms have to cover the value of the token, validating the key proofing alone
is not sufficient to protect a request to an RS.
If an RS validates only the presentation method as described in <xref target="security-key-proof" format="default" sectionFormat="of" derivedContent="Section 6.4"/> without validating the
token itself, an attacker could use a compromised key or a confused deputy to make arbitrary calls to the RS
beyond what has been authorized by the RO.</t>
      </section>
      <section anchor="security-token-cache" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-caching-token-validation-re">Caching Token Validation Result</name>
        <t indent="0" pn="section-6.3-1">Since token validation can be an expensive process, requiring either cryptographic operations or network calls to an introspection
service as described in <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/>, an RS could cache the results of token validation for a particular token.
The trade-off for using a cached validation for a token presents an important decision space for implementers: relying on a cached validation result
increases performance and lowers processing overhead, but it comes at the expense of the liveness and accuracy of the information
in the cache. While a cached value is in use at the RS, an attacker could present a revoked token and have it accepted by the RS.</t>
        <t indent="0" pn="section-6.3-2">As with any cache, the consistency of this cache can be managed in a variety of ways. One of the most simple
methods is managing the lifetime of the cache in order to balance the performance and security properties.
If the cache is too long, an attacker has a larger window in which to use a revoked token. If the window is too short, the benefits of using the cache are diminished.
It is also possible that an AS could send a proactive signal to the RS to invalidate revoked access tokens, though such a mechanism
is outside the scope of this specification.</t>
      </section>
      <section anchor="security-key-proof" numbered="true" removeInRFC="false" toc="include" pn="section-6.4">
        <name slugifiedName="name-key-proof-validation">Key Proof Validation</name>
        <t indent="0" pn="section-6.4-1">For key-bound access tokens, the proofing method needs to be validated alongside the value of the token itself, as described in <xref target="security-token-validation" format="default" sectionFormat="of" derivedContent="Section 6.2"/>.
The process of validation is defined by the key proofing method, as described in <xref section="7.3" sectionFormat="of" target="RFC9635" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9635#section-7.3" derivedContent="GNAP"/>.</t>
        <t indent="0" pn="section-6.4-2">If the proofing method is not validated, an attacker could use a compromised token without access to the token's bound key.</t>
        <t indent="0" pn="section-6.4-3">The RS also needs to ensure that the proofing method is appropriate for the key associated with the token, including any choice of algorithm or identifiers.</t>
        <t indent="0" pn="section-6.4-4">The proofing should be validated independently on each request to the RS, particularly as aspects of the call could vary.
As such, the RS should never cache the results of a proof validation from one message and apply it to a subsequent message.</t>
      </section>
      <section anchor="token-exfiltration" numbered="true" removeInRFC="false" toc="include" pn="section-6.5">
        <name slugifiedName="name-token-exfiltration">Token Exfiltration</name>
        <t indent="0" pn="section-6.5-1">Since the RS sees the token value, it is possible for a compromised RS to leak that value to an attacker.
As such, the RS needs to protect token values as sensitive information and protect them from exfiltration.</t>
        <t indent="0" pn="section-6.5-2">This is especially problematic with bearer tokens and tokens bound to a shared key, since an RS has access
to all information necessary to create a new, valid request using the token in question.</t>
      </section>
      <section anchor="security-token-reuse-by-rs" numbered="true" removeInRFC="false" toc="include" pn="section-6.6">
        <name slugifiedName="name-token-reuse-by-an-rs">Token Reuse by an RS</name>
        <t indent="0" pn="section-6.6-1">If the access token is a bearer token, or the RS has access to the key material needed to present the token,
the RS could be tricked into reusing an access token presented to it by a client. While it is possible to build
a system that makes use of this artifact as a feature, it is safer to exchange the incoming access token for
another contextual token for use by the RS, as described in <xref target="token-chaining" format="default" sectionFormat="of" derivedContent="Section 4"/>. This access token can be bound
to the RS's own keys and limited to access needed by the RS, instead of the full set of rights associated with
the token issued to the client instance.</t>
      </section>
      <section anchor="token-format-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-6.7">
        <name slugifiedName="name-token-format-considerations">Token Format Considerations</name>
        <t indent="0" pn="section-6.7-1">With formatted tokens, the format of the token is likely to have its own considerations, and the RS needs
to follow any such considerations during the token validation process. The application and scope of
these considerations is specific to the format and outside the scope of this specification.</t>
      </section>
      <section anchor="over-sharing-token-contents" numbered="true" removeInRFC="false" toc="include" pn="section-6.8">
        <name slugifiedName="name-oversharing-token-contents">Oversharing Token Contents</name>
        <t indent="0" pn="section-6.8-1">The contents of the access token model divulge information about the access token's context and rights to the RS.
This is true whether the contents are parsed from the token itself or sent in an introspection response.</t>
        <t indent="0" pn="section-6.8-2">It's likely that every RS does not need to know all details of the token model, especially in systems where
a single access token is usable across multiple RSs. An attacker could use this to gain information about
the larger system by compromising only one RS. By limiting the information available to only
that which is relevant to a specific RS, such as using a limited introspection reply as defined in <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/>,
a system can follow the principle of least disclosure to each RS.</t>
      </section>
      <section anchor="resource-references" numbered="true" removeInRFC="false" toc="include" pn="section-6.9">
        <name slugifiedName="name-resource-references">Resource References</name>
        <t indent="0" pn="section-6.9-1">Resource references, as returned by the protocol in <xref target="rs-register-resource-handle" format="default" sectionFormat="of" derivedContent="Section 3.4"/>, are intended to be opaque to
both the RS and the client. However, since they are under the control of the AS, the AS can put whatever content
it wants into the reference value. This value could unintentionally disclose system structure or other internal
details if it was processed by an unintended party. Furthermore, such patterns could lead to the client software and
RS depending on certain structures being present in the reference value, which diminishes the separation of concerns
of the different roles in a GNAP system.</t>
        <t indent="0" pn="section-6.9-2">To mitigate this, the AS should only use fully random or encrypted values for resource references.</t>
      </section>
      <section anchor="token-re-issuance-from-an-untrusted-as" numbered="true" removeInRFC="false" toc="include" pn="section-6.10">
        <name slugifiedName="name-token-reissuance-from-an-un">Token Reissuance from an Untrusted AS</name>
        <t indent="0" pn="section-6.10-1">It is possible for an attacker's client instance to issue its own tokens to another client instance, acting as
an AS that the second client instance has chosen to trust. If the token is a bearer token or the reissuance
is bound using an AS-provided key, the target client instance will not be able to tell that the token was originally
issued by the valid AS. This process allows an attacker to insert their own session and rights into an unsuspecting
client instance in the guise of a valid token for the attacker that appears to have been issued to the target
client instance on behalf of its own RO.</t>
        <t indent="0" pn="section-6.10-2">This attack is predicated on a misconfiguration with the targeted client, as it has been configured to get tokens
from the attacker's AS and use those tokens with the target RS, which has no association with the attacker's AS.
However, since the token is ultimately coming from the trusted AS and is being presented with a valid key,
the RS has no way of telling that the token was passed through an intermediary.</t>
        <t indent="0" pn="section-6.10-3">To mitigate this, the RS can publish its association with the trusted AS through either discovery or documentation.
Therefore, a client properly following this association would only go directly to the trusted RS for
	access tokens for the RS.</t>
        <t indent="0" pn="section-6.10-4">Furthermore, limiting the use of bearer tokens and AS-provided keys to only highly trusted ASs in certain circumstances prevents the attacker from being able to willingly exfiltrate their token to an unsuspecting client instance.</t>
      </section>
      <section anchor="introspection-of-token-keys" numbered="true" removeInRFC="false" toc="include" pn="section-6.11">
        <name slugifiedName="name-introspection-of-token-keys">Introspection of Token Keys</name>
        <t indent="0" pn="section-6.11-1">The introspection response defined in <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/> provides a means for the AS to tell the RS what key material is needed to validate the key proof of the request. Capture of the introspection response can expose
these security keys to an attacker. In the case of asymmetric cryptography, only the public key is exposed,
and the token cannot be reused by the attacker based on this result alone. This could potentially divulge
information about the client instance that was unknown otherwise.</t>
        <t indent="0" pn="section-6.11-2">If an access token is bound to a symmetric key, the RS will need access to the full key value in order to validate
the key proof of the request, as described in <xref target="security-key-proof" format="default" sectionFormat="of" derivedContent="Section 6.4"/>. However, divulging the key
material to the RS also gives the RS the ability to create a new request with the token.
In this circumstance, the RS is under similar risk of token exfiltration and
reuse as a bearer token, as described in <xref target="security-token-reuse-by-rs" format="default" sectionFormat="of" derivedContent="Section 6.6"/>. Consequently, symmetric
keys should only be used in systems where the RS can be fully trusted to not create a new request with
tokens presented to it.</t>
      </section>
      <section anchor="security-rs-registration" numbered="true" removeInRFC="false" toc="include" pn="section-6.12">
        <name slugifiedName="name-rs-registration-and-managem">RS Registration and Management</name>
        <t indent="0" pn="section-6.12-1">Most functions of the RS-facing API in <xref target="rs-facing-api" format="default" sectionFormat="of" derivedContent="Section 3"/> are protected by requiring the RS to
present proof of a signing key along with the request, in order to identify the RS making the
call, potentially coupled with an AS-specific access token.
This practice allows the AS to differentially respond to API calls to different RSs, such as
answering introspection calls with only the access rights relevant to a given RS instead of
all access rights an access token could be good for.</t>
        <t indent="0" pn="section-6.12-2">While the means by which an RS and its keys become known to the AS is out of scope for this
specification, it is anticipated that common practice will be to statically register an
RS, allowing it to protect specific resources or certain classes of resources.
Fundamentally, the RS can only offer the resources that it serves. However, a rogue AS could
attempt to register a set of resources that mimics a different RS in order to solicit an access
token that is usable at the target RS. If the access token is a bearer token or is bound to a symmetric
key that is known to the RS, then the attacker's RS gains the ability and knowledge needed
to use that token elsewhere.</t>
        <t indent="0" pn="section-6.12-3">In some ecosystems, dynamic registration of an RS and its associated resources is feasible.
In such systems, the identity of the RS could be conveyed by a URI passed in the <tt>location</tt> field
of an access rights request, thereby allowing the AS to limit the view the RS has into the
larger system.</t>
      </section>
    </section>
    <section anchor="Privacy" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <section anchor="token-contents" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-token-contents">Token Contents</name>
        <t indent="0" pn="section-7.1-1">The contents of the access token could potentially contain personal information about the end user, RO, or other parties.
This is true whether the contents are parsed from the token itself or sent in an introspection response.</t>
        <t indent="0" pn="section-7.1-2">While an RS will sometimes need this information for processing, it's often the case that an RS is exposed to these
details only in passing, and not intentionally. For example, consider a client that has been issued an access token that is
usable for both medical and non-medical APIs. If this access token contains a medical record number to facilitate the
RS serving the medical API, then any RS for a non-medical API would also learn the user's medical record number
in the process, even though that API has no need to make such a correlation.</t>
        <t indent="0" pn="section-7.1-3">To mitigate this, a formatted token could contain separate sections targeted to different RSs to segregate data.
Alternatively, token introspection can be used to limit the data returned to each RS, as defined in <xref target="introspection" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.</t>
      </section>
      <section anchor="token-use-disclosure-through-introspection" numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
        <name slugifiedName="name-token-use-disclosure-throug">Token Use Disclosure through Introspection</name>
        <t indent="0" pn="section-7.2-1">When introspection is used by an RS, the AS is made aware of a particular token being used at a particular RS.
When the RS is a separate system, the AS would not otherwise have insight into this action. This can potentially
lead to the AS learning about patterns and actions of particular end users by watching which RSs are accessed
and when.</t>
      </section>
      <section anchor="mapping-a-user-to-an-as" numbered="true" removeInRFC="false" toc="include" pn="section-7.3">
        <name slugifiedName="name-mapping-a-user-to-an-as">Mapping a User to an AS</name>
        <t indent="0" pn="section-7.3-1">When the client instance receives information about the protecting AS from an RS, it can be used to
derive information about the resources being protected without releasing the resources themselves. For example,
if a medical record is protected by a personal AS, an untrusted client could call an RS to discover the location
of the AS protecting the record. Since the AS is tied strongly to a single RO, the untrusted and unauthorized client
software can gain information about the resource being protected without accessing the record itself.</t>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="RFC9635" to="GNAP"/>
    <displayreference target="RFC7519" to="JWT"/>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-8.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>
        <reference anchor="RFC9635" target="https://www.rfc-editor.org/info/rfc9635" quoteTitle="true" derivedAnchor="GNAP">
          <front>
            <title>Grant Negotiation and Authorization Protocol (GNAP)</title>
            <author fullname="J. Richer" initials="J." role="editor" surname="Richer"/>
            <author fullname="F. Imbault" initials="F." surname="Imbault"/>
            <date month="October" year="2024"/>
            <abstract>
              <t indent="0">The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software and conveying the results and artifacts of that delegation to the software. This delegation can include access to a set of APIs as well as subject information passed directly to the software.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9635"/>
          <seriesInfo name="DOI" value="10.17487/RFC9635"/>
        </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="RFC3986" target="https://www.rfc-editor.org/info/rfc3986" quoteTitle="true" derivedAnchor="RFC3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="January" year="2005"/>
            <abstract>
              <t indent="0">A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </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="RFC8792" target="https://www.rfc-editor.org/info/rfc8792" quoteTitle="true" derivedAnchor="RFC8792">
          <front>
            <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="June" year="2020"/>
            <abstract>
              <t indent="0">This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8792"/>
          <seriesInfo name="DOI" value="10.17487/RFC8792"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="BISCUIT" target="https://www.biscuitsec.org/" quoteTitle="true" derivedAnchor="BISCUIT">
          <front>
            <title>Biscuit Authorization</title>
            <author>
              <organization showOnFrontPage="true">Biscuit</organization>
            </author>
          </front>
        </reference>
        <reference anchor="MACAROON" target="https://www.ndss-symposium.org/ndss2014/               ndss-2014-programme/macaroons-cookies-contextual-caveats-               decentralized-authorization-cloud/" quoteTitle="true" derivedAnchor="MACAROON">
          <front>
            <title>Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud</title>
            <author fullname="Arnar Birgisson"/>
            <author fullname="Joe Gibbs Politz"/>
            <author fullname="Ulfar Erlingsson"/>
            <author fullname="Ankur Taly"/>
            <author fullname="Michael Vrable"/>
            <author fullname="Mark Lentczner"/>
            <date month="February" year="2014"/>
          </front>
          <refcontent>NDSS Symposium 2014</refcontent>
          <seriesInfo name="DOI" value="10.14722/ndss.2014.23212"/>
        </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="ZCAPLD" target="https://w3c-ccg.github.io/zcap-spec/" quoteTitle="true" derivedAnchor="ZCAPLD">
          <front>
            <title>Authorization Capabilities for Linked Data v0.3</title>
            <author fullname="Christine Lemmer-Webber" role="editor"/>
            <author fullname="Manu Sporny" role="editor"/>
            <date month="January" year="2023"/>
          </front>
          <refcontent>W3C Draft Community Group Report</refcontent>
        </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 editors would like to thank the following
      individuals for their reviews, feedback, implementations, and contributions:
      <contact fullname="Aaron Parecki"/>, <contact fullname="Adrian       Gropper"/>, <contact fullname="Andrii Deinega"/>, <contact fullname="Annabelle Backman"/>, <contact fullname="Dmitry Barinov"/>,
      <contact fullname="Fabien Imbault"/>, <contact fullname="Florian       Helmschmidt"/>, <contact fullname="George Fletcher"/>, <contact fullname="Justin Richer"/>, <contact fullname="Kathleen Moriarty"/>,
      <contact fullname="Leif Johansson"/>, <contact fullname="Mike Varley"/>,
      <contact fullname="Nat Sakimura"/>, <contact fullname="Takahiko       Kawasaki"/>, and <contact fullname="Yaron Sheffer"/>.</t>
      <t indent="0" pn="section-appendix.a-2">Additionally, the editors want to acknowledge the immense contributions of
      <contact fullname="Aaron Parecki"/> to the content of this document. We
      thank him for his insight, input, and hard work, without which GNAP
      would not have grown to what it is.</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 initials="J." surname="Richer" fullname="Justin Richer" role="editor">
        <organization showOnFrontPage="true">Bespoke Engineering</organization>
        <address>
          <email>ietf@justin.richer.org</email>
          <uri>https://bspk.io/</uri>
        </address>
      </author>
      <author initials="F." surname="Imbault" fullname="Fabien Imbault">
        <organization showOnFrontPage="true">acert.io</organization>
        <address>
          <email>fabien.imbault@acert.io</email>
          <uri>https://acert.io/</uri>
        </address>
      </author>
    </section>
  </back>
</rfc>
