<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-privacypass-auth-scheme-15" number="9577" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" prepTime="2024-06-13T15:32:52" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-privacypass-auth-scheme-15" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9577" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Privacy Pass Authentication">The Privacy Pass HTTP Authentication Scheme</title>
    <seriesInfo name="RFC" value="9577" stream="IETF"/>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization showOnFrontPage="true">Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino</city>
          <region>California</region>
          <code>95014</code>
          <country>United States of America</country>
        </postal>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <author initials="S." surname="Valdez" fullname="Steven Valdez">
      <organization showOnFrontPage="true">Google LLC</organization>
      <address>
        <email>svaldez@chromium.org</email>
      </address>
    </author>
    <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
      <organization showOnFrontPage="true">Cloudflare</organization>
      <address>
        <email>caw@heapingbits.net</email>
      </address>
    </author>
    <date month="06" year="2024"/>
    <area>sec</area>
    <workgroup>privacypass</workgroup>
    <keyword>anonymous</keyword>
    <keyword>authorization</keyword>
    <keyword>crypto</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines an HTTP authentication scheme for Privacy Pass,
a privacy-preserving authentication mechanism used for authorization.
The authentication scheme specified in this document can be used by Clients
to redeem Privacy Pass tokens with an Origin. It can also be used by
Origins to challenge Clients to present Privacy Pass tokens.</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/rfc9577" 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) 2024 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-http-authentication-scheme">HTTP Authentication Scheme</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-token-challenge">Token Challenge</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-token-challenge-structure">Token Challenge Structure</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-sending-token-challenges">Sending Token Challenges</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-processing-token-challenges">Processing Token Challenges</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-token-caching">Token Caching</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-token-redemption">Token Redemption</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.2.2">
                  <li pn="section-toc.1-1.2.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.2.2.2.2.1.1"><xref derivedContent="2.2.1" format="counter" sectionFormat="of" target="section-2.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-structure">Token Structure</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.2.2.2.2.2.1"><xref derivedContent="2.2.2" format="counter" sectionFormat="of" target="section-2.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sending-tokens">Sending Tokens</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.2.2.2.2.3.1"><xref derivedContent="2.2.3" format="counter" sectionFormat="of" target="section-2.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-verification">Token Verification</xref></t>
                  </li>
                </ul>
              </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-client-behavior">Client Behavior</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-choosing-to-redeem-tokens">Choosing to Redeem Tokens</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-choosing-between-multiple-c">Choosing between Multiple Challenges</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-origin-behavior">Origin Behavior</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-greasing">Greasing</xref></t>
              </li>
            </ul>
          </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-security-considerations">Security 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-randomness-requirements">Randomness Requirements</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-replay-attacks">Replay Attacks</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-reflection-attacks">Reflection Attacks</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-exhaustion-attacks">Token Exhaustion Attacks</xref></t>
              </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-timing-correlation-attacks">Timing Correlation Attacks</xref></t>
              </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-cross-context-linkability-a">Cross-Context Linkability Attacks</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA 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-authentication-scheme">Authentication Scheme</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-privacy-pass-token-types-re">Privacy Pass Token Types Registry</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.2.2">
                  <li pn="section-toc.1-1.6.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.1.1"><xref derivedContent="6.2.1" format="counter" sectionFormat="of" target="section-6.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reserved-values">Reserved Values</xref></t>
                  </li>
                </ul>
              </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-references">References</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-normative-references">Normative References</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-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-vectors">Test Vectors</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="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-challenge-and-redemption-st">Challenge and Redemption Structure Test Vectors</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="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-http-header-test-vectors">HTTP Header Test Vectors</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.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">Privacy Pass tokens are unlinkable authenticators that can be used to
anonymously authorize a Client (see
<xref target="RFC9576" format="default" sectionFormat="of" derivedContent="ARCHITECTURE"/>).
Tokens are generated by token Issuers, on the basis of authentication,
attestation, or some previous action such as solving a CAPTCHA. A Client
possessing such a token is able to prove that it was able to get a token
issued, without allowing the relying party redeeming the Client's token
(the Origin) to link it with the issuance flow.</t>
      <t indent="0" pn="section-1-2">Different types of authenticators, using different token issuance protocols,
can be used as Privacy Pass tokens.</t>
      <t indent="0" pn="section-1-3">This document defines a common HTTP authentication scheme
(<xref section="11" sectionFormat="comma" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-11" derivedContent="HTTP"/>), "PrivateToken", that allows Clients to redeem various
kinds of Privacy Pass tokens.</t>
      <t indent="0" pn="section-1-4">Clients and relying parties (Origins) interact using this scheme to perform the
token challenge and token redemption flow. In particular, Origins challenge
Clients for a token with an HTTP authentication challenge (using the
<tt>WWW-Authenticate</tt> response header field). Clients can then react to that
challenge by issuing a new request with a corresponding token (using the <tt>Authorization</tt>
request header field). Clients generate tokens that match the Origin's token
challenge by running one of the token issuance protocols defined in
<xref target="RFC9578" format="default" sectionFormat="of" derivedContent="ISSUANCE"/>. The act of presenting a token in an
<tt>Authorization</tt> request header field is referred to as "token redemption". This
interaction between the Client and Origin is shown below.</t>
      <figure anchor="fig-overview" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-challenge-and-redemption-pr">Challenge and Redemption Protocol Flow</name>
        <artset pn="section-1-5.1">
          <artwork type="svg" align="left" pn="section-1-5.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="192" width="456" viewBox="0 0 456 192" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
              <path d="M 8,32 L 8,64" fill="none" stroke="black"/>
              <path d="M 40,64 L 40,176" fill="none" stroke="black"/>
              <path d="M 80,32 L 80,64" fill="none" stroke="black"/>
              <path d="M 328,32 L 328,64" fill="none" stroke="black"/>
              <path d="M 360,64 L 360,112" fill="none" stroke="black"/>
              <path d="M 360,144 L 360,176" fill="none" stroke="black"/>
              <path d="M 400,32 L 400,64" fill="none" stroke="black"/>
              <path d="M 8,32 L 80,32" fill="none" stroke="black"/>
              <path d="M 328,32 L 400,32" fill="none" stroke="black"/>
              <path d="M 8,64 L 80,64" fill="none" stroke="black"/>
              <path d="M 328,64 L 400,64" fill="none" stroke="black"/>
              <path d="M 40,96 L 56,96" fill="none" stroke="black"/>
              <path d="M 336,96 L 352,96" fill="none" stroke="black"/>
              <path d="M 48,160 L 96,160" fill="none" stroke="black"/>
              <path d="M 280,160 L 360,160" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="360,96 348,90.4 348,101.6" fill="black" transform="rotate(0,352,96)"/>
              <polygon class="arrowhead" points="56,160 44,154.4 44,165.6" fill="black" transform="rotate(180,48,160)"/>
              <g class="text">
                <text x="44" y="52">Origin</text>
                <text x="364" y="52">Client</text>
                <text x="136" y="100">WWW-Authenticate:</text>
                <text x="268" y="100">TokenChallenge</text>
                <text x="284" y="132">(Run</text>
                <text x="340" y="132">issuance</text>
                <text x="416" y="132">protocol)</text>
                <text x="164" y="164">Authorization:</text>
                <text x="248" y="164">token</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="left" pn="section-1-5.1.2">
+--------+                              +--------+
| Origin |                              | Client |
+---+----+                              +---+----+
    |                                       |
    +-- WWW-Authenticate: TokenChallenge --&gt;|
    |                                       |
    |                            (Run issuance protocol)
    |                                       |
    |&lt;------ Authorization: token ----------+
    |                                       |
</artwork>
        </artset>
      </figure>
      <t indent="0" pn="section-1-6">In addition to working with different token issuance protocols, this scheme
optionally supports the use of tokens that are associated with Origin-chosen
contexts and specific Origin names. Relying parties that request and redeem
tokens can choose a specific kind of token, as appropriate for its use case.
These options (1) allow for different deployment models to prevent double-spending and (2) allow for both interactive (online challenges) and non-interactive (pre-fetched) tokens.</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">Unless otherwise specified, this document encodes protocol messages in TLS
notation from
<xref target="RFC8446" sectionFormat="comma" section="3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-3" derivedContent="TLS13"/>.</t>
        <t indent="0" pn="section-1.1-3">This document uses the terms "Client", "Origin", "Issuer", "issuance protocol",
and "Token" as defined in <xref target="RFC9576" format="default" sectionFormat="of" derivedContent="ARCHITECTURE"/>. It additionally
uses the following terms in more specific ways:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-1.1-4">
          <dt pn="section-1.1-4.1">Issuer key:</dt>
          <dd pn="section-1.1-4.2">Keying material that can be used with an issuance protocol
to create a signed token.</dd>
          <dt pn="section-1.1-4.3">Token challenge:</dt>
          <dd pn="section-1.1-4.4">A request for tokens sent from an Origin to a Client, using
the <tt>WWW-Authenticate</tt> HTTP header field. This challenge identifies a specific
token Issuer and issuance protocol. Token challenges optionally include
one or both of the following: a redemption context (see <xref target="context-construction" format="default" sectionFormat="of" derivedContent="Section 2.1.1.2"/>) and
a list of associated Origins. These optional values can then
be bound to the token that is issued.</dd>
          <dt pn="section-1.1-4.5">Token redemption:</dt>
          <dd pn="section-1.1-4.6">An action by which a Client presents a token to an Origin
in an HTTP request, using the <tt>Authorization</tt> HTTP header field.</dd>
        </dl>
      </section>
    </section>
    <section anchor="challenge-redemption" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-http-authentication-scheme">HTTP Authentication Scheme</name>
      <t indent="0" pn="section-2-1">Token redemption is performed using HTTP authentication
(<xref section="11" sectionFormat="comma" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-11" derivedContent="HTTP"/>), with the scheme "PrivateToken". Origins challenge
Clients to present a token from a specific Issuer (<xref target="challenge" format="default" sectionFormat="of" derivedContent="Section 2.1"/>). Once a
Client has received a token from that Issuer or already has a valid token
available, it presents the token to the Origin (<xref target="redemption" format="default" sectionFormat="of" derivedContent="Section 2.2"/>). The process of
presenting a token as authentication to an Origin is also referred to
as "spending" a token.</t>
      <t indent="0" pn="section-2-2">In order to prevent linkability across different transactions, Clients
will often present a particular "PrivateToken" only once. Origins can link multiple
transactions to the same Client if that Client spends the same token value more
than once. As such, Origins ought to expect at most one unique token
value, carried in one request, for each challenge.</t>
      <t indent="0" pn="section-2-3">The rest of this section describes the token challenge and redemption interactions
in more detail.</t>
      <section anchor="challenge" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-token-challenge">Token Challenge</name>
        <t indent="0" pn="section-2.1-1">Origins send a token challenge to Clients in a <tt>WWW-Authenticate</tt> header field
with the "PrivateToken" scheme. This authentication scheme has two mandatory parameters:
one containing a token challenge and another containing the <tt>token-key</tt> used for
producing (and verifying) a corresponding token.</t>
        <t indent="0" pn="section-2.1-2">Origins that support the "PrivateToken" authentication scheme need to handle
the following tasks in constructing the <tt>WWW-Authenticate</tt> header field:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2.1-3"><li pn="section-2.1-3.1" derivedCounter="1.">Select which Issuer to use, and configure the Issuer name and <tt>token-key</tt> to
include in <tt>WWW-Authenticate</tt> token challenges. The Issuer name is included in
the token challenge, and the Issuer <tt>token-key</tt> is used to populate the
<tt>WWW-Authenticate</tt> header parameter.</li>
          <li pn="section-2.1-3.2" derivedCounter="2.">Determine a redemption context construction to include in the
token challenge, as discussed in <xref target="context-construction" format="default" sectionFormat="of" derivedContent="Section 2.1.1.2"/>.</li>
          <li pn="section-2.1-3.3" derivedCounter="3.">Select the Origin information to include in the token challenge. This can
be empty to allow fully cross-Origin tokens, a single Origin name that
matches the Origin itself for per-Origin tokens, or a list of Origin names
containing the Origin itself. See <xref section="3.4" sectionFormat="of" target="RFC9576" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9576#section-3.4" derivedContent="ARCHITECTURE"/> for more
information about the difference between cross-Origin and per-Origin tokens.</li>
        </ol>
        <t indent="0" pn="section-2.1-4">Once these decisions are made, Origins construct the <tt>WWW-Authenticate</tt> header
by first constructing the token challenge as described in <xref target="challenge-structure" format="default" sectionFormat="of" derivedContent="Section 2.1.1"/>.
Origins send challenges as described in <xref target="send-challenge" format="default" sectionFormat="of" derivedContent="Section 2.1.2"/>, and Clients process
them as described in Sections <xref target="process-challenge" format="counter" sectionFormat="of" derivedContent="2.1.3"/> and <xref target="caching" format="counter" sectionFormat="of" derivedContent="2.1.4"/>.</t>
        <section anchor="challenge-structure" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.1">
          <name slugifiedName="name-token-challenge-structure">Token Challenge Structure</name>
          <t indent="0" pn="section-2.1.1-1">This document defines the default challenge structure that can be used across
token types, although future token types <bcp14>MAY</bcp14> extend or modify the structure
of the challenge; see <xref target="token-types" format="default" sectionFormat="of" derivedContent="Section 6.2"/> for the registry information
that establishes and defines the relationship between <tt>token_type</tt> and the
contents of the TokenChallenge message.</t>
          <t indent="0" pn="section-2.1.1-2">All token challenges <bcp14>MUST</bcp14> begin with a 2-octet integer that defines the
token type, in network byte order. This type indicates the issuance protocol
used to generate the token and determines the structure and semantics of the rest of
the structure. Values are registered in an IANA registry; see <xref target="token-types" format="default" sectionFormat="of" derivedContent="Section 6.2"/>. Clients <bcp14>MUST</bcp14>
ignore challenges with token types they do not support.</t>
          <t indent="0" pn="section-2.1.1-3">Even when a given token type uses the default challenge structure,
the requirements on the presence or interpretation of the fields can differ
across token types. For example, some token types might require that <tt>origin_info</tt>
is non-empty, while others allow it to be empty.</t>
          <t indent="0" pn="section-2.1.1-4">The default TokenChallenge message has the following structure:</t>
          <artwork align="left" pn="section-2.1.1-5">
struct {
    uint16_t token_type;
    opaque issuer_name&lt;1..2^16-1&gt;;
    opaque redemption_context&lt;0..32&gt;;
    opaque origin_info&lt;0..2^16-1&gt;;
} TokenChallenge;
</artwork>
          <t indent="0" pn="section-2.1.1-6">The structure fields are defined as follows:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.1.1-7">
            <li pn="section-2.1.1-7.1">
              <tt>token_type</tt> is a 2-octet integer, in network byte order, as described
above.</li>
            <li pn="section-2.1.1-7.2">
              <tt>issuer_name</tt> is an ASCII string that identifies the Issuer, using the format of a
server name as defined in <xref target="server-name" format="default" sectionFormat="of" derivedContent="Section 2.1.1.1"/>. This name identifies the Issuer that is allowed to
issue tokens that can be redeemed by this Origin. The field that stores this string in the challenge
is prefixed with a 2-octet integer indicating the length, in network byte order.</li>
            <li pn="section-2.1.1-7.3">
              <tt>redemption_context</tt> is a field that is either 0 or 32 bytes, prefixed with a single
octet indicating the length (either 0 or 32). If the value is non-empty, it is a 32-byte value
generated by the Origin that allows the Origin to require that Clients fetch tokens
bound to a specific context, as opposed to reusing tokens that were fetched for other
contexts. See <xref target="context-construction" format="default" sectionFormat="of" derivedContent="Section 2.1.1.2"/> for example contexts that might be useful in
practice. Challenges with <tt>redemption_context</tt> values of invalid lengths <bcp14>MUST</bcp14> be ignored.</li>
            <li pn="section-2.1.1-7.4">
              <tt>origin_info</tt> is an ASCII string that either is empty or contains one or more
Origin names that allow a token to be scoped to a specific set of Origins. Each
Origin name uses the format of a server name as defined in <xref target="server-name" format="default" sectionFormat="of" derivedContent="Section 2.1.1.1"/>. The string
is prefixed with a 2-octet integer indicating the length, in network byte order.
If empty, any non-Origin-specific token can be redeemed. If the string contains
multiple Origin names, they are delimited with commas (",") without any whitespace.
If this field is not empty, the Origin <bcp14>MUST</bcp14> include its own name as one of the
names in the list.</li>
          </ul>
          <t indent="0" pn="section-2.1.1-8">If <tt>origin_info</tt> contains multiple Origin names, this means the challenge is valid
for any of the Origins in the list, including the Origin that issued the challenge
(which must always be present in the list if it is non-empty; see <xref target="process-challenge" format="default" sectionFormat="of" derivedContent="Section 2.1.3"/>).
This can be useful in settings where Clients pre-fetch and cache tokens for a particular
challenge -- including the <tt>origin_info</tt> field -- and then later redeem these tokens
with one of the Origins in the list. See <xref target="caching" format="default" sectionFormat="of" derivedContent="Section 2.1.4"/> for more discussion about
token caching.</t>
          <section anchor="server-name" numbered="true" removeInRFC="false" toc="exclude" pn="section-2.1.1.1">
            <name slugifiedName="name-server-name-encoding">Server Name Encoding</name>
            <t indent="0" pn="section-2.1.1.1-1">Server names contained in a token challenge are ASCII strings that contain a hostname
and optional port, where the port is implied to be "443" if missing. The names use the
format of the authority portion of a URI as defined in <xref section="3.2" sectionFormat="of" target="RFC3986" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3986#section-3.2" derivedContent="URI"/>.
The names <bcp14>MUST NOT</bcp14> include a "userinfo" portion of an authority. For example, a valid
server name might be "issuer.example.com" or "issuer.example.com:8443",
but not "issuer@example.com".</t>
          </section>
          <section anchor="context-construction" numbered="true" removeInRFC="false" toc="exclude" pn="section-2.1.1.2">
            <name slugifiedName="name-redemption-context-construc">Redemption Context Construction</name>
            <t indent="0" pn="section-2.1.1.2-1">The TokenChallenge redemption context allows the Origin to determine the
context in which a given token can be redeemed. This value can be a unique
per-request nonce, constructed from 32 freshly generated random bytes. It
can also represent state or properties of the Client session. Some example
properties and methods for constructing the corresponding context are below.
This list is not exhaustive.</t>
            <dl spacing="normal" indent="3" newline="false" pn="section-2.1.1.2-2">
              <dt pn="section-2.1.1.2-2.1">Context bound to a given time window:</dt>
              <dd pn="section-2.1.1.2-2.2">Construct the redemption context as
F(current time window), where F is a pseudorandom function.</dd>
              <dt pn="section-2.1.1.2-2.3">Context bound to a Client network based on Autonomous System Number (ASN):</dt>
              <dd pn="section-2.1.1.2-2.4">Construct the redemption context as
F(Client ASN), where F is a pseudorandom function.</dd>
              <dt pn="section-2.1.1.2-2.5">Context bound to a given time window and Client network:</dt>
              <dd pn="section-2.1.1.2-2.6">Construct the redemption
context as F(current time window, Client ASN), where F is a pseudorandom function.</dd>
            </dl>
            <t indent="0" pn="section-2.1.1.2-3">Preventing double-spending on tokens requires the Origin to keep state
associated with the redemption context. An empty redemption context is not
bound to any property of the Client request, so state to prevent double-spending
needs to be stored and shared across all Origin servers that can accept tokens until
<tt>token-key</tt> expiration or rotation. For a non-empty redemption context, the
double-spend state only needs to be stored across the set of Origin servers that will
accept tokens with that redemption context.</t>
            <t indent="0" pn="section-2.1.1.2-4">Origins that share redemption contexts, i.e., by using the same redemption
context, choosing the same Issuer, and providing the same <tt>origin_info</tt> field in
the TokenChallenge, must necessarily share state required to enforce
double-spend prevention. Origins should consider the operational complexity of this
shared state before choosing to share redemption contexts. Failure to
successfully synchronize this state and use it for double-spend prevention can
allow Clients to redeem tokens to one Origin that were issued after an
interaction with another Origin that shares the context.</t>
          </section>
        </section>
        <section anchor="send-challenge" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.2">
          <name slugifiedName="name-sending-token-challenges">Sending Token Challenges</name>
          <t indent="0" pn="section-2.1.2-1">When used in an authentication challenge, the "PrivateToken" scheme uses the
following parameters:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.1.2-2">
            <li pn="section-2.1.2-2.1">
              <tt>challenge</tt>, which contains a base64url TokenChallenge value, encoded per <xref target="RFC4648" format="default" sectionFormat="of" derivedContent="RFC4648"/>. This document follows the default padding behavior described in
<xref section="3.2" sectionFormat="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-3.2" derivedContent="RFC4648"/>, so the base64url value <bcp14>MUST</bcp14> include padding.
As an authentication parameter (<tt>auth-param</tt> from <xref section="11.2" sectionFormat="comma" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-11.2" derivedContent="HTTP"/>),
the value can be either a token or a quoted-string and might be required to
be a quoted-string if the base64url string includes "=" characters. This
parameter is required for all challenges.</li>
            <li pn="section-2.1.2-2.2">
              <tt>token-key</tt>, which contains a base64url encoding of the public key for
use with the issuance protocol indicated by the challenge. See <xref target="RFC9578" format="default" sectionFormat="of" derivedContent="ISSUANCE"/>
for more information about how this public key is used by the issuance protocols
described in that specification. The encoding of
the public key is determined by the token type; see <xref target="token-types" format="default" sectionFormat="of" derivedContent="Section 6.2"/>.
As with <tt>challenge</tt>, the base64url value <bcp14>MUST</bcp14> include padding. As an
authentication parameter (<tt>auth-param</tt> from <xref section="11.2" sectionFormat="comma" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-11.2" derivedContent="HTTP"/>), the
value can be either a token or a quoted-string and might be required to be a
quoted-string if the base64url string includes "=" characters. This parameter
<bcp14>MAY</bcp14> be omitted in deployments where Clients are able to retrieve the Issuer key
using an out-of-band mechanism.</li>
            <li pn="section-2.1.2-2.3">
              <tt>max-age</tt>, which is an optional parameter that consists of the number of seconds for
which the challenge will be accepted by the Origin.</li>
          </ul>
          <t indent="0" pn="section-2.1.2-3">The header field <bcp14>MAY</bcp14> also include the standard <tt>realm</tt> parameter, if desired.
Issuance protocols <bcp14>MAY</bcp14> define other parameters, some of which might be required.
Clients <bcp14>MUST</bcp14> ignore parameters in challenges that are not defined for the issuance
protocol corresponding to the token type in the challenge.</t>
          <t indent="0" pn="section-2.1.2-4">As an example, the <tt>WWW-Authenticate</tt> header field could look like this:</t>
          <artwork align="left" pn="section-2.1.2-5">
WWW-Authenticate:
  PrivateToken challenge="abc...", token-key="123..."
</artwork>
          <section anchor="sending-multiple-token-challenges" numbered="true" removeInRFC="false" toc="exclude" pn="section-2.1.2.1">
            <name slugifiedName="name-sending-multiple-token-chal">Sending Multiple Token Challenges</name>
            <t indent="0" pn="section-2.1.2.1-1">It is possible for the <tt>WWW-Authenticate</tt> header field to include multiple
challenges (<xref section="11.6.1" sectionFormat="comma" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-11.6.1" derivedContent="HTTP"/>). This allows the Origin to indicate
support for different token types or different Issuers, or to include multiple redemption
contexts. For example, the <tt>WWW-Authenticate</tt> header field could look like this:</t>
            <artwork align="left" pn="section-2.1.2.1-2">
WWW-Authenticate:
  PrivateToken challenge="abc...", token-key="123...",
  PrivateToken challenge="def...", token-key="234..."
</artwork>
            <t indent="0" pn="section-2.1.2.1-3">Origins should only include challenges for different types of issuance
protocols with functionally equivalent properties. For instance, both issuance
protocols in <xref target="RFC9578" format="default" sectionFormat="of" derivedContent="ISSUANCE"/> have the same functional properties, albeit with
different mechanisms for verifying the resulting tokens during redemption.
Since Clients are free to choose which challenge they want to consume when
presented with options, mixing multiple challenges with different functional
properties for one use case is nonsensical. If the Origin has a preference
for one challenge over another (for example, if one uses a token type
that is faster to verify), it can sort it to be first in the list
of challenges as a hint to the Client.</t>
          </section>
        </section>
        <section anchor="process-challenge" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.3">
          <name slugifiedName="name-processing-token-challenges">Processing Token Challenges</name>
          <t indent="0" pn="section-2.1.3-1">Upon receipt of a challenge, a Client validates the TokenChallenge structure
before taking any action, such as fetching a new token or redeeming a token
in a new request. Validation requirements are as follows:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.1.3-2">
            <li pn="section-2.1.3-2.1">The <tt>token_type</tt> is recognized and supported by the Client;</li>
            <li pn="section-2.1.3-2.2">The TokenChallenge structure is well-formed; and</li>
            <li pn="section-2.1.3-2.3">If the <tt>origin_info</tt> field is non-empty, the name of the Origin that issued the
authentication challenge is included in the list of Origin names. Comparison
of the Origin name that issued the authentication challenge against elements
in the <tt>origin_info</tt> list is done via case-insensitive equality checks.</li>
          </ul>
          <t indent="0" pn="section-2.1.3-3">If validation fails, the Client <bcp14>MUST NOT</bcp14> fetch or redeem a token based on the
challenge. Clients <bcp14>MAY</bcp14> have further restrictions and requirements around
validating when a challenge is considered acceptable or valid. For example,
Clients can choose to ignore challenges that list Origin names for which the
current connection is not authoritative (according to the TLS certificate).</t>
          <t indent="0" pn="section-2.1.3-4">Caching and pre-fetching of tokens are discussed in <xref target="caching" format="default" sectionFormat="of" derivedContent="Section 2.1.4"/>.</t>
        </section>
        <section anchor="caching" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.4">
          <name slugifiedName="name-token-caching">Token Caching</name>
          <t indent="0" pn="section-2.1.4-1">Clients can generate multiple tokens from a single TokenChallenge and cache
them for future use. This improves privacy by separating the time of token
issuance from the time of token redemption, and also allows Clients to avoid
the overhead of receiving new tokens via the issuance protocol.</t>
          <t indent="0" pn="section-2.1.4-2">Cached tokens can only be redeemed when they match all of the fields in the
TokenChallenge: <tt>token_type</tt>, <tt>issuer_name</tt>, <tt>redemption_context</tt>, and <tt>origin_info</tt>.
Clients ought to store cached tokens based on all of these fields, to
avoid trying to redeem a token that does not match. Note that each token
has a unique Client nonce, which is sent in token redemption (<xref target="redemption" format="default" sectionFormat="of" derivedContent="Section 2.2"/>).</t>
          <t indent="0" pn="section-2.1.4-3">If a Client fetches a batch of multiple tokens for future use that are bound
to a specific redemption context (the <tt>redemption_context</tt> in the TokenChallenge
was not empty), Clients <bcp14>SHOULD</bcp14> discard these tokens upon flushing state such as
HTTP cookies <xref target="I-D.ietf-httpbis-rfc6265bis" format="default" sectionFormat="of" derivedContent="COOKIES"/>, or if there is a network
change and the Client does not have any Origin-specific state like HTTP cookies.
Using these tokens in a context that otherwise would not be linkable to the
original context could allow the Origin to recognize a Client.</t>
        </section>
      </section>
      <section anchor="redemption" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-token-redemption">Token Redemption</name>
        <t indent="0" pn="section-2.2-1">The output of the issuance protocol is a token that corresponds to the Origin's
challenge (see <xref target="challenge" format="default" sectionFormat="of" derivedContent="Section 2.1"/>).</t>
        <section anchor="token-structure" numbered="true" removeInRFC="false" toc="include" pn="section-2.2.1">
          <name slugifiedName="name-token-structure">Token Structure</name>
          <t indent="0" pn="section-2.2.1-1">A token is a structure that begins with a 2-octet field that indicates a token
type, which <bcp14>MUST</bcp14> match the <tt>token_type</tt> in the TokenChallenge structure. This value
determines the structure and semantics of the rest of the token structure.</t>
          <t indent="0" pn="section-2.2.1-2">This document defines the default token structure that can be used across
token types, although future token types <bcp14>MAY</bcp14> extend or modify the structure
of the token; see <xref target="token-types" format="default" sectionFormat="of" derivedContent="Section 6.2"/> for the registry information that
establishes and defines the relationship between <tt>token_type</tt> and the contents
of the token structure.</t>
          <t indent="0" pn="section-2.2.1-3">The default token message has the following structure:</t>
          <artwork align="left" pn="section-2.2.1-4">
struct {
    uint16_t token_type;
    uint8_t nonce[32];
    uint8_t challenge_digest[32];
    uint8_t token_key_id[Nid];
    uint8_t authenticator[Nk];
} Token;
</artwork>
          <t indent="0" pn="section-2.2.1-5">The structure fields are defined as follows:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2.1-6">
            <li pn="section-2.2.1-6.1">
              <tt>token_type</tt> is a 2-octet integer, in network byte order, as described
above.</li>
            <li pn="section-2.2.1-6.2">
              <tt>nonce</tt> is a 32-octet value containing a Client-generated random nonce.</li>
            <li pn="section-2.2.1-6.3">
              <tt>challenge_digest</tt> is a 32-octet value containing the hash of the
original TokenChallenge, SHA-256(TokenChallenge), where SHA-256 is as defined
in <xref target="SHS" format="default" sectionFormat="of" derivedContent="SHS"/>. Changing the hash function to something
other than SHA-256 would require defining a new token type and token structure
(since the contents of <tt>challenge_digest</tt> would be computed differently),
which can be done in a future specification.</li>
            <li pn="section-2.2.1-6.4">
              <tt>token_key_id</tt> is a Nid-octet identifier for the token authentication
key. The value of this field is defined by the <tt>token_type</tt> and corresponding
issuance protocol.</li>
            <li pn="section-2.2.1-6.5">
              <tt>authenticator</tt> is a Nk-octet authenticator that is cryptographically bound
to the preceding fields in the token; see <xref target="verification" format="default" sectionFormat="of" derivedContent="Section 2.2.3"/> for more information
about how this field is used in verifying a token. The <tt>token_type</tt> and corresponding
issuance protocol determine the value of the <tt>authenticator</tt> field and how it is computed.
The value of constant Nk depends on <tt>token_type</tt>, as defined in <xref target="token-types" format="default" sectionFormat="of" derivedContent="Section 6.2"/>.</li>
          </ul>
          <t indent="0" pn="section-2.2.1-7">The <tt>authenticator</tt> value in the token structure is computed over the <tt>token_type</tt>,
<tt>nonce</tt>, <tt>challenge_digest</tt>, and <tt>token_key_id</tt> fields. A token is considered valid
if token verification succeeds; see <xref target="verification" format="default" sectionFormat="of" derivedContent="Section 2.2.3"/> for details about
verifying the token and its <tt>authenticator</tt> value.</t>
        </section>
        <section anchor="sending-tokens" numbered="true" removeInRFC="false" toc="include" pn="section-2.2.2">
          <name slugifiedName="name-sending-tokens">Sending Tokens</name>
          <t indent="0" pn="section-2.2.2-1">When used for Client authorization, the "PrivateToken" authentication
scheme defines one parameter, <tt>token</tt>, which contains the base64url-encoded
token structure. As with the challenge parameters (<xref target="challenge" format="default" sectionFormat="of" derivedContent="Section 2.1"/>), the base64url
value <bcp14>MUST</bcp14> include padding. As an authentication parameter (<tt>auth-param</tt> from
<xref section="11.2" sectionFormat="comma" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-11.2" derivedContent="HTTP"/>), the value can be either a token or a
quoted-string and might be required to be a quoted-string if the base64url
string includes "=" characters. All unknown or unsupported parameters to
"PrivateToken" authentication credentials <bcp14>MUST</bcp14> be ignored.</t>
          <t indent="0" pn="section-2.2.2-2">Clients present this token structure to Origins in a new HTTP request using
the <tt>Authorization</tt> header field as follows:</t>
          <artwork align="left" pn="section-2.2.2-3">
Authorization: PrivateToken token="abc..."
</artwork>
          <t indent="0" pn="section-2.2.2-4">For context-bound tokens, Origins store or reconstruct the contexts of previous
TokenChallenge structures in order to validate the token. A TokenChallenge can
be bound to a specific TLS session with a Client, but Origins can also accept
tokens for valid challenges in new sessions. Origins <bcp14>SHOULD</bcp14> implement some form
of double-spend prevention that prevents a token with the same nonce from being
redeemed twice. Double-spend prevention ensures that Clients cannot replay tokens
for previous challenges. See <xref target="replay-attacks" format="default" sectionFormat="of" derivedContent="Section 5.2"/> for more information about replay
attacks. For context-bound tokens, this double-spend prevention can require no state
or minimal state, since the context can be used to verify token uniqueness.</t>
        </section>
        <section anchor="verification" numbered="true" removeInRFC="false" toc="include" pn="section-2.2.3">
          <name slugifiedName="name-token-verification">Token Verification</name>
          <t indent="0" pn="section-2.2.3-1">A token consists of some input cryptographically bound to an <tt>authenticator</tt>
value, such as a digital signature. Verifying a token consists of checking that
the <tt>authenticator</tt> value is correct.</t>
          <t indent="0" pn="section-2.2.3-2">The <tt>authenticator</tt> value is as computed when running and finalizing the issuance
protocol corresponding to the token type with the following values as the input:</t>
          <artwork align="left" pn="section-2.2.3-3">
struct {
    uint16_t token_type;
    uint8_t nonce[32];
    uint8_t challenge_digest[32];
    uint8_t token_key_id[Nid];
} AuthenticatorInput;
</artwork>
          <t indent="0" pn="section-2.2.3-4">The values of these fields are as described in <xref target="token-structure" format="default" sectionFormat="of" derivedContent="Section 2.2.1"/>. The cryptographic
verification check depends on the token type; see
Sections <xref target="RFC9578" section="5.4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9578#section-5.4" derivedContent="ISSUANCE"/> and <xref target="RFC9578" section="6.4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9578#section-6.4" derivedContent="ISSUANCE"/> of <xref target="RFC9578" format="default" sectionFormat="of" derivedContent="ISSUANCE"/> for verification instructions for the issuance
protocols described in that specification. As such, the security properties of the
token, e.g., the probability that one can forge an <tt>authenticator</tt> value without
invoking the issuance protocol, depend on the cryptographic algorithm used by
the issuance protocol as determined by the token type.</t>
        </section>
      </section>
    </section>
    <section anchor="client-behavior" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-client-behavior">Client Behavior</name>
      <t indent="0" pn="section-3-1">When a Client receives one or more token challenges in response to a request,
the Client has a set of choices to make:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-2">
        <li pn="section-3-2.1">Whether or not to redeem a token via a new request to the Origin.</li>
        <li pn="section-3-2.2">Whether to redeem a previously issued and cached token or redeem a token freshly issued from the issuance protocol.</li>
        <li pn="section-3-2.3">If multiple challenges were sent, which challenge to use for redeeming a
token on a subsequent request.</li>
      </ul>
      <t indent="0" pn="section-3-3">The approach to these choices depends on the use case of the application, as
well as the deployment model (see <xref section="4" sectionFormat="of" target="RFC9576" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9576#section-4" derivedContent="ARCHITECTURE"/> for discussion
of the different deployment models).</t>
      <section anchor="choosing-to-redeem-tokens" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-choosing-to-redeem-tokens">Choosing to Redeem Tokens</name>
        <t indent="0" pn="section-3.1-1">Some applications of tokens might require Clients to always present a token
as authentication in order to successfully make requests. For example, a restricted
service that wants to only allow access to valid users but wants to do so without learning
specific user credential information could use tokens that are based on attesting user
credentials. In these kinds of use cases, Clients will need to always redeem a
token in order to successfully make a request.</t>
        <t indent="0" pn="section-3.1-2">Many other use cases for Privacy Pass tokens involve open services that must work
with any Client, including those that either cannot redeem tokens or can only sometimes redeem
tokens. For example, a service can use tokens as a way to reduce the incidence of
presenting CAPTCHAs to users. In such use cases, services will regularly encounter
Clients that cannot redeem a token or choose not to. In order to mitigate the risk
of these services relying on always receiving tokens, Clients that are capable of
redeeming tokens can ignore token challenges (and instead behave as if they were a Client
that either doesn't support redeeming tokens or is unable to generate a new token, by not
sending a new request that contains a token to redeem) with some
non-trivial probability. See <xref section="5.1" sectionFormat="of" target="RFC9576" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9576#section-5.1" derivedContent="ARCHITECTURE"/> for further considerations
regarding avoiding discriminatory behavior across Clients when using Privacy Pass tokens.</t>
        <t indent="0" pn="section-3.1-3">Clients might also choose to not redeem tokens in subsequent requests when the
token challenges indicate erroneous or malicious behavior on the part of the
challenging Origin. For example, if a Client's ability to generate tokens via an
Attester and Issuer is limited to a certain rate, a malicious Origin could send
an excessive number of token challenges with unique redemption contexts
in order to (1) cause the Client to exhaust its ability to generate new tokens or (2) overwhelm issuance servers. Based on the specific deployment, the limits here will vary, but Clients <bcp14>SHOULD</bcp14> have some implementation-specific policy to minimize the number of tokens that can be retrieved by Origins.</t>
      </section>
      <section anchor="choosing-between-multiple-challenges" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-choosing-between-multiple-c">Choosing between Multiple Challenges</name>
        <t indent="0" pn="section-3.2-1">A single response from an Origin can include multiple token challenges.
For example, a set of challenges could include different token types
and Issuers, to allow Clients to choose a preferred Issuer or type.</t>
        <t indent="0" pn="section-3.2-2">If Clients choose to respond, Clients should satisfy exactly one of
the challenges presented. The choice of which challenge to use for redeeming
tokens is up to Client policy. This can involve which token types are
supported or preferred, which Issuers are supported or preferred, or whether
or not the Client is able to use cached tokens based on the redemption context
or Origin information in the challenge. See <xref target="caching" format="default" sectionFormat="of" derivedContent="Section 2.1.4"/> for more discussion
on token caching. Regardless of how the choice is made, it <bcp14>SHOULD</bcp14> be done in a
consistent manner to ensure that the choice does not reveal information about the
specific Client; see <xref section="6.2" sectionFormat="of" target="RFC9576" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9576#section-6.2" derivedContent="ARCHITECTURE"/> for more details on the privacy
implications of issuance consistency.</t>
      </section>
    </section>
    <section anchor="origin-behavior" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-origin-behavior">Origin Behavior</name>
      <t indent="0" pn="section-4-1">Origins choose what token challenges to send to Clients; these token challenges will vary,
depending on the use case and deployment model. The Origin chooses
which token types, Issuers, redemption contexts, and Origin information to include
in challenges. If an Origin sends multiple challenges, each challenge <bcp14>SHOULD</bcp14>
be equivalent in terms of acceptability for token redemption, since Clients
are free to choose to generate tokens based on any of the challenges.</t>
      <t indent="0" pn="section-4-2">Origins ought to consider the time involved in token issuance. Particularly,
a challenge that includes a unique redemption context will prevent a Client
from using cached tokens and thus can add more delay before the Client
is able to redeem a token.</t>
      <t indent="0" pn="section-4-3">Origins <bcp14>SHOULD</bcp14> minimize the number of challenges sent to a particular Client
context (referred to as the "redemption context" in
<xref section="3.3" sectionFormat="of" target="RFC9576" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9576#section-3.3" derivedContent="ARCHITECTURE"/>), to avoid overwhelming Clients and Issuers
with token requests that might cause Clients to hit rate limits.</t>
      <section anchor="greasing" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-greasing">Greasing</name>
        <t indent="0" pn="section-4.1-1">In order to prevent Clients from becoming incompatible with new token challenges,
Origins <bcp14>SHOULD</bcp14> include random token types, from the reserved list of "greased"
types (defined in <xref target="token-types" format="default" sectionFormat="of" derivedContent="Section 6.2"/>), with some non-trivial probability.</t>
        <t indent="0" pn="section-4.1-2">Additionally, for deployments where tokens are not required (such as when tokens
are used as a way to avoid showing CAPTCHAs), Origins <bcp14>SHOULD</bcp14> randomly
choose to not challenge Clients for tokens with some non-trivial probability.
This helps Origins ensure that their behavior for handling Clients that cannot
redeem tokens is maintained and exercised consistently.</t>
      </section>
    </section>
    <section anchor="sec-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">This section contains security considerations for the "PrivateToken" authentication
scheme described in this document.</t>
      <section anchor="randomness-requirements" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-randomness-requirements">Randomness Requirements</name>
        <t indent="0" pn="section-5.1-1">All random values in the challenge and token <bcp14>MUST</bcp14> be
generated using a cryptographically secure source of randomness <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/>.</t>
      </section>
      <section anchor="replay-attacks" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-replay-attacks">Replay Attacks</name>
        <t indent="0" pn="section-5.2-1">Applications <bcp14>SHOULD</bcp14> constrain tokens to a single Origin unless the use case can
accommodate replay attacks. Replaying tokens is not necessarily a security
or privacy problem. As an example, it is reasonable for Clients to replay tokens
in contexts where token redemption does not induce side effects and in which
Client requests are already linkable. One possible setting where this applies
is where tokens are sent as part of 0-RTT data.</t>
        <t indent="0" pn="section-5.2-2">If successful token redemption produces side effects, Origins <bcp14>SHOULD</bcp14> implement an
anti-replay mechanism to mitigate the harm of such replays. See <xref section="8" sectionFormat="comma" target="RFC8446" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-8" derivedContent="TLS13"/>
and <xref section="9.2" sectionFormat="comma" target="RFC9001" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9001#section-9.2" derivedContent="RFC9001"/> for details about anti-replay mechanisms, as well as
<xref section="3" sectionFormat="comma" target="RFC8470" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8470#section-3" derivedContent="RFC8470"/> for discussion about safety considerations for 0-RTT
HTTP data.</t>
      </section>
      <section anchor="reflection-attacks" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-reflection-attacks">Reflection Attacks</name>
        <t indent="0" pn="section-5.3-1">The security properties of token challenges vary, depending on whether the
challenge contains a redemption context or not, as well as whether the
challenge is a per-Origin challenge or not. For example, cross-Origin tokens with empty
contexts can be reflected from one party by another, as shown below.</t>
        <figure anchor="fig-replay" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-reflection-attack-example">Reflection Attack Example</name>
          <artset pn="section-5.3-2.1">
            <artwork type="svg" align="left" pn="section-5.3-2.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="176" width="488" viewBox="0 0 488 176" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,64" fill="none" stroke="black"/>
                <path d="M 40,64 L 40,160" fill="none" stroke="black"/>
                <path d="M 80,32 L 80,64" fill="none" stroke="black"/>
                <path d="M 184,32 L 184,64" fill="none" stroke="black"/>
                <path d="M 224,64 L 224,160" fill="none" stroke="black"/>
                <path d="M 272,32 L 272,64" fill="none" stroke="black"/>
                <path d="M 408,32 L 408,64" fill="none" stroke="black"/>
                <path d="M 440,64 L 440,160" fill="none" stroke="black"/>
                <path d="M 480,32 L 480,64" fill="none" stroke="black"/>
                <path d="M 8,32 L 80,32" fill="none" stroke="black"/>
                <path d="M 184,32 L 272,32" fill="none" stroke="black"/>
                <path d="M 408,32 L 480,32" fill="none" stroke="black"/>
                <path d="M 8,64 L 80,64" fill="none" stroke="black"/>
                <path d="M 184,64 L 272,64" fill="none" stroke="black"/>
                <path d="M 408,64 L 480,64" fill="none" stroke="black"/>
                <path d="M 40,96 L 64,96" fill="none" stroke="black"/>
                <path d="M 200,96 L 216,96" fill="none" stroke="black"/>
                <path d="M 224,112 L 240,112" fill="none" stroke="black"/>
                <path d="M 416,112 L 432,112" fill="none" stroke="black"/>
                <path d="M 232,128 L 296,128" fill="none" stroke="black"/>
                <path d="M 360,128 L 440,128" fill="none" stroke="black"/>
                <path d="M 48,144 L 64,144" fill="none" stroke="black"/>
                <path d="M 208,144 L 224,144" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="440,112 428,106.4 428,117.6" fill="black" transform="rotate(0,432,112)"/>
                <polygon class="arrowhead" points="240,128 228,122.4 228,133.6" fill="black" transform="rotate(180,232,128)"/>
                <polygon class="arrowhead" points="224,96 212,90.4 212,101.6" fill="black" transform="rotate(0,216,96)"/>
                <polygon class="arrowhead" points="56,144 44,138.4 44,149.6" fill="black" transform="rotate(180,48,144)"/>
                <g class="text">
                  <text x="44" y="52">Origin</text>
                  <text x="228" y="52">Attacker</text>
                  <text x="444" y="52">Client</text>
                  <text x="132" y="100">TokenChallenge</text>
                  <text x="284" y="116">(reflect</text>
                  <text x="364" y="116">challenge)</text>
                  <text x="328" y="132">Token</text>
                  <text x="108" y="148">(reflect</text>
                  <text x="172" y="148">token)</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="left" pn="section-5.3-2.1.2">
+--------+            +----------+                +--------+
| Origin |            | Attacker |                | Client |
+---+----+            +----+-----+                +---+----+
    |                      |                          |
    +--- TokenChallenge --&gt;|                          |
    |                      +-- (reflect challenge) --&gt;|
    |                      |&lt;-------- Token ----------+
    |&lt;-- (reflect token) --+                          |
    |                      |                          |
</artwork>
          </artset>
        </figure>
      </section>
      <section anchor="token-exhaustion-attacks" numbered="true" removeInRFC="false" toc="include" pn="section-5.4">
        <name slugifiedName="name-token-exhaustion-attacks">Token Exhaustion Attacks</name>
        <t indent="0" pn="section-5.4-1">When a Client holds cross-Origin tokens with empty contexts, it
is possible for any Origin in the cross-Origin set to deplete that Client's
set of tokens. To prevent this from happening, tokens can be scoped to single
Origins (with non-empty <tt>origin_info</tt>) such that they can only be redeemed for
a single Origin. Alternatively, if tokens are cross-Origin tokens, Clients can use
alternate methods to prevent many tokens from being redeemed at once. For
example, if the Origin requests an excess of tokens, the Client could choose to
not present any tokens for verification if a redemption had already
occurred in a given time window.</t>
        <t indent="0" pn="section-5.4-2">Token challenges that include non-empty <tt>origin_info</tt> bind tokens to one or more
specific Origins. As described in <xref target="process-challenge" format="default" sectionFormat="of" derivedContent="Section 2.1.3"/>, Clients only accept such
challenges from Origin names listed in the <tt>origin_info</tt> string if it is non-empty. Even if multiple
Origins are listed, a token can only be redeemed for an Origin if the challenge
has a match for the <tt>origin_info</tt>. For example, if "a.example.com" issues
a challenge with an <tt>origin_info</tt> string of "a.example.com,b.example.com", a
Client could redeem a token fetched for this challenge if and only if
"b.example.com" also included an <tt>origin_info</tt> string of
"a.example.com,b.example.com". On the other hand, if "b.example.com" had an
<tt>origin_info</tt> string of "b.example.com", "b.example.com,a.example.com", or
"a.example.com,b.example.com,c.example.com", the string would not match, and the
Client would need to use a different token.</t>
      </section>
      <section anchor="timing-correlation-attacks" numbered="true" removeInRFC="false" toc="include" pn="section-5.5">
        <name slugifiedName="name-timing-correlation-attacks">Timing Correlation Attacks</name>
        <t indent="0" pn="section-5.5-1">Context-bound token challenges require Clients to obtain matching tokens when
challenged, rather than presenting a token that was obtained from a different
context in the past. This can make it more likely that issuance and redemption
events will occur at approximately the same time. For example, if a Client is
challenged for a token with a unique context at time T1 and then subsequently
obtains a token at time T2, a colluding Issuer and Origin can link this to the
same Client if T2 is unique to the Client. This linkability is less feasible as
the number of issuance events at time T2 increases. Depending on the <tt>max-age</tt>
token challenge parameter, Clients <bcp14>MAY</bcp14> try to add delay to the time between
being challenged and redeeming a token to make this sort of linkability more
difficult. For more discussion on correlation risks between token issuance and
redemption, see <xref section="6.3" sectionFormat="of" target="RFC9576" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9576#section-6.3" derivedContent="ARCHITECTURE"/>.</t>
      </section>
      <section anchor="cross-context-linkability-attacks" numbered="true" removeInRFC="false" toc="include" pn="section-5.6">
        <name slugifiedName="name-cross-context-linkability-a">Cross-Context Linkability Attacks</name>
        <t indent="0" pn="section-5.6-1">As discussed in <xref target="challenge" format="default" sectionFormat="of" derivedContent="Section 2.1"/>, Clients <bcp14>SHOULD</bcp14> discard any context-bound tokens
upon flushing cookies or changing networks, to prevent an Origin from using the
redemption context state as a cookie to recognize Clients.</t>
      </section>
    </section>
    <section anchor="iana" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="authentication-scheme" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-authentication-scheme">Authentication Scheme</name>
        <t indent="0" pn="section-6.1-1">IANA has registered the "PrivateToken" authentication scheme in the
"HTTP Authentication Schemes" subregistry of the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" as defined
in <xref section="16.4" sectionFormat="comma" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-16.4" derivedContent="HTTP"/>.</t>
        <dl indent="3" newline="false" spacing="normal" pn="section-6.1-2">
          <dt pn="section-6.1-2.1">Authentication Scheme Name:</dt>
          <dd pn="section-6.1-2.2">PrivateToken</dd>
          <dt pn="section-6.1-2.3">Reference:</dt>
          <dd pn="section-6.1-2.4">RFC 9577, <xref target="challenge-redemption" format="default" sectionFormat="of" derivedContent="Section 2"/></dd>
        </dl>
      </section>
      <section anchor="token-types" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-privacy-pass-token-types-re">Privacy Pass Token Types Registry</name>
        <t indent="0" pn="section-6.2-1">IANA has created a new "Privacy Pass Token Types" registry in a new
"Privacy Pass" page to list identifiers for issuance protocols
defined for use with the Privacy Pass token authentication scheme. These
identifiers are 2-byte values, so the maximum possible value is
0xFFFF = 65535.</t>
        <t indent="0" pn="section-6.2-2">New registrations need to list the following attributes:</t>
        <dl spacing="compact" indent="3" newline="false" pn="section-6.2-3">
          <dt pn="section-6.2-3.1">Value:</dt>
          <dd pn="section-6.2-3.2">
            The 2-byte identifier for the algorithm.</dd>
          <dt pn="section-6.2-3.3">Name:</dt>
          <dd pn="section-6.2-3.4">Name of the issuance protocol.</dd>
          <dt pn="section-6.2-3.5">Token Structure:</dt>
          <dd pn="section-6.2-3.6">The contents of the token structure; see <xref target="redemption" format="default" sectionFormat="of" derivedContent="Section 2.2"/>.</dd>
          <dt pn="section-6.2-3.7">Token Key Encoding:</dt>
          <dd pn="section-6.2-3.8">The encoding of the <tt>token-key</tt> parameter; see <xref target="send-challenge" format="default" sectionFormat="of" derivedContent="Section 2.1.2"/>.</dd>
          <dt pn="section-6.2-3.9">TokenChallenge Structure:</dt>
          <dd pn="section-6.2-3.10">The contents of the TokenChallenge structure; see <xref target="challenge" format="default" sectionFormat="of" derivedContent="Section 2.1"/>.</dd>
          <dt pn="section-6.2-3.11">Publicly Verifiable:</dt>
          <dd pn="section-6.2-3.12">A Y/N value indicating if the output tokens have the
public verifiability property; see <xref section="3.5" sectionFormat="of" target="RFC9576" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9576#section-3.5" derivedContent="ARCHITECTURE"/>
for more details about this property.</dd>
          <dt pn="section-6.2-3.13">Public Metadata:</dt>
          <dd pn="section-6.2-3.14">A Y/N value indicating if the output tokens can contain
public metadata; see <xref section="3.5" sectionFormat="of" target="RFC9576" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9576#section-3.5" derivedContent="ARCHITECTURE"/>
for more details about this property.</dd>
          <dt pn="section-6.2-3.15">Private Metadata:</dt>
          <dd pn="section-6.2-3.16">A Y/N value indicating if the output tokens can contain
private metadata; see <xref section="3.5" sectionFormat="of" target="RFC9576" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9576#section-3.5" derivedContent="ARCHITECTURE"/>
for more details about this property.</dd>
          <dt pn="section-6.2-3.17">Nk:</dt>
          <dd pn="section-6.2-3.18">The length in bytes of an output authenticator.</dd>
          <dt pn="section-6.2-3.19">Nid:</dt>
          <dd pn="section-6.2-3.20">The length of the token key identifier.</dd>
          <dt pn="section-6.2-3.21">Change Controller:</dt>
          <dd pn="section-6.2-3.22">The entity that is responsible for the definition of the registration.</dd>
          <dt pn="section-6.2-3.23">Reference:</dt>
          <dd pn="section-6.2-3.24">Where this algorithm is defined.</dd>
          <dt pn="section-6.2-3.25">Notes:</dt>
          <dd pn="section-6.2-3.26">Any notes associated with the entry.</dd>
        </dl>
        <t indent="0" pn="section-6.2-4">New entries in this registry are subject to the Specification Required
registration policy (<xref section="4.6" sectionFormat="comma" target="RFC8126" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.6" derivedContent="RFC8126"/>). Designated experts need to
ensure that the token type is defined to be used for both token issuance and
redemption. Additionally, the experts can reject registrations on the basis
that they do not meet the security and privacy requirements for issuance
protocols defined in <xref section="3.2" sectionFormat="of" target="RFC9576" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9576#section-3.2" derivedContent="ARCHITECTURE"/>.</t>
        <t indent="0" pn="section-6.2-5"><xref target="RFC9578" format="default" sectionFormat="of" derivedContent="ISSUANCE"/> defines entries for this registry.</t>
        <section anchor="reserved-values" numbered="true" removeInRFC="false" toc="include" pn="section-6.2.1">
          <name slugifiedName="name-reserved-values">Reserved Values</name>
          <t indent="0" pn="section-6.2.1-1">This document defines several reserved values, which can be used by Clients
and servers to send "greased" values in token challenges and redemptions to
ensure that implementations remain able to handle unknown token types
gracefully (this technique is inspired by <xref target="RFC8701" format="default" sectionFormat="of" derivedContent="RFC8701"/>). Implementations <bcp14>SHOULD</bcp14>
select reserved values at random when including them in greased messages.
Servers can include these in TokenChallenge structures, either as the only
challenge when no real token type is desired or as one challenge in a list of
challenges that include real values. Clients can include these in token
structures when they are not able to present a real token. The
contents of the token structure <bcp14>SHOULD</bcp14> be filled with random bytes when
using greased values.</t>
          <t indent="0" pn="section-6.2.1-2">The initial contents of this registry consist of multiple reserved values,
with the following attributes, which are repeated for each registration:</t>
          <dl spacing="compact" indent="3" newline="false" pn="section-6.2.1-3">
            <dt pn="section-6.2.1-3.1">Value:</dt>
            <dd pn="section-6.2.1-3.2">0x0000, 0x02AA, 0x1132, 0x2E96, 0x3CD3, 0x4473, 0x5A63, 0x6D32, 0x7F3F,
0x8D07, 0x916B, 0xA6A4, 0xBEAB, 0xC3F3, 0xDA42, 0xE944, 0xF057</dd>
            <dt pn="section-6.2.1-3.3">Name:</dt>
            <dd pn="section-6.2.1-3.4">RESERVED</dd>
            <dt pn="section-6.2.1-3.5">Token Structure:</dt>
            <dd pn="section-6.2.1-3.6">Random bytes</dd>
            <dt pn="section-6.2.1-3.7">Token Key Encoding:</dt>
            <dd pn="section-6.2.1-3.8">Random bytes</dd>
            <dt pn="section-6.2.1-3.9">TokenChallenge Structure:</dt>
            <dd pn="section-6.2.1-3.10">Random bytes</dd>
            <dt pn="section-6.2.1-3.11">Publicly Verifiable:</dt>
            <dd pn="section-6.2.1-3.12">N/A</dd>
            <dt pn="section-6.2.1-3.13">Public Metadata:</dt>
            <dd pn="section-6.2.1-3.14">N/A</dd>
            <dt pn="section-6.2.1-3.15">Private Metadata:</dt>
            <dd pn="section-6.2.1-3.16">N/A</dd>
            <dt pn="section-6.2.1-3.17">Nk:</dt>
            <dd pn="section-6.2.1-3.18">N/A</dd>
            <dt pn="section-6.2.1-3.19">Nid:</dt>
            <dd pn="section-6.2.1-3.20">N/A</dd>
            <dt pn="section-6.2.1-3.21">Change Controller:</dt>
            <dd pn="section-6.2.1-3.22">IETF</dd>
            <dt pn="section-6.2.1-3.23">Reference:</dt>
            <dd pn="section-6.2.1-3.24">RFC 9577</dd>
            <dt pn="section-6.2.1-3.25">Notes:</dt>
            <dd pn="section-6.2.1-3.26">None</dd>
          </dl>
        </section>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="RFC9576" to="ARCHITECTURE"/>
    <displayreference target="RFC8446" to="TLS13"/>
    <displayreference target="RFC3986" to="URI"/>
    <displayreference target="RFC9578" to="ISSUANCE"/>
    <displayreference target="RFC9110" to="HTTP"/>
    <displayreference target="I-D.ietf-httpbis-rfc6265bis" to="COOKIES"/>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC9576" target="https://www.rfc-editor.org/info/rfc9576" quoteTitle="true" derivedAnchor="ARCHITECTURE">
          <front>
            <title>The Privacy Pass Architecture</title>
            <author initials="A" surname="Davidson" fullname="Alex Davidson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J" surname="Iyengar" fullname="Jana Iyengar">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2024" month="June"/>
          </front>
          <seriesInfo name="RFC" value="9576"/>
          <seriesInfo name="DOI" value="10.17487/RFC9576"/>
        </reference>
        <reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9110" quoteTitle="true" derivedAnchor="HTTP">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t indent="0">This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="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="RFC4648" target="https://www.rfc-editor.org/info/rfc4648" quoteTitle="true" derivedAnchor="RFC4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <date month="October" year="2006"/>
            <abstract>
              <t indent="0">This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="SHS" target="https://doi.org/10.6028/nist.fips.180-4" quoteTitle="true" derivedAnchor="SHS">
          <front>
            <title>Secure Hash Standard (SHS)</title>
            <author>
              <organization showOnFrontPage="true">National Institute of Standards and Technology</organization>
            </author>
            <date month="August" year="2015"/>
          </front>
          <seriesInfo name="NIST FIPS Publication" value="180-4"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="TLS13">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986" quoteTitle="true" derivedAnchor="URI">
          <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>
      </references>
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-httpbis-rfc6265bis" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-14" derivedAnchor="COOKIES">
          <front>
            <title>Cookies: HTTP State Management Mechanism</title>
            <author fullname="Steven Bingler" initials="S." surname="Bingler" role="editor">
              <organization showOnFrontPage="true">Google LLC</organization>
            </author>
            <author fullname="Mike West" initials="M." surname="West" role="editor">
              <organization showOnFrontPage="true">Google LLC</organization>
            </author>
            <author fullname="John Wilander" initials="J." surname="Wilander" role="editor">
              <organization showOnFrontPage="true">Apple, Inc</organization>
            </author>
            <date day="2" month="May" year="2024"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-rfc6265bis-14"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC9578" target="https://www.rfc-editor.org/info/rfc9578" quoteTitle="true" derivedAnchor="ISSUANCE">
          <front>
            <title>Privacy Pass Issuance Protocols</title>
            <author initials="S." surname="Celi" fullname="Sofia Celi">
              <organization showOnFrontPage="true">Brave Software</organization>
            </author>
            <author initials="A." surname="Davidson" fullname="Alex Davidson">
              <organization showOnFrontPage="true">Brave Software</organization>
            </author>
            <author initials="S." surname="Valdez" fullname="Steven Valdez">
              <organization showOnFrontPage="true">Google LLC</organization>
            </author>
            <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
              <organization showOnFrontPage="true">Cloudflare</organization>
            </author>
            <date month="June" year="2024"/>
          </front>
          <seriesInfo name="RFC" value="9578"/>
          <seriesInfo name="DOI" value="10.17487/RFC9578"/>
        </reference>
        <reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086" quoteTitle="true" derivedAnchor="RFC4086">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="J. Schiller" initials="J." surname="Schiller"/>
            <author fullname="S. Crocker" initials="S." surname="Crocker"/>
            <date month="June" year="2005"/>
            <abstract>
              <t indent="0">Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t indent="0">Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. 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="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/>
        </reference>
        <reference anchor="RFC8470" target="https://www.rfc-editor.org/info/rfc8470" quoteTitle="true" derivedAnchor="RFC8470">
          <front>
            <title>Using Early Data in HTTP</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson"/>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="W. Tarreau" initials="W." surname="Tarreau"/>
            <date month="September" year="2018"/>
            <abstract>
              <t indent="0">Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8470"/>
          <seriesInfo name="DOI" value="10.17487/RFC8470"/>
        </reference>
        <reference anchor="RFC8701" target="https://www.rfc-editor.org/info/rfc8701" quoteTitle="true" derivedAnchor="RFC8701">
          <front>
            <title>Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility</title>
            <author fullname="D. Benjamin" initials="D." surname="Benjamin"/>
            <date month="January" year="2020"/>
            <abstract>
              <t indent="0">This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8701"/>
          <seriesInfo name="DOI" value="10.17487/RFC8701"/>
        </reference>
        <reference anchor="RFC9001" target="https://www.rfc-editor.org/info/rfc9001" quoteTitle="true" derivedAnchor="RFC9001">
          <front>
            <title>Using TLS to Secure QUIC</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <author fullname="S. Turner" initials="S." role="editor" surname="Turner"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">This document describes how Transport Layer Security (TLS) is used to secure QUIC.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9001"/>
          <seriesInfo name="DOI" value="10.17487/RFC9001"/>
        </reference>
      </references>
    </references>
    <section anchor="test-vectors" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-test-vectors">Test Vectors</name>
      <t indent="0" pn="section-appendix.a-1">This section includes test vectors for the HTTP authentication scheme specified
in this document. It consists of the following types of test vectors:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-appendix.a-2"><li pn="section-appendix.a-2.1" derivedCounter="1.">Test vectors for the challenge and redemption protocols. Implementations can
use these test vectors for verifying code that builds and encodes
TokenChallenge structures, as well as code that produces a well-formed token
bound to a TokenChallenge.</li>
        <li pn="section-appendix.a-2.2" derivedCounter="2.">Test vectors for the HTTP headers used for authentication. Implementations
can use these test vectors for validating whether they parse HTTP
authentication headers correctly to produce TokenChallenge structures and the
other associated parameters, such as the <tt>token-key</tt> and <tt>max-age</tt> values.</li>
      </ol>
      <section anchor="challenge-and-redemption-structure-test-vectors" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.1">
        <name slugifiedName="name-challenge-and-redemption-st">Challenge and Redemption Structure Test Vectors</name>
        <t indent="0" pn="section-appendix.a.1-1">This section includes test vectors for the challenge and redemption
functionalities described in Sections <xref target="challenge" format="counter" sectionFormat="of" derivedContent="2.1"/> and <xref target="redemption" format="counter" sectionFormat="of" derivedContent="2.2"/>. Each test vector
lists the following values:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-appendix.a.1-2">
          <dt pn="section-appendix.a.1-2.1"><tt>token_type</tt>:</dt>
          <dd pn="section-appendix.a.1-2.2">The type of token issuance protocol -- a value from
<xref target="token-types" format="default" sectionFormat="of" derivedContent="Section 6.2"/>. For these test vectors, <tt>token_type</tt> is <tt>0x0002</tt>, corresponding
to the issuance protocol discussed in Section <xref target="RFC9578" sectionFormat="bare" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9578#section-6" derivedContent="ISSUANCE">"Issuance Protocol for Publicly Verifiable Tokens"</xref> of <xref target="RFC9578" format="default" sectionFormat="of" derivedContent="ISSUANCE"/>.</dd>
          <dt pn="section-appendix.a.1-2.3"><tt>issuer_name</tt>:</dt>
          <dd pn="section-appendix.a.1-2.4"> The name of the Issuer in the TokenChallenge structure,
represented as a hexadecimal string.</dd>
          <dt pn="section-appendix.a.1-2.5"><tt>redemption_context</tt>:</dt>
          <dd pn="section-appendix.a.1-2.6">The redemption context in the TokenChallenge structure,
represented as a hexadecimal string.</dd>
          <dt pn="section-appendix.a.1-2.7"><tt>origin_info</tt>:</dt>
          <dd pn="section-appendix.a.1-2.8"> The Origin information in the TokenChallenge structure, represented as
a hexadecimal string.</dd>
          <dt pn="section-appendix.a.1-2.9"><tt>nonce</tt>:</dt>
          <dd pn="section-appendix.a.1-2.10">The nonce in the token structure, represented as a hexadecimal string.</dd>
          <dt pn="section-appendix.a.1-2.11"><tt>token_key_id</tt>:</dt>
          <dd pn="section-appendix.a.1-2.12">The public token key, encoded based on the corresponding token
type, represented as a hexadecimal string.</dd>
          <dt pn="section-appendix.a.1-2.13"><tt>token_authenticator_input</tt>:</dt>
          <dd pn="section-appendix.a.1-2.14">The values in the token structure used to compute
the token authenticator value, represented as a hexadecimal string.</dd>
        </dl>
        <t indent="0" pn="section-appendix.a.1-3">Test vectors are provided for each of the following TokenChallenge
configurations:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-appendix.a.1-4"><li pn="section-appendix.a.1-4.1" derivedCounter="1.">TokenChallenge with a single Origin and a non-empty redemption context.</li>
          <li pn="section-appendix.a.1-4.2" derivedCounter="2.">TokenChallenge with a single Origin and empty redemption context.</li>
          <li pn="section-appendix.a.1-4.3" derivedCounter="3.">TokenChallenge with an empty Origin and redemption context.</li>
          <li pn="section-appendix.a.1-4.4" derivedCounter="4.">TokenChallenge with an empty Origin and a non-empty redemption context.</li>
          <li pn="section-appendix.a.1-4.5" derivedCounter="5.">TokenChallenge with multiple Origins and a non-empty redemption context.</li>
          <li pn="section-appendix.a.1-4.6" derivedCounter="6.">TokenChallenge for greasing.</li>
        </ol>
        <t indent="0" pn="section-appendix.a.1-5">These test vectors are below.</t>
        <artwork align="left" pn="section-appendix.a.1-6">
// Test vector 1:
//   token_type(0002), issuer_name(issuer.example),
//   origin_info(origin.example), redemption_context(non-empty)
token_type: 0002
issuer_name: 6973737565722e6578616d706c65
redemption_context:
476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb
origin_info: 6f726967696e2e6578616d706c65
nonce:
e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
token_key_id:
ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
14f235e41ef7e2378e6f202688abab8e1d5518ec82964255526efd8f9db88205a
8ddd3ffb1db298fcc3ad36c42388fca572f8982a9ca248a3056186322d93ca147
266121ddeb5632c07f1f71cd2708

// Test vector 2:
//   token_type(0002), issuer_name(issuer.example),
//   origin_info(origin.example), redemption_context(empty)
token_type: 0002
issuer_name: 6973737565722e6578616d706c65
redemption_context:
origin_info: 6f726967696e2e6578616d706c65
nonce:
e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
token_key_id:
ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
14f235e41ef7e2378e6f202688abab11e15c91a7c2ad02abd66645802373db1d8
23bea80f08d452541fb2b62b5898bca572f8982a9ca248a3056186322d93ca147
266121ddeb5632c07f1f71cd2708

// Test vector 3:
//   token_type(0002), issuer_name(issuer.example),
//   origin_info(), redemption_context(empty)
token_type: 0002
issuer_name: 6973737565722e6578616d706c65
redemption_context:
origin_info:
nonce:
e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
token_key_id:
ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
14f235e41ef7e2378e6f202688ababb741ec1b6fd05f1e95f8982906aec161289
6d9ca97d53eef94ad3c9fe023f7a4ca572f8982a9ca248a3056186322d93ca147
266121ddeb5632c07f1f71cd2708

// Test vector 4:
//   token_type(0002), issuer_name(issuer.example),
//   origin_info(), redemption_context(non-empty)
token_type: 0002
issuer_name: 6973737565722e6578616d706c65
redemption_context:
476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb
origin_info:
nonce:
e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
token_key_id:
ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
14f235e41ef7e2378e6f202688ababb85fb5bc06edeb0e8e8bdb5b3bea8c4fa40
837c82e8bcaf5882c81e14817ea18ca572f8982a9ca248a3056186322d93ca147
266121ddeb5632c07f1f71cd2708

// Test vector 5:
//   token_type(0002), issuer_name(issuer.example),
//   origin_info(foo.example,bar.example),
//   redemption_context(non-empty)
token_type: 0002
issuer_name: 6973737565722e6578616d706c65
redemption_context:
476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb
origin_info: 666f6f2e6578616d706c652c6261722e6578616d706c65
nonce:
e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
token_key_id:
ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
14f235e41ef7e2378e6f202688ababa2a775866b6ae0f98944910c8f48728d8a2
735b9157762ddbf803f70e2e8ba3eca572f8982a9ca248a3056186322d93ca147
266121ddeb5632c07f1f71cd2708

// Test vector 6:
//   token_type(0000), structure(random_bytes)
token_type: 0000
token_authenticator_input: 000058405ad31e286e874cb42d0ef9d50461ae
703bb71a21178beb429c43c0effe587456d856f0f2bdfc216ef93d5c225e2a93e
84cb686e63919788087f7ab1054aa817f09dcb919a0ed6f90fe887e8b08cd1eee
44d5be8d813eda9f2656db61c932db8d73f8690604ded0120157923bbd19d5549
e639e4de07530aee1d370f5187b678685715bd878dde24346751eb532a87b71ea
40bbe5a13218658e303c648eb03817453690bfcbe8255081bf27ff0891cd02ee2
483e48a2c494bdef696f943fa992a65303292c25d0d3f62da86a70d0b020f0ff5
b90d0ff0f6abdb097d321fde04f3a1994e63bcd35a88c21236c7dc67600482223
f54b25e39a250439f27ecb5ae9eb8ed548a3ec1f1d6f510d08281929c8fe08834
2959e35ea9b3b6f6a96fc1a8edba4ed297f4cf02d0e4482b79a11f671745d7b7d
b120eddd8a4c2b6501bbc895b2160b8071615d9c1b18f32e056bfee29deac6a7d
6cf7b522a5badd63b9cb
</artwork>
      </section>
      <section anchor="http-header-test-vectors" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.2">
        <name slugifiedName="name-http-header-test-vectors">HTTP Header Test Vectors</name>
        <t indent="0" pn="section-appendix.a.2-1">This section includes test vectors for the contents of the HTTP authentication
headers. Each test vector consists of one or more challenges that comprise
a <tt>WWW-Authenticate</tt> header; see
<xref target="choosing-between-multiple-challenges" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.
For each challenge, the token-type, <tt>token-key</tt>, <tt>max-age</tt>, and <tt>token-challenge</tt>
parameters are listed. Each challenge also includes an unknown (unspecified)
parameter that implementations are meant to ignore.</t>
        <t indent="0" pn="section-appendix.a.2-2">The parameters for each challenge are indexed by their position
in the <tt>WWW-Authenticate</tt> challenge list. For example, <tt>token-key-0</tt> denotes
the <tt>token-key</tt> parameter for the first challenge in the list, whereas
<tt>token-key-1</tt> denotes the <tt>token-key</tt> for the second challenge in the list.</t>
        <t indent="0" pn="section-appendix.a.2-3">The resulting wire-encoded <tt>WWW-Authenticate</tt> header based on this
list of challenges is then listed at the end. Line folding is only
used to fit the document-formatting constraints and is not supported
in actual requests.</t>
        <t indent="0" pn="section-appendix.a.2-4">The last challenge in this list includes Basic authentication, a grease
challenge, and a valid challenge for token type <tt>0x0001</tt>. Correct Client
implementations will ignore the Basic and grease challenges.</t>
        <artwork align="left" pn="section-appendix.a.2-5">
token-type-0: 0x0002
token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864
8016503040202a11a301806092a864886f70d010108300b060960864801650304020
2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2
5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9
ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f
67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b
f6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6c
bbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b1dba9e828bbd81e2
91317144e7ff89f55619709b096cbb9ea474cead264c2073fe49740c01f00e109106
066983d21e5f83f086e2e823c879cd43cef700d2a352a9babd612d03cad02db134b7
e225a5f0203010001
max-age-0: 10
token-challenge-0: 0002000e6973737565722e6578616d706c65208a3e83a33d9
8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696
e2e6578616d706c65

WWW-Authenticate: PrivateToken challenge="AAIADmlzc3Vlci5leGFtcGxlII
o-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==",
 token-key="MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqG
SIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM
_KsluUsuZKIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi7pA1I-beWi
JNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwyB6vGvcte155T8mKMTknaHl1fORTtS
bvm_bOuZl5uEI7kPRGGiKvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE
7KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0zq0mTCBz_kl0DAHwDh
CRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo1Kpur1hLQPK0C2xNLfiJaXwIDAQAB",unknow
nChallengeAttribute="ignore-me", max-age="10"

token-type-0: 0x0002
token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864
8016503040202a11a301806092a864886f70d010108300b060960864801650304020
2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2
5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9
ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f
67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b
f6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6c
bbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b1dba9e828bbd81e2
91317144e7ff89f55619709b096cbb9ea474cead264c2073fe49740c01f00e109106
066983d21e5f83f086e2e823c879cd43cef700d2a352a9babd612d03cad02db134b7
e225a5f0203010001
max-age-0: 10
token-challenge-0: 0002000e6973737565722e6578616d706c65208a3e83a33d9
8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696
e2e6578616d706c65
token-type-1: 0x0001
token-key-1: ebb1fed338310361c08d0c7576969671296e05e99a17d7926dfc28a
53fabd489fac0f82bca86249a668f3a5bfab374c9
max-age-1: 10
token-challenge-1: 0001000e6973737565722e6578616d706c65208a3e83a33d9
8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696
e2e6578616d706c65

WWW-Authenticate: PrivateToken challenge="AAIADmlzc3Vlci5leGFtcGxlII
o-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==",
 token-key="MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqG
SIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM
_KsluUsuZKIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi7pA1I-beWi
JNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwyB6vGvcte155T8mKMTknaHl1fORTtS
bvm_bOuZl5uEI7kPRGGiKvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE
7KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0zq0mTCBz_kl0DAHwDh
CRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo1Kpur1hLQPK0C2xNLfiJaXwIDAQAB",unknow
nChallengeAttribute="ignore-me", max-age="10", PrivateToken challeng
e="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPp
LODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0zgxA2HAjQx1dpaWcSluBem
aF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownChallengeAttribute="ig
nore-me", max-age="10"

token-type-0: 0x0000
token-key-0: 856de3c710b892e7cca1ae5eb121af42ca8e779137a11224228c9b9
9b0729bf84d5057d030000309b8f0d06ccffa17561f9eacd4c312e985a6bc60ffbea
0610264dcb1726255313da81d665692686a1d8644f1516bf612cea009e6dff6d9a9a
959fb538e1b5b2343c092992942382bdde22d5b324b1e4618ed21d7806286c2ce
token-challenge-0: 0000acc3b25795c636fd9dd8b12982394abba8777d35978e8
77fc8848892a217233045ac25a3d55c07c54efe6372973fee0073e77fc61bf19ab88
0f20edf5d627502
token-type-1: 0x0001
token-key-1: ebb1fed338310361c08d0c7576969671296e05e99a17d7926dfc28a
53fabd489fac0f82bca86249a668f3a5bfab374c9
max-age-1: 10
token-challenge-1: 0001000e6973737565722e6578616d706c65208a3e83a33d9
8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696
e2e6578616d706c65

WWW-Authenticate: Basic realm="grease", PrivateToken challenge="AACs
w7JXlcY2_Z3YsSmCOUq7qHd9NZeOh3_IhIiSohcjMEWsJaPVXAfFTv5jcpc_7gBz53_G
G_GauIDyDt9dYnUC", token-key="hW3jxxC4kufMoa5esSGvQsqOd5E3oRIkIoybmbB
ym_hNUFfQMAADCbjw0GzP-hdWH56s1MMS6YWmvGD_vqBhAmTcsXJiVTE9qB1mVpJoah2
GRPFRa_YSzqAJ5t_22ampWftTjhtbI0PAkpkpQjgr3eItWzJLHkYY7SHXgGKGws4=",
PrivateToken challenge="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6
a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0z
gxA2HAjQx1dpaWcSluBemaF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownC
hallengeAttribute="ignore-me", max-age="10"
</artwork>
      </section>
    </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="T." surname="Pauly" fullname="Tommy Pauly">
        <organization showOnFrontPage="true">Apple Inc.</organization>
        <address>
          <postal>
            <street>One Apple Park Way</street>
            <city>Cupertino</city>
            <region>California</region>
            <code>95014</code>
            <country>United States of America</country>
          </postal>
          <email>tpauly@apple.com</email>
        </address>
      </author>
      <author initials="S." surname="Valdez" fullname="Steven Valdez">
        <organization showOnFrontPage="true">Google LLC</organization>
        <address>
          <email>svaldez@chromium.org</email>
        </address>
      </author>
      <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
        <organization showOnFrontPage="true">Cloudflare</organization>
        <address>
          <email>caw@heapingbits.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
