<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-privacypass-architecture-16" number="9576" category="info" tocInclude="true" submissionType="IETF" consensus="true" obsoletes="" updates="" sortRefs="true" symRefs="true" xml:lang="en" prepTime="2024-06-13T15:32:36" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-privacypass-architecture-16" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9576" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Privacy Pass Architecture">The Privacy Pass Architecture</title>
    <seriesInfo name="RFC" value="9576" stream="IETF"/>
    <author initials="A." surname="Davidson" fullname="Alex Davidson">
      <organization showOnFrontPage="true">NOVA LINCS, Universidade NOVA de Lisboa</organization>
      <address>
        <postal>
          <street>Largo da Torre</street>
          <city>Caparica</city>
          <country>Portugal</country>
        </postal>
        <email>alex.davidson92@gmail.com</email>
      </address>
    </author>
    <author initials="J." surname="Iyengar" fullname="Jana Iyengar">
      <organization showOnFrontPage="true">Fastly</organization>
      <address>
        <email>jri@fastly.com</email>
      </address>
    </author>
    <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
      <organization showOnFrontPage="true">Cloudflare</organization>
      <address>
        <postal>
          <street>101 Townsend St</street>
          <city>San Francisco</city>
          <region>CA</region>
          <code>94107</code>
          <country>United States of America</country>
        </postal>
        <email>caw@heapingbits.net</email>
      </address>
    </author>
    <date month="06" year="2024"/>
    <area>sec</area>
    <workgroup>privacypass</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document specifies the Privacy Pass architecture and requirements for
its constituent protocols used for authorization based on privacy-preserving
authentication mechanisms. It describes the conceptual model of Privacy Pass
and its protocols, its security and privacy goals, practical deployment models,
and recommendations for each deployment model, to help ensure that the desired
security and privacy goals are fulfilled.</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 document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </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).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see 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/rfc9576" 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>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" 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-terminology">Terminology</xref></t>
          </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-architecture">Architecture</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" keepWithNext="true" 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-overview">Overview</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-use-cases">Use Cases</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-goals-and-threat-mo">Privacy Goals and Threat Model</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-redemption-protocol">Redemption Protocol</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-issuance-protocol">Issuance Protocol</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.5.2">
                  <li pn="section-toc.1-1.3.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.5.2.1.1"><xref derivedContent="3.5.1" format="counter" sectionFormat="of" target="section-3.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-attester-role">Attester Role</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.5.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.5.2.2.1"><xref derivedContent="3.5.2" format="counter" sectionFormat="of" target="section-3.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-issuer-role">Issuer Role</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.5.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.5.2.3.1"><xref derivedContent="3.5.3" format="counter" sectionFormat="of" target="section-3.5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-issuance-metadata">Issuance Metadata</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.5.2.4">
                    <t indent="0" pn="section-toc.1-1.3.2.5.2.4.1"><xref derivedContent="3.5.4" format="counter" sectionFormat="of" target="section-3.5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-future-issuance-protocol-re">Future Issuance Protocol Requirements</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.6">
                <t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-information-flow">Information Flow</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.6.2">
                  <li pn="section-toc.1-1.3.2.6.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.1.1"><xref derivedContent="3.6.1" format="counter" sectionFormat="of" target="section-3.6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-challenge-flow">Token Challenge Flow</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.2.1"><xref derivedContent="3.6.2" format="counter" sectionFormat="of" target="section-3.6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-attestation-flow">Attestation Flow</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.3.1"><xref derivedContent="3.6.3" format="counter" sectionFormat="of" target="section-3.6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-issuance-flow">Issuance Flow</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.4">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.4.1"><xref derivedContent="3.6.4" format="counter" sectionFormat="of" target="section-3.6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-redemption-flow">Token Redemption Flow</xref></t>
                  </li>
                </ul>
              </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-deployment-models">Deployment Models</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-shared-origin-attester-issu">Shared Origin, Attester, Issuer</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-joint-attester-and-issuer">Joint Attester and Issuer</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-joint-origin-and-issuer">Joint Origin and Issuer</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-split-origin-attester-issue">Split Origin, Attester, Issuer</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-deployment-considerations">Deployment 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-discriminatory-treatment">Discriminatory Treatment</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-centralization">Centralization</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-privacy-considerations">Privacy 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-partitioning-by-issuance-me">Partitioning by Issuance Metadata</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-partitioning-by-issuance-co">Partitioning by Issuance Consistency</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-partitioning-by-side-channe">Partitioning by Side Channels</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-caching">Token Caching</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Privacy Pass is an architecture for authorization based on privacy-preserving
authentication mechanisms. In other words, relying parties authenticate Clients
in a privacy-preserving way, i.e., without learning any unique, per-Client
information through the authentication protocol, and then make authorization
decisions on the basis of that authentication succeeding or failing. Possible
authorization decisions might be to provide Clients with read access to a
particular resource or write access to a particular resource.</t>
      <t indent="0" pn="section-1-2">Typical approaches for authorizing Clients, such as through the use of long-term
state (cookies), are not privacy friendly, since they allow servers to track
Clients across sessions and interactions. Privacy Pass takes a different
approach: instead of presenting linkable state-carrying information to servers,
e.g., a cookie indicating whether or not the Client is an authorized user or
has completed some prior challenge, Clients present unlinkable proofs that
attest to this information. These proofs, or tokens, are private in the sense
that a given token cannot be linked to the protocol interaction where that
token was initially issued.</t>
      <t indent="0" pn="section-1-3">At a high level, the Privacy Pass architecture consists of two protocols:
redemption and issuance. The redemption protocol, described in
<xref target="RFC9577" format="default" sectionFormat="of" derivedContent="AUTHSCHEME"/>, runs between Clients and
Origins (servers). It allows Origins to challenge Clients to present tokens
for consumption. Origins verify the token to authenticate the Client -- without
learning any specific information about the Client -- and then make an authorization
decision on the basis of the token verifying successfully or not. Depending
on the type of token, e.g., whether or not it can be cached, the Client
either presents a previously obtained token or invokes an issuance protocol,
e.g., the protocols described in <xref target="RFC9578" format="default" sectionFormat="of" derivedContent="ISSUANCE"/>, to acquire a token to
present as authorization.</t>
      <t indent="0" pn="section-1-4">This document describes requirements for both redemption and issuance
protocols and how they interact. It also provides recommendations on how
the architecture should be deployed to ensure the privacy of Clients and
the security of all participating entities.</t>
    </section>
    <section anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-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-2-2">The following terms are used throughout this document:</t>
      <dl indent="3" newline="false" spacing="normal" pn="section-2-3">
        <dt pn="section-2-3.1">Client:</dt>
        <dd pn="section-2-3.2">
          <t indent="0" pn="section-2-3.2.1">An entity that seeks authorization to an Origin. Using terminology from <xref target="RFC9334" format="default" sectionFormat="of" derivedContent="RFC9334"/>,
Clients implement the Remote ATtestation procedureS (RATS) Attester role.</t>
        </dd>
        <dt pn="section-2-3.3">Token:</dt>
        <dd pn="section-2-3.4">
          <t indent="0" pn="section-2-3.4.1">A cryptographic authentication message used for authorization decisions,
produced as output from an issuance mechanism or protocol.</t>
        </dd>
        <dt pn="section-2-3.5">Origin:</dt>
        <dd pn="section-2-3.6">
          <t indent="0" pn="section-2-3.6.1">An entity that consumes tokens presented by Clients and uses them to make authorization decisions.</t>
        </dd>
        <dt pn="section-2-3.7">Token challenge:</dt>
        <dd pn="section-2-3.8">
          <t indent="0" pn="section-2-3.8.1">The mechanism by which Origins request tokens from Clients, often denoted TokenChallenge.</t>
        </dd>
        <dt pn="section-2-3.9">Token request:</dt>
        <dd pn="section-2-3.10">
          <t indent="0" pn="section-2-3.10.1">A message used by Clients to request a token from an Issuer, often denoted TokenRequest.</t>
        </dd>
        <dt pn="section-2-3.11">Token response:</dt>
        <dd pn="section-2-3.12">
          <t indent="0" pn="section-2-3.12.1">A message used by Issuers to send tokens to a Client, often denoted TokenResponse.</t>
        </dd>
        <dt pn="section-2-3.13">Redemption:</dt>
        <dd pn="section-2-3.14">
          <t indent="0" pn="section-2-3.14.1">The mechanism by which Clients present tokens to Origins for the
purposes of authorization.</t>
        </dd>
        <dt pn="section-2-3.15">Issuer:</dt>
        <dd pn="section-2-3.16">
          <t indent="0" pn="section-2-3.16.1">An entity that issues tokens to Clients for properties
attested to by the Attester.</t>
        </dd>
        <dt pn="section-2-3.17">Issuance:</dt>
        <dd pn="section-2-3.18">
          <t indent="0" pn="section-2-3.18.1">The mechanism by which an Issuer produces tokens for Clients.</t>
        </dd>
        <dt pn="section-2-3.19">Attester:</dt>
        <dd pn="section-2-3.20">
          <t indent="0" pn="section-2-3.20.1">An entity that attests to properties of Clients for the
purposes of token issuance. Using terminology from <xref target="RFC9334" format="default" sectionFormat="of" derivedContent="RFC9334"/>, Attesters implement the RATS Verifier role.</t>
        </dd>
        <dt pn="section-2-3.21">Attestation procedure:</dt>
        <dd pn="section-2-3.22">
          <t indent="0" pn="section-2-3.22.1">The procedure by which an Attester determines whether or not a Client
has the specific set of properties that are necessary for token issuance.</t>
        </dd>
      </dl>
      <t indent="0" pn="section-2-4">The trust relationships between each of the entities in this list are further
elaborated upon in <xref target="privacy-and-trust" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.</t>
    </section>
    <section anchor="architecture" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-architecture">Architecture</name>
      <t indent="0" pn="section-3-1">The Privacy Pass architecture consists of four logical entities --
Client, Origin, Issuer, and Attester -- that work in concert
for token redemption and issuance. This section presents an overview
of Privacy Pass, a high-level description of the threat model and
privacy goals of the architecture, and the goals and requirements of
the redemption and issuance protocols. Deployment variations for the
Origin, Issuer, and Attester in this architecture, including
considerations for implementing these entities, are further discussed
in <xref target="deployment" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
      <section anchor="overview" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-overview">Overview</name>
        <t indent="0" pn="section-3.1-1">This section describes the typical interaction flow for Privacy Pass, as shown in <xref target="fig-overview" format="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.1-2"><li pn="section-3.1-2.1" derivedCounter="1.">A Client interacts with an Origin by sending a request or otherwise
interacting with the Origin in a way that triggers a response containing
a token challenge. The token challenge indicates a specific Issuer to use.</li>
          <li pn="section-3.1-2.2" derivedCounter="2.">If the Client already has a token available that satisfies the token
challenge, e.g., because the Client has a cache of previously issued tokens,
it can skip to <xref format="none" target="step-redemption" sectionFormat="of" derivedContent="">step 6</xref> and redeem its
token; see <xref target="hoarding" format="default" sectionFormat="of" derivedContent="Section 7.1"/> for security considerations regarding cached tokens.</li>
          <li pn="section-3.1-2.3" derivedCounter="3.">If the Client does not have a token available and decides it wants to
obtain one (or more) bound to the token challenge, it then invokes the
issuance protocol. As a prerequisite to the issuance protocol, the Client
runs the deployment-specific attestation process that is required for the
designated Issuer. Client attestation can be done via proof of solving a
CAPTCHA, checking device or hardware attestation validity, etc.; see
<xref target="attester" format="default" sectionFormat="of" derivedContent="Section 3.5.1"/> for more details.</li>
          <li pn="section-3.1-2.4" derivedCounter="4.">If the attestation process completes successfully, the Client creates a
token request to send to the designated Issuer (generally via the Attester,
though it is not required to be sent through the Attester).
The Attester and Issuer might be functions on the same server, depending on the
deployment model (see <xref target="deployment" format="default" sectionFormat="of" derivedContent="Section 4"/>). Depending on the attestation process, it
is possible for attestation to run alongside the issuance protocol, e.g., where
Clients send necessary attestation information to the Attester along with their
token request. If the attestation process fails, the Client receives an error
and issuance aborts without a token.</li>
          <li pn="section-3.1-2.5" derivedCounter="5.">The Issuer generates a token response based on the token request, which
is returned to the Client (generally via the Attester). Upon receiving the
token response, the Client computes a token from the token challenge and token
response. This token can be validated by anyone with the per-Issuer key but
cannot be linked to the content of the token request or token response.</li>
          <li pn="section-3.1-2.6" derivedCounter="6.">
            <t anchor="step-redemption" indent="0" pn="section-3.1-2.6.1">If the Client has a token, it includes it in a subsequent request to
the Origin, as authorization. This token is sent only once in reaction to a
challenge; Clients do not send tokens more than once, even if they receive
duplicate or redundant challenges. The Origin
validates that the token was generated by the expected Issuer and has not
already been redeemed for the corresponding token challenge.  If the Client
does not have a token, perhaps because issuance failed, the Client does not
reply to the Origin's challenge with a new request.</t>
          </li>
        </ol>
        <figure anchor="fig-overview" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-privacy-pass-redemption-and">Privacy Pass Redemption and Issuance Protocol Interaction</name>
          <artset pn="section-3.1-3.1">
            <artwork type="svg" align="left" pn="section-3.1-3.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 520 224" 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,208" 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 216,64 L 216,208" fill="none" stroke="black"/>
                <path d="M 256,32 L 256,64" fill="none" stroke="black"/>
                <path d="M 336,32 L 336,64" fill="none" stroke="black"/>
                <path d="M 376,64 L 376,144" fill="none" stroke="black"/>
                <path d="M 376,192 L 376,208" fill="none" stroke="black"/>
                <path d="M 424,32 L 424,64" fill="none" stroke="black"/>
                <path d="M 440,32 L 440,64" fill="none" stroke="black"/>
                <path d="M 472,64 L 472,208" fill="none" stroke="black"/>
                <path d="M 512,32 L 512,64" fill="none" stroke="black"/>
                <path d="M 8,32 L 80,32" fill="none" stroke="black"/>
                <path d="M 184,32 L 256,32" fill="none" stroke="black"/>
                <path d="M 336,32 L 424,32" fill="none" stroke="black"/>
                <path d="M 440,32 L 512,32" fill="none" stroke="black"/>
                <path d="M 8,64 L 80,64" fill="none" stroke="black"/>
                <path d="M 184,64 L 256,64" fill="none" stroke="black"/>
                <path d="M 336,64 L 424,64" fill="none" stroke="black"/>
                <path d="M 440,64 L 512,64" fill="none" stroke="black"/>
                <path d="M 48,96 L 88,96" fill="none" stroke="black"/>
                <path d="M 168,96 L 216,96" fill="none" stroke="black"/>
                <path d="M 40,112 L 56,112" fill="none" stroke="black"/>
                <path d="M 192,112 L 208,112" fill="none" stroke="black"/>
                <path d="M 224,126 L 240,126" fill="none" stroke="black"/>
                <path d="M 224,130 L 240,130" fill="none" stroke="black"/>
                <path d="M 352,126 L 368,126" fill="none" stroke="black"/>
                <path d="M 352,130 L 368,130" fill="none" stroke="black"/>
                <path d="M 216,160 L 288,160" fill="none" stroke="black"/>
                <path d="M 408,160 L 464,160" fill="none" stroke="black"/>
                <path d="M 224,176 L 288,176" fill="none" stroke="black"/>
                <path d="M 416,176 L 472,176" fill="none" stroke="black"/>
                <path d="M 48,192 L 64,192" fill="none" stroke="black"/>
                <path d="M 192,192 L 216,192" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="472,160 460,154.4 460,165.6" fill="black" transform="rotate(0,464,160)"/>
                <polygon class="arrowhead" points="376,128 364,122.4 364,133.6" fill="black" transform="rotate(0,368,128)"/>
                <polygon class="arrowhead" points="232,176 220,170.4 220,181.6" fill="black" transform="rotate(180,224,176)"/>
                <polygon class="arrowhead" points="232,128 220,122.4 220,133.6" fill="black" transform="rotate(180,224,128)"/>
                <polygon class="arrowhead" points="216,112 204,106.4 204,117.6" fill="black" transform="rotate(0,208,112)"/>
                <polygon class="arrowhead" points="56,192 44,186.4 44,197.6" fill="black" transform="rotate(180,48,192)"/>
                <polygon class="arrowhead" points="56,96 44,90.4 44,101.6" fill="black" transform="rotate(180,48,96)"/>
                <g class="text">
                  <text x="44" y="52">Origin</text>
                  <text x="220" y="52">Client</text>
                  <text x="380" y="52">Attester</text>
                  <text x="476" y="52">Issuer</text>
                  <text x="128" y="100">Request</text>
                  <text x="124" y="116">TokenChallenge</text>
                  <text x="296" y="132">Attestation</text>
                  <text x="348" y="164">TokenRequest</text>
                  <text x="352" y="180">TokenResponse</text>
                  <text x="128" y="196">Request+Token</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="left" pn="section-3.1-3.1.2">
+--------+            +--------+         +----------+ +--------+
| Origin |            | Client |         | Attester | | Issuer |
+---+----+            +---+----+         +----+-----+ +---+----+
    |                     |                   |           |
    |&lt;----- Request ------+                   |           |
    +-- TokenChallenge --&gt;|                   |           |
    |                     |&lt;== Attestation ==&gt;|           |
    |                     |                   |           |
    |                     +--------- TokenRequest -------&gt;|
    |                     |&lt;-------- TokenResponse -------+
    |&lt;-- Request+Token ---+                   |           |
    |                     |                   |           |
</artwork>
          </artset>
        </figure>
      </section>
      <section anchor="use-cases" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-use-cases">Use Cases</name>
        <t indent="0" pn="section-3.2-1">Use cases for Privacy Pass are broad and depend greatly on the deployment model
as discussed in <xref target="deployment" format="default" sectionFormat="of" derivedContent="Section 4"/>. The initial motivating use case for Privacy Pass
<xref target="PrivacyPassCloudflare" format="default" sectionFormat="of" derivedContent="PrivacyPassCloudflare"/> was to help rate-limit malicious or otherwise abusive
traffic from services such as Tor <xref target="DMS2004" format="default" sectionFormat="of" derivedContent="DMS2004"/>. The generalized and evolved
architecture described in this document also works for this use case. However,
for added clarity, some more possible use cases are described below.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-2">
          <li pn="section-3.2-2.1">Low-quality, anti-fraud signal for open Internet services. Tokens can attest that
the Client behind the user agent is likely not a bot attempting to perform some
form of automated attack such as credential stuffing. Example attestation procedures
for this use case might be solving some form of CAPTCHA or presenting evidence of a
valid, unlocked device in good standing.</li>
          <li pn="section-3.2-2.2">Privacy-preserving authentication for proprietary services. Tokens can attest that
the Client is a valid subscriber for a proprietary service, such as a deployment of
Oblivious HTTP <xref target="RFC9458" format="default" sectionFormat="of" derivedContent="OHTTP"/>.</li>
        </ul>
      </section>
      <section anchor="privacy-and-trust" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-privacy-goals-and-threat-mo">Privacy Goals and Threat Model</name>
        <t indent="0" pn="section-3.3-1">The end-to-end flow for Privacy Pass described in <xref target="overview" format="default" sectionFormat="of" derivedContent="Section 3.1"/> involves three
different types of contexts:</t>
        <dl indent="3" newline="false" spacing="normal" pn="section-3.3-2">
          <dt pn="section-3.3-2.1">Redemption context:</dt>
          <dd pn="section-3.3-2.2">
            <t indent="0" pn="section-3.3-2.2.1">The interactions and set of information shared
between the Client and Origin, i.e., the information that is provided or
otherwise available to the Origin during redemption that might be used
to identify a Client and construct a token challenge. This context includes all
information associated with redemption, such as the timestamp of the event,
Client-visible information (including the IP address), and the Origin name.</t>
          </dd>
          <dt pn="section-3.3-2.3">Issuance context:</dt>
          <dd pn="section-3.3-2.4">
            <t indent="0" pn="section-3.3-2.4.1">The interactions and set of information shared between the Client, Attester,
and Issuer, i.e., the information that is provided or otherwise available
to the Attester and Issuer during issuance that might be used to identify a Client.
This context includes all information associated with issuance, such as the
timestamp of the event, any Client-visible information (including the IP
address), and the Origin name (if revealed during issuance). This does not
include the token challenge in its entirety, as that is kept secret from the
Issuer during the issuance protocol.</t>
          </dd>
          <dt pn="section-3.3-2.5">Attestation context:</dt>
          <dd pn="section-3.3-2.6">
            <t indent="0" pn="section-3.3-2.6.1">The interactions and set of information shared between
the Client and Attester only, for the purposes of attesting the validity of
the Client, that is provided or otherwise available during attestation that
might be used to identify the Client. This context includes all information
associated with attestation, such as the timestamp of the event and any
Client-visible information, including information needed for the attestation
procedure to complete.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-3.3-3">The privacy goals of Privacy Pass assume a threat model in which Origins trust
specific Issuers to produce tokens, and Issuers in turn trust one or more
Attesters to correctly run the attestation procedure with Clients. This
arrangement ensures that tokens that validate for a given Issuer were only
issued to a Client that successfully completed attestation with an Attester
that the Issuer trusts. Moreover, this arrangement means that if an Origin
accepts tokens issued by an Issuer that trusts multiple Attesters, then a
Client can use any one of these Attesters to issue and redeem tokens for the
Origin. Whether or not these different entities in the architecture collude
for learning redemption, issuance, or attestation contexts, as well as the
necessary preconditions for context unlinkability, depends on the deployment
model; see <xref target="deployment" format="default" sectionFormat="of" derivedContent="Section 4"/> for more details.</t>
        <t indent="0" pn="section-3.3-4">The mechanisms for establishing trust between each entity in this arrangement
are deployment specific. For example, in settings where Clients interact with
Issuers through an Attester, Attesters and Issuers might use
mutually authenticated TLS to authenticate one another. In settings where
Clients do not communicate with Issuers through an Attester, the Attesters
might convey this trust via a digital signature that Issuers can verify.</t>
        <t indent="0" pn="section-3.3-5">Clients explicitly trust Attesters to perform attestation correctly and in a
way that does not violate their privacy. In particular, this means that Attesters
that may be privy to private information about Clients are trusted to not disclose
this information to non-colluding parties. Colluding parties are assumed to have
access to the same information; see <xref target="deployment" format="default" sectionFormat="of" derivedContent="Section 4"/> for more about different
deployment models and non-collusion assumptions. However, Clients assume that Issuers and
Origins are malicious.</t>
        <t indent="0" pn="section-3.3-6">Given this threat model, the privacy goals of Privacy Pass are oriented around
unlinkability based on redemption, issuance, and attestation contexts, as
described below.</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.3-7"><li pn="section-3.3-7.1" derivedCounter="1.">Origin-Client unlinkability. This means that given two redemption contexts,
the Origin cannot determine if both redemption contexts correspond to the same
Client or two different Clients. Informally, this means that a Client in a
redemption context is indistinguishable from any other Client that might use
the same redemption context. The set of Clients that share the same redemption
context is referred to as a redemption anonymity set.</li>
          <li pn="section-3.3-7.2" derivedCounter="2.">Issuer-Client unlinkability. This is similar to Origin-Client unlinkability
in that a Client in an issuance context is indistinguishable from any other
Client that might use the same issuance context. The set of Clients that share
the same issuance context is referred to as an issuance anonymity set.</li>
          <li pn="section-3.3-7.3" derivedCounter="3.">Attester-Origin unlinkability. This is similar to Origin-Client and
Issuer-Client unlinkability. It means that given two attestation contexts,
the Attester cannot determine if both contexts correspond to the same Origin
or two different Origins. The set of Origins that share the same attestation
context is referred to as an attestation anonymity set.</li>
          <li pn="section-3.3-7.4" derivedCounter="4.">Redemption context unlinkability. Given two redemption contexts, the Origin
cannot determine which issuance and attestation contexts each redemption
corresponds to, even with the collaboration of the Issuer and Attester (should
these be different parties). This means that any information that may be learned
about the Client during the issuance and attestation flows cannot be used by the
Origin to compromise Client privacy.</li>
        </ol>
        <t indent="0" pn="section-3.3-8">These unlinkability properties ensure that only the Clients are able to correlate
information that might be used to identify them with activity on the Origin.
The Attester, Issuer, and Origin only receive the information necessary to perform
their respective functions.</t>
        <t indent="0" pn="section-3.3-9">The manner in which these unlinkability properties are achieved depends on the
deployment model, type of attestation, and issuance protocol details. For example,
as discussed in <xref target="deployment" format="default" sectionFormat="of" derivedContent="Section 4"/>, in some cases it is necessary to use an anonymization
service that hides Client IP addresses, such as Tor <xref target="DMS2004" format="default" sectionFormat="of" derivedContent="DMS2004"/>. In general,
anonymization services ensure that all Clients that use the service are indistinguishable
from one another, though in practice there may be small distinguishing features
(TLS fingerprints, HTTP headers, etc.). Moreover, Clients generally trust these services
to not disclose private Client information (such as IP addresses) to untrusted parties.
Failure to use an anonymization service when interacting with Attesters, Issuers, or
Origins can allow the set of possible Clients to be partitioned by the Client's IP address
and can therefore lead to unlinkability violations. Similarly, malicious Origins
may attempt to link two redemption contexts together by using Client-specific
Issuer Public Keys. See Sections <xref target="deployment-considerations" format="counter" sectionFormat="of" derivedContent="5"/> and <xref target="privacy" format="counter" sectionFormat="of" derivedContent="6"/> for more
information.</t>
        <t indent="0" pn="section-3.3-10">Sections <xref target="redemption" format="counter" sectionFormat="of" derivedContent="3.4"/> and <xref target="issuance-protocol" format="counter" sectionFormat="of" derivedContent="3.5"/> describe the functional properties and security
requirements of the redemption and issuance protocols in more detail. <xref target="flow" format="default" sectionFormat="of" derivedContent="Section 3.6"/>
describes how information flows between the Issuer, Origin, Client, and Attester
through these protocols.</t>
      </section>
      <section anchor="redemption" numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-redemption-protocol">Redemption Protocol</name>
        <t indent="0" pn="section-3.4-1">The Privacy Pass redemption protocol, described in
<xref target="RFC9577" format="default" sectionFormat="of" derivedContent="AUTHSCHEME"/>, is an authorization protocol
wherein Clients present tokens to Origins for authorization. Normally,
redemption is preceded by a challenge, wherein the Origin challenges
Clients for a token with a TokenChallenge (<xref section="2.1" sectionFormat="comma" target="RFC9577" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9577#section-2.1" derivedContent="AUTHSCHEME"/>) and,
if possible, Clients present a valid token (<xref section="2.2" sectionFormat="comma" target="RFC9577" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9577#section-2.2" derivedContent="AUTHSCHEME"/>)
in reaction to the challenge. This interaction is shown below.</t>
        <figure anchor="fig-redemption" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-challenge-and-redemption-pr">Challenge and Redemption Protocol Interaction</name>
          <artset pn="section-3.4-2.1">
            <artwork type="svg" align="left" pn="section-3.4-2.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 432 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 216,64 L 216,160" fill="none" stroke="black"/>
                <path d="M 256,32 L 256,64" fill="none" stroke="black"/>
                <path d="M 8,32 L 80,32" fill="none" stroke="black"/>
                <path d="M 184,32 L 256,32" fill="none" stroke="black"/>
                <path d="M 8,64 L 80,64" fill="none" stroke="black"/>
                <path d="M 184,64 L 256,64" fill="none" stroke="black"/>
                <path d="M 48,96 L 88,96" fill="none" stroke="black"/>
                <path d="M 168,96 L 216,96" fill="none" stroke="black"/>
                <path d="M 40,112 L 56,112" fill="none" stroke="black"/>
                <path d="M 192,112 L 208,112" fill="none" stroke="black"/>
                <path d="M 232,126 L 248,126" fill="none" stroke="black"/>
                <path d="M 232,130 L 248,130" fill="none" stroke="black"/>
                <path d="M 408,126 L 424,126" fill="none" stroke="black"/>
                <path d="M 408,130 L 424,130" fill="none" stroke="black"/>
                <path d="M 48,144 L 64,144" fill="none" stroke="black"/>
                <path d="M 192,144 L 216,144" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="432,128 420,122.4 420,133.6" fill="black" transform="rotate(0,424,128)"/>
                <polygon class="arrowhead" points="240,128 228,122.4 228,133.6" fill="black" transform="rotate(180,232,128)"/>
                <polygon class="arrowhead" points="216,112 204,106.4 204,117.6" fill="black" transform="rotate(0,208,112)"/>
                <polygon class="arrowhead" points="56,144 44,138.4 44,149.6" fill="black" transform="rotate(180,48,144)"/>
                <polygon class="arrowhead" points="56,96 44,90.4 44,101.6" fill="black" transform="rotate(180,48,96)"/>
                <g class="text">
                  <text x="44" y="52">Origin</text>
                  <text x="220" y="52">Client</text>
                  <text x="128" y="100">Request</text>
                  <text x="124" y="116">TokenChallenge</text>
                  <text x="292" y="132">Issuance</text>
                  <text x="364" y="132">protocol</text>
                  <text x="128" y="148">Request+Token</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="left" pn="section-3.4-2.1.2">
+--------+            +--------+
| Origin |            | Client |
+---+----+            +---+----+
    |                     |
    |&lt;----- Request ------+
    +-- TokenChallenge --&gt;|
    |                     | &lt;== Issuance protocol ==&gt;
    |&lt;-- Request+Token ---+
    |                     |
</artwork>
          </artset>
        </figure>
        <t indent="0" pn="section-3.4-3">Alternatively, when configured to do so, Clients may opportunistically present
token values to Origins without a corresponding TokenChallenge.</t>
        <t indent="0" pn="section-3.4-4">The structure and semantics of the TokenChallenge and token messages depend
on the issuance protocol and token type being used; see <xref target="RFC9577" format="default" sectionFormat="of" derivedContent="AUTHSCHEME"/> for
more information.</t>
        <t indent="0" pn="section-3.4-5">The challenge provides the Client with the information necessary to obtain
tokens that the server might subsequently accept in the redemption context.
There are a number of ways in which the token may vary based on this challenge,
including the following:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.4-6">
          <li pn="section-3.4-6.1">Issuance protocol. The challenge identifies the type of issuance protocol
required for producing the token. Different issuance protocols have different
security properties, e.g., some issuance protocols may produce tokens that
are publicly verifiable, whereas others may not have this property.</li>
          <li pn="section-3.4-6.2">Issuer identity. Token challenges identify which Issuers are trusted for a
given issuance protocol. As described in <xref target="privacy-and-trust" format="default" sectionFormat="of" derivedContent="Section 3.3"/>, the choice
of Issuer determines the type of Attesters and attestation procedures possible
for a token from the specified Issuer, but the Origin does not learn exactly
which Attester was used for a given token issuance event.</li>
          <li pn="section-3.4-6.3">Redemption context. Challenges can be bound to a given redemption context,
which influences a Client's ability to pre-fetch and cache tokens. For
example, an empty redemption context always allows tokens to be issued and
redeemed non-interactively, whereas a fresh and random redemption context
means that the redeemed token must be issued only after the Client receives
the challenge. See <xref section="2.1.1" sectionFormat="of" target="RFC9577" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9577#section-2.1.1" derivedContent="AUTHSCHEME"/> for more details.</li>
          <li pn="section-3.4-6.4">Per-Origin or cross-Origin. Challenges can be constrained to the Origin for
which the challenge originated (referred to as per-Origin tokens) or
can be used across multiple Origins (referred to as cross-Origin tokens).
The set of Origins for which a cross-Origin token is applicable is referred
to as the cross-Origin set. Opting into this set is done by explicitly agreeing
on the contents of the set. Every Origin in a cross-Origin set, by opting in,
agrees to admit tokens for any other Origin in the set. See
<xref section="2.1.1" sectionFormat="of" target="RFC9577" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9577#section-2.1.1" derivedContent="AUTHSCHEME"/> for more information on how this set is created.</li>
        </ul>
        <t indent="0" pn="section-3.4-7">Origins that admit cross-Origin tokens bear some risk of allowing tokens
issued for one Origin to be spent in an interaction with another Origin.
In particular, cross-Origin tokens issued based on a challenge for
one Origin can be redeemed at another Origin in the cross-Origin set,
which can make it difficult to regulate token consumption. Depending on the
use case, Origins may need to maintain state to track redeemed tokens. For
example, Origins that accept cross-Origin tokens across shared redemption
contexts <bcp14>SHOULD</bcp14> track which tokens have already been redeemed in those
redemption contexts, since these tokens can be issued and then spent multiple
times for any such challenge. Note that Clients that redeem the
same token to multiple Origins do risk those Origins being able to link
Client activity together, which can disincentivize this behavior. See
<xref section="2.1.1" sectionFormat="of" target="RFC9577" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9577#section-2.1.1" derivedContent="AUTHSCHEME"/> for discussion.</t>
        <t indent="0" pn="section-3.4-8">How Clients respond to token challenges can have privacy implications.
For example, if an Origin allows the Client to choose an Issuer, then the choice
of Issuer can reveal information about the Client used to partition anonymity
sets; see <xref target="rotation-and-consistency" format="default" sectionFormat="of" derivedContent="Section 6.2"/> for more information about these privacy
considerations.</t>
      </section>
      <section anchor="issuance-protocol" numbered="true" removeInRFC="false" toc="include" pn="section-3.5">
        <name slugifiedName="name-issuance-protocol">Issuance Protocol</name>
        <t indent="0" pn="section-3.5-1">The Privacy Pass issuance protocols, such as those described in <xref target="RFC9578" format="default" sectionFormat="of" derivedContent="ISSUANCE"/>, are two-message
protocols that take as input a TokenChallenge from the redemption protocol
(<xref section="2.1" sectionFormat="comma" target="RFC9577" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9577#section-2.1" derivedContent="AUTHSCHEME"/>) and produce a token
(<xref section="2.2" sectionFormat="comma" target="RFC9577" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9577#section-2.2" derivedContent="AUTHSCHEME"/>), as shown in <xref target="fig-overview" format="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
        <t indent="0" pn="section-3.5-2">The structure and semantics of the TokenRequest and TokenResponse messages
depend on the issuance protocol and token type being used; see <xref target="RFC9578" format="default" sectionFormat="of" derivedContent="ISSUANCE"/>
for more information.</t>
        <t indent="0" pn="section-3.5-3">Clients interact with the Attester and Issuer to produce a token for
a challenge. The context in which an Attester vouches for a Client during
issuance is referred to as the attestation context. This context includes all
information associated with the issuance event, such as the timestamp of the
event and Client-visible information, including the IP address or other
information specific to the type of attestation done.</t>
        <t indent="0" pn="section-3.5-4">Each issuance protocol may be different, e.g., in the number and types of
participants, underlying cryptographic constructions used when issuing tokens,
and even privacy properties.</t>
        <t indent="0" pn="section-3.5-5">Clients initiate the issuance protocol using the token challenge, a randomly
generated nonce, and a public key for the Issuer, all of which are the Client's
private input to the protocol and ultimately bound to an output token;
see <xref section="2.2" sectionFormat="of" target="RFC9577" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9577#section-2.2" derivedContent="AUTHSCHEME"/> for details. Future specifications
may change or extend the Client's input to the issuance protocol to produce
tokens with a different structure.</t>
        <t indent="0" pn="section-3.5-6">Token properties vary based on the issuance protocol. Important properties
supported in this architecture are described below.</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.5-7"><li pn="section-3.5-7.1" derivedCounter="1.">Public verifiability. This means that the token can be verified using the Issuer
Public Key. A token that does not have public verifiability can only be verified
using the Issuer secret key.</li>
          <li pn="section-3.5-7.2" derivedCounter="2.">Public metadata. This means that the token can be cryptographically bound to
arbitrary public information. See <xref target="metadata-privacy" format="default" sectionFormat="of" derivedContent="Section 6.1"/> for privacy considerations
regarding public metadata.</li>
          <li pn="section-3.5-7.3" derivedCounter="3.">Private metadata. This means that the token can be cryptographically bound to
arbitrary private information, i.e., information that the Client does not observe
during token issuance or redemption. See <xref target="metadata-privacy" format="default" sectionFormat="of" derivedContent="Section 6.1"/> for privacy
considerations regarding private metadata.</li>
        </ol>
        <t indent="0" pn="section-3.5-8">The issuance protocol itself can be any interactive protocol between the Client,
Issuer, or other parties that produces a valid token bound to the Client's
private input, subject to the following security requirements.</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.5-9"><li pn="section-3.5-9.1" derivedCounter="1.">Unconditional input secrecy. The issuance protocol <bcp14>MUST NOT</bcp14> reveal anything
about the Client's private input, including the challenge and nonce, to the
Attester or Issuer, regardless of the hardness assumptions of the underlying
cryptographic protocol(s). This property is sometimes also referred to as
blindness.</li>
          <li pn="section-3.5-9.2" derivedCounter="2.">One-more forgery security. The issuance protocol <bcp14>MUST NOT</bcp14> allow malicious
Clients or Attesters (acting as Clients) to forge tokens offline or otherwise
without interacting with the Issuer directly.</li>
          <li pn="section-3.5-9.3" derivedCounter="3.">Concurrent security. The issuance protocol <bcp14>MUST</bcp14> be safe to run concurrently
with arbitrarily many Clients, Attesters, and Issuers.</li>
        </ol>
        <t indent="0" pn="section-3.5-10">See <xref target="extensions" format="default" sectionFormat="of" derivedContent="Section 3.5.4"/> for requirements on new issuance protocol variants and
related extensions.</t>
        <t indent="0" pn="section-3.5-11">In the sections below, we describe the Attester and Issuer roles in more
detail.</t>
        <section anchor="attester" numbered="true" removeInRFC="false" toc="include" pn="section-3.5.1">
          <name slugifiedName="name-attester-role">Attester Role</name>
          <t indent="0" pn="section-3.5.1-1">In Privacy Pass, attestation is the process by which an Attester bears
witness to, confirms, or authenticates a Client so as to verify properties
about the Client that are required for issuance. Issuers trust Attesters
to perform attestation correctly, i.e., to implement attestation procedures
in such a way that those procedures are not subverted or bypassed by malicious Clients.</t>
          <t indent="0" pn="section-3.5.1-2"><xref target="RFC9334" format="default" sectionFormat="of" derivedContent="RFC9334"/> describes an architecture for attestation procedures. Using
that architecture as a conceptual basis, Clients are RATS Attesters that
produce attestation evidence, and Attesters are RATS Verifiers that
appraise the validity of attestation evidence.</t>
          <t indent="0" pn="section-3.5.1-3">The type of attestation procedure is a deployment-specific option and outside
the scope of the issuance protocol. Example attestation procedures are below.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.1-4">
            <li pn="section-3.5.1-4.1">Solving a CAPTCHA. Clients that solve CAPTCHA challenges can be attested to
have this capability for the purpose of being ruled out as a bot or otherwise
automated Client.</li>
            <li pn="section-3.5.1-4.2">Presenting evidence of Client device validity. Some Clients run on trusted
hardware that is capable of producing device-level attestation evidence.</li>
            <li pn="section-3.5.1-4.3">Proving properties about Client state. Clients can be associated with state,
and the Attester can verify this state. Examples of state include the
Client's geographic region and whether the Client has a valid
application-layer account.</li>
          </ul>
          <t indent="0" pn="section-3.5.1-5">Attesters may support different types of attestation procedures.</t>
          <t indent="0" pn="section-3.5.1-6">Each attestation procedure has different security properties. For
example, attesting to having a valid account is different from attesting to
running on trusted hardware. Supporting multiple attestation procedures is
an important step towards ensuring equitable access for Clients; see <xref target="discrimination" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.</t>
          <t indent="0" pn="section-3.5.1-7">The role of the Attester in the issuance protocol and its impact on privacy
depend on the type of attestation procedure, issuance protocol, and deployment
model. For instance, increasing the number of required attestation procedures
could decrease the overall anonymity set size. As an example, the number of Clients
that have solved a CAPTCHA in the past day, that have a valid account, and that
are running on a trusted device is less than the number of Clients that have
solved a CAPTCHA in the past day. See <xref target="rotation-and-consistency" format="default" sectionFormat="of" derivedContent="Section 6.2"/> for more discussion
of how the variety of attestation procedures can negatively impact Client privacy.</t>
          <t indent="0" pn="section-3.5.1-8">Depending on the issuance protocol, the Issuer might learn
information about the Origin. To ensure Issuer-Client unlinkability, the Issuer
should be unable to link that information to a specific Client. For such
issuance protocols where the Attester has access to Client-specific
information, such as is the case for attestation procedures that involve
Client-specific information (such as application-layer account information)
or for deployment models where the Attester learns Client-specific information
(such as Client IP addresses), Clients trust the Attester to not share any
Client-specific information with the Issuer. In deployments where the Attester
does not learn Client-specific information or where the Attester and Issuer are
operated by the same entity (such as in the Joint Attester and Issuer model
described in <xref target="deploy-joint-issuer" format="default" sectionFormat="of" derivedContent="Section 4.2"/>), the Client does not need to explicitly
trust the Attester in this regard.</t>
          <t indent="0" pn="section-3.5.1-9">Issuers trust Attesters to correctly and reliably perform attestation. However,
certain types of attestation procedures can vary in value over time, e.g., if the
attestation procedure is compromised. Broken
attestation procedures are considered exceptional events and require
configuration changes to address the underlying cause. For example, if
an attestation procedure is compromised or subverted because of a zero-day
exploit on devices that implement the attestation procedure, then the
corresponding attestation procedure should be untrusted until the exploit is
patched. Addressing changes in attestation quality is therefore a
deployment-specific task. In Split Origin, Attester, and Issuer deployments (see
<xref target="deploy-split" format="default" sectionFormat="of" derivedContent="Section 4.4"/>), Issuers can choose to remove compromised Attesters from
their trusted set until the compromise is patched.</t>
          <t indent="0" pn="section-3.5.1-10">From the perspective of an Origin, tokens produced by an Issuer with at least
one compromised Attester cannot be trusted, assuming that the Origin does not know
which attestation procedure was used for issuance. This is because the Origin
cannot distinguish between tokens that were issued via compromised Attesters
and tokens that were issued via uncompromised Attesters, absent some
distinguishing information in the tokens themselves or from the Issuer. As a
result, until the attestation procedure is fixed, the Issuer cannot be trusted
by Origins. Moreover, as a consequence, any tokens issued by an Issuer with a
compromised Attester may no longer be trusted by Origins, even if those tokens
were issued to Clients interacting with an uncompromised Attester.</t>
        </section>
        <section anchor="issuer-role" numbered="true" removeInRFC="false" toc="include" pn="section-3.5.2">
          <name slugifiedName="name-issuer-role">Issuer Role</name>
          <t indent="0" pn="section-3.5.2-1">In Privacy Pass, the Issuer is responsible for completing the issuance protocol
for Clients that complete attestation through a trusted Attester. As described
in <xref target="attester" format="default" sectionFormat="of" derivedContent="Section 3.5.1"/>, Issuers explicitly trust Attesters to correctly and reliably
perform attestation. Origins explicitly trust Issuers to only issue tokens
from trusted Attesters. Clients do not explicitly trust Issuers.</t>
          <t indent="0" pn="section-3.5.2-2">Depending on the deployment model case, issuance may require some form of
Client anonymization service, similar to an IP-hiding proxy, so that Issuers
cannot learn information about Clients. This can be provided by an explicit
participant in the issuance protocol, or it can be provided via external means,
such as through the use of an IP-hiding proxy service like Tor <xref target="DMS2004" format="default" sectionFormat="of" derivedContent="DMS2004"/>.
In general, Clients <bcp14>SHOULD</bcp14> minimize or remove identifying
information where possible when invoking the issuance protocol.</t>
          <t indent="0" pn="section-3.5.2-3">Issuers are uniquely identifiable by all Clients with a consistent
identifier. In a web context, this identifier might be the Issuer hostname.
Issuers maintain one or more configurations, including issuance key pairs, for
use in the issuance protocol. Each configuration is assumed to have a unique
and canonical identifier, sometimes referred to as a key identifier or key ID.
Issuers can rotate these configurations as needed to mitigate the risk of compromise;
see <xref target="rotation-and-consistency" format="default" sectionFormat="of" derivedContent="Section 6.2"/> for more considerations around configuration
rotation. The Issuer Public Key for each active configuration is made available
to Origins and Clients for use in the issuance and redemption protocols.</t>
        </section>
        <section anchor="metadata" numbered="true" removeInRFC="false" toc="include" pn="section-3.5.3">
          <name slugifiedName="name-issuance-metadata">Issuance Metadata</name>
          <t indent="0" pn="section-3.5.3-1">Certain instantiations of the issuance protocol may permit public or private
metadata to be cryptographically bound to a token. As an example, one
trivial way to include public metadata is to assign a unique Issuer
Public Key for each value of metadata, such that N keys yield
log<sub>2</sub>(N) bits of metadata. Metadata may be public or private.</t>
          <t indent="0" pn="section-3.5.3-2">Public metadata is metadata that Clients can observe as part of the token
issuance flow. Public metadata can be either transparent or opaque. For
example, transparent public metadata is a value that either the Client
generates itself or the Issuer provides during the issuance flow and that the
Client can check for correctness. Opaque public metadata is metadata
the Client can see but cannot check for correctness. As an example, the
opaque public metadata might be a "fraud detection signal", computed on
behalf of the Issuer, during token issuance. Generally speaking, Clients
cannot determine if this value is generated in a way that permits tracking.</t>
          <t indent="0" pn="section-3.5.3-3">Private metadata is metadata that Clients cannot observe as part of the token
issuance flow. Such instantiations can be built on the private metadata bit
construction from Kreuter et al. <xref target="KLOR20" format="default" sectionFormat="of" derivedContent="KLOR20"/>
or the attribute-based Verifiable Oblivious Pseudorandom Function (VOPRF) from Huang et al. <xref target="HIJK21" format="default" sectionFormat="of" derivedContent="HIJK21"/>.</t>
          <t indent="0" pn="section-3.5.3-4">Metadata can be arbitrarily long or bounded in length. The amount of permitted
metadata may be determined by an application or by the underlying cryptographic
protocol. The total amount of metadata bits included in a token is the sum of
public and private metadata bits. Every bit of metadata can be used to
partition the Client issuance or redemption anonymity sets; see
<xref target="metadata-privacy" format="default" sectionFormat="of" derivedContent="Section 6.1"/> for more information.</t>
        </section>
        <section anchor="extensions" numbered="true" removeInRFC="false" toc="include" pn="section-3.5.4">
          <name slugifiedName="name-future-issuance-protocol-re">Future Issuance Protocol Requirements</name>
          <t indent="0" pn="section-3.5.4-1">The Privacy Pass architecture and ecosystem are both intended to be receptive
to extensions that expand the current set of functionalities through new
issuance protocols. Each new issuance protocol and extension <bcp14>MUST</bcp14> adhere
to the following requirements:</t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.5.4-2"><li pn="section-3.5.4-2.1" derivedCounter="1.">Include a detailed analysis of the privacy impacts of the extension, why
these impacts are justified, and guidelines on how to use the protocol
to mitigate or minimize negative deployment or privacy consequences
discussed in Sections <xref target="deployment-considerations" format="counter" sectionFormat="of" derivedContent="5"/> and <xref target="privacy" format="counter" sectionFormat="of" derivedContent="6"/>, respectively.</li>
            <li pn="section-3.5.4-2.2" derivedCounter="2.">Adhere to the guidelines specified in <xref target="issuer-role" format="default" sectionFormat="of" derivedContent="Section 3.5.2"/> for managing Issuer
Public Key data.</li>
            <li pn="section-3.5.4-2.3" derivedCounter="3.">Clearly specify how to interpret and validate TokenChallenge and token
messages that are exchanged during the redemption protocol.</li>
          </ol>
        </section>
      </section>
      <section anchor="flow" numbered="true" removeInRFC="false" toc="include" pn="section-3.6">
        <name slugifiedName="name-information-flow">Information Flow</name>
        <t indent="0" pn="section-3.6-1">The end-to-end process of redemption and issuance protocols involves information
flowing between the Issuer, Origin, Client, and Attester. That information can
have implications on the privacy goals that Privacy Pass aims to provide
as outlined in <xref target="privacy-and-trust" format="default" sectionFormat="of" derivedContent="Section 3.3"/>. In this section, we describe the flow
of information between each party. How this information affects the privacy
goals in particular deployment models is further discussed in <xref target="deployment" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
        <section anchor="challenge-flow" numbered="true" removeInRFC="false" toc="include" pn="section-3.6.1">
          <name slugifiedName="name-token-challenge-flow">Token Challenge Flow</name>
          <t indent="0" pn="section-3.6.1-1">To use Privacy Pass, Origins choose an Issuer from which they are willing to
accept tokens. Origins then construct a token challenge using this specified
Issuer and information from the redemption context it shares with the Client.
This token challenge is then delivered to a Client. The token challenge conveys
information about the Issuer and the redemption context, such as whether the
Origin desires a per-Origin or cross-Origin token. Any entity that sees
the token challenge might learn things about the Client as known to the Origin.
This is why input secrecy is a requirement for issuance protocols, as it
ensures that the challenge is not directly available to the Issuer.</t>
        </section>
        <section anchor="attestation-flow" numbered="true" removeInRFC="false" toc="include" pn="section-3.6.2">
          <name slugifiedName="name-attestation-flow">Attestation Flow</name>
          <t indent="0" pn="section-3.6.2-1">Clients interact with the Attester to prove that they meet some required
set of properties. In doing so, Clients contribute information to the
attestation context, which might include sensitive information such as
application-layer identities, IP addresses, and so on. Clients can choose
whether or not to contribute this information based on local policy or
preference.</t>
        </section>
        <section anchor="issue-flow" numbered="true" removeInRFC="false" toc="include" pn="section-3.6.3">
          <name slugifiedName="name-issuance-flow">Issuance Flow</name>
          <t indent="0" pn="section-3.6.3-1">Clients use the issuance protocol to produce a token bound to a token
challenge. In doing so, there are several ways in which the issuance protocol
contributes information to the attestation or issuance contexts. For example, a
token request may contribute information to the attestation or issuance
contexts as described below.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.6.3-2">
            <li pn="section-3.6.3-2.1">Issuance protocol. The type of issuance protocol can contribute information
about the Issuer's capabilities to the attestation or issuance contexts, as
well as the capabilities of a given Client. For example, if a Client is
presented with multiple issuance protocol options, then the choice of which
issuance protocol to use can contribute information about the Client's
capabilities.</li>
            <li pn="section-3.6.3-2.2">Issuer configuration. Information about the Issuer configuration, such as
its identity or the public key used to validate tokens it creates, can be
revealed during issuance and contribute to the attestation or issuance
contexts.</li>
            <li pn="section-3.6.3-2.3">Attestation information. The issuance protocol can contribute information to
the attestation or issuance contexts based on what attestation procedure the
Issuer uses to trust a token request. In particular, a token request that is
validated by a given Attester means that the Client that generated the token
request must be capable of completing the designated attestation procedure.</li>
            <li pn="section-3.6.3-2.4">Origin information. The issuance protocol can contribute information about
the Origin that challenged the Client; see <xref target="challenge-flow" format="default" sectionFormat="of" derivedContent="Section 3.6.1"/>. In particular,
a token request designated for a specific Issuer might imply that the resulting
token is for an Origin that trusts the specified Issuer. However, this is not
always true, as some token requests can correspond to cross-Origin tokens,
i.e., they are tokens that would be accepted at any Origin that accepts the
cross-Origin token.</li>
          </ul>
          <t indent="0" pn="section-3.6.3-3">Moreover, a token may contribute information to the issuance attestation or
contexts as described below.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.6.3-4">
            <li pn="section-3.6.3-4.1">Origin information. The issuance protocol can contribute information about
the Origin in how it responds to a token request. For example, if an Issuer
learns the Origin during issuance and is also configured to respond in some way
on the basis of that information, and the Client interacts with the Issuer
transitively through the Attester, that response can reveal information to the
Attester.</li>
            <li pn="section-3.6.3-4.2">Token. The token produced by the issuance protocol can contain information
from the issuance context. In particular, depending on the issuance protocol,
tokens can contain public or private metadata, and Issuers can choose that
metadata on the basis of information in the issuance context.</li>
          </ul>
          <t indent="0" pn="section-3.6.3-5">Exceptional cases in the issuance protocol, such as when either the
Attester or Issuer aborts the protocol, can contribute information to the
attestation or issuance contexts. The extent to which information in this
context harms the Issuer-Client or Attester-Origin unlinkability goals as discussed in
<xref target="privacy-and-trust" format="default" sectionFormat="of" derivedContent="Section 3.3"/> depends on the deployment model; see <xref target="deployment" format="default" sectionFormat="of" derivedContent="Section 4"/>.
Clients can choose whether or not to contribute information to these contexts
based on local policy or preference.</t>
        </section>
        <section anchor="redemption-flow" numbered="true" removeInRFC="false" toc="include" pn="section-3.6.4">
          <name slugifiedName="name-token-redemption-flow">Token Redemption Flow</name>
          <t indent="0" pn="section-3.6.4-1">Clients send tokens to Origins during the redemption protocol. Any information
that is added to the token during issuance can therefore be sent to the Origin.
Information can be either (1) explicitly passed in a token or (2) implicit
in the way the Client responds to a token challenge. For example, if a Client
fails to complete issuance and consequently fails to redeem a token for
a token challenge, this can reveal information to the Origin that
it might not otherwise have access to. However, an Origin cannot necessarily
distinguish between a Client that fails to complete issuance and one that
ignores the token challenge altogether.</t>
        </section>
      </section>
    </section>
    <section anchor="deployment" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-deployment-models">Deployment Models</name>
      <t indent="0" pn="section-4-1">The Origin, Attester, and Issuer portrayed in <xref target="fig-overview" format="default" sectionFormat="of" derivedContent="Figure 1"/> can be
instantiated and deployed in a number of ways. The deployment model directly
influences the manner in which attestation, issuance, and redemption contexts
are separated to achieve Origin-Client, Issuer-Client, and Attester-Origin
unlinkability.</t>
      <t indent="0" pn="section-4-2">This section covers some expected deployment models and their corresponding
security and privacy considerations. Each deployment model is described in
terms of the trust relationships and communication patterns between the Client,
Attester, Issuer, and Origin. Entities drawn within the same bounding box are
assumed to be operated by the same party and are therefore able to collude.
Collusion can enable linking of attestation, issuance, and redemption contexts.
Entities not drawn within the same bounding box (i.e., operated by separate parties) are assumed to not collude. Mechanisms for enforcing non-collusion are out of scope for this architecture.</t>
      <section anchor="deploy-shared" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-shared-origin-attester-issu">Shared Origin, Attester, Issuer</name>
        <t indent="0" pn="section-4.1-1">In this model, the Origin, Attester, and Issuer are all operated by the same
entity, as shown in <xref target="fig-deploy-shared" format="default" sectionFormat="of" derivedContent="Figure 3"/>.</t>
        <figure anchor="fig-deploy-shared" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-shared-deployment-model">Shared Deployment Model</name>
          <artset pn="section-4.1-2.1">
            <artwork type="svg" align="left" pn="section-4.1-2.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 528 256" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,48 L 8,80" fill="none" stroke="black"/>
                <path d="M 40,80 L 40,240" fill="none" stroke="black"/>
                <path d="M 80,48 L 80,80" fill="none" stroke="black"/>
                <path d="M 144,32 L 144,80" fill="none" stroke="black"/>
                <path d="M 168,48 L 168,80" fill="none" stroke="black"/>
                <path d="M 216,80 L 216,104" fill="none" stroke="black"/>
                <path d="M 216,120 L 216,160" fill="none" stroke="black"/>
                <path d="M 256,48 L 256,80" fill="none" stroke="black"/>
                <path d="M 304,48 L 304,80" fill="none" stroke="black"/>
                <path d="M 344,80 L 344,96" fill="none" stroke="black"/>
                <path d="M 344,128 L 344,192" fill="none" stroke="black"/>
                <path d="M 376,48 L 376,80" fill="none" stroke="black"/>
                <path d="M 424,48 L 424,80" fill="none" stroke="black"/>
                <path d="M 456,80 L 456,208" fill="none" stroke="black"/>
                <path d="M 496,48 L 496,80" fill="none" stroke="black"/>
                <path d="M 520,48 L 520,80" fill="none" stroke="black"/>
                <path d="M 144,32 L 504,32" fill="none" stroke="black"/>
                <path d="M 8,48 L 80,48" fill="none" stroke="black"/>
                <path d="M 168,48 L 256,48" fill="none" stroke="black"/>
                <path d="M 304,48 L 376,48" fill="none" stroke="black"/>
                <path d="M 424,48 L 496,48" fill="none" stroke="black"/>
                <path d="M 8,80 L 80,80" fill="none" stroke="black"/>
                <path d="M 168,80 L 256,80" fill="none" stroke="black"/>
                <path d="M 304,80 L 376,80" fill="none" stroke="black"/>
                <path d="M 424,80 L 496,80" fill="none" stroke="black"/>
                <path d="M 160,96 L 208,96" fill="none" stroke="black"/>
                <path d="M 224,96 L 336,96" fill="none" stroke="black"/>
                <path d="M 352,96 L 448,96" fill="none" stroke="black"/>
                <path d="M 464,96 L 504,96" fill="none" stroke="black"/>
                <path d="M 48,112 L 304,112" fill="none" stroke="black"/>
                <path d="M 440,112 L 456,112" fill="none" stroke="black"/>
                <path d="M 48,142 L 72,142" fill="none" stroke="black"/>
                <path d="M 48,146 L 72,146" fill="none" stroke="black"/>
                <path d="M 184,142 L 208,142" fill="none" stroke="black"/>
                <path d="M 184,146 L 208,146" fill="none" stroke="black"/>
                <path d="M 40,176 L 128,176" fill="none" stroke="black"/>
                <path d="M 248,176 L 336,176" fill="none" stroke="black"/>
                <path d="M 48,192 L 128,192" fill="none" stroke="black"/>
                <path d="M 256,192 L 344,192" fill="none" stroke="black"/>
                <path d="M 40,224 L 208,224" fill="none" stroke="black"/>
                <path d="M 272,224 L 456,224" fill="none" stroke="black"/>
                <path d="M 504,32 C 512.83064,32 520,39.16936 520,48" fill="none" stroke="black"/>
                <path d="M 160,96 C 151.16936,96 144,88.83064 144,80" fill="none" stroke="black"/>
                <path d="M 504,96 C 512.83064,96 520,88.83064 520,80" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="464,224 452,218.4 452,229.6" fill="black" transform="rotate(0,456,224)"/>
                <polygon class="arrowhead" points="344,176 332,170.4 332,181.6" fill="black" transform="rotate(0,336,176)"/>
                <polygon class="arrowhead" points="216,144 204,138.4 204,149.6" fill="black" transform="rotate(0,208,144)"/>
                <polygon class="arrowhead" points="56,192 44,186.4 44,197.6" fill="black" transform="rotate(180,48,192)"/>
                <polygon class="arrowhead" points="56,144 44,138.4 44,149.6" fill="black" transform="rotate(180,48,144)"/>
                <polygon class="arrowhead" points="56,112 44,106.4 44,117.6" fill="black" transform="rotate(180,48,112)"/>
                <g class="text">
                  <text x="44" y="68">Client</text>
                  <text x="212" y="68">Attester</text>
                  <text x="340" y="68">Issuer</text>
                  <text x="460" y="68">Origin</text>
                  <text x="372" y="116">TokenChallenge</text>
                  <text x="128" y="148">Attestation</text>
                  <text x="188" y="180">TokenRequest</text>
                  <text x="192" y="196">TokenResponse</text>
                  <text x="240" y="228">Token</text>
                  <text x="456" y="244">|</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="left" pn="section-4.1-2.1.2">
                 +---------------------------------------------.
+--------+       |  +----------+     +--------+     +--------+  |
| Client |       |  | Attester |     | Issuer |     | Origin |  |
+---+----+       |  +-----+----+     +----+---+     +---+----+  |
    |             `-------|---------------|-------------|------'
    |&lt;-------------------------------- TokenChallenge --+
    |                     |               |             |
    |&lt;=== Attestation ===&gt;|               |             |
    |                     |               |             |
    +----------- TokenRequest -----------&gt;|             |
    |&lt;---------- TokenResponse -----------+             |
    |                                                   |
    +--------------------- Token -----------------------&gt;
    |                                                   |
</artwork>
          </artset>
        </figure>
        <t indent="0" pn="section-4.1-3">This model represents the initial deployment of Privacy Pass, as described in
<xref target="PrivacyPassCloudflare" format="default" sectionFormat="of" derivedContent="PrivacyPassCloudflare"/>. In this model, the Attester, Issuer, and Origin
share the attestation, issuance, and redemption contexts. As a result,
attestation mechanisms that can uniquely identify a Client, e.g., requiring
that Clients authenticate with some type of application-layer account, are
not appropriate, as they could lead to unlinkability violations.</t>
        <t indent="0" pn="section-4.1-4">Origin-Client, Issuer-Client, and Attester-Origin unlinkability requires that
issuance and redemption events be separated over time, such as through the use
of tokens that correspond to token challenges with an empty redemption context
(see <xref target="redemption" format="default" sectionFormat="of" derivedContent="Section 3.4"/>), or that they be separated over space, such as through the use of an
anonymizing service when connecting to the Origin.</t>
      </section>
      <section anchor="deploy-joint-issuer" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-joint-attester-and-issuer">Joint Attester and Issuer</name>
        <t indent="0" pn="section-4.2-1">In this model, the Attester and Issuer are operated by the same entity,
separate from the Origin. The Origin trusts the joint Attester
and Issuer to perform attestation and issue tokens. Clients interact
with the joint Attester and Issuer for attestation and issuance. This
arrangement is shown in <xref target="fig-deploy-joint-issuer" format="default" sectionFormat="of" derivedContent="Figure 4"/>.</t>
        <figure anchor="fig-deploy-joint-issuer" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-joint-attester-and-issuer-d">Joint Attester and Issuer Deployment Model</name>
          <artset pn="section-4.2-2.1">
            <artwork type="svg" align="left" pn="section-4.2-2.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 520 256" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,48 L 8,80" fill="none" stroke="black"/>
                <path d="M 40,80 L 40,240" fill="none" stroke="black"/>
                <path d="M 80,48 L 80,80" fill="none" stroke="black"/>
                <path d="M 160,32 L 160,80" fill="none" stroke="black"/>
                <path d="M 184,48 L 184,80" fill="none" stroke="black"/>
                <path d="M 232,80 L 232,104" fill="none" stroke="black"/>
                <path d="M 232,120 L 232,160" fill="none" stroke="black"/>
                <path d="M 272,48 L 272,80" fill="none" stroke="black"/>
                <path d="M 320,48 L 320,80" fill="none" stroke="black"/>
                <path d="M 360,80 L 360,96" fill="none" stroke="black"/>
                <path d="M 360,128 L 360,192" fill="none" stroke="black"/>
                <path d="M 392,48 L 392,80" fill="none" stroke="black"/>
                <path d="M 416,48 L 416,80" fill="none" stroke="black"/>
                <path d="M 440,48 L 440,80" fill="none" stroke="black"/>
                <path d="M 472,80 L 472,208" fill="none" stroke="black"/>
                <path d="M 512,48 L 512,80" fill="none" stroke="black"/>
                <path d="M 160,32 L 400,32" fill="none" stroke="black"/>
                <path d="M 8,48 L 80,48" fill="none" stroke="black"/>
                <path d="M 184,48 L 272,48" fill="none" stroke="black"/>
                <path d="M 320,48 L 392,48" fill="none" stroke="black"/>
                <path d="M 440,48 L 512,48" fill="none" stroke="black"/>
                <path d="M 8,80 L 80,80" fill="none" stroke="black"/>
                <path d="M 184,80 L 272,80" fill="none" stroke="black"/>
                <path d="M 320,80 L 392,80" fill="none" stroke="black"/>
                <path d="M 440,80 L 512,80" fill="none" stroke="black"/>
                <path d="M 176,96 L 224,96" fill="none" stroke="black"/>
                <path d="M 240,96 L 352,96" fill="none" stroke="black"/>
                <path d="M 368,96 L 400,96" fill="none" stroke="black"/>
                <path d="M 48,112 L 320,112" fill="none" stroke="black"/>
                <path d="M 456,112 L 472,112" fill="none" stroke="black"/>
                <path d="M 48,142 L 80,142" fill="none" stroke="black"/>
                <path d="M 48,146 L 80,146" fill="none" stroke="black"/>
                <path d="M 192,142 L 224,142" fill="none" stroke="black"/>
                <path d="M 192,146 L 224,146" fill="none" stroke="black"/>
                <path d="M 40,176 L 144,176" fill="none" stroke="black"/>
                <path d="M 264,176 L 352,176" fill="none" stroke="black"/>
                <path d="M 48,192 L 136,192" fill="none" stroke="black"/>
                <path d="M 264,192 L 360,192" fill="none" stroke="black"/>
                <path d="M 40,224 L 224,224" fill="none" stroke="black"/>
                <path d="M 288,224 L 472,224" fill="none" stroke="black"/>
                <path d="M 400,32 C 408.83064,32 416,39.16936 416,48" fill="none" stroke="black"/>
                <path d="M 176,96 C 167.16936,96 160,88.83064 160,80" fill="none" stroke="black"/>
                <path d="M 400,96 C 408.83064,96 416,88.83064 416,80" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="480,224 468,218.4 468,229.6" fill="black" transform="rotate(0,472,224)"/>
                <polygon class="arrowhead" points="360,176 348,170.4 348,181.6" fill="black" transform="rotate(0,352,176)"/>
                <polygon class="arrowhead" points="232,144 220,138.4 220,149.6" fill="black" transform="rotate(0,224,144)"/>
                <polygon class="arrowhead" points="56,192 44,186.4 44,197.6" fill="black" transform="rotate(180,48,192)"/>
                <polygon class="arrowhead" points="56,144 44,138.4 44,149.6" fill="black" transform="rotate(180,48,144)"/>
                <polygon class="arrowhead" points="56,112 44,106.4 44,117.6" fill="black" transform="rotate(180,48,112)"/>
                <g class="text">
                  <text x="44" y="68">Client</text>
                  <text x="228" y="68">Attester</text>
                  <text x="356" y="68">Issuer</text>
                  <text x="476" y="68">Origin</text>
                  <text x="388" y="116">TokenChallenge</text>
                  <text x="136" y="148">Attestation</text>
                  <text x="204" y="180">TokenRequest</text>
                  <text x="200" y="196">TokenResponse</text>
                  <text x="256" y="228">Token</text>
                  <text x="472" y="244">|</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="left" pn="section-4.2-2.1.2">
                   +------------------------------.
+--------+         |  +----------+     +--------+  |  +--------+
| Client |         |  | Attester |     | Issuer |  |  | Origin |
+---+----+         |  +-----+----+     +----+---+  |  +---+----+
    |               `-------|---------------|-----'       |
    |&lt;---------------------------------- TokenChallenge --+
    |                       |               |             |
    |&lt;==== Attestation ====&gt;|               |             |
    |                       |               |             |
    +------------- TokenRequest -----------&gt;|             |
    |&lt;----------- TokenResponse ------------+             |
    |                                                     |
    +----------------------- Token -----------------------&gt;
    |                                                     |
</artwork>
          </artset>
        </figure>
        <t indent="0" pn="section-4.2-3">This model is useful if an Origin wants to offload attestation and issuance to
a trusted entity. In this model, the Attester and Issuer share an attestation
and issuance context for the Client, separate from the Origin's
redemption context.</t>
        <t indent="0" pn="section-4.2-4">Similar to the shared Origin, Attester, Issuer model, Issuer-Client and
Origin-Client unlinkability in this model requires that issuance and redemption
events, respectively, be separated over time or space. Attester-Origin
unlinkability requires that the Attester and Issuer do not learn the Origin
for a particular token request. For this reason, issuance protocols that
require the Issuer to learn information about the Origin, such as the issuance protocol described in <xref target="I-D.ietf-privacypass-rate-limit-tokens" format="default" sectionFormat="of" derivedContent="RATE-LIMITED"/>, are not
appropriate, since they could lead to Attester-Origin unlinkability violations
through the Origin name.</t>
      </section>
      <section anchor="deploy-joint-origin" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-joint-origin-and-issuer">Joint Origin and Issuer</name>
        <t indent="0" pn="section-4.3-1">In this model, the Origin and Issuer are operated by the same entity, separate
from the Attester, as shown in <xref target="fig-deploy-joint-origin" format="default" sectionFormat="of" derivedContent="Figure 5"/>. The Issuer accepts token
requests that come from trusted Attesters. Since the Attester and Issuer are
separate entities, this model requires some mechanism by which Issuers
establish trust in the Attester (as described in <xref target="privacy-and-trust" format="default" sectionFormat="of" derivedContent="Section 3.3"/>).
For example, in settings where the Attester is a Client-trusted service that
directly communicates with the Issuer, one way to establish this trust is via
mutually authenticated TLS. However, alternative authentication mechanisms are
possible. In this model, the Origin and Issuer are operated by the same entity, separate from the Attester, as shown in the figure below.</t>
        <figure anchor="fig-deploy-joint-origin" align="left" suppress-title="false" pn="figure-5">
          <name slugifiedName="name-joint-origin-and-issuer-dep">Joint Origin and Issuer Deployment Model</name>
          <artset pn="section-4.3-2.1">
            <artwork type="svg" align="left" pn="section-4.3-2.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 528 256" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,48 L 8,80" fill="none" stroke="black"/>
                <path d="M 40,80 L 40,240" fill="none" stroke="black"/>
                <path d="M 80,48 L 80,80" fill="none" stroke="black"/>
                <path d="M 168,48 L 168,80" fill="none" stroke="black"/>
                <path d="M 216,80 L 216,104" fill="none" stroke="black"/>
                <path d="M 216,120 L 216,160" fill="none" stroke="black"/>
                <path d="M 256,48 L 256,80" fill="none" stroke="black"/>
                <path d="M 280,32 L 280,80" fill="none" stroke="black"/>
                <path d="M 304,48 L 304,80" fill="none" stroke="black"/>
                <path d="M 344,80 L 344,96" fill="none" stroke="black"/>
                <path d="M 344,128 L 344,192" fill="none" stroke="black"/>
                <path d="M 376,48 L 376,80" fill="none" stroke="black"/>
                <path d="M 424,48 L 424,80" fill="none" stroke="black"/>
                <path d="M 456,80 L 456,208" fill="none" stroke="black"/>
                <path d="M 496,48 L 496,80" fill="none" stroke="black"/>
                <path d="M 520,48 L 520,80" fill="none" stroke="black"/>
                <path d="M 280,32 L 504,32" fill="none" stroke="black"/>
                <path d="M 8,48 L 80,48" fill="none" stroke="black"/>
                <path d="M 168,48 L 256,48" fill="none" stroke="black"/>
                <path d="M 304,48 L 376,48" fill="none" stroke="black"/>
                <path d="M 424,48 L 496,48" fill="none" stroke="black"/>
                <path d="M 8,80 L 80,80" fill="none" stroke="black"/>
                <path d="M 168,80 L 256,80" fill="none" stroke="black"/>
                <path d="M 304,80 L 376,80" fill="none" stroke="black"/>
                <path d="M 424,80 L 496,80" fill="none" stroke="black"/>
                <path d="M 296,96 L 336,96" fill="none" stroke="black"/>
                <path d="M 352,96 L 448,96" fill="none" stroke="black"/>
                <path d="M 464,96 L 504,96" fill="none" stroke="black"/>
                <path d="M 48,112 L 304,112" fill="none" stroke="black"/>
                <path d="M 440,112 L 456,112" fill="none" stroke="black"/>
                <path d="M 48,142 L 72,142" fill="none" stroke="black"/>
                <path d="M 48,146 L 72,146" fill="none" stroke="black"/>
                <path d="M 184,142 L 208,142" fill="none" stroke="black"/>
                <path d="M 184,146 L 208,146" fill="none" stroke="black"/>
                <path d="M 40,176 L 136,176" fill="none" stroke="black"/>
                <path d="M 256,176 L 336,176" fill="none" stroke="black"/>
                <path d="M 48,192 L 128,192" fill="none" stroke="black"/>
                <path d="M 256,192 L 344,192" fill="none" stroke="black"/>
                <path d="M 40,224 L 208,224" fill="none" stroke="black"/>
                <path d="M 272,224 L 456,224" fill="none" stroke="black"/>
                <path d="M 504,32 C 512.83064,32 520,39.16936 520,48" fill="none" stroke="black"/>
                <path d="M 296,96 C 287.16936,96 280,88.83064 280,80" fill="none" stroke="black"/>
                <path d="M 504,96 C 512.83064,96 520,88.83064 520,80" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="464,224 452,218.4 452,229.6" fill="black" transform="rotate(0,456,224)"/>
                <polygon class="arrowhead" points="344,176 332,170.4 332,181.6" fill="black" transform="rotate(0,336,176)"/>
                <polygon class="arrowhead" points="216,144 204,138.4 204,149.6" fill="black" transform="rotate(0,208,144)"/>
                <polygon class="arrowhead" points="56,192 44,186.4 44,197.6" fill="black" transform="rotate(180,48,192)"/>
                <polygon class="arrowhead" points="56,144 44,138.4 44,149.6" fill="black" transform="rotate(180,48,144)"/>
                <polygon class="arrowhead" points="56,112 44,106.4 44,117.6" fill="black" transform="rotate(180,48,112)"/>
                <g class="text">
                  <text x="44" y="68">Client</text>
                  <text x="212" y="68">Attester</text>
                  <text x="340" y="68">Issuer</text>
                  <text x="460" y="68">Origin</text>
                  <text x="372" y="116">TokenChallenge</text>
                  <text x="128" y="148">Attestation</text>
                  <text x="196" y="180">TokenRequest</text>
                  <text x="192" y="196">TokenResponse</text>
                  <text x="240" y="228">Token</text>
                  <text x="456" y="244">|</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="left" pn="section-4.3-2.1.2">
                                  +----------------------------.
+--------+          +----------+  |  +--------+     +--------+  |
| Client |          | Attester |  |  | Issuer |     | Origin |  |
+---+----+          +-----+----+  |  +----+---+     +---+----+  |
    |                     |        `------|-------------|------'
    |&lt;-------------------------------- TokenChallenge --+
    |                     |               |             |
    |&lt;=== Attestation ===&gt;|               |             |
    |                     |               |             |
    +------------ TokenRequest ----------&gt;|             |
    |&lt;---------- TokenResponse -----------+             |
    |                                                   |
    +--------------------- Token -----------------------&gt;
    |                                                   |
</artwork>
          </artset>
        </figure>
        <t indent="0" pn="section-4.3-3">This model is useful for Origins that require Client-identifying attestation,
e.g., through the use of application-layer account information, but do not
otherwise want to learn information about individual Clients beyond what is
observed during the token redemption, such as Client IP addresses.</t>
        <t indent="0" pn="section-4.3-4">In this model, attestation contexts are separate from Issuer and redemption
contexts. As a result, any type of attestation is suitable in this model.</t>
        <t indent="0" pn="section-4.3-5">Moreover, assuming that there is more than one Origin involved, any type of token challenge is suitable, since no single party will have access to the identifying
Client information and unique Origin information. Issuers that produce tokens
for a single Origin are not suitable in this model, since an Attester can
infer the Origin from a token request, as described in <xref target="issue-flow" format="default" sectionFormat="of" derivedContent="Section 3.6.3"/>. However,
since the issuance protocol provides input secrecy, the Attester does not learn
details about the corresponding token challenge, such as whether the token
challenge is per Origin or across Origins.</t>
      </section>
      <section anchor="deploy-split" numbered="true" removeInRFC="false" toc="include" pn="section-4.4">
        <name slugifiedName="name-split-origin-attester-issue">Split Origin, Attester, Issuer</name>
        <t indent="0" pn="section-4.4-1">In this model, the Origin, Attester, and Issuer are all operated by different
entities. As with the Joint Origin and Issuer model (<xref target="deploy-joint-origin" format="default" sectionFormat="of" derivedContent="Section 4.3"/>), the Issuer accepts token
requests that come from trusted Attesters, and the details of that trust
establishment depend on the issuance protocol and relationship between the
Attester and Issuer; see <xref target="privacy-and-trust" format="default" sectionFormat="of" derivedContent="Section 3.3"/>. This arrangement is shown
in <xref target="fig-overview" format="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
        <t indent="0" pn="section-4.4-2">This is the most general deployment model and is necessary for some
types of issuance protocols where the Attester plays a role in token
issuance; see <xref target="I-D.ietf-privacypass-rate-limit-tokens" format="default" sectionFormat="of" derivedContent="RATE-LIMITED"/> for one such type of issuance protocol.</t>
        <t indent="0" pn="section-4.4-3">In this model, the Attester, Issuer, and Origin have a separate view
of the Client: the Attester sees potentially sensitive Client-identifying
information, such as account identifiers or IP addresses; the Issuer
sees only the information necessary for issuance; and the Origin sees
token challenges, corresponding tokens, and Client source information,
such as their IP address. As a result, attestation, issuance, and redemption
contexts are separate, and therefore any type of token challenge is suitable in
this model as long as there is more than a single Origin.</t>
        <t indent="0" pn="section-4.4-4">As with the Joint Origin and Issuer model (<xref target="deploy-joint-origin" format="default" sectionFormat="of" derivedContent="Section 4.3"/>), and as
described in <xref target="issue-flow" format="default" sectionFormat="of" derivedContent="Section 3.6.3"/>, if the Issuer produces tokens for a single Origin,
then per-Origin tokens are not appropriate, since the Attester can infer the
Origin from a token request.</t>
      </section>
    </section>
    <section anchor="deployment-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-deployment-considerations">Deployment Considerations</name>
      <t indent="0" pn="section-5-1"><xref target="deployment" format="default" sectionFormat="of" derivedContent="Section 4"/> discusses deployment models that are possible in practice.
Beyond possible implications on security and privacy properties of the
resulting system, Privacy Pass deployments can impact the overall ecosystem
in two important ways: (1) discriminatory treatment of Clients and the gated
access to otherwise open services and (2) centralization. This section
describes considerations relevant to these topics.</t>
      <section anchor="discrimination" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-discriminatory-treatment">Discriminatory Treatment</name>
        <t indent="0" pn="section-5.1-1">Origins can use tokens as a signal for distinguishing between (1) Clients
that are capable of completing attestation with one Attester trusted by the
Origin's chosen Issuer and (2) Clients that are not capable of doing the same. A
consequence of this is that Privacy Pass could enable discriminatory treatment
of Clients based on attestation support. For example, an Origin could only
authorize Clients that successfully authenticate with a token, prohibiting access
to all other Clients.</t>
        <t indent="0" pn="section-5.1-2">The types of attestation procedures supported for a particular deployment depend
greatly on the use case. For example, consider a proprietary deployment of Privacy Pass
that authorizes Clients to access a resource such as an anonymization service. In this
context, it is reasonable to support specific types of attestation procedures that
demonstrate that Clients can access the resource, such as with an account or specific
type of device. However, in open deployments of Privacy Pass that are used to
safeguard access to otherwise open or publicly accessible resources, diversity
in attestation procedures is critically important so as to not discriminate against
Clients that choose certain software, hardware, or identity providers.</t>
        <t indent="0" pn="section-5.1-3">In principle, Issuers should strive to mitigate discriminatory behavior by
providing equitable access to all Clients. This can be done by working with a
set of Attesters that are suitable for all Clients. In practice, this may require
trade-offs in what type of attestation Issuers are willing to trust so as to
enable more widespread support. In other words, trusting a variety of Attesters
with a diverse set of attestation procedures would presumably increase support
among Clients, though most likely at the expense of decreasing the overall value
of tokens issued by the Issuer.</t>
        <t indent="0" pn="section-5.1-4">For example, to disallow discriminatory behavior between Clients with and
without device attestation support, an Issuer may wish to support Attesters
that support CAPTCHA-based attestation. This means that the overall attestation
value of a Privacy Pass token is bound by the difficulty in spoofing or
bypassing either one of these attestation procedures.</t>
      </section>
      <section anchor="centralization" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-centralization">Centralization</name>
        <t indent="0" pn="section-5.2-1">A consequence of limiting the number of participants (Attesters or Issuers) in
Privacy Pass deployments for meaningful privacy is that it forces concentrated
centralization among those participants.
<xref target="RFC9518" format="default" sectionFormat="of" derivedContent="CENTRALIZATION"/> discusses
several ways in which this might be mitigated. For example, a multi-stakeholder
governance model could be established to determine what candidate participants
are fit to operate as participants in a Privacy Pass deployment. This is
precisely the system used to control the Web's trust model.</t>
        <t indent="0" pn="section-5.2-2">Alternatively, Privacy Pass deployments might mitigate this problem through
implementation. For example, rather than centralize the role of attestation
in one or a few entities, attestation could be a distributed function performed
by a quorum of many parties, provided that neither Issuers nor Origins learn
which Attester implementations were chosen. As a result, Clients could have
more opportunities to switch between attestation participants.</t>
      </section>
    </section>
    <section anchor="privacy" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-6-1">The previous section discusses the impact of deployment details on
Origin-Client, Issuer-Client, and Attester-Origin unlinkability.
The value these properties afford to end users depends on
the size of anonymity sets in which Clients or Origins are
unlinkable. For example, consider two different deployments, one wherein
there exists a redemption anonymity set of size two and another
wherein there exists a redemption anonymity set of size 2<sup>32</sup>. Although
Origin-Client unlinkability guarantees that the Origin cannot link any two
requests to the same Client based on these contexts, respectively, the
smaller these sets become, the higher the probability of determining the "true" Client.</t>
      <t indent="0" pn="section-6-2">In practice, there are a number of ways in which the size of anonymity sets
may be reduced or partitioned, though they all center around the concept of
consistency. In particular, by definition, all Clients in an anonymity set
share a consistent view of information needed to run the issuance and
redemption protocols. The Issuer Public Key is an example of the type of information needed to run these protocols. When two Clients have inconsistent
information, these Clients effectively have different redemption contexts and
therefore belong in different anonymity sets.</t>
      <t indent="0" pn="section-6-3">The following subsections discuss issues that can influence anonymity set size.
For each issue, we discuss mitigations or safeguards to protect against the
underlying problem.</t>
      <section anchor="metadata-privacy" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-partitioning-by-issuance-me">Partitioning by Issuance Metadata</name>
        <t indent="0" pn="section-6.1-1">Any public or private metadata bits of information can be used to further
segment the size of the Client anonymity set. Any Issuer that wanted to
track a single Client could add a single metadata bit to Client tokens. For
the tracked Client, it would set the bit to <tt>1</tt>, and <tt>0</tt> otherwise. Adding
additional bits provides an exponential increase in tracking granularity
in a manner similar to introducing more Issuers (though with more potential targeting).</t>
        <t indent="0" pn="section-6.1-2">For this reason, deployments should take the amount of metadata used by an Issuer
in creating tokens, together with the bits of information that Issuers may learn about Clients through other means, into account. Since this
metadata may be useful for practical deployments of Privacy Pass, Issuers
must balance this against the reduction in Client privacy.</t>
        <t indent="0" pn="section-6.1-3">The number of permitted metadata values often depends on deployment-specific
details. In general, limiting the amount of metadata permitted helps limit the
extent to which metadata can uniquely identify individual Clients. Failure to
bound the number of possible metadata values can therefore lead to a reduction in
Client privacy. Most token types do not admit any metadata, so this bound is
implicitly enforced.</t>
      </section>
      <section anchor="rotation-and-consistency" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-partitioning-by-issuance-co">Partitioning by Issuance Consistency</name>
        <t indent="0" pn="section-6.2-1">Anonymity sets can be partitioned by information used for the issuance
protocol, including metadata, Issuer configuration (keys), and Issuer
selection.</t>
        <t indent="0" pn="section-6.2-2">Any issuance metadata bits of information can be used to partition the Client
anonymity set. For example, any Issuer that wanted to track a single Client
could add a single metadata bit to Client tokens. For the tracked Client, it
would set the bit to <tt>1</tt>, and <tt>0</tt> otherwise. Adding additional bits provides an
exponential increase in tracking granularity in a manner similar to introducing more
Issuers (though with more potential targeting).</t>
        <t indent="0" pn="section-6.2-3">The number of active Issuer configurations also contributes to anonymity set
partitioning. In particular, when an Issuer updates their configuration and
the corresponding key pair, any Client that invokes the issuance protocol with
this configuration becomes part of a set of Clients that also ran the
issuance protocol using the same configuration. Issuer configuration updates,
e.g., due to key rotation, are an important part of hedging against long-term
private key compromise. In general, key rotations represent a trade-off between
Client privacy and Issuer security. Therefore, it is important that key
rotations occur on a regular cycle to reduce the harm of an Issuer key
compromise.</t>
        <t indent="0" pn="section-6.2-4">Lastly, if Clients are willing to issue and redeem tokens from a large number
of Issuers for a specific Origin and that Origin accepts tokens from all
Issuers, partitioning can occur. As an example, if a Client obtains tokens from
many Issuers and an Origin later challenges that Client for a token from each
Issuer, the Origin can learn information about the Client. This arrangement
might happen if Clients request tokens from different Issuers, each of which
has different Attester preferences. Each per-Issuer token that a Client holds
essentially corresponds to a bit of information about the Client that the Origin
learns. Therefore, there is an exponential loss in privacy relative to the
number of Issuers.</t>
        <t indent="0" pn="section-6.2-5">The fundamental problem here is that the number of possible issuance
configurations, including the keys in use and the Issuer identities themselves,
can partition the Client anonymity set. To mitigate this problem, Clients
<bcp14>SHOULD</bcp14> bound the number of active issuance configurations per Origin as well as
across Origins. Moreover, Clients <bcp14>SHOULD</bcp14> employ some form of consistency
mechanism to ensure that they receive the same configuration information and
are not being actively partitioned into smaller anonymity sets. See
<xref target="I-D.ietf-privacypass-key-consistency" format="default" sectionFormat="of" derivedContent="CONSISTENCY"/> for possible consistency
mechanisms. Depending on the deployment, the Attester might assist the Client
in applying these consistency checks across Clients. Failure to apply a
consistency check can allow Client-specific keys to violate Origin-Client
unlinkability.</t>
      </section>
      <section anchor="partitioning-by-side-channels" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-partitioning-by-side-channe">Partitioning by Side Channels</name>
        <t indent="0" pn="section-6.3-1">Side-channel attacks, such as those based on timing correlation, could be
used to reduce anonymity set size. In particular,
for interactive tokens that are bound to a Client-specific redemption
context, the anonymity set of Clients during the issuance protocol consists
of those Clients that started issuance between the time of the Origin's
challenge and the corresponding token redemption. Depending on the number
of Clients using a particular Issuer during that time window, the set can
be small. Applications should take such side channels into consideration before
choosing a particular deployment model and type of token challenge and
redemption context.</t>
      </section>
    </section>
    <section anchor="security" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">This document describes security and privacy requirements for the Privacy Pass
redemption and issuance protocols. It also describes deployment models built
around non-collusion assumptions and privacy considerations for using Privacy
Pass within those models. Ensuring Client privacy -- separation of attestation
and redemption contexts -- requires active work on behalf of the Client,
especially in the presence of malicious Issuers and Origins. Implementing the
mitigations discussed in Sections <xref target="deployment" format="counter" sectionFormat="of" derivedContent="4"/> and <xref target="privacy" format="counter" sectionFormat="of" derivedContent="6"/> is therefore necessary
to ensure that Privacy Pass offers meaningful privacy improvements to end users.</t>
      <section anchor="hoarding" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-token-caching">Token Caching</name>
        <t indent="0" pn="section-7.1-1">Depending on the Origin's token challenge, Clients can request and cache more
than one token using an issuance protocol. Cached tokens help improve privacy by
separating the time of token issuance from the time of token redemption; they
also allow Clients to reduce the overhead of receiving new tokens via the
issuance protocol.</t>
        <t indent="0" pn="section-7.1-2">As a consequence, Origins that send token challenges that are compatible with
cached tokens need to take precautions to ensure that tokens are not replayed.
This is typically done via keeping track of tokens that are redeemed for the
period of time in which cached tokens would be accepted for particular
challenges.</t>
        <t indent="0" pn="section-7.1-3">Moreover, since tokens are not intrinsically bound to Clients, it is possible
for malicious Clients to collude and share tokens in a so-called "hoarding
attack". As an example of this attack, many distributed Clients could obtain
cacheable tokens and then share them with a single Client to redeem the tokens in a way
that would violate an Origin's attempt to limit tokens to any one particular
Client. In general, mechanisms for mitigating hoarding attacks depend on the
deployment model and use case. For example, in the Joint Origin and Issuer model,
comparing the issuance and redemption contexts can help detect hoarding attacks,
i.e., if the distribution of redemption contexts is noticeably different from the
distribution of issuance contexts. Rate-limiting issuance, at either the Client,
Attester, or Issuer, can also help mitigate these attacks.</t>
      </section>
    </section>
    <section anchor="iana" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <displayreference target="RFC9577" to="AUTHSCHEME"/>
    <displayreference target="RFC9578" to="ISSUANCE"/>
    <displayreference target="RFC9458" to="OHTTP"/>
    <displayreference target="I-D.ietf-privacypass-rate-limit-tokens" to="RATE-LIMITED"/>
    <displayreference target="RFC9518" to="CENTRALIZATION"/>
    <displayreference target="I-D.ietf-privacypass-key-consistency" to="CONSISTENCY"/>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC9577" target="https://www.rfc-editor.org/info/rfc9577" quoteTitle="true" derivedAnchor="AUTHSCHEME">
          <front>
            <title>The Privacy Pass HTTP Authentication Scheme</title>
            <author initials="T." surname="Pauly" fullname="Tommy Pauly">
              <organization showOnFrontPage="true">Apple Inc.</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="9577"/>
          <seriesInfo name="DOI" value="10.17487/RFC9577"/>
        </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="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>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC9518" target="https://www.rfc-editor.org/info/rfc9518" quoteTitle="true" derivedAnchor="CENTRALIZATION">
          <front>
            <title>Centralization, Decentralization, and Internet Standards</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="December" year="2023"/>
            <abstract>
              <t indent="0">This document discusses aspects of centralization that relate to Internet standards efforts. It argues that, while standards bodies have a limited ability to prevent many forms of centralization, they can still make contributions that assist in the decentralization of the Internet.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9518"/>
          <seriesInfo name="DOI" value="10.17487/RFC9518"/>
        </reference>
        <reference anchor="I-D.ietf-privacypass-key-consistency" target="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-key-consistency-01" quoteTitle="true" derivedAnchor="CONSISTENCY">
          <front>
            <title>Key Consistency and Discovery</title>
            <author initials="A." surname="Davidson" fullname="Alex Davidson">
              <organization showOnFrontPage="true">Brave Software</organization>
            </author>
            <author initials="M." surname="Finkel" fullname="Matthew Finkel">
              <organization showOnFrontPage="true">The Tor Project</organization>
            </author>
            <author initials="M." surname="Thomson" fullname="Martin Thomson">
              <organization showOnFrontPage="true">Mozilla</organization>
            </author>
            <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
              <organization showOnFrontPage="true">Cloudflare</organization>
            </author>
            <date month="July" day="10" year="2023"/>
            <abstract>
              <t indent="0">   This document describes the consistency requirements of protocols
   such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user
   privacy.  It presents definitions for consistency and then surveys
   mechanisms for providing consistency in varying threat models.  In
   concludes with discussion of open problems in this area.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-key-consistency-01"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="DMS2004" target="https://svn.torproject.org/svn/projects/design-paper/tor-design.html" quoteTitle="true" derivedAnchor="DMS2004">
          <front>
            <title>Tor: The Second-Generation Onion Router</title>
            <author initials="R." surname="Dingledine">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Mathewson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Syverson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="May"/>
          </front>
        </reference>
        <reference anchor="HIJK21" target="https://research.fb.com/privatestats" quoteTitle="true" derivedAnchor="HIJK21">
          <front>
            <title>DIT: De-Identified Authenticated Telemetry at Scale</title>
            <author initials="S." surname="Huang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Iyengar">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Jeyaraman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Kushwah">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C-K." surname="Lee">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Z." surname="Luo">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Mohassel">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Raghunathan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Shaikh">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y-C." surname="Sung">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Zhang">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="January"/>
          </front>
        </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="KLOR20" target="https://doi.org/10.1007/978-3-030-56784-2_11" quoteTitle="true" derivedAnchor="KLOR20">
          <front>
            <title>Anonymous Tokens with Private Metadata Bit</title>
            <author fullname="Ben Kreuter" surname="Kreuter"/>
            <author fullname="Tancrède Lepoint" surname="Lepoint"/>
            <author fullname="Michele Orrù" surname="Orrù"/>
            <author fullname="Mariana Raykova" surname="Raykova"/>
            <author>
              <organization showOnFrontPage="true">Springer International Publishing</organization>
            </author>
            <date year="2020"/>
          </front>
          <refcontent>Advances in Cryptology - CRYPTO 2020, pp. 308-336</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-030-56784-2_11"/>
        </reference>
        <reference anchor="RFC9458" target="https://www.rfc-editor.org/info/rfc9458" quoteTitle="true" derivedAnchor="OHTTP">
          <front>
            <title>Oblivious HTTP</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson"/>
            <author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
            <date month="January" year="2024"/>
            <abstract>
              <t indent="0">This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9458"/>
          <seriesInfo name="DOI" value="10.17487/RFC9458"/>
        </reference>
        <reference anchor="PrivacyPassCloudflare" target="https://blog.cloudflare.com/cloudflare-supports-privacy-pass/" quoteTitle="true" derivedAnchor="PrivacyPassCloudflare">
          <front>
            <title>Cloudflare supports Privacy Pass</title>
            <author initials="N." surname="Sullivan">
              <organization showOnFrontPage="true">Cloudflare</organization>
            </author>
            <date month="November" year="2017"/>
          </front>
        </reference>
        <reference anchor="I-D.ietf-privacypass-rate-limit-tokens" target="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-rate-limit-tokens-06" quoteTitle="true" derivedAnchor="RATE-LIMITED">
          <front>
            <title>Rate-Limited Token Issuance Protocol</title>
            <author initials="S." surname="Hendrickson" fullname="Scott Hendrickson">
              <organization showOnFrontPage="true">Google LLC</organization>
            </author>
            <author initials="J." surname="Iyengar" fullname="Jana Iyengar">
              <organization showOnFrontPage="true">Fastly</organization>
            </author>
            <author initials="T." surname="Pauly" fullname="Tommy Pauly">
              <organization showOnFrontPage="true">Apple Inc.</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="April" day="1" year="2024"/>
            <abstract>
              <t indent="0">   This document specifies a variant of the Privacy Pass issuance
   protocol that allows for tokens to be rate-limited on a per-origin
   basis.  This enables origins to use tokens for use cases that need to
   restrict access from anonymous clients.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-rate-limit-tokens-06"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC9334" target="https://www.rfc-editor.org/info/rfc9334" quoteTitle="true" derivedAnchor="RFC9334">
          <front>
            <title>Remote ATtestation procedureS (RATS) Architecture</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="D. Thaler" initials="D." surname="Thaler"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="N. Smith" initials="N." surname="Smith"/>
            <author fullname="W. Pan" initials="W." surname="Pan"/>
            <date month="January" year="2023"/>
            <abstract>
              <t indent="0">In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9334"/>
          <seriesInfo name="DOI" value="10.17487/RFC9334"/>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Eric Kinnear"/>, <contact fullname="Scott Hendrickson"/>, <contact fullname="Tommy Pauly"/>,
<contact fullname="Christopher Patton"/>, <contact fullname="Benjamin Schwartz"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Steven Valdez"/>, and other
contributors of the Privacy Pass Working Group for many helpful contributions
to this document.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="A." surname="Davidson" fullname="Alex Davidson">
        <organization showOnFrontPage="true">NOVA LINCS, Universidade NOVA de Lisboa</organization>
        <address>
          <postal>
            <street>Largo da Torre</street>
            <city>Caparica</city>
            <country>Portugal</country>
          </postal>
          <email>alex.davidson92@gmail.com</email>
        </address>
      </author>
      <author initials="J." surname="Iyengar" fullname="Jana Iyengar">
        <organization showOnFrontPage="true">Fastly</organization>
        <address>
          <email>jri@fastly.com</email>
        </address>
      </author>
      <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
        <organization showOnFrontPage="true">Cloudflare</organization>
        <address>
          <postal>
            <street>101 Townsend St</street>
            <city>San Francisco</city>
            <region>CA</region>
            <code>94107</code>
            <country>United States of America</country>
          </postal>
          <email>caw@heapingbits.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
