rfc9576.original.xml		rfc9576.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.11 (Ruby 3.1.		<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
	2) -->		ipr="trust200902"
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		docName="draft-ietf-privacypass-architecture-16"
	-ietf-privacypass-architecture-16" category="info" tocInclude="true" sortRefs="t		number="9576"
	rue" symRefs="true" version="3">		category="info"
	<!-- xml2rfc v2v3 conversion 3.12.10 -->		tocInclude="true"
			submissionType="IETF"
			consensus="true"
			obsoletes=""
			updates=""
			sortRefs="true"
			symRefs="true"
			version="3"
			xml:lang="en">
	<front>		<front>
	<title abbrev="Privacy Pass Architecture">The Privacy Pass Architecture</tit le>		<title abbrev="Privacy Pass Architecture">The Privacy Pass Architecture</tit le>
	<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-architecture -16"/>		<seriesInfo name="RFC" value="9576"/>
	<author initials="A." surname="Davidson" fullname="Alex Davidson">		<author initials="A." surname="Davidson" fullname="Alex Davidson">
	<organization>LIP</organization>		<organization>NOVA LINCS, Universidade NOVA de Lisboa</organization>
	<address>		<address>
	<postal>		<postal>
	<city>Lisbon</city>		<street>Largo da Torre</street>
			<city>Caparica</city>
	<country>Portugal</country>		<country>Portugal</country>
	</postal>		</postal>
	<email>alex.davidson92@gmail.com</email>		<email>alex.davidson92@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="J." surname="Iyengar" fullname="Jana Iyengar">		<author initials="J." surname="Iyengar" fullname="Jana Iyengar">
	<organization>Fastly</organization>		<organization>Fastly</organization>
	<address>		<address>
	<email>jri@fastly.com</email>		<email>jri@fastly.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="C. A." surname="Wood" fullname="Christopher A. Wood">		<author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
	<organization>Cloudflare</organization>		<organization>Cloudflare</organization>
	<address>		<address>
	<postal>		<postal>
	<street>101 Townsend St</street>		<street>101 Townsend St</street>
	<city>San Francisco</city>		<city>San Francisco</city>
			<region>CA</region>
			<code>94107</code>
	<country>United States of America</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>caw@heapingbits.net</email>		<email>caw@heapingbits.net</email>
	</address>		</address>
	</author>		</author>
	<date year="2023" month="September" day="25"/>
	<keyword>Internet-Draft</keyword>		<date year="2024" month="June"/>
			<area>sec</area>
			<workgroup>privacypass</workgroup>
	<abstract>		<abstract>
	<t>This document specifies the Privacy Pass architecture and requirements for		<t>This document specifies the Privacy Pass architecture and requirements for
	its constituent protocols used for authorization based on privacy-preserving		its constituent protocols used for authorization based on privacy-preserving
	authentication mechanisms. It describes the conceptual model of Privacy Pass		authentication mechanisms. It describes the conceptual model of Privacy Pass
	and its protocols, its security and privacy goals, practical deployment models,		and its protocols, its security and privacy goals, practical deployment models,
	and recommendations for each deployment model that helps ensure the desired		and recommendations for each deployment model, to help ensure that the desired
	security and privacy goals are fulfilled.</t>		security and privacy goals are fulfilled.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t>Privacy Pass is an architecture for authorization based on privacy-pres erving		<t>Privacy Pass is an architecture for authorization based on privacy-pres erving
	authentication mechanisms. In other words, relying parties authenticate clients		authentication mechanisms. In other words, relying parties authenticate Clients
	in a privacy-preserving way, i.e., without learning any unique, per-client		in a privacy-preserving way, i.e., without learning any unique, per-Client
	information through the authentication protocol, and then make authorization		information through the authentication protocol, and then make authorization
	decisions on the basis of that authentication succeeding or failing. Possible		decisions on the basis of that authentication succeeding or failing. Possible
	authorization decisions might be to provide clients with read access to a		authorization decisions might be to provide Clients with read access to a
	particular resource or write access to a particular resource.</t>		particular resource or write access to a particular resource.</t>
	<t>Typical approaches for authorizing clients, such as through the use of		<t>Typical approaches for authorizing Clients, such as through the use of
	long-term		long-term
	state (cookies), are not privacy-friendly since they allow servers to track		state (cookies), are not privacy friendly, since they allow servers to track
	clients across sessions and interactions. Privacy Pass takes a different		Clients across sessions and interactions. Privacy Pass takes a different
	approach: instead of presenting linkable state-carrying information to servers,		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		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		has completed some prior challenge, Clients present unlinkable proofs that
	attest to this information. These proofs, or tokens, are private in the sense		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		that a given token cannot be linked to the protocol interaction where that
	token was initially issued.</t>		token was initially issued.</t>
	<t>At a high level, the Privacy Pass architecture consists of two protocol s:		<t>At a high level, the Privacy Pass architecture consists of two protocol s:
	redemption and issuance. The redemption protocol, described in		redemption and issuance. The redemption protocol, described in
	<xref target="AUTHSCHEME"/>, runs between Clients and		<xref target="RFC9577"/>, runs between Clients and
	Origins (servers). It allows Origins to challenge Clients to present tokens		Origins (servers). It allows Origins to challenge Clients to present tokens
	for consumption. Origins verify the token to authenticate the Client -- without		for consumption. Origins verify the token to authenticate the Client -- without
	learning any specific information about the Client -- and then make an authoriza tion		learning any specific information about the Client -- and then make an authoriza tion
	decision on the basis of the token verifying successfully or not. Depending		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		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,		either presents a previously obtained token or invokes an issuance protocol,
	such as <xref target="ISSUANCE"/>, to acquire a token to		e.g., the protocols described in <xref target="RFC9578"/>, to acquire a token to
	present as authorization.</t>		present as authorization.</t>
	<t>This document describes requirements for both redemption and issuance		<t>This document describes requirements for both redemption and issuance
	protocols and how they interact. It also provides recommendations on how		protocols and how they interact. It also provides recommendations on how
	the architecture should be deployed to ensure the privacy of clients and		the architecture should be deployed to ensure the privacy of Clients and
	the security of all participating entities.</t>		the security of all participating entities.</t>
	</section>		</section>
	<section anchor="terminology">		<section anchor="terminology">
	<name>Terminology</name>		<name>Terminology</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	"MAY", and "OPTIONAL" in this document are to be interpreted as		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and		"<bcp14>SHOULD NOT</bcp14>",
	only when, they		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	appear in all capitals, as shown here.</t>		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
			are to be interpreted as described in BCP&nbsp;14
			<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
			when, they appear in all capitals, as shown here.</t>
	<t>The following terms are used throughout this document:</t>		<t>The following terms are used throughout this document:</t>
	<dl>		<dl>
	<dt>Client:</dt>		<dt>Client:</dt>
	<dd>		<dd>
	<t>An entity that seeks authorization to an Origin. Using <xref target		<t>An entity that seeks authorization to an Origin. Using terminology
	="RFC9334"/> terminology,		from <xref target="RFC9334"/>,
	Clients implement the RATS Attester role.</t>		Clients implement the Remote ATtestation procedureS (RATS) Attester role.</t>
	</dd>		</dd>
	<dt>Token:</dt>		<dt>Token:</dt>
	<dd>		<dd>
	<t>A cryptographic authentication message used for authorization decis ions,		<t>A cryptographic authentication message used for authorization decis ions,
	produced as output from an issuance mechanism or protocol.</t>		produced as output from an issuance mechanism or protocol.</t>
	</dd>		</dd>
	<dt>Origin:</dt>		<dt>Origin:</dt>
	<dd>		<dd>
	<t>An entity that consumes tokens presented by Clients and uses them t o make authorization decisions.</t>		<t>An entity that consumes tokens presented by Clients and uses them t o make authorization decisions.</t>
	</dd>		</dd>
	skipping to change at line 140 ¶		skipping to change at line 164 ¶
	<t>An entity that issues tokens to Clients for properties		<t>An entity that issues tokens to Clients for properties
	attested to by the Attester.</t>		attested to by the Attester.</t>
	</dd>		</dd>
	<dt>Issuance:</dt>		<dt>Issuance:</dt>
	<dd>		<dd>
	<t>The mechanism by which an Issuer produces tokens for Clients.</t>		<t>The mechanism by which an Issuer produces tokens for Clients.</t>
	</dd>		</dd>
	<dt>Attester:</dt>		<dt>Attester:</dt>
	<dd>		<dd>
	<t>An entity that attests to properties of Clients for the		<t>An entity that attests to properties of Clients for the
	purposes of token issuance. Using <xref target="RFC9334"/> terminology, Attester		purposes of token issuance. Using terminology from <xref target="RFC9334"/>, Att
	s implement		esters implement the RATS Verifier role.</t>
	the RATS Verifier role.</t>
	</dd>		</dd>
	<dt>Attestation procedure:</dt>		<dt>Attestation procedure:</dt>
	<dd>		<dd>
	<t>The procedure by which an Attester determines whether or not a Clie nt		<t>The procedure by which an Attester determines whether or not a Clie nt
	has the specific set of properties that are necessary for token issuance.</t>		has the specific set of properties that are necessary for token issuance.</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>The trust relationships between each of the entities in this list is fu rther		<t>The trust relationships between each of the entities in this list are f urther
	elaborated upon in <xref target="privacy-and-trust"/>.</t>		elaborated upon in <xref target="privacy-and-trust"/>.</t>
	</section>		</section>
	<section anchor="architecture">		<section anchor="architecture">
	<name>Architecture</name>		<name>Architecture</name>
	<t>The Privacy Pass architecture consists of four logical entities --		<t>The Privacy Pass architecture consists of four logical entities --
	Client, Origin, Issuer, and Attester -- that work in concert		Client, Origin, Issuer, and Attester -- that work in concert
	for token redemption and issuance. This section presents an overview		for token redemption and issuance. This section presents an overview
	of Privacy Pass, a high-level description of the threat model and		of Privacy Pass, a high-level description of the threat model and
	privacy goals of the architecture, and the goals and requirements of		privacy goals of the architecture, and the goals and requirements of
	the redemption and issuance protocols. Deployment variations for the		the redemption and issuance protocols. Deployment variations for the
	Origin, Issuer, and Attester in this architecture, including		Origin, Issuer, and Attester in this architecture, including
	considerations for implementing these entities, are further discussed		considerations for implementing these entities, are further discussed
	in <xref target="deployment"/>.</t>		in <xref target="deployment"/>.</t>
	<section anchor="overview">		<section anchor="overview">
	<name>Overview</name>		<name>Overview</name>
	<t>This section describes the typical interaction flow for Privacy Pass. </t>		<t>This section describes the typical interaction flow for Privacy Pass, as shown in <xref target="fig-overview"/>.</t>
	<ol spacing="normal" type="1"><li>A Client interacts with an Origin by s ending a request or otherwise		<ol spacing="normal" type="1"><li>A Client interacts with an Origin by s ending a request or otherwise
	interacting with the Origin in a way that triggers a response containing		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>		a token challenge. The token challenge indicates a specific Issuer to use.</li>
	<li>If the Client already has a token available that satisfies the tok en		<li>If the Client already has a token available that satisfies the tok en
	challenge, e.g., because the Client has a cache of previously issued tokens,		challenge, e.g., because the Client has a cache of previously issued tokens,
	it can skip to <xref format="none" target="step-redemption">step 6</xref> and re deem its		it can skip to <xref format="none" target="step-redemption">step 6</xref> and re deem its
	token; see <xref target="hoarding"/> for security considerations of cached token s.</li>		token; see <xref target="hoarding"/> for security considerations regarding cache d tokens.</li>
	<li>If the Client does not have a token available and decides it wants to		<li>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		obtain one (or more) bound to the token challenge, it then invokes the
	issuance protocol. As a prerequisite to the issuance protocol, the Client		issuance protocol. As a prerequisite to the issuance protocol, the Client
	runs the deployment-specific attestation process that is required for the		runs the deployment-specific attestation process that is required for the
	designated Issuer. Client attestation can be done via proof of solving a		designated Issuer. Client attestation can be done via proof of solving a
	CAPTCHA, checking device or hardware attestation validity, etc.; see		CAPTCHA, checking device or hardware attestation validity, etc.; see
	<xref target="attester"/> for more details.</li>		<xref target="attester"/> for more details.</li>
	<li>If the attestation process completes successfully, the client crea tes a		<li>If the attestation process completes successfully, the Client crea tes a
	token request to send to the designated Issuer (generally via the Attester,		token request to send to the designated Issuer (generally via the Attester,
	though it is not required to be sent through 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		The Attester and Issuer might be functions on the same server, depending on the
	deployment model (see <xref target="deployment"/>). Depending on the attestation process, it		deployment model (see <xref target="deployment"/>). Depending on the attestation process, it
	is possible for attestation to run alongside the issuance protocol, e.g., where		is possible for attestation to run alongside the issuance protocol, e.g., where
	Clients send necessary attestation information to the Attester along with their		Clients send necessary attestation information to the Attester along with their
	token request. If the attestation process fails, the Client receives an error		token request. If the attestation process fails, the Client receives an error
	and issuance aborts without a token.</li>		and issuance aborts without a token.</li>
	<li>The Issuer generates a token response based on the token request, which		<li>The Issuer generates a token response based on the token request, which
	is returned to the Client (generally via the Attester). Upon receiving the		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		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		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>		cannot be linked to the content of the token request or token response.</li>
	<li>		<li>
	<t anchor="step-redemption">If the Client has a token, it includes i t in a subsequent request to		<t anchor="step-redemption">If the Client has a token, it includes i t in a subsequent request to
	the Origin, as authorization. This token is sent only once in reaction to a		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		challenge; Clients do not send tokens more than once, even if they receive
	duplicate or redundant challenges. The Origin		duplicate or redundant challenges. The Origin
	validates that the token was generated by the expected Issuer and has not		validates that the token was generated by the expected Issuer and has not
	already been redeemed for the corresponding token challenge. If the Client		already been redeemed for the corresponding token challenge. If the Client
	does not have a token, perhaps because issuance failed, the client does not		does not have a token, perhaps because issuance failed, the Client does not
	reply to the Origin's challenge with a new request.</t>		reply to the Origin's challenge with a new request.</t>
	</li>		</li>
	</ol>		</ol>
	<figure anchor="fig-overview">		<figure anchor="fig-overview">
	<name>Privacy pass redemption and issuance protocol interaction</name>		<name>Privacy Pass Redemption and Issuance Protocol Interaction</name>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="224" width="520" viewBox="0 0 520 224" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" viewBox="0 0 520 224" class="diagram" text-anchor="middle" font-family="mo nospace" font-size="13px" stroke-linecap="round">
	<path d="M 8,32 L 8,64" fill="none" stroke="black"/>		<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 40,64 L 40,208" fill="none" stroke="black"/>
	<path d="M 80,32 L 80,64" 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 184,32 L 184,64" fill="none" stroke="black"/>
	<path d="M 216,64 L 216,208" 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 256,32 L 256,64" fill="none" stroke="black"/>
	<path d="M 336,32 L 336,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,64 L 376,144" fill="none" stroke="black"/>
	<path d="M 376,192 L 376,208" 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 424,32 L 424,64" fill="none" stroke="black"/>
	skipping to change at line 288 ¶		skipping to change at line 312 ¶
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	</section>		</section>
	<section anchor="use-cases">		<section anchor="use-cases">
	<name>Use Cases</name>		<name>Use Cases</name>
	<t>Use cases for Privacy Pass are broad and depend greatly on the deploy ment model		<t>Use cases for Privacy Pass are broad and depend greatly on the deploy ment model
	as discussed in <xref target="deployment"/>. The initial motivating use case for Privacy Pass		as discussed in <xref target="deployment"/>. The initial motivating use case for Privacy Pass
	<xref target="PrivacyPassCloudflare"/> was to help rate-limit malicious or other wise abusive		<xref target="PrivacyPassCloudflare"/> was to help rate-limit malicious or other wise abusive
	traffic from services such as Tor <xref target="DMS2004"/>. The generalized and evolved		traffic from services such as Tor <xref target="DMS2004"/>. The generalized and evolved
	architecture described in this document also work for this use case. However,		architecture described in this document also works for this use case. However,
	for added clarity, some more possible use cases are described below.</t>		for added clarity, some more possible use cases are described below.</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Low-quality, anti-fraud signal for open Internet services. Tokens can attest that		<li>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		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 proced ures		form of automated attack such as credential stuffing. Example attestation proced ures
	for this use case might be solving some form of CAPTCHA or presenting evidence o f a		for this use case might be solving some form of CAPTCHA or presenting evidence o f a
	valid, unlocked device in good standing.</li>		valid, unlocked device in good standing.</li>
	<li>Privacy-preserving authentication for proprietary services. Tokens can attest that		<li>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		the Client is a valid subscriber for a proprietary service, such as a deployment of
	Oblivious HTTP <xref target="OHTTP"/>.</li>		Oblivious HTTP <xref target="RFC9458"/>.</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="privacy-and-trust">		<section anchor="privacy-and-trust">
	<name>Privacy Goals and Threat Model</name>		<name>Privacy Goals and Threat Model</name>
	<t>The end-to-end flow for Privacy Pass described in <xref target="overv iew"/> involves three		<t>The end-to-end flow for Privacy Pass described in <xref target="overv iew"/> involves three
	different types of contexts:</t>		different types of contexts:</t>
	<dl>		<dl>
	<dt>Redemption context:</dt>		<dt>Redemption context:</dt>
	<dd>		<dd>
	<t>The interactions and set of information shared		<t>The interactions and set of information shared
	between the Client and Origin, i.e., the information that is provided or		between the Client and Origin, i.e., the information that is provided or
	otherwise available to the Origin during redemption that might be used		otherwise available to the Origin during redemption that might be used
	to identify a Client and construct a token challenge. This context includes all		to identify a Client and construct a token challenge. This context includes all
	information associated with redemption, such as the timestamp of the event,		information associated with redemption, such as the timestamp of the event,
	Client-visible information (including the IP address), and the Origin name.</t>		Client-visible information (including the IP address), and the Origin name.</t>
	</dd>		</dd>
	<dt>Issuance context:</dt>		<dt>Issuance context:</dt>
	<dd>		<dd>
	<t>The interactions and set of information shared between the Client , Attester,		<t>The interactions and set of information shared between the Client , Attester,
	and Issuer, i.e., the information that is provided or otherwise available		and Issuer, i.e., the information that is provided or otherwise available
	to Attester and Issuer during issuance that might be used to identify a Client.		to the Attester and Issuer during issuance that might be used to identify a Clie nt.
	This context includes all information associated with issuance, such as the		This context includes all information associated with issuance, such as the
	timestamp of the event, any Client-visible information (including the IP		timestamp of the event, any Client-visible information (including the IP
	address), and the Origin name (if revealed during issuance). This does not		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		include the token challenge in its entirety, as that is kept secret from the
	Issuer during the issuance protocol.</t>		Issuer during the issuance protocol.</t>
	</dd>		</dd>
	<dt>Attestation context:</dt>		<dt>Attestation context:</dt>
	<dd>		<dd>
	<t>The interactions and set of information shared between		<t>The interactions and set of information shared between
	the Client and Attester only, for the purposes of attesting the validity of		the Client and Attester only, for the purposes of attesting the validity of
	the Client, that is provided or otherwise available during attestation that		the Client, that is provided or otherwise available during attestation that
	might be used to identify the Client. This context includes all information		might be used to identify the Client. This context includes all information
	associated with attestation, such as the timestamp of the event and any		associated with attestation, such as the timestamp of the event and any
	Client-visible information, including information needed for the attestation		Client-visible information, including information needed for the attestation
	procedure to complete.</t>		procedure to complete.</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>The privacy goals of Privacy Pass assume a threat model in which Orig ins trust		<t>The privacy goals of Privacy Pass assume a threat model in which Orig ins trust
	specific Issuers to produce tokens, and Issuers in turn trust one or more		specific Issuers to produce tokens, and Issuers in turn trust one or more
	Attesters to correctly run the attestation procedure with Clients. This		Attesters to correctly run the attestation procedure with Clients. This
	arrangement ensures that tokens which validate for a given Issuer were only		arrangement ensures that tokens that validate for a given Issuer were only
	issued to a Client that successfully completed attestation with an Attester		issued to a Client that successfully completed attestation with an Attester
	that the Issuer trusts. Moreover, this arrangement means that if an Origin		that the Issuer trusts. Moreover, this arrangement means that if an Origin
	accepts tokens issued by an Issuer that trusts multiple Attesters, then a		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		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		Origin. Whether or not these different entities in the architecture collude
	for learning redemption, issuance, or attestation contexts, as well as the		for learning redemption, issuance, or attestation contexts, as well as the
	necessary preconditions for context unlinkability, depends on the deployment		necessary preconditions for context unlinkability, depends on the deployment
	model; see <xref target="deployment"/> for more details.</t>		model; see <xref target="deployment"/> for more details.</t>
	<t>The mechanisms for establishing trust between each entity in this arr angement		<t>The mechanisms for establishing trust between each entity in this arr angement
	are deployment-specific. For example, in settings where Clients interact with		are deployment specific. For example, in settings where Clients interact with
	Issuers through an Attester, Attesters and Issuers might use		Issuers through an Attester, Attesters and Issuers might use
	mutually authenticated TLS to authenticate one another. In settings where		mutually authenticated TLS to authenticate one another. In settings where
	Clients do not communicate with Issuers through an Attester, the Attesters		Clients do not communicate with Issuers through an Attester, the Attesters
	might convey this trust via a digital signature that Issuers can verify.</t>		might convey this trust via a digital signature that Issuers can verify.</t>
	<t>Clients explicitly trust Attesters to perform attestation correctly a nd in a		<t>Clients explicitly trust Attesters to perform attestation correctly a nd in a
	way that does not violate their privacy. In particular, this means that Attester s		way that does not violate their privacy. In particular, this means that Attester s
	which may be privy to private information about Clients are trusted to not discl ose		that may be privy to private information about Clients are trusted to not disclo se
	this information to non-colluding parties. Colluding parties are assumed to have		this information to non-colluding parties. Colluding parties are assumed to have
	access to the same information; see <xref target="deployment"/> for more about d ifferent		access to the same information; see <xref target="deployment"/> for more about d ifferent
	deployment models and non-collusion assumptions. However, Clients assume Issuers and		deployment models and non-collusion assumptions. However, Clients assume that Is suers and
	Origins are malicious.</t>		Origins are malicious.</t>
	<t>Given this threat model, the privacy goals of Privacy Pass are orient ed around		<t>Given this threat model, the privacy goals of Privacy Pass are orient ed around
	unlinkability based on redemption, issuance, and attestation contexts, as		unlinkability based on redemption, issuance, and attestation contexts, as
	described below.</t>		described below.</t>
	<ol spacing="normal" type="1"><li>Origin-Client unlinkability. This mean s that given two redemption contexts,		<ol spacing="normal" type="1"><li>Origin-Client unlinkability. This mean s that given two redemption contexts,
	the Origin cannot determine if both redemption contexts correspond to the same		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		Client or two different Clients. Informally, this means that a Client in a
	redemption context is indistinguishable from any other Client that might use		redemption context is indistinguishable from any other Client that might use
	the same redemption context. The set of Clients that share the same redemption		the same redemption context. The set of Clients that share the same redemption
	context is referred to as a redemption anonymity set.</li>		context is referred to as a redemption anonymity set.</li>
	skipping to change at line 387 ¶		skipping to change at line 411 ¶
	the Attester cannot determine if both contexts correspond to the same Origin		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		or two different Origins. The set of Origins that share the same attestation
	context is referred to as an attestation anonymity set.</li>		context is referred to as an attestation anonymity set.</li>
	<li>Redemption context unlinkability. Given two redemption contexts, t he Origin		<li>Redemption context unlinkability. Given two redemption contexts, t he Origin
	cannot determine which issuance and attestation contexts each redemption		cannot determine which issuance and attestation contexts each redemption
	corresponds to, even with the collaboration of the Issuer and Attester (should		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		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		about the Client during the issuance and attestation flows cannot be used by the
	Origin to compromise Client privacy.</li>		Origin to compromise Client privacy.</li>
	</ol>		</ol>
	<t>These unlinkability properties ensure that only the Client is able to correlate		<t>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.		information that might be used to identify them with activity on the Origin.
	The Attester, Issuer, and Origin only receive the information necessary to perfo rm		The Attester, Issuer, and Origin only receive the information necessary to perfo rm
	their respective functions.</t>		their respective functions.</t>
	<t>The manner in which these unlinkability properties are achieved depen ds on the		<t>The manner in which these unlinkability properties are achieved depen ds on the
	deployment model, type of attestation, and issuance protocol details. For exampl e,		deployment model, type of attestation, and issuance protocol details. For exampl e,
	as discussed in <xref target="deployment"/>, in some cases it is necessary to us e an anonymization		as discussed in <xref target="deployment"/>, in some cases it is necessary to us e an anonymization
	service such as Tor <xref target="DMS2004"/> which hides Clients IP addresses. I		service that hides Client IP addresses, such as Tor <xref target="DMS2004"/>. In
	n general,		general,
	anonymization services ensures that all Clients which use the service are indist		anonymization services ensure that all Clients that use the service are indistin
	inguishable		guishable
	from one another, though in practice there may be small distinguishing features		from one another, though in practice there may be small distinguishing features
	(TLS fingerprints, HTTP headers, etc). Moreover, Clients generally trust these s ervices		(TLS fingerprints, HTTP headers, etc.). Moreover, Clients generally trust these services
	to not disclose private Client information (such as IP addresses) to untrusted p arties.		to not disclose private Client information (such as IP addresses) to untrusted p arties.
	Failure to use an anonymization service when interacting with Attesters, Issuers , or		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,		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		and can therefore lead to unlinkability violations. Similarly, malicious Origins
	may attempt to link two redemption contexts together by using Client-specific		may attempt to link two redemption contexts together by using Client-specific
	Issuer public keys. See <xref target="deployment-considerations"/> and <xref tar get="privacy"/> for more		Issuer Public Keys. See Sections&nbsp;<xref target="deployment-considerations" f ormat="counter"/> and <xref target="privacy" format="counter"/> for more
	information.</t>		information.</t>
	<t>The remainder of this section describes the functional properties and security		<t>Sections <xref target="redemption" format="counter"/> and <xref targe t="issuance-protocol" format="counter"/> describe the functional properties and security
	requirements of the redemption and issuance protocols in more detail. <xref targ et="flow"/>		requirements of the redemption and issuance protocols in more detail. <xref targ et="flow"/>
	describes how information flows between Issuer, Origin, Client, and Attester		describes how information flows between the Issuer, Origin, Client, and Attester
	through these protocols.</t>		through these protocols.</t>
	</section>		</section>
	<section anchor="redemption">		<section anchor="redemption">
	<name>Redemption Protocol</name>		<name>Redemption Protocol</name>
	<t>The Privacy Pass redemption protocol, described in		<t>The Privacy Pass redemption protocol, described in
	<xref target="AUTHSCHEME"/>, is an authorization protocol		<xref target="RFC9577"/>, is an authorization protocol
	wherein Clients present tokens to Origins for authorization. Normally,		wherein Clients present tokens to Origins for authorization. Normally,
	redemption is preceded by a challenge, wherein the Origin challenges		redemption is preceded by a challenge, wherein the Origin challenges
	Clients for a token with a TokenChallenge (<xref section="2.1" sectionFormat="co		Clients for a token with a TokenChallenge (<xref section="2.1" sectionFormat="co
	mma" target="AUTHSCHEME"/>) and,		mma" target="RFC9577"/>) and,
	if possible, Clients present a valid Token (<xref section="2.2" sectionFormat="c		if possible, Clients present a valid token (<xref section="2.2" sectionFormat="c
	omma" target="AUTHSCHEME"/>)		omma" target="RFC9577"/>)
	in reaction to the challenge. This interaction is shown below.</t>		in reaction to the challenge. This interaction is shown below.</t>
	<figure anchor="fig-redemption">		<figure anchor="fig-redemption">
	<name>Challenge and redemption protocol interaction</name>		<name>Challenge and Redemption Protocol Interaction</name>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="176" width="432" viewBox="0 0 432 176" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" viewBox="0 0 432 176" class="diagram" text-anchor="middle" font-family="mo nospace" font-size="13px" stroke-linecap="round">
	<path d="M 8,32 L 8,64" fill="none" stroke="black"/>		<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 40,64 L 40,160" fill="none" stroke="black"/>
	<path d="M 80,32 L 80,64" 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 184,32 L 184,64" fill="none" stroke="black"/>
	<path d="M 216,64 L 216,160" 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 256,32 L 256,64" fill="none" stroke="black"/>
	<path d="M 8,32 L 80,32" 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 184,32 L 256,32" fill="none" stroke="black"/>
	<path d="M 8,64 L 80,64" 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 184,64 L 256,64" fill="none" stroke="black"/>
	skipping to change at line 473 ¶		skipping to change at line 498 ¶
	| |		| |
	|<----- Request ------+		|<----- Request ------+
	+-- TokenChallenge -->|		+-- TokenChallenge -->|
	| | <== Issuance protocol ==>		| | <== Issuance protocol ==>
	|<-- Request+Token ---+		|<-- Request+Token ---+
	| |		| |
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t>Alternatively, when configured to do so, Clients may opportunisticall y present		<t>Alternatively, when configured to do so, Clients may opportunisticall y present
	Token values to Origins without a corresponding TokenChallenge.</t>		token values to Origins without a corresponding TokenChallenge.</t>
	<t>The structure and semantics of the TokenChallenge and Token messages		<t>The structure and semantics of the TokenChallenge and token messages
	depend		depend
	on the issuance protocol and token type being used; see <xref target="AUTHSCHEME		on the issuance protocol and token type being used; see <xref target="RFC9577"/>
	"/> for		for
	more information.</t>		more information.</t>
	<t>The challenge provides the client with the information necessary to o btain		<t>The challenge provides the Client with the information necessary to o btain
	tokens that the server might subsequently accept in the redemption context.		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,		There are a number of ways in which the token may vary based on this challenge,
	including:</t>		including the following:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Issuance protocol. The challenge identifies the type of issuance p rotocol		<li>Issuance protocol. The challenge identifies the type of issuance p rotocol
	required for producing the token. Different issuance protocols have different		required for producing the token. Different issuance protocols have different
	security properties, e.g., some issuance protocols may produce tokens that		security properties, e.g., some issuance protocols may produce tokens that
	are publicly verifiable, whereas others may not have this property.</li>		are publicly verifiable, whereas others may not have this property.</li>
	<li>Issuer identity. Token challenges identify which Issuers are trust ed for a		<li>Issuer identity. Token challenges identify which Issuers are trust ed for a
	given issuance protocol. As described in <xref target="privacy-and-trust"/>, the choice		given issuance protocol. As described in <xref target="privacy-and-trust"/>, the choice
	of Issuer determines the type of Attesters and attestation procedures possible		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		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>		which Attester was used for a given token issuance event.</li>
	<li>Redemption context. Challenges can be bound to a given redemption context,		<li>Redemption context. Challenges can be bound to a given redemption context,
	which influences a client's ability to pre-fetch and cache tokens. For		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		example, an empty redemption context always allows tokens to be issued and
	redeemed non-interactively, whereas a fresh and random redemption context		redeemed non-interactively, whereas a fresh and random redemption context
	means that the redeemed token must be issued only after the client receives		means that the redeemed token must be issued only after the Client receives
	the challenge. See <xref section="2.1.1" sectionFormat="of" target="AUTHSCHEME"/		the challenge. See <xref section="2.1.1" sectionFormat="of" target="RFC9577"/> f
	> for more details.</li>		or more details.</li>
	<li>Per-Origin or cross-Origin. Challenges can be constrained to the O rigin for		<li>Per-Origin or cross-Origin. Challenges can be constrained to the O rigin for
	which the challenge originated (referred to as per-Origin tokens), or		which the challenge originated (referred to as per-Origin tokens) or
	can be used across multiple Origins (referred to as cross-Origin tokens).		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		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		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,		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		agrees to admit tokens for any other Origin in the set. See
	<xref section="2.1.1" sectionFormat="of" target="AUTHSCHEME"/> for more informat ion on how this set is created.</li>		<xref section="2.1.1" sectionFormat="of" target="RFC9577"/> for more information on how this set is created.</li>
	</ul>		</ul>
	<t>Origins that admit cross-Origin tokens bear some risk of allowing tok ens		<t>Origins that admit cross-Origin tokens bear some risk of allowing tok ens
	issued for one Origin to be spent in an interaction with another Origin.		issued for one Origin to be spent in an interaction with another Origin.
	In particular, cross-Origin tokens issued based on a challenge for		In particular, cross-Origin tokens issued based on a challenge for
	one Origin can be redeemed at another Origin in the cross-Origin set,		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		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		use case, Origins may need to maintain state to track redeemed tokens. For
	example, Origins that accept cross-Origin tokens across shared redemption		example, Origins that accept cross-Origin tokens across shared redemption
	contexts SHOULD track which tokens have been redeemed already in those		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		redemption contexts, since these tokens can be issued and then spent multiple
	times for any such challenge. Note that Clients which redeem the		times for any such challenge. Note that Clients that redeem the
	same token to multiple Origins do risk those Origins being able to link		same token to multiple Origins do risk those Origins being able to link
	Client activity together, which can disincentivize this behavior. See		Client activity together, which can disincentivize this behavior. See
	<xref section="2.1.1" sectionFormat="of" target="AUTHSCHEME"/> for discussion.</ t>		<xref section="2.1.1" sectionFormat="of" target="RFC9577"/> for discussion.</t>
	<t>How Clients respond to token challenges can have privacy implications .		<t>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		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		of Issuer can reveal information about the Client used to partition anonymity
	sets; see <xref target="rotation-and-consistency"/> for more information about t hese privacy		sets; see <xref target="rotation-and-consistency"/> for more information about t hese privacy
	considerations.</t>		considerations.</t>
	</section>		</section>
	<section anchor="issuance-protocol">		<section anchor="issuance-protocol">
	<name>Issuance Protocol</name>		<name>Issuance Protocol</name>
	<t>The Privacy Pass issuance protocol, described in <xref target="ISSUAN		<t>The Privacy Pass issuance protocols, such as those described in <xref
	CE"/>, is a two-message		target="RFC9578"/>, are two-message
	protocol that takes as input a TokenChallenge from the redemption protocol		protocols that take as input a TokenChallenge from the redemption protocol
	(<xref section="2.1" sectionFormat="comma" target="AUTHSCHEME"/>) and produces a		(<xref section="2.1" sectionFormat="comma" target="RFC9577"/>) and produce a tok
	Token		en
	(<xref section="2.2" sectionFormat="comma" target="AUTHSCHEME"/>), as shown in <		(<xref section="2.2" sectionFormat="comma" target="RFC9577"/>), as shown in <xre
	xref target="fig-overview"/>.</t>		f target="fig-overview"/>.</t>
	<t>The structure and semantics of the TokenRequest and TokenResponse mes sages		<t>The structure and semantics of the TokenRequest and TokenResponse mes sages
	depend on the issuance protocol and token type being used; see <xref target="ISS UANCE"/>		depend on the issuance protocol and token type being used; see <xref target="RFC 9578"/>
	for more information.</t>		for more information.</t>
	<t>Clients interact with the Attester and Issuer to produce a token for		<t>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		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		issuance is referred to as the attestation context. This context includes all
	information associated with the issuance event, such as the timestamp of the		information associated with the issuance event, such as the timestamp of the
	event and Client-visible information, including the IP address or other		event and Client-visible information, including the IP address or other
	information specific to the type of attestation done.</t>		information specific to the type of attestation done.</t>
	<t>Each issuance protocol may be different, e.g., in the number and type s of		<t>Each issuance protocol may be different, e.g., in the number and type s of
	participants, underlying cryptographic constructions used when issuing tokens,		participants, underlying cryptographic constructions used when issuing tokens,
	and even privacy properties.</t>		and even privacy properties.</t>
	<t>Clients initiate the issuance protocol using the token challenge, a r andomly		<t>Clients initiate the issuance protocol using the token challenge, a r andomly
	generated nonce, and public key for the Issuer, all of which are the Client's		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;		private input to the protocol and ultimately bound to an output token;
	see <xref section="2.2" sectionFormat="of" target="AUTHSCHEME"/> for details. Fu		see <xref section="2.2" sectionFormat="of" target="RFC9577"/> for details. Futur
	ture specifications		e specifications
	may change or extend the Client's input to the issuance protocol to produce		may change or extend the Client's input to the issuance protocol to produce
	Tokens with a different structure.</t>		tokens with a different structure.</t>
	<t>Token properties vary based on the issuance protocol. Important prope rties		<t>Token properties vary based on the issuance protocol. Important prope rties
	supported in this architecture are described below.</t>		supported in this architecture are described below.</t>
	<ol spacing="normal" type="1"><li>Public verifiability. This means the T		<ol spacing="normal" type="1"><li>Public verifiability. This means that
	oken can be verified using the Issuer		the token can be verified using the Issuer
	public key. A Token that does not have public verifiability can only be verified		Public Key. A token that does not have public verifiability can only be verified
	using the Issuer secret key.</li>		using the Issuer secret key.</li>
	<li>Public metadata. This means that the Token can be cryptographicall y bound to		<li>Public metadata. This means that the token can be cryptographicall y bound to
	arbitrary public information. See <xref target="metadata-privacy"/> for privacy considerations		arbitrary public information. See <xref target="metadata-privacy"/> for privacy considerations
	of public metadata.</li>		regarding public metadata.</li>
	<li>Private metadata. This means that the Token can be cryptographical		<li>Private metadata. This means that the token can be cryptographical
	ly bound to		ly bound to
	arbitrary private information, i.e., information that the Client does not observ e		arbitrary private information, i.e., information that the Client does not observ e
	during Token issuance or redemption. See <xref target="metadata-privacy"/> for p		during token issuance or redemption. See <xref target="metadata-privacy"/> for p
	rivacy		rivacy
	considerations of private metadata.</li>		considerations regarding private metadata.</li>
	</ol>		</ol>
	<t>The issuance protocol itself can be any interactive protocol between Client,		<t>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		Issuer, or other parties that produces a valid token bound to the Client's
	private input, subject to the following security requirements.</t>		private input, subject to the following security requirements.</t>
	<ol spacing="normal" type="1"><li>Unconditional input secrecy. The issua nce protocol MUST NOT reveal anything		<ol spacing="normal" type="1"><li>Unconditional input secrecy. The issua nce protocol <bcp14>MUST NOT</bcp14> reveal anything
	about the Client's private input, including the challenge and nonce, to the		about the Client's private input, including the challenge and nonce, to the
	Attester or Issuer, regardless of the hardness assumptions of the underlying		Attester or Issuer, regardless of the hardness assumptions of the underlying
	cryptographic protocol(s). This property is sometimes also referred to as		cryptographic protocol(s). This property is sometimes also referred to as
	blindness.</li>		blindness.</li>
	<li>One-more forgery security. The issuance protocol MUST NOT allow ma licious		<li>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		Clients or Attesters (acting as Clients) to forge tokens offline or otherwise
	without interacting with the Issuer directly.</li>		without interacting with the Issuer directly.</li>
	<li>Concurrent security. The issuance protocol MUST be safe to run con		<li>Concurrent security. The issuance protocol <bcp14>MUST</bcp14> be
	currently		safe to run concurrently
	with arbitrarily many Clients, Attesters and Issuers.</li>		with arbitrarily many Clients, Attesters, and Issuers.</li>
	</ol>		</ol>
	<t>See <xref target="extensions"/> for requirements on new issuance prot ocol variants and		<t>See <xref target="extensions"/> for requirements on new issuance prot ocol variants and
	related extensions.</t>		related extensions.</t>
	<t>In the sections below, we describe the Attester and Issuer roles in m ore		<t>In the sections below, we describe the Attester and Issuer roles in m ore
	detail.</t>		detail.</t>
	<section anchor="attester">		<section anchor="attester">
	<name>Attester Role</name>		<name>Attester Role</name>
	<t>In Privacy Pass, attestation is the process by which an Attester be ars		<t>In Privacy Pass, attestation is the process by which an Attester be ars
	witness to, confirms, or authenticates a Client so as to verify properties		witness to, confirms, or authenticates a Client so as to verify properties
	about the Client that are required for Issuance. Issuers trust Attesters		about the Client that are required for issuance. Issuers trust Attesters
	to perform attestation correctly, i.e., to implement attestation procedures		to perform attestation correctly, i.e., to implement attestation procedures
	in a way that are not subverted or bypassed by malicious Clients.</t>		in such a way that those procedures are not subverted or bypassed by malicious C lients.</t>
	<t><xref target="RFC9334"/> describes an architecture for attestation procedures. Using		<t><xref target="RFC9334"/> describes an architecture for attestation procedures. Using
	that architecture as a conceptual basis, Clients are RATS attesters that		that architecture as a conceptual basis, Clients are RATS Attesters that
	produce attestation evidence, and Attesters are RATS verifiers that		produce attestation evidence, and Attesters are RATS Verifiers that
	appraise the validity of attestation evidence.</t>		appraise the validity of attestation evidence.</t>
	<t>The type of attestation procedure is a deployment-specific option a nd outside		<t>The type of attestation procedure is a deployment-specific option a nd outside
	the scope of the issuance protocol. Example attestation procedures are below.</t >		the scope of the issuance protocol. Example attestation procedures are below.</t >
	<ul spacing="normal">		<ul spacing="normal">
	<li>Solving a CAPTCHA. Clients that solve CAPTCHA challenges can be attested to		<li>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		have this capability for the purpose of being ruled out as a bot or otherwise
	automated Client.</li>		automated Client.</li>
	<li>Presenting evidence of Client device validity. Some Clients run on trusted		<li>Presenting evidence of Client device validity. Some Clients run on trusted
	hardware that are capable of producing device-level attestation evidence.</li>		hardware that is capable of producing device-level attestation evidence.</li>
	<li>Proving properties about Client state. Clients can be associated		<li>Proving properties about Client state. Clients can be associated
	with state		with state,
	and the Attester can verify this state. Examples of state include the		and the Attester can verify this state. Examples of state include the
	Client's geographic region and whether the Client has a valid		Client's geographic region and whether the Client has a valid
	application-layer account.</li>		application-layer account.</li>
	</ul>		</ul>
	<t>Attesters may support different types of attestation procedures.</t >		<t>Attesters may support different types of attestation procedures.</t >
	<t>Each attestation procedure has different security properties. For		<t>Each attestation procedure has different security properties. For
	example, attesting to having a valid account is different from attesting to		example, attesting to having a valid account is different from attesting to
	running on trusted hardware. Supporting multiple attestation procedures is		running on trusted hardware. Supporting multiple attestation procedures is
	an important step towards ensuring equitable access for Clients; see <xref targe t="discrimination"/>.</t>		an important step towards ensuring equitable access for Clients; see <xref targe t="discrimination"/>.</t>
	<t>The role of the Attester in the issuance protocol and its impact on privacy		<t>The role of the Attester in the issuance protocol and its impact on privacy
	depends on the type of attestation procedure, issuance protocol, and deployment		depend on the type of attestation procedure, issuance protocol, and deployment
	model. For instance, increasing the number of required attestation procedures		model. For instance, increasing the number of required attestation procedures
	could decrease the overall anonymity set size. As an example, the number of Clie nts		could decrease the overall anonymity set size. As an example, the number of Clie nts
	that have solved a CAPTCHA in the past day, that have a valid account, and that		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		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"/> for more discussion		solved a CAPTCHA in the past day. See <xref target="rotation-and-consistency"/> for more discussion
	of how the variety of attestation procedures can negatively impact Client privac y.</t>		of how the variety of attestation procedures can negatively impact Client privac y.</t>
	<t>Depending on the issuance protocol, the Issuer might learn		<t>Depending on the issuance protocol, the Issuer might learn
	information about the Origin. To ensure Issuer-Client unlinkability, the Issuer		information about the Origin. To ensure Issuer-Client unlinkability, the Issuer
	should be unable to link that information to a specific Client. For such		should be unable to link that information to a specific Client. For such
	issuance protocols where the Attester has access to Client-specific		issuance protocols where the Attester has access to Client-specific
	information, such as is the case for attestation procedures that involve		information, such as is the case for attestation procedures that involve
	Client-specific information (such as application-layer account information)		Client-specific information (such as application-layer account information)
	or for deployment models where the Attester learns Client-specific 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		(such as Client IP addresses), Clients trust the Attester to not share any
	Client-specific information with the Issuer. In deployments where the Attester		Client-specific information with the Issuer. In deployments where the Attester
	does not learn Client-specific information, or where the Attester and Issuer are		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		operated by the same entity (such as in the Joint Attester and Issuer model
	described in <xref target="deploy-joint-issuer"/>), the Client does not need to explicitly		described in <xref target="deploy-joint-issuer"/>), the Client does not need to explicitly
	trust the Attester in this regard.</t>		trust the Attester in this regard.</t>
	<t>Issuers trust Attesters to correctly and reliably perform attestati on. However,		<t>Issuers trust Attesters to correctly and reliably perform attestati on. However,
	certain types of attestation can vary in value over time, e.g., if the		certain types of attestation procedures can vary in value over time, e.g., if th e
	attestation procedure is compromised. Broken		attestation procedure is compromised. Broken
	attestation procedures are considered exceptional events and require		attestation procedures are considered exceptional events and require
	configuration changes to address the underlying cause. For example, if		configuration changes to address the underlying cause. For example, if
	an attestation procedure is compromised or subverted because of a zero-day		an attestation procedure is compromised or subverted because of a zero-day
	exploit on devices that implement the attestation procedure, then the		exploit on devices that implement the attestation procedure, then the
	corresponding attestation procedure should be untrusted until the exploit is		corresponding attestation procedure should be untrusted until the exploit is
	patched. Addressing changes in attestation quality is therefore a		patched. Addressing changes in attestation quality is therefore a
	deployment-specific task. In Split Attester and Issuer deployments (see		deployment-specific task. In Split Origin, Attester, and Issuer deployments (see
	<xref target="deploy-split"/>), Issuers can choose to remove compromised Atteste rs from		<xref target="deploy-split"/>), Issuers can choose to remove compromised Atteste rs from
	their trusted set until the compromise is patched.</t>		their trusted set until the compromise is patched.</t>
	<t>From the perspective of an Origin, tokens produced by an Issuer wit h at least		<t>From the perspective of an Origin, tokens produced by an Issuer wit h at least
	one compromised Attester cannot be trusted assuming the Origin does not know		one compromised Attester cannot be trusted, assuming that the Origin does not kn ow
	which attestation procedure was used for issuance. This is because the Origin		which attestation procedure was used for issuance. This is because the Origin
	cannot distinguish between tokens that were issued via compromised Attesters		cannot distinguish between tokens that were issued via compromised Attesters
	and tokens that were issued via uncompromised Attesters absent some		and tokens that were issued via uncompromised Attesters, absent some
	distinguishing information in the tokens themselves or from the Issuer. As a		distinguishing information in the tokens themselves or from the Issuer. As a
	result, until the attestation procedure is fixed, the Issuer cannot be trusted		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		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		compromised Attester may no longer be trusted by Origins, even if those tokens
	were issued to Clients interacting with an uncompromised Attester.</t>		were issued to Clients interacting with an uncompromised Attester.</t>
	</section>		</section>
	<section anchor="issuer-role">		<section anchor="issuer-role">
	<name>Issuer Role</name>		<name>Issuer Role</name>
	<t>In Privacy Pass, the Issuer is responsible for completing the issua nce protocol		<t>In Privacy Pass, the Issuer is responsible for completing the issua nce protocol
	for Clients that complete attestation through a trusted Attester. As described		for Clients that complete attestation through a trusted Attester. As described
	in <xref target="attester"/>, Issuers explicitly trust Attesters to correctly an d reliably		in <xref target="attester"/>, Issuers explicitly trust Attesters to correctly an d reliably
	perform attestation. Origins explicitly trust Issuers to only issue tokens		perform attestation. Origins explicitly trust Issuers to only issue tokens
	from trusted Attesters. Clients do not explicitly trust Issuers.</t>		from trusted Attesters. Clients do not explicitly trust Issuers.</t>
	<t>Depending on the deployment model case, issuance may require some f orm of		<t>Depending on the deployment model case, issuance may require some f orm of
	Client anonymization service, similar to an IP-hiding proxy, so that Issuers		Client anonymization service, similar to an IP-hiding proxy, so that Issuers
	cannot learn information about Clients. This can be provided by an explicit		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,		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="DMS 2004"/>.		such as through the use of an IP-hiding proxy service like Tor <xref target="DMS 2004"/>.
	In general, Clients SHOULD minimize or remove identifying		In general, Clients <bcp14>SHOULD</bcp14> minimize or remove identifying
	information where possible when invoking the issuance protocol.</t>		information where possible when invoking the issuance protocol.</t>
	<t>Issuers are uniquely identifiable by all Clients with a consistent		<t>Issuers are uniquely identifiable by all Clients with a consistent
	identifier. In a web context, this identifier might be the Issuer host name.		identifier. In a web context, this identifier might be the Issuer hostname.
	Issuers maintain one or more configurations, including issuance key pairs, for		Issuers maintain one or more configurations, including issuance key pairs, for
	use in the issuance protocol. Each configuration is assumed to have a unique		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.		and canonical identifier, sometimes referred to as a key identifier or key ID.
	Issuers can rotate these configurations as needed to mitigate risk of compromise ;		Issuers can rotate these configurations as needed to mitigate the risk of compro mise;
	see <xref target="rotation-and-consistency"/> for more considerations around con figuration		see <xref target="rotation-and-consistency"/> for more considerations around con figuration
	rotation. The Issuer public key for each active configuration is made available		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>		to Origins and Clients for use in the issuance and redemption protocols.</t>
	</section>		</section>
	<section anchor="metadata">		<section anchor="metadata">
	<name>Issuance Metadata</name>		<name>Issuance Metadata</name>
	<t>Certain instantiations of the issuance protocol may permit public o r private		<t>Certain instantiations of the issuance protocol may permit public o r private
	metadata to be cryptographically bound to a token. As an example, one		metadata to be cryptographically bound to a token. As an example, one
	trivial way to include public metadata is to assign a unique Issuer		trivial way to include public metadata is to assign a unique Issuer
	public key for each value of metadata, such that N keys yields		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>		log<sub>2</sub>(N) bits of metadata. Metadata may be public or private.</t>
	<t>Public metadata is that which clients can observe as part of the to		<t>Public metadata is metadata that Clients can observe as part of the
	ken		token
	issuance flow. Public metadata can either be transparent or opaque. For		issuance flow. Public metadata can be either transparent or opaque. For
	example, transparent public metadata is a value that the client either		example, transparent public metadata is a value that either the Client
	generates itself, or the Issuer provides during the issuance flow and		generates itself or the Issuer provides during the issuance flow and that the
	the client can check for correctness. Opaque public metadata is metadata		Client can check for correctness. Opaque public metadata is metadata
	the client can see but cannot check for correctness. As an example, the		the Client can see but cannot check for correctness. As an example, the
	opaque public metadata might be a "fraud detection signal", computed on		opaque public metadata might be a "fraud detection signal", computed on
	behalf of the Issuer, during token issuance. Generally speaking, Clients		behalf of the Issuer, during token issuance. Generally speaking, Clients
	cannot determine if this value is generated in a way that permits tracking.</t>		cannot determine if this value is generated in a way that permits tracking.</t>
	<t>Private metadata is that which Clients cannot observe as part of th		<t>Private metadata is metadata that Clients cannot observe as part of
	e token		the token
	issuance flow. Such instantiations can be built on the Private Metadata Bit		issuance flow. Such instantiations can be built on the private metadata bit
	construction from Kreuter et al. <xref target="KLOR20"/>		construction from Kreuter et al.&nbsp;<xref target="KLOR20"/>
	or the attribute-based VOPRF from Huang et al. <xref target="HIJK21"/>.</t>		or the attribute-based Verifiable Oblivious Pseudorandom Function (VOPRF) from H
			uang et al.&nbsp;<xref target="HIJK21"/>.</t>
	<t>Metadata can be arbitrarily long or bounded in length. The amount o f permitted		<t>Metadata can be arbitrarily long or bounded in length. The amount o f permitted
	metadata may be determined by application or by the underlying cryptographic		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		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		public and private metadata bits. Every bit of metadata can be used to
	partition the Client issuance or redemption anonymity sets; see		partition the Client issuance or redemption anonymity sets; see
	<xref target="metadata-privacy"/> for more information.</t>		<xref target="metadata-privacy"/> for more information.</t>
	</section>		</section>
	<section anchor="extensions">		<section anchor="extensions">
	<name>Future Issuance Protocol Requirements</name>		<name>Future Issuance Protocol Requirements</name>
	<t>The Privacy Pass architecture and ecosystem are both intended to be receptive		<t>The Privacy Pass architecture and ecosystem are both intended to be receptive
	to extensions that expand the current set of functionalities through new		to extensions that expand the current set of functionalities through new
	issuance protocols. Each new issuance protocol and extension MUST adhere		issuance protocols. Each new issuance protocol and extension <bcp14>MUST</bcp14> adhere
	to the following requirements:</t>		to the following requirements:</t>
	<ol spacing="normal" type="1"><li>Include a detailed analysis of the p rivacy impacts of the extension, why		<ol spacing="normal" type="1"><li>Include a detailed analysis of the p rivacy impacts of the extension, why
	these impacts are justified, and guidelines on how to use the protocol		these impacts are justified, and guidelines on how to use the protocol
	to mitigate or minimize negative deployment or privacy consequences		to mitigate or minimize negative deployment or privacy consequences
	discussed in <xref target="deployment-considerations"/> and <xref target="privac y"/>, respectively.</li>		discussed in Sections&nbsp;<xref target="deployment-considerations" format="coun ter"/> and <xref target="privacy" format="counter"/>, respectively.</li>
	<li>Adhere to the guidelines specified in <xref target="issuer-role" /> for managing Issuer		<li>Adhere to the guidelines specified in <xref target="issuer-role" /> for managing Issuer
	public key data.</li>		Public Key data.</li>
	<li>Clearly specify how to interpret and validate TokenChallenge and		<li>Clearly specify how to interpret and validate TokenChallenge and
	Token		token
	messages that are exchanged during the redemption protocol.</li>		messages that are exchanged during the redemption protocol.</li>
	</ol>		</ol>
	</section>		</section>
	</section>		</section>
	<section anchor="flow">		<section anchor="flow">
	<name>Information Flow</name>		<name>Information Flow</name>
	<t>The end-to-end process of redemption and issuance protocols involves information		<t>The end-to-end process of redemption and issuance protocols involves information
	flowing between Issuer, Origin, Client, and Attester. That information can		flowing between the Issuer, Origin, Client, and Attester. That information can
	have implications on the privacy goals that Privacy Pass aims to provide		have implications on the privacy goals that Privacy Pass aims to provide
	as outlined in <xref target="privacy-and-trust"/>. In this section, we describe the flow		as outlined in <xref target="privacy-and-trust"/>. In this section, we describe the flow
	of information between each party. How this information affects the privacy		of information between each party. How this information affects the privacy
	goals in particular deployment models is further discussed in <xref target="depl oyment"/>.</t>		goals in particular deployment models is further discussed in <xref target="depl oyment"/>.</t>
	<section anchor="challenge-flow">		<section anchor="challenge-flow">
	<name>Token Challenge Flow</name>		<name>Token Challenge Flow</name>
	<t>To use Privacy Pass, Origins choose an Issuer from which they are w illing to		<t>To use Privacy Pass, Origins choose an Issuer from which they are w illing to
	accept tokens. Origins then construct a token challenge using this specified		accept tokens. Origins then construct a token challenge using this specified
	Issuer and information from the redemption context it shares with the Client.		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		This token challenge is then delivered to a Client. The token challenge conveys
	skipping to change at line 771 ¶		skipping to change at line 796 ¶
	presented with multiple issuance protocol options, then the choice of which		presented with multiple issuance protocol options, then the choice of which
	issuance protocol to use can contribute information about the Client's		issuance protocol to use can contribute information about the Client's
	capabilities.</li>		capabilities.</li>
	<li>Issuer configuration. Information about the Issuer configuration , such as		<li>Issuer configuration. Information about the Issuer configuration , such as
	its identity or the public key used to validate tokens it creates, can be		its identity or the public key used to validate tokens it creates, can be
	revealed during issuance and contribute to the attestation or issuance		revealed during issuance and contribute to the attestation or issuance
	contexts.</li>		contexts.</li>
	<li>Attestation information. The issuance protocol can contribute in formation to		<li>Attestation information. The issuance protocol can contribute in formation to
	the attestation or issuance contexts based on what attestation procedure the		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		Issuer uses to trust a token request. In particular, a token request that is
	validated by a given Attester means that the Client which generated the token		validated by a given Attester means that the Client that generated the token
	request must be capable of the completing the designated attestation procedure.<		request must be capable of completing the designated attestation procedure.</li>
	/li>
	<li>Origin information. The issuance protocol can contribute informa tion about		<li>Origin information. The issuance protocol can contribute informa tion about
	the Origin that challenged the Client in <xref target="challenge-flow"/>. In par ticular,		the Origin that challenged the Client; see <xref target="challenge-flow"/>. In p articular,
	a token request designated for a specific Issuer might imply that the resulting		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		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,		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		i.e., they are tokens that would be accepted at any Origin that accepts the
	cross-Origin token.</li>		cross-Origin token.</li>
	</ul>		</ul>
	<t>Moreover, a token may contribute information to the issuance attest ation or		<t>Moreover, a token may contribute information to the issuance attest ation or
	contexts as described below.</t>		contexts as described below.</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Origin information. The issuance protocol can contribute informa tion about		<li>Origin information. The issuance protocol can contribute informa tion about
	skipping to change at line 798 ¶		skipping to change at line 823 ¶
	transitively through the Attester, that response can reveal information to the		transitively through the Attester, that response can reveal information to the
	Attester.</li>		Attester.</li>
	<li>Token. The token produced by the issuance protocol can contain i nformation		<li>Token. The token produced by the issuance protocol can contain i nformation
	from the issuance context. In particular, depending on the issuance protocol,		from the issuance context. In particular, depending on the issuance protocol,
	tokens can contain public or private metadata, and Issuers can choose that		tokens can contain public or private metadata, and Issuers can choose that
	metadata on the basis of information in the issuance context.</li>		metadata on the basis of information in the issuance context.</li>
	</ul>		</ul>
	<t>Exceptional cases in the issuance protocol, such as when either the		<t>Exceptional cases in the issuance protocol, such as when either the
	Attester or Issuer aborts the protocol, can contribute information to the		Attester or Issuer aborts the protocol, can contribute information to the
	attestation or issuance contexts. The extent to which information in this		attestation or issuance contexts. The extent to which information in this
	context harms the Issuer-Client or Attester-Origin unlinkability goals in		context harms the Issuer-Client or Attester-Origin unlinkability goals as discus
	<xref target="privacy-and-trust"/> depends on deployment model; see <xref target		sed in
	="deployment"/>.		<xref target="privacy-and-trust"/> depends on the deployment model; see <xref ta
			rget="deployment"/>.
	Clients can choose whether or not to contribute information to these contexts		Clients can choose whether or not to contribute information to these contexts
	based on local policy or preference.</t>		based on local policy or preference.</t>
	</section>		</section>
	<section anchor="redemption-flow">		<section anchor="redemption-flow">
	<name>Token Redemption Flow</name>		<name>Token Redemption Flow</name>
	<t>Clients send tokens to Origins during the redemption protocol. Any information		<t>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.		that is added to the token during issuance can therefore be sent to the Origin.
	Information can either be explicitly passed in a token, or it can be implicit		Information can be either (1)&nbsp;explicitly passed in a token or (2)&nbsp;impl icit
	in the way the Client responds to a token challenge. For example, if a Client		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		fails to complete issuance and consequently fails to redeem a token for
	a token challenge, this can reveal information to the Origin that		a token challenge, this can reveal information to the Origin that
	it might not otherwise have access to. However, an Origin cannot necessarily		it might not otherwise have access to. However, an Origin cannot necessarily
	distinguish between a Client that fails to complete issuance and one that		distinguish between a Client that fails to complete issuance and one that
	ignores the token challenge altogether.</t>		ignores the token challenge altogether.</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="deployment">		<section anchor="deployment">
	<name>Deployment Models</name>		<name>Deployment Models</name>
	<t>The Origin, Attester, and Issuer portrayed in <xref target="fig-overvie w"/> can be		<t>The Origin, Attester, and Issuer portrayed in <xref target="fig-overvie w"/> can be
	instantiated and deployed in a number of ways. The deployment model directly		instantiated and deployed in a number of ways. The deployment model directly
	influences the manner in which attestation, issuance, and redemption contexts		influences the manner in which attestation, issuance, and redemption contexts
	are separated to achieve Origin-Client, Issuer-Client, and Attester-Origin		are separated to achieve Origin-Client, Issuer-Client, and Attester-Origin
	unlinkability.</t>		unlinkability.</t>
	<t>This section covers some expected deployment models and their correspon ding		<t>This section covers some expected deployment models and their correspon ding
	security and privacy considerations. Each deployment model is described in		security and privacy considerations. Each deployment model is described in
	terms of the trust relationships and communication patterns between Client,		terms of the trust relationships and communication patterns between the Client,
	Attester, Issuer, and Origin. Entities drawn within the same bounding box are		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.		assumed to be operated by the same party and are therefore able to collude.
	Collusion can enable linking of attestation, issuance, and redemption contexts.		Collusion can enable linking of attestation, issuance, and redemption contexts.
	Entities not drawn within the same bounding box are assumed to not		Entities not drawn within the same bounding box (i.e., operated by separate part
	collude, meaning that entities operated by separate parties that do not collude.		ies) are assumed to not collude. Mechanisms for enforcing non-collusion are out
	Mechanisms for enforcing non-collusion are out of scope for this architecture.</		of scope for this architecture.</t>
	t>
	<section anchor="deploy-shared">		<section anchor="deploy-shared">
	<name>Shared Origin, Attester, Issuer</name>		<name>Shared Origin, Attester, Issuer</name>
	<t>In this model, the Origin, Attester, and Issuer are all operated by t he same		<t>In this model, the Origin, Attester, and Issuer are all operated by t he same
	entity, as shown in <xref target="fig-deploy-shared"/>.</t>		entity, as shown in <xref target="fig-deploy-shared"/>.</t>
	<figure anchor="fig-deploy-shared">		<figure anchor="fig-deploy-shared">
	<name>Shared Deployment Model</name>		<name>Shared Deployment Model</name>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="256" width="528" viewBox="0 0 528 256" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" viewBox="0 0 528 256" class="diagram" text-anchor="middle" font-family="mo nospace" font-size="13px" stroke-linecap="round">
	<path d="M 8,48 L 8,80" fill="none" stroke="black"/>		<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 40,80 L 40,240" fill="none" stroke="black"/>
	<path d="M 80,48 L 80,80" 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 144,32 L 144,80" fill="none" stroke="black"/>
	<path d="M 168,48 L 168,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,80 L 216,104" fill="none" stroke="black"/>
	<path d="M 216,120 L 216,160" 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 256,48 L 256,80" fill="none" stroke="black"/>
	<path d="M 304,48 L 304,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,80 L 344,96" fill="none" stroke="black"/>
	skipping to change at line 932 ¶		skipping to change at line 956 ¶
	</figure>		</figure>
	<t>This model represents the initial deployment of Privacy Pass, as desc ribed in		<t>This model represents the initial deployment of Privacy Pass, as desc ribed in
	<xref target="PrivacyPassCloudflare"/>. In this model, the Attester, Issuer, and Origin		<xref target="PrivacyPassCloudflare"/>. In this model, the Attester, Issuer, and Origin
	share the attestation, issuance, and redemption contexts. As a result,		share the attestation, issuance, and redemption contexts. As a result,
	attestation mechanisms that can uniquely identify a Client, e.g., requiring		attestation mechanisms that can uniquely identify a Client, e.g., requiring
	that Clients authenticate with some type of application-layer account, are		that Clients authenticate with some type of application-layer account, are
	not appropriate, as they could lead to unlinkability violations.</t>		not appropriate, as they could lead to unlinkability violations.</t>
	<t>Origin-Client, Issuer-Client, and Attester-Origin unlinkability requi res that		<t>Origin-Client, Issuer-Client, and Attester-Origin unlinkability requi res that
	issuance and redemption events be separated over time, such as through the use		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		of tokens that correspond to token challenges with an empty redemption context
	(see <xref target="redemption"/>), or be separated over space, such as through t he use of an		(see <xref target="redemption"/>), or that they be separated over space, such as through the use of an
	anonymizing service when connecting to the Origin.</t>		anonymizing service when connecting to the Origin.</t>
	</section>		</section>
	<section anchor="deploy-joint-issuer">		<section anchor="deploy-joint-issuer">
	<name>Joint Attester and Issuer</name>		<name>Joint Attester and Issuer</name>
	<t>In this model, the Attester and Issuer are operated by the same entit		<t>In this model, the Attester and Issuer are operated by the same entit
	y		y,
	that is separate from the Origin. The Origin trusts the joint Attester		separate from the Origin. The Origin trusts the joint Attester
	and Issuer to perform attestation and issue Tokens. Clients interact		and Issuer to perform attestation and issue tokens. Clients interact
	with the joint Attester and Issuer for attestation and issuance. This		with the joint Attester and Issuer for attestation and issuance. This
	arrangement is shown in <xref target="fig-deploy-joint-issuer"/>.</t>		arrangement is shown in <xref target="fig-deploy-joint-issuer"/>.</t>
	<figure anchor="fig-deploy-joint-issuer">		<figure anchor="fig-deploy-joint-issuer">
	<name>Joint Attester and Issuer Deployment Model</name>		<name>Joint Attester and Issuer Deployment Model</name>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="256" width="520" viewBox="0 0 520 256" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" viewBox="0 0 520 256" class="diagram" text-anchor="middle" font-family="mo nospace" font-size="13px" stroke-linecap="round">
	<path d="M 8,48 L 8,80" fill="none" stroke="black"/>		<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 40,80 L 40,240" fill="none" stroke="black"/>
	<path d="M 80,48 L 80,80" 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 160,32 L 160,80" fill="none" stroke="black"/>
	<path d="M 184,48 L 184,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,80 L 232,104" fill="none" stroke="black"/>
	<path d="M 232,120 L 232,160" 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 272,48 L 272,80" fill="none" stroke="black"/>
	<path d="M 320,48 L 320,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,80 L 360,96" fill="none" stroke="black"/>
	skipping to change at line 1029 ¶		skipping to change at line 1054 ¶
	+------------- TokenRequest ----------->| |		+------------- TokenRequest ----------->| |
	|<----------- TokenResponse ------------+ |		|<----------- TokenResponse ------------+ |
	| |		| |
	+----------------------- Token ----------------------->		+----------------------- Token ----------------------->
	| |		| |
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t>This model is useful if an Origin wants to offload attestation and is suance to		<t>This model is useful if an Origin wants to offload attestation and is suance to
	a trusted entity. In this model, the Attester and Issuer share an attestation		a trusted entity. In this model, the Attester and Issuer share an attestation
	and issuance context for the Client, which is separate from the Origin's		and issuance context for the Client, separate from the Origin's
	redemption context.</t>		redemption context.</t>
	<t>Similar to the Shared Origin, Attester, Issuer model, Issuer-Client a		<t>Similar to the shared Origin, Attester, Issuer model, Issuer-Client a
	nd		nd
	Origin-Client unlinkability in this model requires issuance and redemption		Origin-Client unlinkability in this model requires that issuance and redemption
	events, respectively, be separated over time or space. Attester-Origin		events, respectively, be separated over time or space. Attester-Origin
	unlinkability requires that the Attester and Issuer do not learn the Origin		unlinkability requires that the Attester and Issuer do not learn the Origin
	for a particular token request. For this reason, issuance protocols that		for a particular token request. For this reason, issuance protocols that
	require the Issuer to learn information about the Origin, such as that which		require the Issuer to learn information about the Origin, such as the issuance p
	is described in <xref target="RATE-LIMITED"/>, are not		rotocol described in <xref target="I-D.ietf-privacypass-rate-limit-tokens"/>, ar
	appropriate since they could lead to Attester-Origin unlinkability violations		e not
			appropriate, since they could lead to Attester-Origin unlinkability violations
	through the Origin name.</t>		through the Origin name.</t>
	</section>		</section>
	<section anchor="deploy-joint-origin">		<section anchor="deploy-joint-origin">
	<name>Joint Origin and Issuer</name>		<name>Joint Origin and Issuer</name>
	<t>In this model, the Origin and Issuer are operated by the same entity, separate		<t>In this model, the Origin and Issuer are operated by the same entity, separate
	from the Attester, as shown in the figure below. The Issuer accepts token		from the Attester, as shown in <xref target="fig-deploy-joint-origin"/>. The Iss uer accepts token
	requests that come from trusted Attesters. Since the Attester and Issuer are		requests that come from trusted Attesters. Since the Attester and Issuer are
	separate entities, this model requires some mechanism by which Issuers		separate entities, this model requires some mechanism by which Issuers
	establish trust in the Attester (as described in <xref target="privacy-and-trust "/>).		establish trust in the Attester (as described in <xref target="privacy-and-trust "/>).
	For example, in settings where the Attester is a Client-trusted service that		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		directly communicates with the Issuer, one way to establish this trust is via
	mutually-authenticated TLS. However, alternative authentication mechanisms are		mutually authenticated TLS. However, alternative authentication mechanisms are
	possible. This arrangement is shown in <xref target="fig-deploy-joint-origin"/>.		possible. In this model, the Origin and Issuer are operated by the same entity,
	</t>		separate from the Attester, as shown in the figure below.</t>
	<figure anchor="fig-deploy-joint-origin">		<figure anchor="fig-deploy-joint-origin">
	<name>Joint Origin and Issuer Deployment Model</name>		<name>Joint Origin and Issuer Deployment Model</name>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="256" width="528" viewBox="0 0 528 256" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" viewBox="0 0 528 256" class="diagram" text-anchor="middle" font-family="mo nospace" font-size="13px" stroke-linecap="round">
	<path d="M 8,48 L 8,80" fill="none" stroke="black"/>		<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 40,80 L 40,240" fill="none" stroke="black"/>
	<path d="M 80,48 L 80,80" 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 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,80 L 216,104" fill="none" stroke="black"/>
	<path d="M 216,120 L 216,160" 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 256,48 L 256,80" fill="none" stroke="black"/>
	<path d="M 280,32 L 280,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 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,80 L 344,96" fill="none" stroke="black"/>
	skipping to change at line 1141 ¶		skipping to change at line 1166 ¶
	| |		| |
	+--------------------- Token ----------------------->		+--------------------- Token ----------------------->
	| |		| |
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t>This model is useful for Origins that require Client-identifying atte station,		<t>This model is useful for Origins that require Client-identifying atte station,
	e.g., through the use of application-layer account information, but do not		e.g., through the use of application-layer account information, but do not
	otherwise want to learn information about individual Clients beyond what is		otherwise want to learn information about individual Clients beyond what is
	observed during the token redemption, such as Client IP addresses.</t>		observed during the token redemption, such as Client IP addresses.</t>
	<t>In this model, attestation contexts are separate from issuer and rede mption		<t>In this model, attestation contexts are separate from Issuer and rede mption
	contexts. As a result, any type of attestation is suitable in this model.</t>		contexts. As a result, any type of attestation is suitable in this model.</t>
	<t>Moreover, any type of token challenge is suitable assuming there is m		<t>Moreover, assuming that there is more than one Origin involved, any t
	ore than		ype of token challenge is suitable, since no single party will have access to th
	one Origin involved, since no single party will have access to the identifying		e identifying
	Client information and unique Origin information. Issuers that produce tokens		Client information and unique Origin information. Issuers that produce tokens
	for a single Origin are not suitable in this model since an Attester can		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" />. However,		infer the Origin from a token request, as described in <xref target="issue-flow" />. However,
	since the issuance protocol provides input secrecy, the Attester does not learn		since the issuance protocol provides input secrecy, the Attester does not learn
	details about the corresponding token challenge, such as whether the token		details about the corresponding token challenge, such as whether the token
	challenge is per-Origin or cross-Origin.</t>		challenge is per Origin or across Origins.</t>
	</section>		</section>
	<section anchor="deploy-split">		<section anchor="deploy-split">
	<name>Split Origin, Attester, Issuer</name>		<name>Split Origin, Attester, Issuer</name>
	<t>In this model, the Origin, Attester, and Issuer are all operated by d ifferent		<t>In this model, the Origin, Attester, and Issuer are all operated by d ifferent
	entities. As with the joint Origin and Issuer model, the Issuer accepts token		entities. As with the Joint Origin and Issuer model (<xref
			target="deploy-joint-origin"/>), the Issuer accepts token
	requests that come from trusted Attesters, and the details of that trust		requests that come from trusted Attesters, and the details of that trust
	establishment depend on the issuance protocol and relationship between		establishment depend on the issuance protocol and relationship between the
	Attester and Issuer; see <xref target="privacy-and-trust"/>. This arrangement is shown		Attester and Issuer; see <xref target="privacy-and-trust"/>. This arrangement is shown
	in <xref target="fig-overview"/>.</t>		in <xref target="fig-overview"/>.</t>
	<t>This is the most general deployment model, and is necessary for some		<t>This is the most general deployment model and is necessary for some
	types of issuance protocols where the Attester plays a role in token		types of issuance protocols where the Attester plays a role in token
	issuance; see <xref target="RATE-LIMITED"/> for one such type of issuance protoc ol.</t>		issuance; see <xref target="I-D.ietf-privacypass-rate-limit-tokens"/> for one su ch type of issuance protocol.</t>
	<t>In this model, the Attester, Issuer, and Origin have a separate view		<t>In this model, the Attester, Issuer, and Origin have a separate view
	of the Client: the Attester sees potentially sensitive Client identifying		of the Client: the Attester sees potentially sensitive Client-identifying
	information, such as account identifiers or IP addresses, the Issuer		information, such as account identifiers or IP addresses; the Issuer
	sees only the information necessary for issuance, and the Origin sees		sees only the information necessary for issuance; and the Origin sees
	token challenges, corresponding tokens, and Client source information,		token challenges, corresponding tokens, and Client source information,
	such as their IP address. As a result, attestation, issuance, and redemption		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		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>		this model as long as there is more than a single Origin.</t>
	<t>As in the Joint Origin and Issuer model in <xref target="deploy-joint -origin"/>, and as		<t>As with the Joint Origin and Issuer model (<xref target="deploy-joint -origin"/>), and as
	described in <xref target="issue-flow"/>, if the Issuer produces tokens for a si ngle Origin,		described in <xref target="issue-flow"/>, if the Issuer produces tokens for a si ngle Origin,
	then per-Origin tokens are not appropriate since the Attester can infer the		then per-Origin tokens are not appropriate, since the Attester can infer the
	Origin from a token request.</t>		Origin from a token request.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="deployment-considerations">		<section anchor="deployment-considerations">
	<name>Deployment Considerations</name>		<name>Deployment Considerations</name>
	<t><xref target="deployment"/> discusses deployment models that are possib le in practice.		<t><xref target="deployment"/> discusses deployment models that are possib le in practice.
	Beyond possible implications on security and privacy properties of the		Beyond possible implications on security and privacy properties of the
	resulting system, Privacy Pass deployments can impact the overall ecosystem		resulting system, Privacy Pass deployments can impact the overall ecosystem
	in two important ways: (1) discriminatory treatment of Clients and the gated		in two important ways: (1)&nbsp;discriminatory treatment of Clients and the gate
	access to otherwise open services, and (2) centralization. This section		d
			access to otherwise open services and (2)&nbsp;centralization. This section
	describes considerations relevant to these topics.</t>		describes considerations relevant to these topics.</t>
	<section anchor="discrimination">		<section anchor="discrimination">
	<name>Discriminatory Treatment</name>		<name>Discriminatory Treatment</name>
	<t>Origins can use tokens as a signal for distinguishing between Clients		<t>Origins can use tokens as a signal for distinguishing between (1)&nbs p;Clients
	that are capable of completing attestation with one Attester trusted by the		that are capable of completing attestation with one Attester trusted by the
	Origin's chosen Issuer, and Clients that are not capable of doing the same. A		Origin's chosen Issuer and (2)&nbsp;Clients that are not capable of doing the sa me. A
	consequence of this is that Privacy Pass could enable discriminatory treatment		consequence of this is that Privacy Pass could enable discriminatory treatment
	of Clients based on Attestation support. For example, an Origin could only		of Clients based on attestation support. For example, an Origin could only
	authorize Clients that successfully authenticate with a token, prohibiting acces s		authorize Clients that successfully authenticate with a token, prohibiting acces s
	to all other Clients.</t>		to all other Clients.</t>
	<t>The type of attestation procedures supported for a particular deploym ent depends		<t>The types of attestation procedures supported for a particular deploy ment depend
	greatly on the use case. For example, consider a proprietary deployment of Priva cy Pass		greatly on the use case. For example, consider a proprietary deployment of Priva cy Pass
	that authorizes clients to access a resource such as an anonymization service. I n this		that authorizes Clients to access a resource such as an anonymization service. I n this
	context, it is reasonable to support specific types of attestation procedures th at		context, it is reasonable to support specific types of attestation procedures th at
	demonstrate Clients can access the resource, such as with an account or specific		demonstrate that Clients can access the resource, such as with an account or spe cific
	type of device. However, in open deployments of Privacy Pass that are used to		type of device. However, in open deployments of Privacy Pass that are used to
	safeguard access to otherwise open or publicly accessible resources, diversity		safeguard access to otherwise open or publicly accessible resources, diversity
	in attestation procedures is critically important so as to not discriminate agai nst		in attestation procedures is critically important so as to not discriminate agai nst
	Clients that choose certain software, hardware, or identity providers.</t>		Clients that choose certain software, hardware, or identity providers.</t>
	<t>In principle, Issuers should strive to mitigate discriminatory behavi or by		<t>In principle, Issuers should strive to mitigate discriminatory behavi or by
	providing equitable access to all Clients. This can be done by working with a		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 requir e		set of Attesters that are suitable for all Clients. In practice, this may requir e
	tradeoffs in what type of attestation Issuers are willing to trust so as to		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		enable more widespread support. In other words, trusting a variety of Attesters
	with a diverse set of attestation procedures would presumably increase support		with a diverse set of attestation procedures would presumably increase support
	among Clients, though most likely at the expense of decreasing the overall value		among Clients, though most likely at the expense of decreasing the overall value
	of tokens issued by the Issuer.</t>		of tokens issued by the Issuer.</t>
	<t>For example, to disallow discriminatory behavior between Clients with and		<t>For example, to disallow discriminatory behavior between Clients with and
	without device attestation support, an Issuer may wish to support Attesters		without device attestation support, an Issuer may wish to support Attesters
	that support CAPTCHA-based attestation. This means that the overall attestation		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		value of a Privacy Pass token is bound by the difficulty in spoofing or
	bypassing either one of these attestation procedures.</t>		bypassing either one of these attestation procedures.</t>
	</section>		</section>
	<section anchor="centralization">		<section anchor="centralization">
	<name>Centralization</name>		<name>Centralization</name>
	<t>A consequence of limiting the number of participants (Attesters or Is suers) in		<t>A consequence of limiting the number of participants (Attesters or Is suers) in
	Privacy Pass deployments for meaningful privacy is that it forces concentrated		Privacy Pass deployments for meaningful privacy is that it forces concentrated
	centralization amongst those participants.		centralization among those participants.
	<xref target="CENTRALIZATION"/> discusses		<xref target="RFC9518"/> discusses
	several ways in which this might be mitigated. For example, a multi-stakeholder		several ways in which this might be mitigated. For example, a multi-stakeholder
	governance model could be established to determine what candidate participants		governance model could be established to determine what candidate participants
	are fit to operate as participants in a Privacy Pass deployment. This is		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>		precisely the system used to control the Web's trust model.</t>
	<t>Alternatively, Privacy Pass deployments might mitigate this problem t hrough		<t>Alternatively, Privacy Pass deployments might mitigate this problem t hrough
	implementation. For example, rather than centralize the role of attestation		implementation. For example, rather than centralize the role of attestation
	in one or few entities, attestation could be a distributed function performed		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		by a quorum of many parties, provided that neither Issuers nor Origins learn
	which Attester implementations were chosen. As a result, Clients could have		which Attester implementations were chosen. As a result, Clients could have
	more opportunities to switch between attestation participants.</t>		more opportunities to switch between attestation participants.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="privacy">		<section anchor="privacy">
	<name>Privacy Considerations</name>		<name>Privacy Considerations</name>
	<t>The previous section discusses the impact of deployment details on		<t>The previous section discusses the impact of deployment details on
	Origin-Client, Issuer-Client, and Attester-Origin unlinkability.		Origin-Client, Issuer-Client, and Attester-Origin unlinkability.
	The value these properties affords to end users depends on		The value these properties afford to end users depends on
	the size of anonymity sets in which Clients or Origins are		the size of anonymity sets in which Clients or Origins are
	unlinkable. For example, consider two different deployments, one wherein		unlinkable. For example, consider two different deployments, one wherein
	there exists a redemption anonymity set of size two and another		there exists a redemption anonymity set of size two and another
	wherein there redemption anonymity set of size 2<sup>32</sup>. Although		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		Origin-Client unlinkability guarantees that the Origin cannot link any two
	requests to the same Client based on these contexts, respectively, the		requests to the same Client based on these contexts, respectively, the
	probability of determining the "true" Client is higher the smaller these		smaller these sets become, the higher the probability of determining the "true"
	sets become.</t>		Client.</t>
	<t>In practice, there are a number of ways in which the size of anonymity sets		<t>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		may be reduced or partitioned, though they all center around the concept of
	consistency. In particular, by definition, all Clients in an anonymity set		consistency. In particular, by definition, all Clients in an anonymity set
	share a consistent view of information needed to run the issuance and		share a consistent view of information needed to run the issuance and
	redemption protocols. An example type of information needed to run these		redemption protocols. The Issuer Public Key is an example of the type of informa
	protocols is the Issuer public key. When two Clients have inconsistent		tion needed to run these protocols. When two Clients have inconsistent
	information, these Clients effectively have different redemption contexts and		information, these Clients effectively have different redemption contexts and
	therefore belong in different anonymity sets.</t>		therefore belong in different anonymity sets.</t>
	<t>The following sections discuss issues that can influence anonymity set size.		<t>The following subsections discuss issues that can influence anonymity s et size.
	For each issue, we discuss mitigations or safeguards to protect against the		For each issue, we discuss mitigations or safeguards to protect against the
	underlying problem.</t>		underlying problem.</t>
	<section anchor="metadata-privacy">		<section anchor="metadata-privacy">
	<name>Partitioning by Issuance Metadata</name>		<name>Partitioning by Issuance Metadata</name>
	<t>Any public or private metadata bits of information can be used to fur ther		<t>Any public or private metadata bits of information can be used to fur ther
	segment the size of the Client's anonymity set. Any Issuer that wanted to		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		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		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		additional bits provides an exponential increase in tracking granularity
	similarly to introducing more Issuers (though with more potential targeting).</t >		in a manner similar to introducing more Issuers (though with more potential targ eting).</t>
	<t>For this reason, deployments should take the amount of metadata used by an Issuer		<t>For this reason, deployments should take the amount of metadata used by an Issuer
	in creating redemption tokens must into account -- together with the bits		in creating tokens, together with the bits of information that Issuers may learn
	of information that Issuers may learn about Clients otherwise. Since this		about Clients through other means, into account. Since this
	metadata may be useful for practical deployments of Privacy Pass, Issuers		metadata may be useful for practical deployments of Privacy Pass, Issuers
	must balance this against the reduction in Client privacy.</t>		must balance this against the reduction in Client privacy.</t>
	<t>The number of permitted metadata values often depends on deployment-s pecific		<t>The number of permitted metadata values often depends on deployment-s pecific
	details. In general, limiting the amount of metadata permitted helps limit the		details. In general, limiting the amount of metadata permitted helps limit the
	extent to which metadata can uniquely identify individual Clients. Failure to		extent to which metadata can uniquely identify individual Clients. Failure to
	bound the number of possible metadata values can therefore lead to reduction in		bound the number of possible metadata values can therefore lead to a reduction i n
	Client privacy. Most token types do not admit any metadata, so this bound is		Client privacy. Most token types do not admit any metadata, so this bound is
	implicitly enforced.</t>		implicitly enforced.</t>
	</section>		</section>
	<section anchor="rotation-and-consistency">		<section anchor="rotation-and-consistency">
	<name>Partitioning by Issuance Consistency</name>		<name>Partitioning by Issuance Consistency</name>
	<t>Anonymity sets can be partitioned by information used for the issuanc e		<t>Anonymity sets can be partitioned by information used for the issuanc e
	protocol, including: metadata, Issuer configuration (keys), and Issuer		protocol, including metadata, Issuer configuration (keys), and Issuer
	selection.</t>		selection.</t>
	<t>Any issuance metadata bits of information can be used to partition th e Client		<t>Any issuance metadata bits of information can be used to partition th e Client
	anonymity set. For example, any Issuer that wanted to track a single 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		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 bit s provides an		would set the bit to <tt>1</tt>, and <tt>0</tt> otherwise. Adding additional bit s provides an
	exponential increase in tracking granularity similarly to introducing more		exponential increase in tracking granularity in a manner similar to introducing more
	Issuers (though with more potential targeting).</t>		Issuers (though with more potential targeting).</t>
	<t>The number of active Issuer configurations also contributes to anonym ity set		<t>The number of active Issuer configurations also contributes to anonym ity set
	partitioning. In particular, when an Issuer updates their configuration and		partitioning. In particular, when an Issuer updates their configuration and
	the corresponding key pair, any Client that invokes the issuance protocol with		the corresponding key pair, any Client that invokes the issuance protocol with
	this configuration becomes part of a set of Clients which also ran the		this configuration becomes part of a set of Clients that also ran the
	issuance protocol using the same configuration. Issuer configuration updates,		issuance protocol using the same configuration. Issuer configuration updates,
	e.g., due to key rotation, are an important part of hedging against long-term		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		private key compromise. In general, key rotations represent a trade-off between
	Client privacy and Issuer security. Therefore, it is important that key		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		rotations occur on a regular cycle to reduce the harm of an Issuer key
	compromise.</t>		compromise.</t>
	<t>Lastly, if Clients are willing to issue and redeem tokens from a larg e number		<t>Lastly, if Clients are willing to issue and redeem tokens from a larg e number
	of Issuers for a specific Origin, and that Origin accepts tokens from all		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		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		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		Issuer, the Origin can learn information about the Client. This arrangement
	might happen if Clients request tokens from different Issuers, each of which		might happen if Clients request tokens from different Issuers, each of which
	have different Attester preferences. Each per-Issuer token that a Client holds		has different Attester preferences. Each per-Issuer token that a Client holds
	essentially corresponds to a bit of information about the Client that Origin		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		learns. Therefore, there is an exponential loss in privacy relative to the
	number of Issuers.</t>		number of Issuers.</t>
	<t>The fundamental problem here is that the number of possible issuance		<t>The fundamental problem here is that the number of possible issuance
	configurations, including the keys in use and the Issuer identities themselves,		configurations, including the keys in use and the Issuer identities themselves,
	can partition the Client anonymity set. To mitigate this problem, Clients		can partition the Client anonymity set. To mitigate this problem, Clients
	SHOULD bound the number of active issuance configurations per Origin as well as		<bcp14>SHOULD</bcp14> bound the number of active issuance configurations per Ori
	across Origins. Moreover, Clients SHOULD employ some form of consistency		gin as well as
			across Origins. Moreover, Clients <bcp14>SHOULD</bcp14> employ some form of cons
			istency
	mechanism to ensure that they receive the same configuration information and		mechanism to ensure that they receive the same configuration information and
	are not being actively partitioned into smaller anonymity sets. See		are not being actively partitioned into smaller anonymity sets. See
	<xref target="CONSISTENCY"/> for possible consistency		<xref target="I-D.ietf-privacypass-key-consistency"/> for possible consistency
	mechanisms. Depending on the deployment, the Attester might assist the Client		mechanisms. Depending on the deployment, the Attester might assist the Client
	in applying these consistency checks across clients. Failure to apply a		in applying these consistency checks across Clients. Failure to apply a
	consistency check can allow Client-specific keys to violate Origin-Client		consistency check can allow Client-specific keys to violate Origin-Client
	unlinkability.</t>		unlinkability.</t>
	</section>		</section>
	<section anchor="partitioning-by-side-channels">		<section anchor="partitioning-by-side-channels">
	<name>Partitioning by Side-Channels</name>		<name>Partitioning by Side Channels</name>
	<t>Side-channel attacks, such as those based on timing correlation, coul d be		<t>Side-channel attacks, such as those based on timing correlation, coul d be
	used to reduce anonymity set size. In particular,		used to reduce anonymity set size. In particular,
	for interactive tokens that are bound to a Client-specific redemption		for interactive tokens that are bound to a Client-specific redemption
	context, the anonymity set of Clients during the issuance protocol consists		context, the anonymity set of Clients during the issuance protocol consists
	of those Clients that started issuance between the time of the Origin's		of those Clients that started issuance between the time of the Origin's
	challenge and the corresponding token redemption. Depending on the number		challenge and the corresponding token redemption. Depending on the number
	of Clients using a particular Issuer during that time window, the set can		of Clients using a particular Issuer during that time window, the set can
	be small. Applications should take such side channels into consideration before		be small. Applications should take such side channels into consideration before
	choosing a particular deployment model and type of token challenge and		choosing a particular deployment model and type of token challenge and
	redemption context.</t>		redemption context.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="security">		<section anchor="security">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>This document describes security and privacy requirements for the Priva cy Pass		<t>This document describes security and privacy requirements for the Priva cy Pass
	redemption and issuance protocols. It also describes deployment models built		redemption and issuance protocols. It also describes deployment models built
	around non-collusion assumptions and privacy considerations for using Privacy		around non-collusion assumptions and privacy considerations for using Privacy
	Pass within those models. Ensuring Client privacy -- separation of attestation		Pass within those models. Ensuring Client privacy -- separation of attestation
	and redemption contexts -- requires active work on behalf of the Client,		and redemption contexts -- requires active work on behalf of the Client,
	especially in the presence of malicious Issuers and Origins. Implementing		especially in the presence of malicious Issuers and Origins. Implementing the
	mitigations discussed in <xref target="deployment"/> and <xref target="privacy"/		mitigations discussed in Sections&nbsp;<xref target="deployment" format="counter
	> is therefore necessary		"/> and <xref target="privacy" format="counter"/> is therefore necessary
	to ensure that Privacy Pass offers meaningful privacy improvements to end-users.		to ensure that Privacy Pass offers meaningful privacy improvements to end users.
	</t>		</t>
	<section anchor="hoarding">		<section anchor="hoarding">
	<name>Token Caching</name>		<name>Token Caching</name>
	<t>Depending on the Origin's token challenge, Clients can request and ca che more		<t>Depending on the Origin's token challenge, Clients can request and ca che more
	than one token using an issuance protocol. Cached tokens help improve privacy by		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, and		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		also allow Clients to reduce the overhead of receiving new tokens via the
	issuance protocol.</t>		issuance protocol.</t>
	<t>As a consequence, Origins that send token challenges which are compat ible with		<t>As a consequence, Origins that send token challenges that are compati ble with
	cached tokens need to take precautions to ensure that tokens are not replayed.		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		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		period of time in which cached tokens would be accepted for particular
	challenges.</t>		challenges.</t>
	<t>Moreover, since tokens are not intrinsically bound to Clients, it is possible		<t>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		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		attack". As an example of this attack, many distributed Clients could obtain
	cacheable tokens and then share them with a single Client to redeem in a way		cacheable tokens and then share them with a single Client to redeem the tokens i
			n a way
	that would violate an Origin's attempt to limit tokens to any one particular		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		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 ,		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,		comparing the issuance and redemption contexts can help detect hoarding attacks,
	i.e., if the distribution of redemption contexts is noticeably different from th e		i.e., if the distribution of redemption contexts is noticeably different from th e
	distribution of issuance contexts. Rate limiting issuance, either at the Client,		distribution of issuance contexts. Rate-limiting issuance, at either the Client,
	Attester, or Issuer, can also help mitigate these attacks.</t>		Attester, or Issuer, can also help mitigate these attacks.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="iana">		<section anchor="iana">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This document has no IANA actions.</t>		<t>This document has no IANA actions.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<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-L
			IMITED"/>
			<displayreference target="RFC9518" to="CENTRALIZATION"/>
			<displayreference target="I-D.ietf-privacypass-key-consistency" to="CONSISTE
			NCY"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="AUTHSCHEME">
	<front>
	<title>The Privacy Pass HTTP Authentication Scheme</title>
	<author fullname="Tommy Pauly" initials="T." surname="Pauly">
	<organization>Apple Inc.</organization>
	</author>
	<author fullname="Steven Valdez" initials="S." surname="Valdez">
	<organization>Google LLC</organization>
	</author>
	<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
	d">
	<organization>Cloudflare</organization>
	</author>
	<date day="12" month="September" year="2023"/>
	<abstract>
	<t> This document defines an HTTP authentication scheme for Priv
	acy Pass,
	a privacy-preserving authentication mechanism used for authorization.
	The authentication scheme in this document can be used by clients to
	redeem Privacy Pass tokens with an origin. It can also be used by
	origins to challenge clients to present Privacy Pass tokens.
	</t>		<!-- draft-ietf-privacypass-auth-scheme (RFC 9577) -->
	</abstract>		<reference anchor="RFC9577" target="https://www.rfc-editor.org/info/rfc9577">
	</front>		<front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-auth-s		<title>The Privacy Pass HTTP Authentication Scheme</title>
	cheme-13"/>		<author initials="T." surname="Pauly" fullname="Tommy Pauly">
	</reference>		<organization>Apple Inc.</organization>
	<reference anchor="RFC2119">		</author>
	<front>		<author initials="S." surname="Valdez" fullname="Steven Valdez">
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit		<organization>Google LLC</organization>
	le>		</author>
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>		<author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
	<date month="March" year="1997"/>		<organization>Cloudflare</organization>
	<abstract>		</author>
	<t>In many standards track documents several words are used to sig		<date month="June" year="2024"/>
	nify the requirements in the specification. These words are often capitalized. T		</front>
	his document defines these words as they should be interpreted in IETF documents		<seriesInfo name="RFC" value="9577"/>
	. This document specifies an Internet Best Current Practices for the Internet Co		<seriesInfo name="DOI" value="10.17487/RFC9577"/>
	mmunity, and requests discussion and suggestions for improvements.</t>		</reference>
	</abstract>
	</front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<seriesInfo name="BCP" value="14"/>		119.xml"/>
	<seriesInfo name="RFC" value="2119"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>		174.xml"/>
	</reference>
	<reference anchor="RFC8174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l 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>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="PrivacyPassExtension" target="https://github.com/priv
	acypass/challenge-bypass-extension">
	<front>
	<title>Privacy Pass Browser Extension</title>
	<author>
	<organization/>
	</author>
	<date>n.d.</date>
	</front>
	</reference>
	<reference anchor="PrivacyPassCloudflare" target="https://blog.cloudflar e.com/cloudflare-supports-privacy-pass/">		<reference anchor="PrivacyPassCloudflare" target="https://blog.cloudflar e.com/cloudflare-supports-privacy-pass/">
	<front>		<front>
	<title>Cloudflare Supports Privacy Pass</title>		<title>Cloudflare supports Privacy Pass</title>
	<author initials="N." surname="Sullivan">		<author initials="N." surname="Sullivan">
	<organization>Cloudflare</organization>		<organization>Cloudflare</organization>
	</author>		</author>
	<date>n.d.</date>		<date month="November" year="2017"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="DMS2004" target="https://svn.torproject.org/svn/proje cts/design-paper/tor-design.html">		<reference anchor="DMS2004" target="https://svn.torproject.org/svn/proje cts/design-paper/tor-design.html">
	<front>		<front>
	<title>Tor: The Second-Generation Onion Router</title>		<title>Tor: The Second-Generation Onion Router</title>
	<author initials="R." surname="Dingledine">		<author initials="R." surname="Dingledine">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="N." surname="Mathewson">		<author initials="N." surname="Mathewson">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="P." surname="Syverson">		<author initials="P." surname="Syverson">
	<organization/>		<organization/>
	</author>		</author>
	<date year="2004" month="August"/>		<date year="2004" month="May"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="HIJK21" target="https://research.fb.com/privatestats" >		<reference anchor="HIJK21" target="https://research.fb.com/privatestats" >
	<front>		<front>
	<title>PrivateStats: De-Identified Authenticated Logging at Scale</t itle>		<title>DIT: De-Identified Authenticated Telemetry at Scale</title>
	<author initials="S." surname="Huang">		<author initials="S." surname="Huang">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="S." surname="Iyengar">		<author initials="S." surname="Iyengar">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="S." surname="Jeyaraman">		<author initials="S." surname="Jeyaraman">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="S." surname="Kushwah">		<author initials="S." surname="Kushwah">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="C. K." surname="Lee">		<author initials="C-K." surname="Lee">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="Z." surname="Luo">		<author initials="Z." surname="Luo">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="P." surname="Mohassel">		<author initials="P." surname="Mohassel">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="A." surname="Raghunathan">		<author initials="A." surname="Raghunathan">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="S." surname="Shaikh">		<author initials="S." surname="Shaikh">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="Y. C." surname="Sung">		<author initials="Y-C." surname="Sung">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="A." surname="Zhang">		<author initials="A." surname="Zhang">
	<organization/>		<organization/>
	</author>		</author>
	<date year="2021" month="January"/>		<date year="2021" month="January"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="ISSUANCE">
	<front>
	<title>Privacy Pass Issuance Protocol</title>
	<author fullname="Sofia Celi" initials="S." surname="Celi">
	<organization>Brave Software</organization>
	</author>
	<author fullname="Alex Davidson" initials="A." surname="Davidson">
	<organization>Brave Software</organization>
	</author>
	<author fullname="Steven Valdez" initials="S." surname="Valdez">
	<organization>Google LLC</organization>
	</author>
	<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
	d">
	<organization>Cloudflare</organization>
	</author>
	<date day="14" month="September" year="2023"/>
	<abstract>
	<t> This document specifies two variants of the two-message issu
	ance
	protocol for Privacy Pass tokens: one that produces tokens that are
	privately verifiable using the issuance private key, and another that
	produces tokens that are publicly verifiable using the issuance
	public key.
	</t>		<!-- draft-ietf-privacypass-protocol (RFC 9578) -->
	</abstract>		<reference anchor="RFC9578" target="https://www.rfc-editor.org/info/rfc9578">
	</front>		<front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-protoc		<title>Privacy Pass Issuance Protocols</title>
	ol-14"/>		<author initials="S." surname="Celi" fullname="Sofia Celi">
	</reference>		<organization>Brave Software</organization>
	<reference anchor="RFC9334">		</author>
	<front>		<author initials="A." surname="Davidson" fullname="Alex Davidson">
	<title>Remote ATtestation procedureS (RATS) Architecture</title>		<organization>Brave Software</organization>
	<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>		</author>
	<author fullname="D. Thaler" initials="D." surname="Thaler"/>		<author initials="S." surname="Valdez" fullname="Steven Valdez">
	<author fullname="M. Richardson" initials="M." surname="Richardson"/		<organization>Google LLC</organization>
	>		</author>
	<author fullname="N. Smith" initials="N." surname="Smith"/>		<author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
	<author fullname="W. Pan" initials="W." surname="Pan"/>		<organization>Cloudflare</organization>
	<date month="January" year="2023"/>		</author>
	<abstract>		<date month="June" year="2024"/>
	<t>In network protocol exchanges, it is often useful for one end o		</front>
	f a communication to know whether the other end is in an intended operating stat		<seriesInfo name="RFC" value="9578"/>
	e. This document provides an architectural overview of the entities involved tha		<seriesInfo name="DOI" value="10.17487/RFC9578"/>
	t make such tests possible through the process of generating, conveying, and eva		</reference>
	luating evidentiary Claims. It provides a model that is neutral toward processor
	architectures, the content of Claims, and protocols.</t>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
	</abstract>		34.xml"/>
	</front>
	<seriesInfo name="RFC" value="9334"/>		<!-- draft-ietf-ohai-ohttp (RFC 9458; published) -->
	<seriesInfo name="DOI" value="10.17487/RFC9334"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.94
	</reference>		58.xml"/>
	<reference anchor="OHTTP">
	<front>
	<title>Oblivious HTTP</title>
	<author fullname="Martin Thomson" initials="M." surname="Thomson">
	<organization>Mozilla</organization>
	</author>
	<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
	d">
	<organization>Cloudflare</organization>
	</author>
	<date day="25" month="August" year="2023"/>
	<abstract>
	<t> This document describes Oblivious HTTP, a protocol for forwa
	rding
	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="Internet-Draft" value="draft-ietf-ohai-ohttp-10"/>
	</reference>
	<reference anchor="KLOR20" target="https://doi.org/10.1007/978-3-030-567 84-2_11">		<reference anchor="KLOR20" target="https://doi.org/10.1007/978-3-030-567 84-2_11">
	<front>		<front>
	<title>Anonymous Tokens with Private Metadata Bit</title>		<title>Anonymous Tokens with Private Metadata Bit</title>
	<author fullname="Ben Kreuter" surname="Kreuter"/>		<author fullname="Ben Kreuter" surname="Kreuter"/>
	<author fullname="Tancrède Lepoint" surname="Lepoint"/>		<author fullname="Tancrède Lepoint" surname="Lepoint"/>
	<author fullname="Michele Orrù" surname="Orrù"/>		<author fullname="Michele Orrù" surname="Orrù"/>
	<author fullname="Mariana Raykova" surname="Raykova"/>		<author fullname="Mariana Raykova" surname="Raykova"/>
	<author>		<author>
	<organization>Springer International Publishing</organization>		<organization>Springer International Publishing</organization>
	</author>		</author>
	<date year="2020"/>		<date year="2020"/>
	</front>		</front>
	<refcontent>Advances in Cryptology – CRYPTO 2020, pp. 308-336</refcont ent>		<refcontent>Advances in Cryptology - CRYPTO 2020, pp. 308-336</refcont ent>
	<seriesInfo name="DOI" value="10.1007/978-3-030-56784-2_11"/>		<seriesInfo name="DOI" value="10.1007/978-3-030-56784-2_11"/>
	</reference>		</reference>
	<reference anchor="RATE-LIMITED">
	<front>
	<title>Rate-Limited Token Issuance Protocol</title>
	<author fullname="Scott Hendrickson" initials="S." surname="Hendrick
	son">
	<organization>Google LLC</organization>
	</author>
	<author fullname="Jana Iyengar" initials="J." surname="Iyengar">
	<organization>Fastly</organization>
	</author>
	<author fullname="Tommy Pauly" initials="T." surname="Pauly">
	<organization>Apple Inc.</organization>
	</author>
	<author fullname="Steven Valdez" initials="S." surname="Valdez">
	<organization>Google LLC</organization>
	</author>
	<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
	d">
	<organization>Cloudflare</organization>
	</author>
	<date day="6" month="July" year="2022"/>
	<abstract>
	<t> This document specifies a variant of the Privacy Pass issuan
	ce
	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.
	Discussion Venues
	This note is to be removed before publishing as an RFC.
	Source for this draft and an issue tracker can be found at		<!-- draft-ietf-privacypass-rate-limit-tokens (I-D Exists) -->
	https://github.com/tfpauly/privacy-proxy.		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pr
			ivacypass-rate-limit-tokens.xml"/>
	</t>		<!-- draft-nottingham-avoiding-internet-centralizations (RFC 9518; published) --
	</abstract>		>
	</front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<seriesInfo name="Internet-Draft" value="draft-privacypass-rate-limit-		518.xml"/>
	tokens-03"/>
	</reference>
	<reference anchor="CENTRALIZATION">
	<front>
	<title>Centralization, Decentralization, and Internet Standards</tit
	le>
	<author fullname="Mark Nottingham" initials="M." surname="Nottingham
	">
	</author>
	<date day="14" month="September" year="2023"/>
	<abstract>
	<t> This document discusses aspects of centralization that relat
	e to
	Internet standards efforts. It argues that while standards bodies
	have limited ability to prevent many forms of centralization, they
	can still make contributions that assist decentralization of the
	Internet.
	</t>		<!-- draft-ietf-privacypass-key-consistency (Expired) -->
	</abstract>		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pr
	</front>		ivacypass-key-consistency.xml"/>
	<seriesInfo name="Internet-Draft" value="draft-nottingham-avoiding-int
	ernet-centralization-14"/>
	</reference>
	<reference anchor="CONSISTENCY">
	<front>
	<title>Key Consistency and Discovery</title>
	<author fullname="Alex Davidson" initials="A." surname="Davidson">
	<organization>Brave Software</organization>
	</author>
	<author fullname="Matthew Finkel" initials="M." surname="Finkel">
	<organization>The Tor Project</organization>
	</author>
	<author fullname="Martin Thomson" initials="M." surname="Thomson">
	<organization>Mozilla</organization>
	</author>
	<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
	d">
	<organization>Cloudflare</organization>
	</author>
	<date day="10" month="July" year="2023"/>
	<abstract>
	<t> This document describes the consistency requirements of prot
	ocols
	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-co
	nsistency-01"/>
	</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="acknowledgements">
			<section anchor="acknowledgements" numbered="false">
	<name>Acknowledgements</name>		<name>Acknowledgements</name>
	<t>The authors would like to thank Eric Kinnear, Scott Hendrickson, Tommy		<t>The authors would like to thank <contact fullname="Eric Kinnear"/>, <co
	Pauly,		ntact fullname="Scott Hendrickson"/>, <contact fullname="Tommy Pauly"/>,
	Christopher Patton, Benjamin Schwartz, Martin Thomson, Steven Valdez and other		<contact fullname="Christopher Patton"/>, <contact fullname="Benjamin Schwartz"/
			>, <contact fullname="Martin Thomson"/>, <contact fullname="Steven Valdez"/>, an
			d other
	contributors of the Privacy Pass Working Group for many helpful contributions		contributors of the Privacy Pass Working Group for many helpful contributions
	to this document.</t>		to this document.</t>
	</section>		</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA+1965bbRnbu/3oKRP5haZmkLXkyF2XsRCPL4x7rdtTtzEqy
	sjJoEmzCIgEOAHablpRnOc9ynuzsa9WuQoHdGk/+RcnydLOJQl127fv+9nw+
	d0M9bKvHxb2LTVW87urrcnksXpd9Xzzplpt6qJbDoavuufLysquuH09/xa3a
	ZVPuYKhVV66HeV0N6/mev72HL89L8+X5w1+7VTlUj90S/nvVdsfHRd2sW+fq
	ffe4GLpDPzz64ovfffHIva2ON223elycNUPVNdUw/wbHd64fymb1X+W2beCd
	x6p3+/px8R9Du5wVfdsNXbXu4afjDn/4T+fKw7Bpu8eumLsC/tVN/7h4sii+
	Ka/rVd829CHP/8m2+in+vO2uHhfPz17TL8t6gNk+r/tL+euyPTQDruA1vPZw
	VW7p02pX1tvHRQmDLVYy2O8e/csVfrxYtrtoIn9aFGfHqrkqOzOPP5VNGX1M
	0/i27Ift0b7ix67+lzV9Ohr36QLX+Oe2XZlxn266uh/a/abqor/S8E+37WG1
	3pZwoPhZD/tYDY+Lh188LC7am6avmlVxPpiNOC+b4tuubJZ1v2zj/fihgfPG
	r8MZ90W7Lp7sqq5elnbyy/LmXzZVua+bq8t66BdwwM41bbcrh/oa6MMhWfjf
	CqU/JL9nPw1V09dt85gGFEKOCPQPXXvTwzL9V/mbZXeFi9oMw75//PnnV/Ww
	OVzi5n1uCPbz5abcbmH3q/klU3BlRjHzCFsWTSR8XJwf9nugjT6aXHYql9v2
	arH0T9Kcwq/zXgbSizWnidJInr4Lf/ovF/Dm7Ra+2cjH4yP+5sU5XLRfRTO/
	dwEDFcgQzqtl26zmf6yaqoMjaJviVYP/fdMe4DLeo4foHhc4yPyL30aLuqer
	6q+bxdB2+679Ee7/AmaBH30uv/efr6q+vmpgMfuq+xy+OOcPFptht72XWd2c
	1/cGri/QzbZa1U0V/wmW/qIcNtWNXmH/l9ewKcfrquM/fHf2p+8fPYxXT4c0
	VEi28P1vqvnZqmqGel0DLT+BeeAvyLZWxfP26gomUJRDcb6Em34ve6Zd1VfI
	/BZrQ2NwI3B8s4Nw3WEXHz3MrVf+V871fFF8dyibq8m/WqaR+/ufqmPZlTtP
	FuNvfH/oNzflJv934CrfL4rnVZX/87/D3w5t/m+w+y/aDRBttc1/ARjSm/Jq
	c2jg9E7M73xT1m8npvdvC5zh+WFqg+AV/77B7XPz+bwoL4HHlUvgOhebui9A
	ih12cMJFv6+WeOZ9MaSS0UqyAoRQ0VV/PdRdhc/1BbArB5wM2GDTA0kdcDCg
	dBBM7bYvDj3QDXxFTrj+ma/VZYmfww/+YiPVdNdAXSS5hObwq7sKGFNT97se
	Dnoo4Kosu/pS5gkvXVb74VBui127qrbIdSOmg9PF2fkZzejXvloeOuDntByZ
	Q3HVlvj3PW4PvH0L79pv2yNtD43ezxwvH8gaPl3RBGkHiqpcbkbfhynCVdlU
	231fACfF7cNJ423vqpWbnkSBXHR92K5r4MirBZ/crl6ttpVzn6Bq0LWrwxJf
	71x0VnCkcK+iE/v77X5TtANKUVRQYKO6antEdrAvuwEJxzwKJ7OtkTxAnhVl
	5j3FTXmEo1hUi1lxA/IIGGyxBbbREH9pjsWhqf96qOA0qm7OYwXRCPMaNl17
	uNrQfiZT1qOe0b7in4pd+baK98CtgNx7Oj4arcJNqUlq06ElY/aH5bJCvnsF
	MqVYgyiHHxegAfV9fQmHEu9vGHtXX22G4hLOvcV5gVrkd4aWDXtYrooSBoez
	g++UjjZzeQBxBX/r20O3rPCVN0Aolf1ikfkiEMrFcU+kW+7hdUCTVR+dPy5A
	3j/DRW2Kso/2Eu4r7gFomVdzEHk7VDvhxfeXbfsWzvjBjEizaQd/pusOhltt
	j0Vfw13EQYCgt9v2psCjBsGD00WW89bpystlBxsHf+95l+iSorpbEkkDqUU0
	PcDpwZeKVb1eVx1Sgq4Oteh+wC2EORNxwZHBEuF03pZwLgXNfr4su44oNaKg
	Vic4c9XiCuiwLHiV8LUVHTyS6aYikoc9xEUTz6FV6E2TjYX7dOjpew7YPQy0
	228rlJl9u6twr2AAr2DNPA3InIHa/ZRhZe26Jyp05YBykzYQmbWZ/gL1lV6/
	PcP5De1bYDJ8QCJz4QmaMryjrxwTdnEFqmXD3wZ1tMFlAYHi+2G69KrK3yF7
	LLgXxMFgYvz0TYlzqoca1nWEDekPxKye4Fs2QPlwo68ruIenJQoKDlDQ+e7d
	tIFVP3bAJavdnl5ONAJvAM27osUX5o/hyqt4QIJy797985MfLr47f/rdsxfP
	vjqbf7MYW2lwfvMe7smu+vABWNoByPGyGm4qWN5TJddm5V51Nag+fXFfaOYB
	CSOi877QP8Lm+TP2T9PN51PmE3J4IXHRB579wj8PA9frI20XbzBedMtU8S88
	bgECQfimi/imyPFlROvlJfLX+OmEOTYT/DHDHnV2PF18MbHHvgeJBXTAVwV0
	1WoPjAFligwxHPfEXOjpWcGXLrlg9YA0iQS5RO61mplZu6qmr8p29iRYquu6
	PfT42suhBL14JZOD8ermuiXO0XjKCZTilPsBkZydn//w5OXTCRLRR5A+8ECW
	pPzAy/WMnJ5v2cebuEiVrKC8pCpUcdmSNMjSuwv6FH68Ad5KbFYvp9Bi72VM
	P9JRYER4zJG4tJevBwrarnC/WXlhFmCUFdVL4NyW5j4wVxH9Bf4GVC8Sqd4z
	50SiRbVggRrLBYiSumnB2jvinlTFW5g+qRHFvRc/nF/cm/H/Fi9f0c9vnv2f
	H87ePPsGfz7/7snz5/4HJ984/+7VD8+/CT+FJ5++evHi2ctv+GH4tIg+cvde
	PPm3e6wb3Hv1+uLs1csnz+8xo7RHhVwUduKy4l2GI0ZuXvbOcpjiD09f/7//
	+/BXQET/8Obbp48ePvzdhw/yy28f/uZX8AvQd8NvaxugUv4VTw+FGFxcHAU3
	b1nu64H0T6AiOJUbODBgt7B7tF/rFlkN7itKZVYQSbcW4c332yzgsXN8ax47
	MAEaPo4jKzd9Vb1NSJUouxFOtCh+6PFVcDVgIb/78ktcyBCOcOaUudUo5mi/
	kCDePLk4L56QzIJr2rVb0kjwltAkimV33A/tVVfuN8CgRppm35dX1ZTF4HWq
	GVg3e1J/6TwKWPkeFr/u2l10073miqxALxDMh5eY2RVmyWhYEJtWNgNvuTxa
	WYAzJOtjh5s2Vi3DVHX1QSrga/E4w+QukSZqYEUqBJAzsNCnWdC6nqrK1q6H
	Cl8ArBLmRYM/1bH922QE3vNoW81CYOr6JuVkuoVnKMi77Mve8CPmVf0eFlrl
	38UD9axqNStdEqmvPI+Jl/Cg8JY3niGe2LmniTIVXqN7iuQEB4aUc+j2bc/u
	uZRX83QzlEGaTW/G1TeumbTARkFOB8OzwsZM9JIlud4HeQHS5om1+O1XGvev
	xXfJe0nH4lEzs+U5iOKhc8P12lmPd4NpIKhYt7AAvy7DBGBEzwb+FZWDOrAB
	/rq30ODyHjq/Ef6DaCM8J1lV/GaYaKIuKB3BmzcluwS8AtRXA5sFfg94e9B+
	qVBdKbsj70W8cma45JNHE5cF6KbeB8WQjH1RhVTMeQmyBV0WjYP1ocOZOhjh
	su3If3YAssbvvXunxhOwkzm96cMHkpNRhMGNYhSTevMa7D8w2q7I9vNTms+d
	XjO+CTN/t5GP+f0FbZC2BgTyW5wfeVW6wYXNOaGI1+RNkXNVxQz0r2s09Ksb
	l3hkZmIbzMk2EI2IR1blcgNGsXpQUNeIXSPyLbsV3tJX70nqo2rXpLBMrCJY
	HKS0qgvnuuxq4+HBG3NyF5UA4pmBUbw9kBZM57USxzKP6W8OCXYy6PTwZuID
	IiIC07dfHnpgq47IJziamG4+KV7pdrvoRGJv2SDOAWvUrdFSx7nYQ4IxHy6A
	oYu1oN8Xn4XXE/C29qzjw6mqOIGxyE10U4PN6V+FtjQ+jPOQp8k1dFMK2xrg
	wytkJ6WXKkiIqNSTX0otVi/uiHMkH6rpTv4CzwmEowJDPJBUeQQK89qaQ+UW
	/TBH4iH6ovK6rLdkkbPOBMfWe/8ofcUZg56NmctqWaIHxQzNQ5IxI04KNVjY
	Xlaz3Ynl07+t9zjT/wCa2he//s/7n+AP80C6D949Ltiy++pe0zbVvQ9C76sK
	NJJ66Nk4/yfU8oBUNm3Z4QEB+8ZT9jp7Qo2o3pPBJfOBXfoy3aVVC6tHrrsp
	r6vMPuE0UPdB+wNWc1OynuHYMgP9tyruwxR2bVc9AHvn0Hh3Q3KK6KNl21RN
	OLx8o+sKFCo2IF32Hj1kMuDY3rN2JFn57InVezT3xFKmgqrvVQtQprLyDIED
	N8TcmcgWnqTMMGLRrnAHruuSnTa45X27JWdo6Z4+eX3x9LsnM9iEavkWP1sB
	obDvbwMneIPcwI55XW7rFRwkkN6wXNBpu3fvRP/o5LRxq1F6wgnhif7Kn2hu
	keqz6iNzfmZ9XkvkzHi33GA1TaPgeQd3tCvF/SsKqaF7ADfA6kUzh16Mqw2e
	ec305beZDTBW6oyTUh99sCAR6TkwEqC80Dte14dm6U1g0g/KXSWeP3QXiY9C
	/upGLvz7fI0sx31gfBs6amZDkYqBaIu9OInZqDHfQxX8gNZf21zhXZyiXO8o
	AZ1AdTja7qDG2GETJ+cQ7RC+yzPiuovP8SR5oNO7t9cIfQxVfc0Olqrr2s5F
	UhXVHhEZaJ0KvwAy/Edm3XJSTBnMsYfIqAhxisAjZKYz1hId3UkQtE1wXcrk
	TlAcnN8PqInx/EX0uvjd0ULxZhzsDMlSyjAu1kNINuhAoiJ5dyvSJN3dUizL
	sjkiX/DCEQMesjVvK7h+l4fBTblpUT7iBCO3nJHD8Zpg63+d8nQj8YjrsrrC
	DJzkc3+47HHAZjC3HQOMQZDPxo4vu2hSR3CS6P9AzRIHBkay9H4HHM7v4T95
	O2XVEjewpiMxNIyU0kBwNdCVXa/ZHSb0iKOtDvstu0xbDI+sQNaUeJD6kp5J
	kOePD+iRCK8Pu4k+biXRldp01U8gLQx7I69cScwLB1N14rIS1Rl0PC8z4NA6
	PhHiHyOtJj4gWkxO7lJkbFOSVcJKh794eFPVc7qMRTcO1wErOyoF8Q582hsa
	Zh0PmMuN5wv4GKgdMDqc8Vf3Eo3k3gfn/vu//7soy/76yn02l3+fFeZf5lP/
	EX4Y/u7eq3743g7wXin2vfnI87X38H9yFu9pBp9lZ/BZZgafmRnwB44Hz/3L
	fWo/e8/P/p7GLMRbUmT2Y/JZmELi14HHv77je/Nz/v1XXxXW/P7qq6/v/Owv
	eG8438h3JLsBazo55/RZEQmeSvRbusmfsUPqzvv8t64XCN3BVfhkXV/N1cbl
	VJqv7qkJhWGDW41Na4XhDQIj7gdY4FOQeb1z+OMSfxzZZmQXXnYtxo1J4UZN
	pLhCzYz4a6LYshrjgDl5G7IY25DEDSWUB08MGD1E7nSQaYxmAbpmNiUMPd4l
	+Z4w7aFArjnf1juQJjvgsEs0fSIDEbSEQ49Me+jKNarfJFopSWDJmigFaS7g
	mXfvJHlL5ysSnoKvuBXVNajTYCJHXpLIXZ+4+DFiQj4PZs1179e7KL5rbypU
	EckJUq5WMMASFkgaN8V0SRR53e7gz6uMXnpZgX2NCRzF8/Zm/tcDTBdHAGFU
	z9ddeVgVpCpvaQotHKXP+/SbsOAr0JP2oBFhDMIWVpBfVptanCAUiC6vJEi9
	rd9WQBjsLbts2TJBwiThg1IE1UVaE4xIP7NvtN2RyIOvl8u3/iSWSNcN0Uk/
	HODIMA/i2U8l2g5jvRF9ej0PG29wUNDVBqJN1deLOcSuex/WrzC2hXcIJ+hE
	aM8weN4uUSsSkwkO+qptVwVlzOL8YPdfjzNQkviD+nK7Guyl7viR249+H54P
	aUx0+h1r/LlRQ/JFae9qu4ZRX11ua/IRFN9dXLxGD+wr/CEEJ9tNWcN/hmGv
	3h+9mX/07q8LdqK9IBvm3SdjfyN7Fyv8vZ0jB8k6guLr8+6dcjy45miab69J
	YerA9vTJGRTmZYcCaqc/Df1j68fXT9X1a/M+aObitrVWTA8WMNxrdb9axw08
	oEooJxORDRUlCrHpLpHRFWZoGO4TnDxWHwL9sUMSMTycxvFEixEOsBiKmlMl
	j94RTTOiVLjusAyhlchrVfe6CUHdhj9H+U2w9+2ypgsoeUI6E5u3A9Oud3jj
	dnvvj75Gf6/YifPrmtmTHfq+d0nSA2evkb3BtaDkHmEhsg2YQG3iFn/72RXj
	s5sZD0Aw3D/iGIvMMeKZ5NwBcp5eCI9Ps8id5sJNnlZx6rT0PdFZuYmzorSN
	jzkvd/K84PtrIJfrqtwiS4wX/kDoz9sDsqSsMYsu2qEnjzQY2ccZr4PP4W21
	RwkF0mDw1rCLNzvrzUgiQb+YoFzCDPzho7U58zZXFPajr+gM1Y+mMQIlzjsS
	nC428uugdJgmrvCWE8zALtml5GVedhduQBsDRHaCKZg4RbTZTVWtjOlqXuxC
	zA7TnsR3KMGzUcQmVmB7jLMjb7SRnrpJAuEkp1zixNewJoZGQ8abv+gchjt0
	jcTv0LMiflAfMuU8LTTCl6gxowsu6/OitdF+a9iVjgvUy66E60ECmxNl1GnA
	egKvQh0KogNw0p1ckBvMo0MCdT4GEAQIRxtsQlVIJrRz1FCMLst5x4WGO3AH
	ekxA76qWvJ0SngrT31Vlo3d6HeI6DvNM94MPPcssyVnlR+eYDb6i2B22Q436
	n9/iGbvvS6ceNHgQVT9kdXQmawl3RYdC77HRDBP6DuG3RfHnUVImjBQUkDgk
	W6VR0y1eMlLrfeKcla6BdyfuWlVniA/eVHBHha8HN+y+owKSOkT49G5rgmfN
	+j9bbf3YXHN0GTR4Y220nEM/SiKQRHSYLiiQ/YYYHF2CKGwtmQIhWOmpwbHl
	MoqILIpvcVxW8ZFRIFdG/tlLRqhPBhLuTaTp/H0Vx70hVZs8YO8u80ygE7c7
	YE4/0H4ZFaBcPD8f5UQiOZUNsWZKUY8n5xJnImbFHRp+km7QyWlar3EvLB1O
	9Lo68u7x/qJ/GbOTrzCBi+254SCZsn58vAGcMLlwflLVT+imrJEN8VDRdVDT
	LCZC5VucNA1XzEdQvZ8QrIetpIvWnTJj2pyQNC7cwHCAsFDmYLsSPZj0+JG5
	ruYUp4mlPjmqk7wJZmk4FXQ6bFtKPo4TmPkLzZzvoykjWBRP049oYJYaNDD6
	QV3IhfdRHTP86RvE0w755KNCD9pdP71edDxJ2O2DdyAsnWWanrZNGcbJe+cH
	HP4fOf+a6McIQKa2WyQnyg3Mtydh0GEI1UWcJYRM8iyNNIEJnubGXouHmps8
	Fz4evUzUF0NCklp+01rLyb/DGU1VIho+swflT5oCqw8aj7k9bpUtKBzgjYH/
	e3F9xvQgUcx4qmVIboA7NH5rQeQK5IvM5AD8lLQ9SZE7SiGMFdmBeXl6HI/K
	jivRan0qHkn8TSkZt8mjzkyoq2CJEhgtOVPCOBnb5rhDGoDhF5TjQMR46ugw
	NFPvaqwh8dly2e+7uslsm8m2/Ihdc9ldM7c4GfOWPXOTD+Z2zEw52bAvF54D
	zoVIP3bL8Naf3PSzIX9bslfSRZHbyQtzyy1RlW50S4Q9RbvrVe8MRVrd/+QG
	28Uke/yrRTH2BKWb9MeTTMSYu260Jyy4zAnnuR1rQtEV061DgSJhRR+RRRnA
	OXwmS81E/vwZ3edsescK6aXVSUWSPRjzTLwXI0+HyF5SUNGjndZv5EzsdLVr
	qk0JoWPNyg2atFpucD3RqJWxVV8g9RI+jgWMSaf0VQKlBHcTf6i41WhzUR9x
	42WeMpJ3YuIsh/qaDPTGnH2c+RFn5MniaEoSEx75k4LOHhQtx/oSUgKmz12b
	5BHVtWEzOdOPKW04vUGktoDtAeS0SlT+kcox8+UxkXWfDx2pBRBp5rfEeFhz
	Ryc7xykk3cbuA1toemmlEEg81lOhGNmJDWV9KXcOPsWK60YlVIOePjN2iPNE
	djS6P3QkHt3LB5kLbuxIzDgSM8YcQF7BmUWNFvXSMKSP0f3qUTkozDh4qdYV
	qe+9u4/mBgY4sPyjpvx78shvqnJFNm41LB9Y+1onHVJPWKtnMtHFukQ19oq1
	l6zG96e7bnf0AZ1Vo5q26s3uW6AJ8cfkTtLv3g1n1iWJmcZ2Fy0WLWCvxVL0
	g8o6hyAvfPjLVBWgyYAzwleGjAn+wqd2Iez2xXHpTNaomG+xlpNWZ68U2zOs
	eZ+z8EWVLkQUZZIOj1XCWzgKjjElSODvV+xFgBkeKNdd3GNq96o7c38Ae3qJ
	yTj4+sSqmMd5lB84GdMneBujw3I/YScdgoI0K/RkrFlBzeftKhsC69JyF/KP
	cjqnS9Kd6bFb053xYhiPwgLmjULjwwcX3o/FZpYiWaqoS0HZrsZg1HtqxaIz
	qXu9Tbam0JXRB14re3v3SZj6h0wa/F0qP//hIys/43LeuJLckSuhDhWhpytN
	klSol2qDWCuDPMvAe1fiV7PJr/o2ay75xCXvO2C/oiQpccpOkjdy/927sAkz
	BDehVz9aPPzw4QEe0czV4Q7PRqvTgCZnVkyO9ghGc0lKF6lNSczLZp3XWuOm
	luZHJBDdmiB0awLQqQSQUwk8pxJ0TiaVYAbO2UiKf/XV16fSWE7O0qah2Cgl
	J6I8jRISM9clTT55ssWkA0IdQs5KEgI4G4x+EN1+1YLyEGgEOW1L4DyHBsXn
	ksSdUI4UhwH1cNmUvx0hFzROghsXsqGMoRCqYo70wCvR5ee5W3IGFPSm10oV
	Wi8al1Yfj7Uon6zJqtdlJRkvK3UeBXpnPu6IWY75eAiZ+fpbk3vn7YhJ/ZMT
	5J1yE/Xjc5KyKMkhDxN9f+SfV/92xs2A0+pYTyqL5rC7ZBlzUx77SHuV9eNp
	XuNkTMZtbXICZ86Hhx5jLsuIltmKNKFDhRDyhSek2o7OwBVxTj1HdtS04YTh
	4htvRWVEGOVEBk9eESocgqjUFGrSfjNj4PLjmJJmeBCWAsl/zCOmkraSeCXx
	aKw+RRWCR/AZmrR38vbjQrYLzYYVO98lo8Qw9WD38Ml4N6JxqBK/hymx1yBf
	DJFka2SqzCQrdNOCIgiDwZlo0DbU2NkTix31+fweL0Ik0WeUJa3YQiHIfynm
	rKZbqOeaDF60aJYM+sbb4Q1sTC0L9cERkoXfEAp54q6PPQ2L4mnYcsnF9nUo
	Otz4Ns38ROAGA0trlpQKvlSVVtVURnqYr8Es2HAeCFX9SEEN2mowkI+jYNI8
	vOeYeSEo2nRTBV4iaBmXlcbi0NVUhNxidFV7lu55OFFoCedQ9TyhDv4DZzJ+
	I4xlXBLKVKqdh1PYcSBJX0+2dbkeqs5yOi0IkNQoowCw2mw0kMVDoq6EwSbx
	rXnxOjjjMJiGsDFzjQKOz5LzbhQFwhLYmvY+sL3AqVr6AkWX7ie+rH14OR/B
	A7KICn0dUaJg2fgQqAcKSQazc9fhMK86433DjZAi2MxjpKnuKb2dgvjBBYfb
	3moqQPQgOt+KV5zzB2TSqrFBLgAqSwId1ASjyquuQmmIHKIRHxhVGnjpSyM+
	A454jKr50rfOcOBWX4wXiYbmGvAVpoWaEG/wq4ch/bvOCX7tzjRkZS1jX0Rr
	5kKmlYcDUM8DTSlzVHDcZcfyo6v7t4J4IYAMjOoiN4PyOBtPeFLBtDcuc4uo
	wzF8u+iFS8J0udloQF6ltTEfiNTNBIRW/XUmj2Nul0dHJ2FAHIBADmqOmOG8
	BoYPuDpwmJGlmUW0SeujnOZ9zjyVk8is+H6gGUw1gow2pYBRCRMSHuo5aHx0
	rBLldkvhpjhxaBxZ6QuBEOGXCpfgZ0mgx3UcWt1B+4ahzayb2qNh9V6nkKMI
	HJyTJJg4lIFwlpi/D+T/MYz0ZTuIxzX2kGnCBGw1ees9ftCIMYEiTyRMc/ef
	svKrLlt0nGiYxvtf1WEitVe0nFVN62zwKz+L5nNZwabVbcd39i43VryWrFB/
	B1dV12bjGanKhK+n09GQKRZTSzIvOsOinAWT3OKlanBWE25T27LPTFUUOhuj
	LAVVCd/MCXanQZbUqe3dYSEc4uCC9WpmgAZHI5CeJlX9oGQcp/iZf1HvF58U
	l7NrxWvp6ljJuFIy5YaJEqngSOokQYfaXGwsD0wkegMDtaGJsScrL7HRvEKY
	sUjdrd6KgIghA08/gi4JA6RD67AFG5Q3fVcbU50A3sL0xShqaTopwvjbLc2w
	yS535CZlJEqyiRJUbL6rSZLz2jjWZ6bl8yH1MAO7cd0eAoBgHHkKxdjjEGCa
	TGfCuH9L5nO0o5Ixeyrn0YWcx7vlOw5RErTP84wm5bMQtWB9HKshPQoO6llp
	Q5CeBCTi4C1VtUlF+oqNToQi+fPO42lR6OGAjmIG3IxxlHy2OSWdEdNhDz/M
	Iegn7G2nwKYyzGAgR/SFRUDDRDGyeMqD58C4LUsxL8BwCwWTTevzToIf3eeT
	+qjdlpBbhQQ7C6Dwae9C4hFylRShkBCZQMZhtQqorsGeaxQaii7tP7k+sUEe
	5WWRD60dGCBNTp4ZK0UYMN+OLIeCELJXcYAjmuV4A8PNdFJXIs7bECv2TMnD
	LBmvf+qmyeVYF2c79MyVjMSr6EQCpm0qoWJg32zd0sNF8ZrPTb0fudSfSj0a
	Ut/M2D8rQy180i7QAMKL8ENx7hqL9MwraXCyO80bXPoGzUnHN5jJ7+BUV+VQ
	jsPvo8lHl4u8mkpSruwua9ARMdGTh40AOdnG1TfN4wiQ3rlYTqNSsU9mSLMW
	iv+7T3ucwqcFF6PYvM020MNpL8kn6ST94CL2vHCpdaU2wF32IwXFIYSUZO0s
	qTP1k0Nfbde6fk6j8B6Q8LUYzXPmPLqZ8HmfZEirNjoGBz+YzUVoJXnGhFLp
	EvHd9WsBss+7JG2Uji/XD41PGCZ1EnkHkfDyKEWZo3UrTqLqoLDyYUMQOYkC
	+mlfJDOMhV4MWyCcmifvk+Vxm3THwOAru9WWhCTrR4hM0lSa0r/3Z4h/C/LK
	xfJKF3LfZ8Oor5TCQmBjswlE5ZmxbuHgqjT0Rromr5pqTqoSUNRVRdV1vNG3
	bh1Hsn0A2Us/WG3weN6X8HjpExso8k4vU5uuXa+3NRcZBNAjDXNkwY/U31pz
	Hi8t5Cns/aFj5n+XJaBLoVyTqYblC0v/OMheFidy5WvgA7tQX9RPZF4DLfJt
	9S0fermncVy5IVSA8aQIKkuhQTnZZ1WEsbCETF05oqaQfAFLMsicSV0WAeR8
	qNpJqBoNnE/C19/Ad4p3n3j4G3phAjtmIVJ61SEohzgLOocenx53s+E04xkH
	xLodoy3bHPQ+qMc9q8CtYvka+TuyDz0cXRQCUattEVLT49Rwd1tquK+haw0+
	50RpbozBpdjewMlg/gNXPXE3EI5Th5SLAEUYQQSGxIEsDH12EoI1KPjUkU5C
	fvaA8U8gxCbpuhOwwdITNcVtvOljXqe1w3FughlDVAodAyHGy1ryjkyRWHZQ
	xQzMWAWhlKiOi30D4lQbcjSAQlAcck7rst1rpUxOyTtddM0wAb76/FyRprS0
	ehFydijZE2t5fdn1cuRaN8CWhLWoYa5luVf9LKm1w5mzodsdsBKR4r691KBH
	7LIw1eZad4kV29m6b1VJuNRbDwa0DfTNer/RgXGrOXRGExYILU/mNPGtYLJp
	0JFHFWjC/EHjxFraSpuKY8og2IcZtlc3MDFr6Vu4dLEfbKJvAAJHgcjDyWmT
	eGUvqSndhHG8yL+qvKQFga2EpbiZhv0w9A/tIM5j771n8215RBa8pM5GBmyU
	nbZiRxSZiu+J+y1Gcf5abCht0ds+4+ht4vU15ZtUCcJUzcqaTJmiGn5Izj43
	TyH+W6O+aYmuKoEstHkR/t37TieuGBYDNshjxdgiyL6hhXFWktJI1AvMfWCA
	PC5ZMUiuvkylRra5w0AU5jypewpFn3KAGGdyystUMygzOohab+m7pNzsJJ+a
	5XyCgjQSFalx9ik2YODaEqBHDDiqdhmyDrx4m5BBS4IgX1X0ODNcdNShUyDK
	Hy/6+ueKQf+a4NuN3yX7yrKE2BRxtlVgfLp/INSAhsujlPoKtlJER1pfXXJt
	nCGb0hOOYk70xVaQApv8lMJr3G1TUtvpLo7h4DtHY1Kg4Ukhq8byytAuspkG
	FHoOFyvNjFLAR0B3E8iKEeweRfFd3jeu0dsLjzJ/omLCju0CVP2hsYEK3tik
	tMygf2qtNVIrOg7HQJJayBhdM2KPvsYszQ2NLGh1R4pa6QFzJrZe5kvwGS4Z
	OJ/9O8mc7dcfYI0Hu7DSarbM8uiM+nRdUdm5f70cTZSDHLQwn+McBpcMZ64g
	MZXn2VUmlhHli4cl5CbvknyRE6OTrp5ZvrEvsIYIZY0FeKMYGmfrhFOQW/qn
	Fuy6POgkQS0l8RNeyvxHfGpOsb+OohM5/4rGQ0Mo3mV2V913bI974PKRoRDX
	uXMm4Bbzl445+8FAHiH4M0Zjs3Kd9BN0JtWS4UfMmtzw3qfNjvhJNTjUnKwW
	2LMQYzkntFj1EZFNiaYAO0vIzx+BPTtNWZSZkp9Wcg3YuR87JgoCzkvrm9cu
	KWKamntBDEUtJYXhw+0qfq66dg6c3OFJtjUJY5YUev2jxgkTglhDkC7OlszP
	zbJHFU7wU72lN+g8QGXZlwMC/YIg5U2hjZCtquOVC16VMDbJ0S9dzogZyv4t
	Xd1zIN389bCX+j7j1crl6PEZuhW2XFpispRqsAMii/Y+UDnqd1K6o+tGZSGs
	3ZQ4obNJlu/ctxqOhNvgS35aEyqeqZfH95uIIBAEiwOZUD9QzkVugqYCS6dH
	3jLVk9IUuLdNeyOpFxOQFDYJLkFirwMcZBjb18mFOpeAx2NyTgmWQrITsKY9
	u93OxzInnjo0+WMqL3t2kOwQLCqquLHSoDZor9xlo68IZgqFmx6YSgpUBRFp
	FfT0mTnwycu7rn9SYMwQy48Px10eQ2lkKO1RTwTn4LIb4XgKH4OJw9m9UC+F
	ZItSkzVyNHnCCO+20KatTyFxdrNNH4qRoxHhNrLnII4zmSS6zTKuMrM/tSZh
	BAhjgSOZhPhxxr4ppLMKA5gkKDkCuOBX7+cYpbIy4n0Atg484jR6Ql7yuazk
	0yyY0YgGdIZCT4xQon28iByTyffB8hfIialBc9r1CH6ac6b8HiPliLCLAPN8
	sk6u4GtmK5aRQl/PN/VKXBg/EZ5hYbEqlF+wcjUJ96ABffZveJwkvgW6aBvE
	nrRcSUkLnb/8UMhO0Ivcobin4Fdo25VpWjhemi95QxDEEYikM4WJ/tAkFQzY
	M+zZzxLUIumjOdqU/mD1V9IufSncjcetPwWCZTO8udUlUpdkzZN1c3mMCyE5
	SuytwMH5HHtWmUvgxJc+ZZk1xPAV04kyXG7gLINgvHkIFs3EM8hJRaRW9RFW
	lC4No/r7ssaiQUw0ITziyfA0eYNiXa3uU4CPopSN0TLBtuHmFX5NMxMsGiEj
	4ITM8ltC0y7OvglLpTSudpBchz5dJg4j8FeYRlcP9RV+VdM/A3PVzIK7WOtJ
	uJMhPOIXOx0nQklPkieogF0inaON3JWrBBLPQ5H4pBj2QuWOaaJiqDeSg773
	QuKzxbtPNFT7wbmnYjqwW2jQBipTXmwuvcDCg0GXqMHhoXI6rmTRToe4Pbh8
	6hwCKgYLqr5GuFKKcrTebZrE3UnHRdpB/B5Pe+O8hbD9Yvys/RDiCCBW+pLq
	RYtjXW1Xvdu2V78HS+HrR7//HP/n/ssHBXZ/tw8vwoYq8E66H3ACrzOTJiWM
	MzKNy1lC9ZTHDiw4gogPHhCs5hwlSdDz0muRlBNgvDBGxVgr7b6EjUmcsvY7
	mY0tZbN8YoEUDPBLXGgBwDF9bmdqiF+rqnKwB4Rbqi0JtU8FWQ/V8q0oLKQJ
	UNi4eEXTz01Sf04HwtuN9SoiFSfGHXslXZt/lefEZXGPIYCx9oazkhgM+N5M
	Ww5gko/DhNrtOgaemPm9SNp2/dHXnoNJU6IM8rJtjJdRS9kxn05tke7jwCBf
	0Z4zpAlS16U5KgktmvCHyRy5EzmeH6jUJmIgWq1zqLeDKks6A39x/gD6hs2G
	Y4Ph+646oNZdYV0N1jj/8/fPX7159MVX37w6Wzz8Av7/i998/rvf/Hb+5fyL
	L7+Y/+Ovf/PbX80f/dfDhx8+uIB7CLoojDLnzKt/ffX6zbc8OnWmD2N/d/an
	7x89JAf+C3ud8LhNTJ7acFDXT/RG0G5jvG3YMNMvd+Tcw9gUbTzaJbuEPfhT
	ZJUreAg5ZjtydVjm6YIsprhli8Bl4aX+VcSkhGEKSfgaFHKTHUj5FAr3bcwt
	VeAQWilyWcfD2zoabKPq86SNbyyfXRQHBnptfzORbJRJp0VRJhl+ozRpqsX1
	SQ/vPjFJEbf1ZKMcy2XbH0H07zgEixg9aJ81oklQMQZ5sa5JNofR+fqA5qwx
	wZATQvsWYABqSVhiFbipbjI+bVGz8gkbNE99MeeUlCvCyxslL9kMkMeUs3Qm
	ErSUZEkqZii3R9Mg2OTkU98whSPVV2INwVG6iKAOIl/DDfsRTCTK7ePoy9UB
	OP+W6hK1jqf1eCCmjDRS0vDMVYHXIEeEsx0n5IlN31OzjSkElVuRHmYGOUby
	ep6s2PPMe2qWEioi6S3sFp5juE9JFnb0CrdfFJCisCqgTxR8ijbaVrs+H3V/
	fMtamqOHIp0qmcbRfdW0j5BXP7FXcGXFbkYzlGIDYxF9iyL53SeEJTHCGdek
	GwoM3g5QISDjNi6xFsr8GBAKZHRJlAi4jyNDwxaOqGyJcfhoT+JbX+8UihZV
	E8eNaLfEjic7PBZn4rmXNKhx/hMuzSWAxxF8J/LII7nqixGiYrleV8uht/N3
	PP/alpRl4kOhXeXJLhHMNjnrM5CRnLbPGZnrufM9jV1LHk4mqbdhYeoLNI9E
	gTf1disheynv0jqwUPollWcTcOs+A7k2d06BXRhB00CbZMpTfLmCRLP6EK6K
	IMJH2NkyN7zw15Uapgb3eQy3zcCi/UTc1Mw5P8UQhjS5Hgr0hR3ZKJxii1qT
	ilpvQjXHtFt074bMhE2wt6AM1H5cAwXTQYe2BwUJ6F3srQYxEGe9srlghE7k
	5g6sgVyyoO/FCMxRVqt0k9NMyzHYv7iRbS5hxMCMj1CJ+g5lOMIVgrVzBOZa
	DVI9KrkQbtSdluOeLbfCCP4oPF3WPdMQdxpi83Qg8K10Omrt9ih3SQxGZS1M
	MW4cXxasAgJPsHFf5qo9ukPjFCe+0C7pz0t+WL+AEcfydQzbFl07+xZmccQa
	6z35cyS1LnI7yNGQxEwPRdWCU1UXnkekvgNnSqOikxg8lEZfUVpKBkZj7AQP
	yx7B3qYhCkvfWkCaBCXThotUhnKKMqZeEGpeyz5T7jEJ7TGJ4MGHn52KS7nX
	pyZfsK76u+4FgdMawO14EIq3MnSDzfSIaj+DMeFCV3e6uT7Fa7wwTsvsR5Wg
	vlJprHSrbjq9JyMO+Sma5WE5Bi4k8ustIgVrJBai73pJ4Mh8E9QR9akYNVIL
	VL2CqPEs3+lzJjaam2ooUUi/E3/F70Z9uEzLcKNCmovsFT6xp6Af3IWOAru5
	CX3S0yjhEPpYHHqhUYrahO6U2iszrtNP/i5h/t7FzR6FUr2wSEp6hE6ZsQRn
	THCVeAYgeBwmjVVD3SY2ZxqxZleLx+BRAH7JCRBBWnxnjvspR7UlcqxXJtri
	h3Q7XbqdZilcj5p2dxZ5t6PmhgHFBGPDlFyufguurI/mKW0MyKORQNUYqO9B
	VBZsmyIALfBgxXXGra+5lwmLVIwweTPgBDPn+92wzhuF1jWjg7VfRW84RpP3
	vRowT2SszjlngthFgHs6LT3C9Y7u1K3S43+GmGo2/OtBAQF6I7fDhcyU/Iv1
	LMluNt0iw8ZqqTmKgc/0/BQ9FQ5eIcWoHIGvXmxbhsY8nuajDuomq5E857Vk
	YeaaHEt+auiJnkcfSOq28GZfsD4fbA2bxpLXk/RUyvgQnTeNUqY6YoNpR+VM
	tFeBzuzLRsEOE1WxLSJsXhC12VFfYnokmZyS0dyde2byyQQWdzJGbcwrHx4Z
	sqVy2vrYuqhmpwXYSJvPK4UX6kQj1dqDUsUrrXsP0A0m66435KZZtqbOLQt2
	XqjfwGU9GRbMOPUm5DovLNzYVChOmgrj3enDPrgpu6EY2Q3srDBQYGI/BPs5
	NSJsu2ETOr3FB0ZWs70x2j+KW0cqbADNJuU9MQSub3geG8xnsefKxOdMfokU
	agVHfZJZwZ4ubEvOVM7xHdPQe8xdjVU0pVY7ag1emDZQfm0z1Q8DdqH/skDW
	xPgUI1SBQXNMJnmelYauVlBxCjoN2q+LEwo0m9sI9aAJSKBKgRnr7dHlEubi
	Pk3TK+dyrkbYFKgubafQemnP8K0i6yDNInSS3qcX7J1794m5S+xPVVdnEBIm
	zxLLUTqw4lc54BNV6EN8rfKNZOEdSj0xZiQznlFyknpWnMHFwxWmMOkRonlM
	GhnsJMemNgiVUhrJCIZ63G1hFrO02N0rTC1ujkJFNQZkeYm7Irqb7+idbwUz
	UHpplIbrfKmSj3uN6vslBjPauDqGanQYyfNBEjY3qIoWx9jU+15ukbYuIs6D
	m9o1AYpZ69tPYeLDfLQ31qorbzj3XlHWMOWdnCLkW29/osR4k5QD/CObJk8u
	aYaH7CrDyAL+P3XcAhnge+kQA+MiDjwf0hbWH0kmC+fXQl6+O63HJhmhHi9z
	m5Edxvy9NA3E7HqVImO8AN9WStb4IunGhdyKSguTZkLYyOdAHkAu81xrg1wb
	TuTIyjnjlo2vvFx3ZQ9zBjj7IMXWmNEQ+gqdZBi0MQjBkjlex96DHJpS/FoM
	DwQQ5xFksen2fod/izEK9PukY3wMCj369b0bdYx/n7SM589kD/TXAC2dwZH2
	c/gseeln0a+f+TmMIZz/IlN8n6z4fe63Ty0a9Yl/Y0Dqj2liH/+uCNhfjbrG
	fzVqQ5998m9+52ejFSUt4/Hf1/nZjp+MG8bbU7x9tqf/jWebvr3I/g0m/wve
	aRG/o5unoN/CJ1L94d4HEXsserpKPKAsqrXne9SEOkVOSKTVZOv3EOA0nOeU
	PHKhx9BHMn/KtxL3ziwynEw/RHZCUS58nGEbOvxqyRLHZTwKgUcYsJ0GuW6b
	PD1aQDtVlzcj4Uk91/d7av8NA0gD3Qq1BHTs3NrsQtFJP0LjSQaTcJNgGkzl
	eEol1aVVu0xR10TKNcaprbcq6T+V4jVqXcIU6LG7L2m0ofXDBwLczcyr35fL
	6YlxLrhvNcMIPKb1CbywqZZaQm6NLBS30+V9XtBGtXxZcTtRZ5hXoFjCeovR
	Kxre6eJrZo2xE1yWP0YTNr20iwmgEM21kIQQU7GgbirnvVQ/Tu5GWuBqMzgy
	nXLrKfUhLow8rUTcqkZk9IbbNYf3SXeJRG24XXF4bxWHXPeJ2/SG97d2pzit
	NnwaSabb9YWP1Rg+QmcYKQ2/RGv4eL3hl2gOJ1SHv5vucFp7+J/THyY0CHv5
	VI+YZoC3qBY1ReDXh22Mt3tTSmcoxMpqy9Uk16A8H19QVUmvhDtyV601j/oU
	RqOrT1RxalSKatPAScb7aZ+BeEbIrFBVhV++zU6TBcSO2NAoNguA4Gu9VXkT
	cT4hyRn7tI8zEWcTgp3Kl1GQjhpfuhNKxOQBiCWs6UC++JSjdSb9LBO1kXL2
	srfKn0kDJO1F695M2BsRICaK1KzRG/QETU939ahZxj+/eXLxbP787MXZxbNv
	qGWU7RaFezffwoEPc9Z5MN9T4LKc0fEC7neq5Z1W1ILWZ9tl6RXiGq2gnSiS
	9aRuwl0NTrkCPkIzmXnqCXEg40cwgp1SGCl0JjFBW8IUNZV3PkyqFaJ67cb1
	lOe6pZPwDf7mhqSl3K0h3d3bBwH2TeseK+2dLj44WZF/6/3yLi1WHqTg46OG
	6dGgdUCPm4f6dVZXie59/prpXT6KI1Kpk5Y4mXWELuVY5lGXvrP6fNRZ3XrF
	QzsoawIl5hXuvJY9SjHoR2h8QqK3anzJv5MKYFb9S5S/9x/rNipS7e/9x7qN
	ilT9e//RbqMwE/knCuH/uo1iipjS/v7XbZS/f7HSNxYNd1b5UMxHDTlUXAtr
	M9XTka/Hsf8lZ8LfBfSIW0mx7uFCvA91zlPaATaPva5XiCmptu9ldWwJKI/T
	tqRgLSp+UM1F1a2gWWQQkhYj4ZtJ1u0LG+xiCViHTO9Mr5LY88UoFBk4N2S+
	CjsX6ZBxQpB5OpPB7kewgCWMpEElVQh2ZnvNSLXGSrufNC3+cLXVGBHm8yeh
	WHZCmsr6TBNcQnjnctxcfpHHaDD4zR6igVPFeBJK3R7kNLc/MnWLBIuFIvBG
	QU/UjlKEKhgrsyNXqZb2+CQ3D7Hk1cRMEo4vd40S4xPTJ4bAElhcm4AfYwaN
	4uqZYoE0D5rQcqYbcHFwitB+7hCbIoSfv09oKnT7U3WPLkXisxrzMvPOX6aS
	hvQu3XbNAaOvBj2S+OZdmoPYaK9GdF1G29Xkmmx10aQG5qYaoNQes26HUBAC
	hjGKV2sbctO1Ei8WQfl4jLCM2ZbRdvdbamzHyJaapOgd07o8a4pJQRyyGS6v
	n8pEHzPc28IPijPh+S9ujZMwPDOix/H0sRam2LeYgFVzkbWvq1DGlUcJCRfO
	CzEPTkHYRnGRhUkQpFcS+AzHawJfjE8jjpkYTsX1O4k7fpbjD0LYHsr60C3j
	XgEGfQXzIcKcU6l0l2COy8pAP33NIrijiMIsisDEYYpUYl32GZGVSgREuE3Q
	/SaYRwbRT80YnnfZp/B/lv8rMp7BNeBmA7YJXjy3GebBNuNWhF6KZX0PMZqw
	l13uhOxKc4+exkglNgcprYR1Ls728zWEfSabxpeXesAczP4k8CpM2vsDa2Hh
	j0ltZjbpxiAxSw8gn/ddcCn2LK7etEh0S4bwxVou3DlFnvVV3JQrd9MamF/M
	iHpc3H/4oDCwvS228sWiCY2h+hCi3EYsTF65oPgEZRUm77Ga5Aref/SgwLZq
	MBXfR9zmLpkG7QmkDEiS6rr0+YMEHbavl9IS7Jt4whd+wnC+MQRx6IxIAdTQ
	xY7QdRinQpu3WSy3OB2pd/68TaWCqVKwOisJcOTzoZQu4KIF8v2Uqkd7U/hr
	YW0iHHvzTq7nUs8W8CtnKr+ZbFQaprW+7MeTfKWpI3fmyH16qjWEBTY7LewK
	+Yf0FmT0ThvIV/GqgPki8YC1hcWMo8i0T/mE67CpL2veX3oEq/pJiyJVL0D3
	X5jKrgkAztA1aOTINZdb8oHdFW4HzE6UHe36mCxaSRaHI+YFWhTs5XQOglCR
	bkvvkW4oOZBuFAkfllhe0nqYiBgPzccUVALNCkLGFA+05q0pznmAuDwNcy7e
	umrHXWiHKqqP1IvPRSk0UaOES2xcdQPyzAvSsJ4Pw4caJx2q5PsqxspN9i3c
	BsXYwLYhV4eyWxWTnKjtQstr/hJxYp01cKgVljT3GLNO8EIjbHSwFmptDG8w
	0rVBhiBS6mUCSX9VYlKqi2hecsUVkbZv1wPCtM88YDtnOGuNm5hOnVjfQFrN
	siaaUytRYFJ7RIWqItCI5GZrG0tgPo6HzYK5y83KYuJpZ92btnsboBm19Neg
	FeopeW2G7pod9iwISfVtByhALCJZVe16LVWp5ZC91boFcWm9uIf1XJzwOdKW
	btAM3WO708C+YCbMRmBVK1RV8XEF4feo4wEv1Lc3Q5rxvY4nqIYrnjBD6bAj
	oGIBla/0/a7coV7n29lgo52rDZsvCPKHNMuCHDN6m16uToRMryKeUI9MFgup
	aj4A4ovDI9YF+wV0wu2DJgkmFoF6u1e+L5Bgxpdj6TAziAh4wDfkxA+8KGyr
	SAT+WHDkBZ0ogrbMNQ7z6PomVOrRzMqEg2jdHNdLy+b4RsAUoQQrol1TEm/n
	uFsMXRWuUCAgwbXoIpMNIkA3eRrpO4goEX0AGsmTIpHZFJAbNxywjROL++Ge
	+QKd/gHaC5MqIQGwcEIwujY9mI1iN1MMecm6F08SVbt4ugURKtWBIgOzU1pg
	y5ynz15evHny/Ozfn1ycvXpJ8UbgiLiYTbmbl9ct8Rtu6t5UoHPHm2GUbDdV
	lo4Hr1hjyuVWqf7BFdDzHnu3btrtCuHYkD4axhtlEFKtQ/SODc6gDkBiN5Jp
	t+I6YrtaSudfU6dv9eIoCpg/Iyo5mDgOj2yMpdtLkFJiCQvGktYwU+1Qy/i/
	f64uP9Wwlzo9n4SQFobEJ8+ed8wLhUH6kwFL3KmT2nnwbrlj0Y7CAtmfhpVO
	emhslWk7D3vvAtTmurox8cvYWax1oKRtc4nUyuNBaZIXgxeXxV8PbUfAXNz6
	S/LVZwFXlai4kfupUqExDnz2KTIdhUBltOqegZ9ZE0/M/4BdgfOmlhckTlri
	VofGV//3wBGXprbGcofowoBtqic2MkwVgInVWSCSa2pQpVUewRgl/4n0RlnH
	2qt48ZpfmnC5oDko2CE3aA5dgtZrFJkUoUWXdo/bHirpuOkTYc6uE3yzcKtN
	ozoP6gkKgE5iO6lqowkbeuIYipfIMXpJyIdSEfRTjX7QchJxjQoXiKxvWnZ8
	cE95J+OI1+XWxx/9HkTY118SLub+ayCjLQv0kzkxqL8CWVQ2IyUu4qK2IOQ5
	ummNW7cNmQ0ysG2k2lvEiTiBBo1PZAI6AyIf5n0qfe5hLfi9ADRRbICRiF+9
	36HHquOXUOtvRGlvKacjUewUaiStwIrhRvJU4gQZEHadqnzbLrQeZ9hzDbEx
	tDByJ3KxMxIKxQyo1Rpi+hkA21GNL/rgqzWljlOts4EpJqdZPC9J8rbYxeRo
	Tat0A9gutu+KfOXcVjCDSVs88ZibwTF8asw+9Cz3vm/1xpnetH8myI+bgLDO
	QGGNhV+2zl0mH/1yRUBcXNJND4aLl8llV/BSX/9JnkusUfdPxecshnvUX5SZ
	ofA61mRN/ruvz8s1VGIFV7tWVwxKJgOJHGTvW1d461Gxz7BQSQ03uiUGcVKk
	Jit3r5UQyUd0PAkjPA8cHatqp0vDPYhuAutmQCUV1wxu3ZVvt6HXJ7j5P+3j
	neF6Xs0yo7SxspH2d4SBGvy0cuNZ1pWrVfiLnWbh0fo9hhkC6FLUDcfzre9Q
	u2QrCA8I/y5P/+XhX1gA/eWLvwSTnbp4UPPXle8iS7vig4gMxg4cgEIWwaCi
	JHJGcy2ugJ/i1UaTXrDitwKWPPjmeCTCVVu4L8yEQXRa8udKVKQYyu6KvHsP
	xHqK0vussiXGOOqetNQMBOmhTzoroMZE6DQMTumvkxhxO07cYscQjTafF1pg
	G2KEuEcp0J7FwCfri7MHItB7u/OalwaqaQrOapIihLtHYbWRo8b7JxwDu5Tb
	Use214tZu1b6j5p1XcRWkELHhs0kxQRfPrDfaFzDHzpc+UboFiU/MrgypxXe
	uam2+56/T4whRS2IQGDH9TnjBA24MDAfguhp3aUXWWa9GjNIlxvX12s+pt1K
	l2xl8QL9CWz6stdPslvLFa4HNQsD+t3yOfGcgBi0yn57lPpP6jZzigk+DcIW
	sQmmgOSRH0ZqoTZMCFIeh7U07RvFWHnqAiiFh/J/bFaUA5Uq7iOg+QMbnAee
	umXJs2BO7eX1xzDoHOqvS5hx4jKf4MxFljO7v4kzF1nO7P4Gzlyc4MzuYzhz
	cZIzu4/mzDG3kGYCuaMPsDge0Y4aiVgdb29Ie6QvUtVVcGwd9itKYR2kqN5S
	mQdyj6LT2l2CD98CMFCjDbXtRqkVuAccFo7fwtp3gCIv1SjxLjvGLaAO5Mw9
	MmBvB+9RJJMixWvLXSJZuma9raiZDC1PLz1nlUdtRXWWm2pFkMAqEFBPnKMV
	4hvRv6Wsc21MEbNu+5I+lIFS/51yVc3b9dpnnsTsMCqzsO3JmaNq9CRMmE4G
	3ufC+9olPMedMztQITF8tDwut5XnxKwAIF6NtnLhF+IwZknOPS977nFtQqyx
	Q5tr2zTZAP02El7nsPcWL4FQPqoAenESWDFNS9IWoD4nwOYM6aDbrd6/WWGv
	ArdiwLWPOgRYXML2EqMb0ZhuF/hcLya2TgH7q3e2ttLUrMoyBFMFJ4eqvdNQ
	aWwrn6yeCFi1cVqRYxfZptzvuUOV77qsyHdmZ4IN4/eHTA2PoZjYRyFRyCP5
	KIoG5kD4ug+SzBQ28e2MW+y0gfkzmpsTeIgg2gj+/Knl2qMW2LCI1H02SaJW
	b9ueYZblynBC17UCIrrAaGUf1IgDnaEkp9rWuxn1Fd65kdFxLKLiRG8efJKa
	kNQcv9dEBNnDgPCKn0qXtRn2iMiK5NQ+umjzTtLQbUI6KeVUNRE2tjTLihs4
	aX/b0M9IyJ+upOzDXHO2pHcTWASgzUb9sQqjRrlQATL4JrQBqxfB+engsnw9
	TUx1mmrArc5LNfutSkbWiPqAElMeO/1SOODVy/Oz84tnL5/+G8UC6mpYz20B
	EpxkpqmQp4fs+mD4Ex3GkoRSvtUYu+nthaAQ737PJr33knltlbqhYFIbnc1y
	rKrzw9QJL3mKw+IUSUsbuBLZIjApVUUlwD8jUJ+MZn0O1D1/ukEcom2PlXrw
	65J/RS8zKFe9LQvDCE1wBdaU6kzcYysyWT3wTrVWkVm5/tQJkCXl5ml/vusY
	4JEbRHgc4nQbxrlyfGYjX6rvOJfpjxOw/fgAek5wbPs0uwSUQ2r8og/6FpGo
	CVO94NqID8StjToJjLW2NF0+Q41BCgcMZ44lmzwTLTDUxeFNxfncgJHY3vCW
	4EZgnvaleFtB3O5N5ph1NNCxo1O8EIro+YZGiVSwemT4jvIPRjMaATrRBkxk
	KSbOy1A/+glcfslmGwU1VM/ScotVuzxIrEITv7KpcLZbh7f7olSaW5suAAUP
	rPqGd43z+KgTjxPfcQJuhNUCe7EcJrGxpAEZ7q3Mz1EwzkM4IYXyyxC2qufT
	TzTT+VwTR/HFSWhtAjsEH/IlgXIpMUOjoFO3rZYUUotiAaxT1NoeApVnDkID
	uYG1jyEnq615MXWmYTP00ll/6olOC0XSWqSIGvD6vF+XyK8oqNmiStVn49g7
	wqffaQYVNuegYBTzUunvgKBrsOHvPtm0ZYd39kOmX6XPyBvVF9jcJ1UMuZHf
	csPZJY5CpASRRw/LzW8ymd00m8rDMqJvSVfhV3V51DJQX66jTCtqkRWqu+O/
	27IeEux4A6x46hNbBXWPDTqTqJMJKg2E81Xd6DSxfWXWcuSE46SfbFQ8FUAo
	IwgVtko7xnmGhVK/SbRxl9H+aBtxYncYNS8PTHKpvhOnEoNNiHVWq9CdAVia
	JHBRKhMu6G1V7WmDydeSQMCUEvOrdsHrhB1X65Z2iTbcB7LiOY+xjtcavyKe
	G6RNH5UwSc5zvBJ0jsBepl0CfdYQG6yqPDluuKO32Jy2wLpxz4ONgWemhIW+
	neMLYKr39I44Vi4W92Jrz+eX8p9nHJi3sfw4ZM72IJ+qpCPy+ljONoXHTdpp
	7mccjQjwmrX0cXMGUVrVKm9RfkozQ/Knojl22noIVJwrHr85DLUNrYNhF0Pf
	KasDWtHdUdUrLolxWWk6kTp6lyz9GTkMyrEqNCUQkEcRT+FGfKP5Kki3ZO/7
	cxOZkxuSccLrZUVZbMG+Vebj0kEyYL9v8Iy8xz2UUUjiRgQZb3EffZrTTFRs
	YGS0PGOwSTIWro40kbMnL5+MtZC6bMqRBrLBxqgtP1Fy4BGxv0GqXsJwONiT
	JfZ8gYvBDoOeTV1O39WbTh15yTgum7fFsw7U3e9r0MbQX3i+bIeh+A5IBD5+
	S1Gji3a3Q8F22B5n7ummg91r97gLr2EV+IU/VM2PJSju8PDmBgj151nxAum1
	Aeu93dEY5wP11P7XcruqfmZ8VgoNescmzk5EfyRK/yz5m38EbWev7bmOtKco
	V/3zDN8g4QDdr4X7/5LUI4939AAA
	</rfc>		</rfc>
End of changes. 180 change blocks.
	897 lines changed or deleted		364 lines changed or added
This html diff was produced by rfcdiff 1.48.