rfc9577.original.xml   rfc9577.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. 2) --> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.11 (Ruby 3.1. 2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-privacypass-auth-scheme-15" category="std" consensus="true" tocInclude="tr <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
ue" sortRefs="true" symRefs="true" version="3"> -ietf-privacypass-auth-scheme-15" number="9577" submissionType="IETF" category="
std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="
" obsoletes="" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.12.10 --> <!-- xml2rfc v2v3 conversion 3.12.10 -->
<front> <front>
<title abbrev="Privacy Pass Authentication">The Privacy Pass HTTP Authentica tion Scheme</title> <title abbrev="Privacy Pass Authentication">The Privacy Pass HTTP Authentica tion Scheme</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-auth-scheme- 15"/> <seriesInfo name="RFC" value="9577"/>
<author initials="T." surname="Pauly" fullname="Tommy Pauly"> <author initials="T." surname="Pauly" fullname="Tommy Pauly">
<organization>Apple Inc.</organization> <organization>Apple Inc.</organization>
<address> <address>
<postal> <postal>
<street>One Apple Park Way</street> <street>One Apple Park Way</street>
<city>Cupertino, California 95014</city> <city>Cupertino</city>
<country>United States of America</country> <region>California</region>
<code>95014</code>
<country>United States of America</country>
</postal> </postal>
<email>tpauly@apple.com</email> <email>tpauly@apple.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Valdez" fullname="Steven Valdez"> <author initials="S." surname="Valdez" fullname="Steven Valdez">
<organization>Google LLC</organization> <organization>Google LLC</organization>
<address> <address>
<email>svaldez@chromium.org</email> <email>svaldez@chromium.org</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>
<email>caw@heapingbits.net</email> <email>caw@heapingbits.net</email>
</address> </address>
</author> </author>
<date year="2023" month="October" day="23"/> <date year="2024" month="May"/>
<area>sec</area>
<workgroup>privacypass</workgroup>
<keyword>anonymous</keyword> <keyword>anonymous</keyword>
<keyword>authorization</keyword> <keyword>authorization</keyword>
<keyword>crypto</keyword> <keyword>crypto</keyword>
<abstract> <abstract>
<t>This document defines an HTTP authentication scheme for Privacy Pass, <t>This document defines an HTTP authentication scheme for Privacy Pass,
a privacy-preserving authentication mechanism used for authorization. a privacy-preserving authentication mechanism used for authorization.
The authentication scheme in this document can be used by clients The authentication scheme specified in this document can be used by Clients
to redeem Privacy Pass tokens with an origin. It can also be used by to redeem Privacy Pass tokens with an Origin. It can also be used by
origins to challenge clients to present Privacy Pass tokens.</t> Origins to challenge Clients to present Privacy Pass tokens.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Privacy Pass tokens are unlinkable authenticators that can be used to <t>Privacy Pass tokens are unlinkable authenticators that can be used to
anonymously authorize a client (see anonymously authorize a Client (see
<xref target="ARCHITECTURE"/>). <xref target="RFC9576"/>).
Tokens are generated by token issuers, on the basis of authentication, Tokens are generated by token Issuers, on the basis of authentication,
attestation, or some previous action such as solving a CAPTCHA. A client attestation, or some previous action such as solving a CAPTCHA. A Client
possessing such a token is able to prove that it was able to get a token possessing such a token is able to prove that it was able to get a token
issued, without allowing the relying party redeeming the client's token issued, without allowing the relying party redeeming the Client's token
(the origin) to link it with the issuance flow.</t> (the Origin) to link it with the issuance flow.</t>
<t>Different types of authenticators, using different token issuance proto cols, <t>Different types of authenticators, using different token issuance proto cols,
can be used as Privacy Pass tokens.</t> can be used as Privacy Pass tokens.</t>
<t>This document defines a common HTTP authentication scheme <t>This document defines a common HTTP authentication scheme
(<xref section="11" sectionFormat="comma" target="RFC9110"/>), PrivateToken, tha t allows clients to redeem various (<xref section="11" sectionFormat="comma" target="RFC9110"/>), "PrivateToken", t hat allows Clients to redeem various
kinds of Privacy Pass tokens.</t> kinds of Privacy Pass tokens.</t>
<t>Clients and relying parties (origins) interact using this scheme to per <t>Clients and relying parties (Origins) interact using this scheme to per
form the form the
token challenge and token redemption flow. In particular, origins challenge token challenge and token redemption flow. In particular, Origins challenge
clients for a token with an HTTP Authentication challenge (using the Clients for a token with an HTTP authentication challenge (using the
WWW-Authenticate response header field). Clients can then react to that WWW-Authenticate response header field). Clients can then react to that
challenge by issuing a new request with a corresponding token (using the Authori zation challenge by issuing a new request with a corresponding token (using the Authori zation
request header field). Clients generate tokens that match the origin's token request header field). Clients generate tokens that match the Origin's token
challenge by running the token issuance protocol challenge by running one of the token issuance protocols defined in
<xref target="ISSUANCE"/>. The act of presenting a token in an <xref target="RFC9578"/>. The act of presenting a token in an
Authorization request header field is referred to as token redemption. This Authorization request header field is referred to as "token redemption". This
interaction between client and origin is shown below.</t> interaction between the Client and Origin is shown below.</t>
<!-- Removed height="192" width="456" to see if the SVG will display
correctly in the HTML and PDF outputs. -->
<figure anchor="fig-overview"> <figure anchor="fig-overview">
<name>Challenge and redemption protocol flow</name> <name>Challenge and Redemption Protocol Flow</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="192" width="456" viewBox="0 0 456 192" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" viewBox="0 0 456 192" class="diagram" text-anchor="middle" font-family="mono space" 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,176" fill="none" stroke="black"/> <path d="M 40,64 L 40,176" fill="none" stroke="black"/>
<path d="M 80,32 L 80,64" fill="none" stroke="black"/> <path d="M 80,32 L 80,64" fill="none" stroke="black"/>
<path d="M 328,32 L 328,64" fill="none" stroke="black"/> <path d="M 328,32 L 328,64" fill="none" stroke="black"/>
<path d="M 360,64 L 360,112" fill="none" stroke="black"/> <path d="M 360,64 L 360,112" fill="none" stroke="black"/>
<path d="M 360,144 L 360,176" fill="none" stroke="black"/> <path d="M 360,144 L 360,176" fill="none" stroke="black"/>
<path d="M 400,32 L 400,64" fill="none" stroke="black"/> <path d="M 400,32 L 400,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 328,32 L 400,32" fill="none" stroke="black"/> <path d="M 328,32 L 400,32" fill="none" stroke="black"/>
<path d="M 8,64 L 80,64" fill="none" stroke="black"/> <path d="M 8,64 L 80,64" fill="none" stroke="black"/>
skipping to change at line 106 skipping to change at line 117
<polygon class="arrowhead" points="56,160 44,154.4 44,165.6" fill= "black" transform="rotate(180,48,160)"/> <polygon class="arrowhead" points="56,160 44,154.4 44,165.6" fill= "black" transform="rotate(180,48,160)"/>
<g class="text"> <g class="text">
<text x="44" y="52">Origin</text> <text x="44" y="52">Origin</text>
<text x="364" y="52">Client</text> <text x="364" y="52">Client</text>
<text x="136" y="100">WWW-Authenticate:</text> <text x="136" y="100">WWW-Authenticate:</text>
<text x="268" y="100">TokenChallenge</text> <text x="268" y="100">TokenChallenge</text>
<text x="284" y="132">(Run</text> <text x="284" y="132">(Run</text>
<text x="340" y="132">issuance</text> <text x="340" y="132">issuance</text>
<text x="416" y="132">protocol)</text> <text x="416" y="132">protocol)</text>
<text x="164" y="164">Authorization:</text> <text x="164" y="164">Authorization:</text>
<text x="248" y="164">Token</text> <text x="248" y="164">token</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
+--------+ +--------+ +--------+ +--------+
| Origin | | Client | | Origin | | Client |
+---+----+ +---+----+ +---+----+ +---+----+
| | | |
+-- WWW-Authenticate: TokenChallenge -->| +-- WWW-Authenticate: TokenChallenge -->|
| | | |
| (Run issuance protocol) | (Run issuance protocol)
| | | |
|<------ Authorization: Token ----------+ |<------ Authorization: token ----------+
| | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In addition to working with different token issuance protocols, this sc heme <t>In addition to working with different token issuance protocols, this sc heme
optionally supports use of tokens that are associated with origin-chosen optionally supports the use of tokens that are associated with Origin-chosen
contexts and specific origin names. Relying parties that request and redeem contexts and specific Origin names. Relying parties that request and redeem
tokens can choose a specific kind of token, as appropriate for its use case. tokens can choose a specific kind of token, as appropriate for its use case.
These options allow for different deployment models to prevent double-spending, These options (1) allow for different deployment models to prevent double-spendi
and allow for both interactive (online challenges) and non-interactive ng and (2) allow for both interactive (online challenges) and non-interactive (p
(pre-fetched) tokens.</t> re-fetched) tokens.</t>
<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>Unless otherwise specified, this document encodes protocol messages i n TLS <t>Unless otherwise specified, this document encodes protocol messages i n TLS
notation from <xref target="TLS13"/>, Section 3.</t> notation from
<t>This document uses the terms "Client", "Origin", "Issuer", "Issuance <xref target="RFC8446" sectionFormat="comma" section="3"/>.</t>
Protocol", <t>This document uses the terms "Client", "Origin", "Issuer", "issuance
and "Token" as defined in <xref target="ARCHITECTURE"/>. It additionally protocol",
and "Token" as defined in <xref target="RFC9576"/>. It additionally
uses the following terms in more specific ways:</t> uses the following terms in more specific ways:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>Issuer key: Keying material that can be used with an issuance prot <dt>Issuer key:</dt><dd>Keying material that can be used with an issua
ocol nce protocol
to create a signed token.</li> to create a signed token.</dd>
<li>Token challenge: A request for tokens sent from an origin to a cli <dt>Token challenge:</dt><dd>A request for tokens sent from an Origin
ent, using to a Client, using
the "WWW-Authenticate" HTTP header field. This challenge identifies a specific the "WWW-Authenticate" HTTP header field. This challenge identifies a specific
token issuer and issuance protocol. Token challenges optionally include token Issuer and issuance protocol. Token challenges optionally include
one or both of: a redemption context (see <xref target="context-construction"/>) one or both of the following: a redemption context (see <xref target="context-co
, and nstruction"/>) and
a list of associated origins. These optional values are then a list of associated Origins. These optional values can then
be bound to the token that is issued.</li> be bound to the token that is issued.</dd>
<li>Token redemption: An action by which a client presents a token to <dt>Token redemption:</dt><dd>An action by which a Client presents a t
an origin oken to an Origin
in an HTTP request, using the "Authorization" HTTP header field.</li> in an HTTP request, using the "Authorization" HTTP header field.</dd>
</ul> </dl>
</section> </section>
</section> </section>
<section anchor="challenge-redemption"> <section anchor="challenge-redemption">
<name>HTTP Authentication Scheme</name> <name>HTTP Authentication Scheme</name>
<t>Token redemption is performed using HTTP Authentication <t>Token redemption is performed using HTTP authentication
(<xref section="11" sectionFormat="comma" target="RFC9110"/>), with the scheme " PrivateToken". Origins challenge (<xref section="11" sectionFormat="comma" target="RFC9110"/>), with the scheme " PrivateToken". Origins challenge
clients to present a token from a specific issuer (<xref target="challenge"/>). Clients to present a token from a specific Issuer (<xref target="challenge"/>).
Once a Once a
client has received a token from that issuer, or already has a valid token Client has received a token from that Issuer or already has a valid token
available, it presents the token to the origin (<xref target="redemption"/>). Th available, it presents the token to the Origin (<xref target="redemption"/>). Th
e process of e process of
presenting a token as authentication to an origin is also referred to presenting a token as authentication to an Origin is also referred to
as "spending" a token.</t> as "spending" a token.</t>
<t>In order to prevent linkability across different transactions, clients <t>In order to prevent linkability across different transactions, Clients
will often present a particular "PrivateToken" only once. Origins can link multi ple will often present a particular "PrivateToken" only once. Origins can link multi ple
transactions to the same client if that client spends the same token value more transactions to the same Client if that Client spends the same token value more
than once. As such, origins ought to expect at most one unique token than once. As such, Origins ought to expect at most one unique token
value, carried in one request, for each challenge.</t> value, carried in one request, for each challenge.</t>
<t>The rest of this section describes the token challenge and redemption i nteractions <t>The rest of this section describes the token challenge and redemption i nteractions
in more detail.</t> in more detail.</t>
<section anchor="challenge"> <section anchor="challenge">
<name>Token Challenge</name> <name>Token Challenge</name>
<t>Origins send a token challenge to clients in an "WWW-Authenticate" he ader field <t>Origins send a token challenge to Clients in a "WWW-Authenticate" hea der field
with the "PrivateToken" scheme. This authentication scheme has two mandatory par ameters: with the "PrivateToken" scheme. This authentication scheme has two mandatory par ameters:
one containing a token challenge and another containing the token-key used for one containing a token challenge and another containing the token-key used for
producing (and verifying) a corresponding token.</t> producing (and verifying) a corresponding token.</t>
<t>Origins that support the "PrivateToken" authentication scheme need to handle <t>Origins that support the "PrivateToken" authentication scheme need to handle
the following tasks in constructing the WWW-Authenticate header field:</t> the following tasks in constructing the WWW-Authenticate header field:</t>
<ol spacing="normal" type="1"><li>Select which issuer to use, and config <ol spacing="normal" type="1"><li>Select which Issuer to use, and config
ure the issuer name and token-key to ure the Issuer name and token-key to
include in WWW-Authenticate token challenges. The issuer name is included in include in WWW-Authenticate token challenges. The Issuer name is included in
the token challenge, and the issuer token-key is used to populate the the token challenge, and the Issuer token-key is used to populate the
WWW-Authenticate header parameter.</li> WWW-Authenticate header parameter.</li>
<li>Determine a redemption context construction to include in the <li>Determine a redemption context construction to include in the
token challenge, as discussed in <xref target="context-construction"/>.</li> token challenge, as discussed in <xref target="context-construction"/>.</li>
<li>Select the origin information to include in the token challenge. T <li>Select the Origin information to include in the token challenge. T
his can his can
be empty to allow fully cross-origin tokens, a single origin name that be empty to allow fully cross-Origin tokens, a single Origin name that
matches the origin itself for per-origin tokens, or a list of origin names matches the Origin itself for per-Origin tokens, or a list of Origin names
containing the origin itself. See <xref section="3.4" sectionFormat="of" target= containing the Origin itself. See <xref section="3.4" sectionFormat="of" target=
"ARCHITECTURE"/> for more "RFC9576"/> for more
information about the difference between cross-origin and per-origin tokens.</li information about the difference between cross-Origin and per-Origin tokens.</li
> >
</ol> </ol>
<t>Once these decisions are made, origins construct the WWW-Authenticate header <t>Once these decisions are made, Origins construct the WWW-Authenticate header
by first constructing the token challenge as described in <xref target="challeng e-structure"/>. by first constructing the token challenge as described in <xref target="challeng e-structure"/>.
Origins send challenges as described in <xref target="send-challenge"/>, and cli Origins send challenges as described in <xref target="send-challenge"/>, and Cli
ents process ents process
them as described in <xref target="process-challenge"/> and <xref target="cachin them as described in Sections&nbsp;<xref target="process-challenge" format="coun
g"/>.</t> ter"/> and <xref target="caching" format="counter"/>.</t>
<section anchor="challenge-structure"> <section anchor="challenge-structure">
<name>Token Challenge Structure</name> <name>Token Challenge Structure</name>
<t>This document defines the default challenge structure that can be u sed across <t>This document defines the default challenge structure that can be u sed across
token types, although future token types MAY extend or modify the structure token types, although future token types <bcp14>MAY</bcp14> extend or modify the structure
of the challenge; see <xref target="token-types"/> for the registry information of the challenge; see <xref target="token-types"/> for the registry information
which establishes and defines the relationship between "token_type" and the that establishes and defines the relationship between "token_type" and the
contents of the TokenChallenge message.</t> contents of the TokenChallenge message.</t>
<t>All token challenges MUST begin with a 2-octet integer that defines the <t>All token challenges <bcp14>MUST</bcp14> begin with a 2-octet integ er that defines the
token type, in network byte order. This type indicates the issuance protocol token type, in network byte order. This type indicates the issuance protocol
used to generate the token and determines the structure and semantics of the res t of used to generate the token and determines the structure and semantics of the res t of
the structure. Values are registered in an IANA registry, <xref target="token-ty pes"/>. Client MUST the structure. Values are registered in an IANA registry; see <xref target="toke n-types"/>. Clients <bcp14>MUST</bcp14>
ignore challenges with token types they do not support.</t> ignore challenges with token types they do not support.</t>
<t>Even when a given token type uses the default challenge structure, <t>Even when a given token type uses the default challenge structure,
the requirements on the presence or interpretation of the fields can differ the requirements on the presence or interpretation of the fields can differ
across token types. For example, some token types might require that "origin_inf o" across token types. For example, some token types might require that "origin_inf o"
is non-empty, while others allow it to be empty.</t> is non-empty, while others allow it to be empty.</t>
<t>The default TokenChallenge message has the following structure:</t> <t>The default TokenChallenge message has the following structure:</t>
<artwork><![CDATA[ <artwork><![CDATA[
struct { struct {
uint16_t token_type; uint16_t token_type;
opaque issuer_name<1..2^16-1>; opaque issuer_name<1..2^16-1>;
opaque redemption_context<0..32>; opaque redemption_context<0..32>;
opaque origin_info<0..2^16-1>; opaque origin_info<0..2^16-1>;
} TokenChallenge; } TokenChallenge;
]]></artwork> ]]></artwork>
<t>The structure fields are defined as follows:</t> <t>The structure fields are defined as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>"token_type" is a 2-octet integer, in network byte order, as des cribed <li>"token_type" is a 2-octet integer, in network byte order, as des cribed
above.</li> above.</li>
<li>"issuer_name" is an ASCII string that identifies the issuer usin <li>"issuer_name" is an ASCII string that identifies the Issuer, usi
g the format of a ng the format of a
server name defined in <xref target="server-name"/>. This name identifies the is server name as defined in <xref target="server-name"/>. This name identifies the
suer that is allowed to Issuer that is allowed to
issue tokens that can be redeemed by this origin. The field that stores this str issue tokens that can be redeemed by this Origin. The field that stores this str
ing in the challenge ing in the challenge
is prefixed with a 2-octet integer indicating the length, in network byte order. </li> is prefixed with a 2-octet integer indicating the length, in network byte order. </li>
<li>"redemption_context" is a field that is either 0 or 32 bytes, pr efixed with a single <li>"redemption_context" is a field that is either 0 or 32 bytes, pr efixed with a single
octet indicating the length (either 0 or 32). If value is non-empty, it is a 32- octet indicating the length (either 0 or 32). If the value is non-empty, it is a
byte value 32-byte value
generated by the origin that allows the origin to require that clients fetch tok generated by the Origin that allows the Origin to require that Clients fetch tok
ens ens
bound to a specific context, as opposed to reusing tokens that were fetched for other bound to a specific context, as opposed to reusing tokens that were fetched for other
contexts. See <xref target="context-construction"/> for example contexts that mi ght be useful in contexts. See <xref target="context-construction"/> for example contexts that mi ght be useful in
practice. Challenges with redemption_context values of invalid lengths MUST be i practice. Challenges with redemption_context values of invalid lengths <bcp14>MU
gnored.</li> ST</bcp14> be ignored.</li>
<li>"origin_info" is an ASCII string that is either empty, or contai <li>"origin_info" is an ASCII string that either is empty or contain
ns one or more s one or more
origin names that allow a token to be scoped to a specific set of origins. Each Origin names that allow a token to be scoped to a specific set of Origins. Each
origin name uses the format of a server name defined in <xref target="server-nam Origin name uses the format of a server name as defined in <xref target="server-
e"/>. The string name"/>. The string
is prefixed with a 2-octet integer indicating the length, in network byte order. is prefixed with a 2-octet integer indicating the length, in network byte order.
If empty, any non-origin-specific token can be redeemed. If the string contains If empty, any non-Origin-specific token can be redeemed. If the string contains
multiple origin names, they are delimited with commas "," without any whitespace multiple Origin names, they are delimited with commas (",") without any whitespa
. ce.
If this field is not empty, the Origin MUST include its own name as one of the If this field is not empty, the Origin <bcp14>MUST</bcp14> include its own name
as one of the
names in the list.</li> names in the list.</li>
</ul> </ul>
<t>If "origin_info" contains multiple origin names, this means the cha <t>If "origin_info" contains multiple Origin names, this means the cha
llenge is valid llenge is valid
for any of the origins in the list, including the origin which issued the challe for any of the Origins in the list, including the Origin that issued the challen
nge ge
(which must always be present in the list if it is non-empty; see <xref target=" process-challenge"/>). (which must always be present in the list if it is non-empty; see <xref target=" process-challenge"/>).
This can be useful in settings where clients pre-fetch and cache tokens for a pa rticular This can be useful in settings where Clients pre-fetch and cache tokens for a pa rticular
challenge -- including the "origin_info" field -- and then later redeem these to kens challenge -- including the "origin_info" field -- and then later redeem these to kens
with one of the origins in the list. See <xref target="caching"/> for more discu ssion about with one of the Origins in the list. See <xref target="caching"/> for more discu ssion about
token caching.</t> token caching.</t>
<section anchor="server-name"> <section anchor="server-name">
<name>Server Name Encoding</name> <name>Server Name Encoding</name>
<t>Server names contained in a token challenge are ASCII strings tha t contain a hostname <t>Server names contained in a token challenge are ASCII strings tha t contain a hostname
and optional port, where the port is implied to be "443" if missing. The names u se the and optional port, where the port is implied to be "443" if missing. The names u se the
format of the authority portion of a URI as defined in <xref section="3.2" secti format of the authority portion of a URI as defined in <xref section="3.2" secti
onFormat="of" target="URI"/>. onFormat="of" target="RFC3986"/>.
The names MUST NOT include a "userinfo" portion of an authority. For example, a The names <bcp14>MUST NOT</bcp14> include a "userinfo" portion of an authority.
valid For example, a valid
server name might be "issuer.example.com" or "issuer.example.com:8443", server name might be "issuer.example.com" or "issuer.example.com:8443",
but not "issuer@example.com".</t> but not "issuer@example.com".</t>
</section> </section>
<section anchor="context-construction"> <section anchor="context-construction">
<name>Redemption Context Construction</name> <name>Redemption Context Construction</name>
<t>The TokenChallenge redemption context allows the origin to determ ine the <t>The TokenChallenge redemption context allows the Origin to determ ine the
context in which a given token can be redeemed. This value can be a unique context in which a given token can be redeemed. This value can be a unique
per-request nonce, constructed from 32 freshly generated random bytes. It per-request nonce, constructed from 32 freshly generated random bytes. It
can also represent state or properties of the client session. Some example can also represent state or properties of the Client session. Some example
properties and methods for constructing the corresponding context are below. properties and methods for constructing the corresponding context are below.
This list is not exhaustive.</t> This list is not exhaustive.</t>
<ul spacing="normal"> <dl spacing="normal">
<li>Context bound to a given time window: Construct redemption con <dt>Context bound to a given time window:</dt><dd>Construct the re
text as demption context as
F(current time window), where F is a pseudorandom function.</li> F(current time window), where F is a pseudorandom function.</dd>
<li>Context bound to a client network: Construct redemption contex <dt>Context bound to a Client network based on Autonomous System N
t as umber (ASN):</dt><dd>Construct the redemption context as
F(client ASN), where F is a pseudorandom function.</li> F(Client ASN), where F is a pseudorandom function.</dd>
<li>Context bound to a given time window and client network: Const <dt>Context bound to a given time window and Client network:</dt><
ruct redemption dd>Construct the redemption
context as F(current time window, client ASN), where F is a pseudorandom functio context as F(current time window, Client ASN), where F is a pseudorandom functio
n.</li> n.</dd>
</ul> </dl>
<t>Preventing double spending on tokens requires the origin to keep <t>Preventing double-spending on tokens requires the Origin to keep
state state
associated with the redemption context. An empty redemption context is not associated with the redemption context. An empty redemption context is not
bound to any property of the client request, so state to prevent double spending bound to any property of the Client request, so state to prevent double-spending
needs to be stored and shared across all origin servers that can accept tokens u needs to be stored and shared across all Origin servers that can accept tokens u
ntil ntil
token-key expiration or rotation. For a non-empty redemption context, the token-key expiration or rotation. For a non-empty redemption context, the
double spend state only needs to be stored across the set of origin servers that will double-spend state only needs to be stored across the set of Origin servers that will
accept tokens with that redemption context.</t> accept tokens with that redemption context.</t>
<t>Origins that share redemption contexts, i.e., by using the same r edemption <t>Origins that share redemption contexts, i.e., by using the same r edemption
context, choosing the same issuer, and providing the same origin_info field in context, choosing the same Issuer, and providing the same origin_info field in
the TokenChallenge, must necessarily share state required to enforce double the TokenChallenge, must necessarily share state required to enforce
spend prevention. Origins should consider the operational complexity of this double-spend prevention. Origins should consider the operational complexity of t
his
shared state before choosing to share redemption contexts. Failure to shared state before choosing to share redemption contexts. Failure to
successfully synchronize this state and use it for double spend prevention can successfully synchronize this state and use it for double-spend prevention can
allow Clients to redeem tokens to one Origin that were issued after an allow Clients to redeem tokens to one Origin that were issued after an
interaction with another Origin that shares the context.</t> interaction with another Origin that shares the context.</t>
</section> </section>
</section> </section>
<section anchor="send-challenge"> <section anchor="send-challenge">
<name>Sending Token Challenges</name> <name>Sending Token Challenges</name>
<t>When used in an authentication challenge, the "PrivateToken" scheme uses the <t>When used in an authentication challenge, the "PrivateToken" scheme uses the
following parameters:</t> following parameters:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>"challenge", which contains a base64url-encoded <xref target="RF <li>"challenge", which contains a base64url TokenChallenge value, en
C4648"/> TokenChallenge coded per <xref target="RFC4648"/>. This document follows the default padding be
value. This document follows the default padding behavior described in havior described in
<xref section="3.2" sectionFormat="of" target="RFC4648"/>, so the base64url valu <xref section="3.2" sectionFormat="of" target="RFC4648"/>, so the base64url valu
e MUST include padding. e <bcp14>MUST</bcp14> include padding.
As an Authentication Parameter (<tt>auth-param</tt> from <xref section="11.2" se As an authentication parameter (<tt>auth-param</tt> from <xref section="11.2" se
ctionFormat="comma" target="RFC9110"/>), ctionFormat="comma" target="RFC9110"/>),
the value can be either a token or a quoted-string, and might be required to the value can be either a token or a quoted-string and might be required to
be a quoted-string if the base64url string includes "=" characters. This be a quoted-string if the base64url string includes "=" characters. This
parameter is required for all challenges.</li> parameter is required for all challenges.</li>
<li>"token-key", which contains a base64url encoding of the public k ey for <li>"token-key", which contains a base64url encoding of the public k ey for
use with the issuance protocol indicated by the challenge. See <xref target="ISS UANCE"/> use with the issuance protocol indicated by the challenge. See <xref target="RFC 9578"/>
for more information about how this public key is used by the issuance protocols for more information about how this public key is used by the issuance protocols
in that specification. The encoding of described in that specification. The encoding of
the public key is determined by the token type; see <xref target="token-types"/> . the public key is determined by the token type; see <xref target="token-types"/> .
As with "challenge", the base64url value MUST include padding. As an As with "challenge", the base64url value <bcp14>MUST</bcp14> include padding. As
Authentication Parameter (<tt>auth-param</tt> from <xref section="11.2" sectionF an
ormat="comma" target="RFC9110"/>), the authentication parameter (<tt>auth-param</tt> from <xref section="11.2" sectionF
value can be either a token or a quoted-string, and might be required to be a ormat="comma" target="RFC9110"/>), the
value can be either a token or a quoted-string and might be required to be a
quoted-string if the base64url string includes "=" characters. This parameter quoted-string if the base64url string includes "=" characters. This parameter
MAY be omitted in deployments where clients are able to retrieve the issuer key <bcp14>MAY</bcp14> be omitted in deployments where Clients are able to retrieve the Issuer key
using an out-of-band mechanism.</li> using an out-of-band mechanism.</li>
<li>"max-age", an optional parameter that consists of the number of <li>"max-age", which is an optional parameter that consists of the n
seconds for umber of seconds for
which the challenge will be accepted by the origin.</li> which the challenge will be accepted by the Origin.</li>
</ul> </ul>
<t>The header field MAY also include the standard "realm" parameter, i <t>The header field <bcp14>MAY</bcp14> also include the standard "real
f desired. m" parameter, if desired.
Issuance protocols MAY define other parameters, some of which might be required. Issuance protocols <bcp14>MAY</bcp14> define other parameters, some of which mig
Clients MUST ignore parameters in challenges that are not defined for the issuan ht be required.
ce Clients <bcp14>MUST</bcp14> ignore parameters in challenges that are not defined
for the issuance
protocol corresponding to the token type in the challenge.</t> protocol corresponding to the token type in the challenge.</t>
<t>As an example, the WWW-Authenticate header field could look like th is:</t> <t>As an example, the WWW-Authenticate header field could look like th is:</t>
<artwork><![CDATA[ <artwork><![CDATA[
WWW-Authenticate: WWW-Authenticate:
PrivateToken challenge="abc...", token-key="123..." PrivateToken challenge="abc...", token-key="123..."
]]></artwork> ]]></artwork>
<section anchor="sending-multiple-token-challenges"> <section anchor="sending-multiple-token-challenges">
<name>Sending Multiple Token Challenges</name> <name>Sending Multiple Token Challenges</name>
<t>It is possible for the WWW-Authenticate header field to include m ultiple <t>It is possible for the WWW-Authenticate header field to include m ultiple
challenges (<xref section="11.6.1" sectionFormat="comma" target="RFC9110"/>). Th challenges (<xref section="11.6.1" sectionFormat="comma" target="RFC9110"/>). Th
is allows the origin to indicate is allows the Origin to indicate
support for different token types, issuers, or to include multiple redemption support for different token types or different Issuers, or to include multiple r
edemption
contexts. For example, the WWW-Authenticate header field could look like this:</ t> contexts. For example, the WWW-Authenticate header field could look like this:</ t>
<artwork><![CDATA[ <artwork><![CDATA[
WWW-Authenticate: WWW-Authenticate:
PrivateToken challenge="abc...", token-key="123...", PrivateToken challenge="abc...", token-key="123...",
PrivateToken challenge="def...", token-key="234..." PrivateToken challenge="def...", token-key="234..."
]]></artwork> ]]></artwork>
<t>Origins should only include challenges for different types of iss uance <t>Origins should only include challenges for different types of iss uance
protocols with functionally equivalent properties. For instance, both issuance protocols with functionally equivalent properties. For instance, both issuance
protocols in <xref target="ISSUANCE"/> have the same functional properties, albe it with protocols in <xref target="RFC9578"/> have the same functional properties, albei t with
different mechanisms for verifying the resulting tokens during redemption. different mechanisms for verifying the resulting tokens during redemption.
Since clients are free to choose which challenge they want to consume when Since Clients are free to choose which challenge they want to consume when
presented with options, mixing multiple challenges with different functional presented with options, mixing multiple challenges with different functional
properties for one use case is nonsensical. If the origin has a preference properties for one use case is nonsensical. If the Origin has a preference
for one challenge over another (for example, if one uses a token type for one challenge over another (for example, if one uses a token type
that is faster to verify), it can sort it to be first in the list that is faster to verify), it can sort it to be first in the list
of challenges as a hint to the client.</t> of challenges as a hint to the Client.</t>
</section> </section>
</section> </section>
<section anchor="process-challenge"> <section anchor="process-challenge">
<name>Processing Token Challenges</name> <name>Processing Token Challenges</name>
<t>Upon receipt of a challenge, a client validates the TokenChallenge structure <t>Upon receipt of a challenge, a Client validates the TokenChallenge structure
before taking any action, such as fetching a new token or redeeming a token before taking any action, such as fetching a new token or redeeming a token
in a new request. Validation requirements are as follows:</t> in a new request. Validation requirements are as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The token_type is recognized and supported by the client;</li> <li>The token_type is recognized and supported by the Client;</li>
<li>The TokenChallenge structure is well-formed; and</li> <li>The TokenChallenge structure is well-formed; and</li>
<li>If the origin_info field is non-empty, the name of the origin th <li>If the origin_info field is non-empty, the name of the Origin th
at issued the at issued the
authentication challenge is included in the list of origin names. Comparison authentication challenge is included in the list of Origin names. Comparison
of the origin name that issued the authentication challenge against elements of the Origin name that issued the authentication challenge against elements
in the origin_info list is done via case-insensitive equality checks.</li> in the origin_info list is done via case-insensitive equality checks.</li>
</ul> </ul>
<t>If validation fails, the client MUST NOT fetch or redeem a token ba <t>If validation fails, the Client <bcp14>MUST NOT</bcp14> fetch or re
sed on the deem a token based on the
challenge. Clients MAY have further restrictions and requirements around challenge. Clients <bcp14>MAY</bcp14> have further restrictions and requirements
around
validating when a challenge is considered acceptable or valid. For example, validating when a challenge is considered acceptable or valid. For example,
clients can choose to ignore challenges that list origin names for which the Clients can choose to ignore challenges that list Origin names for which the
current connection is not authoritative (according to the TLS certificate).</t> current connection is not authoritative (according to the TLS certificate).</t>
<t>Caching and pre-fetching of tokens is discussed in <xref target="ca ching"/>.</t> <t>Caching and pre-fetching of tokens are discussed in <xref target="c aching"/>.</t>
</section> </section>
<section anchor="caching"> <section anchor="caching">
<name>Token Caching</name> <name>Token Caching</name>
<t>Clients can generate multiple tokens from a single TokenChallenge, and cache <t>Clients can generate multiple tokens from a single TokenChallenge a nd cache
them for future use. This improves privacy by separating the time of token them for future use. This improves privacy by separating the time of token
issuance from the time of token redemption, and also allows clients to avoid issuance from the time of token redemption, and also allows Clients to avoid
any overhead of receiving new tokens via the issuance protocol.</t> the overhead of receiving new tokens via the issuance protocol.</t>
<t>Cached tokens can only be redeemed when they match all of the field s in the <t>Cached tokens can only be redeemed when they match all of the field s in the
TokenChallenge: token_type, issuer_name, redemption_context, and origin_info. TokenChallenge: token_type, issuer_name, redemption_context, and origin_info.
Clients ought to store cached tokens based on all of these fields, to Clients ought to store cached tokens based on all of these fields, to
avoid trying to redeem a token that does not match. Note that each token avoid trying to redeem a token that does not match. Note that each token
has a unique client nonce, which is sent in token redemption (<xref target="rede has a unique Client nonce, which is sent in token redemption (<xref target="rede
mption"/>).</t> mption"/>).</t>
<t>If a client fetches a batch of multiple tokens for future use that <t>If a Client fetches a batch of multiple tokens for future use that
are bound are bound
to a specific redemption context (the redemption_context in the TokenChallenge to a specific redemption context (the redemption_context in the TokenChallenge
was not empty), clients SHOULD discard these tokens upon flushing state such as was not empty), Clients <bcp14>SHOULD</bcp14> discard these tokens upon flushing
HTTP cookies <xref target="COOKIES"/>, or if there is a network state such as
change and the client does not have any origin-specific state like HTTP cookies. HTTP cookies <xref target="I-D.ietf-httpbis-rfc6265bis"/>, or if there is a netw
ork
change and the Client does not have any Origin-specific state like HTTP cookies.
Using these tokens in a context that otherwise would not be linkable to the Using these tokens in a context that otherwise would not be linkable to the
original context could allow the origin to recognize a client.</t> original context could allow the Origin to recognize a Client.</t>
</section> </section>
</section> </section>
<section anchor="redemption"> <section anchor="redemption">
<name>Token Redemption</name> <name>Token Redemption</name>
<t>The output of the issuance protocol is a token that corresponds to th e origin's <t>The output of the issuance protocol is a token that corresponds to th e Origin's
challenge (see <xref target="challenge"/>).</t> challenge (see <xref target="challenge"/>).</t>
<section anchor="token-structure"> <section anchor="token-structure">
<name>Token Structure</name> <name>Token Structure</name>
<t>A token is a structure that begins with a two-octet field that indi <t>A token is a structure that begins with a 2-octet field that indica
cates a token tes a token
type, which MUST match the token_type in the TokenChallenge structure. This valu type, which <bcp14>MUST</bcp14> match the token_type in the TokenChallenge struc
e ture. This value
determines the structure and semantics of the rest of token structure.</t> determines the structure and semantics of the rest of the token structure.</t>
<t>This document defines the default token structure that can be used across <t>This document defines the default token structure that can be used across
token types, although future token types MAY extend or modify the structure token types, although future token types <bcp14>MAY</bcp14> extend or modify the
of the token; see <xref target="token-types"/> for the registry information whic structure
h of the token; see <xref target="token-types"/> for the registry information that
establishes and defines the relationship between "token_type" and the contents establishes and defines the relationship between "token_type" and the contents
of the Token structure.</t> of the token structure.</t>
<t>The default Token message has the following structure:</t> <t>The default token message has the following structure:</t>
<artwork><![CDATA[ <artwork><![CDATA[
struct { struct {
uint16_t token_type; uint16_t token_type;
uint8_t nonce[32]; uint8_t nonce[32];
uint8_t challenge_digest[32]; uint8_t challenge_digest[32];
uint8_t token_key_id[Nid]; uint8_t token_key_id[Nid];
uint8_t authenticator[Nk]; uint8_t authenticator[Nk];
} Token; } Token;
]]></artwork> ]]></artwork>
<t>The structure fields are defined as follows:</t> <t>The structure fields are defined as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>"token_type" is a 2-octet integer, in network byte order, as des cribed <li>"token_type" is a 2-octet integer, in network byte order, as des cribed
above.</li> above.</li>
<li>"nonce" is a 32-octet value containing a client-generated random nonce.</li> <li>"nonce" is a 32-octet value containing a Client-generated random nonce.</li>
<li>"challenge_digest" is a 32-octet value containing the hash of th e <li>"challenge_digest" is a 32-octet value containing the hash of th e
original TokenChallenge, SHA-256(TokenChallenge), where SHA-256 is as defined original TokenChallenge, SHA-256(TokenChallenge), where SHA-256 is as defined
in <xref target="SHS"/>. Changing the hash function to something in <xref target="SHS"/>. Changing the hash function to something
other than SHA-256 would require defining a new token type and token structure other than SHA-256 would require defining a new token type and token structure
(since the contents of challenge_digest would be computed differently), (since the contents of challenge_digest would be computed differently),
which can be done in a future specification.</li> which can be done in a future specification.</li>
<li>"token_key_id" is a Nid-octet identifier for the token authentic ation <li>"token_key_id" is a Nid-octet identifier for the token authentic ation
key. The value of this field is defined by the token_type and corresponding key. The value of this field is defined by the token_type and corresponding
issuance protocol.</li> issuance protocol.</li>
<li>"authenticator" is a Nk-octet authenticator that is cryptographi cally bound <li>"authenticator" is a Nk-octet authenticator that is cryptographi cally bound
to the preceding fields in the token; see <xref target="verification"/> for more information to the preceding fields in the token; see <xref target="verification"/> for more information
about how this field is used in verifying a token. The token_type and correspond ing about how this field is used in verifying a token. The token_type and correspond ing
issuance protocol determine the value of the authenticator field and how it is c omputed. issuance protocol determine the value of the authenticator field and how it is c omputed.
The value of constant Nk depends on token_type, as defined in <xref target="toke n-types"/>.</li> The value of constant Nk depends on token_type, as defined in <xref target="toke n-types"/>.</li>
</ul> </ul>
<t>The authenticator value in the Token structure is computed over the <t>The authenticator value in the token structure is computed over the
token_type, token_type,
nonce, challenge_digest, and token_key_id fields. A token is considered a valid nonce, challenge_digest, and token_key_id fields. A token is considered valid
if token verification using succeeds; see <xref target="verification"/> for deta if token verification succeeds; see <xref target="verification"/> for details ab
ils about out
verifying the token and its authenticator value.</t> verifying the token and its authenticator value.</t>
</section> </section>
<section anchor="sending-tokens"> <section anchor="sending-tokens">
<name>Sending Tokens</name> <name>Sending Tokens</name>
<t>When used for client authorization, the "PrivateToken" authenticati on <t>When used for Client authorization, the "PrivateToken" authenticati on
scheme defines one parameter, "token", which contains the base64url-encoded scheme defines one parameter, "token", which contains the base64url-encoded
Token struct. As with the challenge parameters (<xref target="challenge"/>), the token structure. As with the challenge parameters (<xref target="challenge"/>),
base64url the base64url
value MUST include padding. As an Authentication Parameter (<tt>auth-param</tt> value <bcp14>MUST</bcp14> include padding. As an authentication parameter (<tt>a
from uth-param</tt> from
<xref section="11.2" sectionFormat="comma" target="RFC9110"/>), the value can be either a token or a <xref section="11.2" sectionFormat="comma" target="RFC9110"/>), the value can be either a token or a
quoted-string, and might be required to be a quoted-string if the base64url quoted-string and might be required to be a quoted-string if the base64url
string includes "=" characters. All unknown or unsupported parameters to string includes "=" characters. All unknown or unsupported parameters to
"PrivateToken" authentication credentials MUST be ignored.</t> "PrivateToken" authentication credentials <bcp14>MUST</bcp14> be ignored.</t>
<t>Clients present this Token structure to origins in a new HTTP reque <t>Clients present this token structure to Origins in a new HTTP reque
st using st using
the Authorization header field as follows:</t> the Authorization header field as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Authorization: PrivateToken token="abc..." Authorization: PrivateToken token="abc..."
]]></artwork> ]]></artwork>
<t>For context-bound tokens, origins store or reconstruct the contexts of previous <t>For context-bound tokens, Origins store or reconstruct the contexts of previous
TokenChallenge structures in order to validate the token. A TokenChallenge can TokenChallenge structures in order to validate the token. A TokenChallenge can
be bound to a specific TLS session with a client, but origins can also accept be bound to a specific TLS session with a Client, but Origins can also accept
tokens for valid challenges in new sessions. Origins SHOULD implement some form tokens for valid challenges in new sessions. Origins <bcp14>SHOULD</bcp14> imple
ment some form
of double-spend prevention that prevents a token with the same nonce from being of double-spend prevention that prevents a token with the same nonce from being
redeemed twice. Double-spend prevention ensures that clients cannot replay token s redeemed twice. Double-spend prevention ensures that Clients cannot replay token s
for previous challenges. See <xref target="replay-attacks"/> for more informatio n about replay for previous challenges. See <xref target="replay-attacks"/> for more informatio n about replay
attacks. For context-bound tokens, this double-spend prevention can require no s tate attacks. For context-bound tokens, this double-spend prevention can require no s tate
or minimal state, since the context can be used to verify token uniqueness.</t> or minimal state, since the context can be used to verify token uniqueness.</t>
</section> </section>
<section anchor="verification"> <section anchor="verification">
<name>Token Verification</name> <name>Token Verification</name>
<t>A token consists of some input cryptographically bound to an authen ticator <t>A token consists of some input cryptographically bound to an authen ticator
value, such as a digital signature. Verifying a token consists of checking that value, such as a digital signature. Verifying a token consists of checking that
the authenticator value is correct.</t> the authenticator value is correct.</t>
<t>The authenticator value is as computed when running and finalizing the issuance <t>The authenticator value is as computed when running and finalizing the issuance
protocol corresponding to the token type with the following value as the input:< /t> protocol corresponding to the token type with the following values as the input: </t>
<artwork><![CDATA[ <artwork><![CDATA[
struct { struct {
uint16_t token_type; uint16_t token_type;
uint8_t nonce[32]; uint8_t nonce[32];
uint8_t challenge_digest[32]; uint8_t challenge_digest[32];
uint8_t token_key_id[Nid]; uint8_t token_key_id[Nid];
} AuthenticatorInput; } AuthenticatorInput;
]]></artwork> ]]></artwork>
<t>The value of these fields are as described in <xref target="redempt <t>The values of these fields are as described in <xref target="token-
ion"/>. The cryptographic structure"/>. The cryptographic
verification check depends on the token type; see <xref section="5.4" sectionFor verification check depends on the token type; see
mat="of" target="ISSUANCE"/> Sections&nbsp;<xref target="RFC9578" section="5.4" sectionFormat="bare"/> and <x
and <xref section="6.4" sectionFormat="of" target="ISSUANCE"/> for verification ref target="RFC9578" section="6.4" sectionFormat="bare"/> of <xref target="RFC95
instructions for the issuance 78"/> for verification instructions for the issuance
protocols described in <xref target="ISSUANCE"/>. As such, the security properti protocols described in that specification. As such, the security properties of t
es of the he
token, e.g., the probability that one can forge an authenticator value without token, e.g., the probability that one can forge an authenticator value without
invoking the issuance protocol, depend on the cryptographic algorithm used by invoking the issuance protocol, depend on the cryptographic algorithm used by
the issuance protocol as determined by the token type.</t> the issuance protocol as determined by the token type.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="client-behavior"> <section anchor="client-behavior">
<name>Client Behavior</name> <name>Client Behavior</name>
<t>When a client receives one or more token challenges in response to a re <t>When a Client receives one or more token challenges in response to a re
quest, quest,
the client has a set of choices to make:</t> the Client has a set of choices to make:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Whether or not to redeem a token via a new request to the origin.</l <li>Whether or not to redeem a token via a new request to the Origin.</l
i> i>
<li>Whether to redeem a previously issued and cached token, or redeem a <li>Whether to redeem a previously issued and cached token or redeem a t
token freshly issued from the issuance protocol.</li> oken freshly issued from the issuance protocol.</li>
<li>If multiple challenges were sent, which challenge to use for redeemi ng a <li>If multiple challenges were sent, which challenge to use for redeemi ng a
token on a subsequent request.</li> token on a subsequent request.</li>
</ul> </ul>
<t>The approach to these choices depends on the use case of the applicatio n, as <t>The approach to these choices depends on the use case of the applicatio n, as
well as the deployment model (see <xref section="4" sectionFormat="of" target="A RCHITECTURE"/> for discussion well as the deployment model (see <xref section="4" sectionFormat="of" target="R FC9576"/> for discussion
of the different deployment models).</t> of the different deployment models).</t>
<section anchor="choosing-to-redeem-tokens"> <section anchor="choosing-to-redeem-tokens">
<name>Choosing to Redeem Tokens</name> <name>Choosing to Redeem Tokens</name>
<t>Some applications of tokens might require clients to always present a token <t>Some applications of tokens might require Clients to always present a token
as authentication in order to successfully make requests. For example, a restric ted as authentication in order to successfully make requests. For example, a restric ted
service that wants to only allow access to valid users, but do so without learni service that wants to only allow access to valid users but wants to do so withou
ng t learning
specific user credential information, could use tokens that are based on attesti specific user credential information could use tokens that are based on attestin
ng user g user
credentials. In these kinds of use cases, clients will need to always redeem a credentials. In these kinds of use cases, Clients will need to always redeem a
token in order to successfully make a request.</t> token in order to successfully make a request.</t>
<t>Many other use cases for Privacy Pass tokens involve open services th at must work <t>Many other use cases for Privacy Pass tokens involve open services th at must work
with any client, including those that either cannot redeem tokens, or can only s ometimes redeem with any Client, including those that either cannot redeem tokens or can only so metimes redeem
tokens. For example, a service can use tokens as a way to reduce the incidence o f tokens. For example, a service can use tokens as a way to reduce the incidence o f
presenting CAPTCHAs to users. In such use cases, services will regularly encount er presenting CAPTCHAs to users. In such use cases, services will regularly encount er
clients that cannot redeem a token or choose not to. In order to mitigate the ri Clients that cannot redeem a token or choose not to. In order to mitigate the ri
sk sk
of these services relying on always receiving tokens, clients that are capable o of these services relying on always receiving tokens, Clients that are capable o
f f
redeeming tokens can ignore token challenges (and instead behave as if they were redeeming tokens can ignore token challenges (and instead behave as if they were
a client a Client
that either doesn't support redeeming tokens or is unable to generate a new toke n, by not that either doesn't support redeeming tokens or is unable to generate a new toke n, by not
sending a new request that contains a token to redeem) with some sending a new request that contains a token to redeem) with some
non-trivial probability. See <xref section="5.1" sectionFormat="of" target="ARCH non-trivial probability. See <xref section="5.1" sectionFormat="of" target="RFC9
ITECTURE"/> for further considerations 576"/> for further considerations
on avoiding discriminatory behavior across clients when using Privacy Pass token regarding avoiding discriminatory behavior across Clients when using Privacy Pas
s.</t> s tokens.</t>
<t>Clients might also choose to not redeem tokens in subsequent requests when the <t>Clients might also choose to not redeem tokens in subsequent requests when the
token challenges indicate erroneous or malicious behavior on the part of the token challenges indicate erroneous or malicious behavior on the part of the
challenging origin. For example, if a client's ability to generate tokens via an challenging Origin. For example, if a Client's ability to generate tokens via an
attester and issuer is limited to a certain rate, a malicious origin could send Attester and Issuer is limited to a certain rate, a malicious Origin could send
an excessive number of token challenges with unique redemption contexts an excessive number of token challenges with unique redemption contexts
in order to cause the client to exhaust its ability to generate new tokens, or in order to (1)&nbsp;cause the Client to exhaust its ability to generate new tok
to overwhelm issuance servers. The limits here will vary based on the specific ens or (2)&nbsp;overwhelm issuance servers. Based on the specific deployment, th
deployment, but clients SHOULD have some implementation-specific policy e limits here will vary, but Clients <bcp14>SHOULD</bcp14> have some implementat
to minimize the number of tokens that can be retrieved by origins.</t> ion-specific policy to minimize the number of tokens that can be retrieved by Or
igins.</t>
</section> </section>
<section anchor="choosing-between-multiple-challenges"> <section anchor="choosing-between-multiple-challenges">
<name>Choosing Between Multiple Challenges</name> <name>Choosing between Multiple Challenges</name>
<t>A single response from an origin can include multiple token challenge <t>A single response from an Origin can include multiple token challenge
s. s.
For example, a set of challenges could include different token types For example, a set of challenges could include different token types
and issuers, to allow clients to choose a preferred issuer or type.</t> and Issuers, to allow Clients to choose a preferred Issuer or type.</t>
<t>If clients choose to respond, clients should satisfy exactly one of <t>If Clients choose to respond, Clients should satisfy exactly one of
the challenges presented. The choice of which challenge to use for redeeming the challenges presented. The choice of which challenge to use for redeeming
tokens is up to client policy. This can involve which token types are tokens is up to Client policy. This can involve which token types are
supported or preferred, which issuers are supported or preferred, or whether supported or preferred, which Issuers are supported or preferred, or whether
or not the client is able to use cached tokens based on the redemption context or not the Client is able to use cached tokens based on the redemption context
or origin information in the challenge. See <xref target="caching"/> for more di or Origin information in the challenge. See <xref target="caching"/> for more di
scussion scussion
on token caching. Regardless of how the choice is made, it SHOULD be done in a on token caching. Regardless of how the choice is made, it <bcp14>SHOULD</bcp14>
be done in a
consistent manner to ensure that the choice does not reveal information about th e consistent manner to ensure that the choice does not reveal information about th e
specific client; see <xref section="6.2" sectionFormat="of" target="ARCHITECTURE "/> for more details on the privacy specific Client; see <xref section="6.2" sectionFormat="of" target="RFC9576"/> f or more details on the privacy
implications of issuance consistency.</t> implications of issuance consistency.</t>
</section> </section>
</section> </section>
<section anchor="origin-behavior"> <section anchor="origin-behavior">
<name>Origin Behavior</name> <name>Origin Behavior</name>
<t>Origins choose what token challenges to send to clients, which will var <t>Origins choose what token challenges to send to Clients; these token ch
y allenges will vary,
depending on the use case and deployment model. The origin chooses depending on the use case and deployment model. The Origin chooses
which token types, issuers, redemption contexts, and origin info to include which token types, Issuers, redemption contexts, and Origin information to inclu
in challenges. If an origin sends multiple challenges, each challenge SHOULD de
be equivalent in terms of acceptability for token redemption, since clients in challenges. If an Origin sends multiple challenges, each challenge <bcp14>SHO
ULD</bcp14>
be equivalent in terms of acceptability for token redemption, since Clients
are free to choose to generate tokens based on any of the challenges.</t> are free to choose to generate tokens based on any of the challenges.</t>
<t>Origins ought to consider the time involved in token issuance. Particul arly, <t>Origins ought to consider the time involved in token issuance. Particul arly,
a challenge that includes a unique redemption context will prevent a client a challenge that includes a unique redemption context will prevent a Client
from using cached tokens, and thus can add more delay before the client from using cached tokens and thus can add more delay before the Client
is able to redeem a token.</t> is able to redeem a token.</t>
<t>Origins SHOULD minimize the number of challenges sent to a particular c lient <t>Origins <bcp14>SHOULD</bcp14> minimize the number of challenges sent to a particular Client
context (referred to as the "redemption context" in context (referred to as the "redemption context" in
<xref section="3.3" sectionFormat="of" target="ARCHITECTURE"/>), to avoid overwh <xref section="3.3" sectionFormat="of" target="RFC9576"/>), to avoid overwhelmin
elming clients and issuers g Clients and Issuers
with token requests that might cause clients to hit rate limits.</t> with token requests that might cause Clients to hit rate limits.</t>
<section anchor="greasing"> <section anchor="greasing">
<name>Greasing</name> <name>Greasing</name>
<t>In order to prevent clients becoming incompatible with new token chal <t>In order to prevent Clients from becoming incompatible with new token
lenges, challenges,
origins SHOULD include random token types, from the Reserved list of "greased" Origins <bcp14>SHOULD</bcp14> include random token types, from the reserved list
of "greased"
types (defined in <xref target="token-types"/>), with some non-trivial probabili ty.</t> types (defined in <xref target="token-types"/>), with some non-trivial probabili ty.</t>
<t>Additionally, for deployments where tokens are not required (such as when tokens <t>Additionally, for deployments where tokens are not required (such as when tokens
are used as a way to avoiding showing CAPTCHAs), origins SHOULD randomly
 are used as a way to avoid showing CAPTCHAs), Origins <bcp14>SHOULD</bcp14> rand
choose to not challenge clients for tokens with some non-trivial probability. omly
This helps origins ensure that their behavior for handling clients that cannot choose to not challenge Clients for tokens with some non-trivial probability.
This helps Origins ensure that their behavior for handling Clients that cannot
redeem tokens is maintained and exercised consistently.</t> redeem tokens is maintained and exercised consistently.</t>
</section> </section>
</section> </section>
<section anchor="sec-considerations"> <section anchor="sec-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This section contains security considerations for the PrivateToken auth entication <t>This section contains security considerations for the "PrivateToken" au thentication
scheme described in this document.</t> scheme described in this document.</t>
<section anchor="randomness-requirements"> <section anchor="randomness-requirements">
<name>Randomness Requirements</name> <name>Randomness Requirements</name>
<t>All random values in the challenge and token MUST be <t>All random values in the challenge and token <bcp14>MUST</bcp14> be
generated using a cryptographically secure source of randomness (<xref target="R generated using a cryptographically secure source of randomness <xref target="RF
FC4086"/>).</t> C4086"/>.</t>
</section> </section>
<section anchor="replay-attacks"> <section anchor="replay-attacks">
<name>Replay Attacks</name> <name>Replay Attacks</name>
<t>Applications SHOULD constrain tokens to a single origin unless the us e case can <t>Applications <bcp14>SHOULD</bcp14> constrain tokens to a single Origi n unless the use case can
accommodate replay attacks. Replaying tokens is not necessarily a security accommodate replay attacks. Replaying tokens is not necessarily a security
or privacy problem. As an example, it is reasonable for clients to replay tokens or privacy problem. As an example, it is reasonable for Clients to replay tokens
in contexts where token redemption does not induce side effects and in which in contexts where token redemption does not induce side effects and in which
client requests are already linkable. One possible setting where this applies Client requests are already linkable. One possible setting where this applies
is where tokens are sent as part of 0-RTT data.</t> is where tokens are sent as part of 0-RTT data.</t>
<t>If successful token redemption produces side effects, origins SHOULD <t>If successful token redemption produces side effects, Origins <bcp14>
implement an SHOULD</bcp14> implement an
anti-replay mechanism to mitigate the harm of such replays. See <xref section="8 anti-replay mechanism to mitigate the harm of such replays. See <xref section="8
" sectionFormat="comma" target="TLS13"/> " sectionFormat="comma" target="RFC8446"/>
and <xref section="9.2" sectionFormat="comma" target="RFC9001"/> for details abo ut anti-replay mechanisms, as well as and <xref section="9.2" sectionFormat="comma" target="RFC9001"/> for details abo ut anti-replay mechanisms, as well as
<xref section="3" sectionFormat="comma" target="RFC8470"/> for discussion about safety considerations for 0-RTT <xref section="3" sectionFormat="comma" target="RFC8470"/> for discussion about safety considerations for 0-RTT
HTTP data.</t> HTTP data.</t>
</section> </section>
<section anchor="reflection-attacks"> <section anchor="reflection-attacks">
<name>Reflection Attacks</name> <name>Reflection Attacks</name>
<t>The security properties of token challenges vary depending on whether the <t>The security properties of token challenges vary, depending on whethe r the
challenge contains a redemption context or not, as well as whether the challenge contains a redemption context or not, as well as whether the
challenge is per-origin or not. For example, cross-origin tokens with empty challenge is a per-Origin challenge or not. For example, cross-Origin tokens wit h empty
contexts can be reflected from one party by another, as shown below.</t> contexts can be reflected from one party by another, as shown below.</t>
<!-- [rfced] Figure 2: In the HTML and PDF output files, we see an
ASCII arrow after "(reflect challenge)" as opposed to the SVG-style
arrow used in other parts of the figure. Should the ASCII arrow be
updated to use the same style? If yes, please provide the updated
SVG.
Author: Yes, this probably should be SVG, but I’ll have to get back
to you on the updated SVG. -->
<!-- Removed height="176" width="472" to see if the SVG will display
correctly in the HTML and PDF outputs. -->
<figure anchor="fig-replay"> <figure anchor="fig-replay">
<name>Replay attack example</name> <name>Reflection Attack Example</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="176" width="472" viewBox="0 0 472 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 472 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 176,32 L 176,64" fill="none" stroke="black"/> <path d="M 176,32 L 176,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 264,32 L 264,64" fill="none" stroke="black"/> <path d="M 264,32 L 264,64" fill="none" stroke="black"/>
<path d="M 392,32 L 392,64" fill="none" stroke="black"/> <path d="M 392,32 L 392,64" fill="none" stroke="black"/>
<path d="M 424,64 L 424,144" fill="none" stroke="black"/> <path d="M 424,64 L 424,144" fill="none" stroke="black"/>
<path d="M 464,32 L 464,64" fill="none" stroke="black"/> <path d="M 464,32 L 464,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"/>
skipping to change at line 643 skipping to change at line 667
<polygon class="arrowhead" points="216,96 204,90.4 204,101.6" fi ll="black" transform="rotate(0,208,96)"/> <polygon class="arrowhead" points="216,96 204,90.4 204,101.6" fi ll="black" transform="rotate(0,208,96)"/>
<polygon class="arrowhead" points="56,144 44,138.4 44,149.6" fil l="black" transform="rotate(180,48,144)"/> <polygon class="arrowhead" points="56,144 44,138.4 44,149.6" fil l="black" transform="rotate(180,48,144)"/>
<g class="text"> <g class="text">
<text x="44" y="52">Origin</text> <text x="44" y="52">Origin</text>
<text x="220" y="52">Attacker</text> <text x="220" y="52">Attacker</text>
<text x="428" y="52">Client</text> <text x="428" y="52">Client</text>
<text x="124" y="100">TokenChallenge</text> <text x="124" y="100">TokenChallenge</text>
<text x="276" y="116">(reflect</text> <text x="276" y="116">(reflect</text>
<text x="356" y="116">challenge)</text> <text x="356" y="116">challenge)</text>
<text x="412" y="116">-&gt;</text> <text x="412" y="116">-&gt;</text>
<text x="320" y="132">Token</text> <text x="320" y="132">token</text>
<text x="108" y="148">(reflect</text> <text x="108" y="148">(reflect</text>
<text x="172" y="148">token)</text> <text x="172" y="148">token)</text>
<text x="208" y="148">-</text> <text x="208" y="148">-</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
+--------+ +----------+ +--------+ +--------+ +----------+ +--------+
| Origin | | Attacker | | Client | | Origin | | Attacker | | Client |
+---+----+ +----+-----+ +---+----+ +---+----+ +----+-----+ +---+----+
| | | | | |
+-- TokenChallenge -->| | +-- TokenChallenge -->| |
| +-- (reflect challenge) ->| | +-- (reflect challenge) ->|
| |<-------- Token ---------+ | |<-------- token ---------+
|<-- (reflect token) -+ | |<-- (reflect token) -+ |
| | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="token-exhaustion-attacks"> <section anchor="token-exhaustion-attacks">
<name>Token Exhaustion Attacks</name> <name>Token Exhaustion Attacks</name>
<t>When a Client holds cross-origin tokens with empty contexts, it <t>When a Client holds cross-Origin tokens with empty contexts, it
is possible for any Origin in the cross-origin set to deplete that Client is possible for any Origin in the cross-Origin set to deplete that Client's
set of tokens. To prevent this from happening, tokens can be scoped to single set of tokens. To prevent this from happening, tokens can be scoped to single
Origins (with non-empty origin_info) such that they can only be redeemed for Origins (with non-empty origin_info) such that they can only be redeemed for
a single Origin. Alternatively, if tokens are cross-Origin, Clients can use a single Origin. Alternatively, if tokens are cross-Origin tokens, Clients can u se
alternate methods to prevent many tokens from being redeemed at once. For alternate methods to prevent many tokens from being redeemed at once. For
example, if the Origin requests an excess of tokens, the Client could choose to example, if the Origin requests an excess of tokens, the Client could choose to
not present any tokens for verification if a redemption had already not present any tokens for verification if a redemption had already
occurred in a given time window.</t> occurred in a given time window.</t>
<t>Token challenges that include non-empty origin_info bind tokens to on e or more <t>Token challenges that include non-empty origin_info bind tokens to on e or more
specific origins. As described in <xref target="challenge"/>, clients only accep specific Origins. As described in <xref target="process-challenge"/>, Clients on
t such ly accept such
challenges from origin names listed in the origin_info string. Even if multiple challenges from Origin names listed in the origin_info string if it is non-empty
origins are listed, a token can only be redeemed for an origin if the challenge . Even if multiple
Origins are listed, a token can only be redeemed for an Origin if the challenge
has a match for the origin_info. For example, if "a.example.com" issues has a match for the origin_info. For example, if "a.example.com" issues
a challenge with an origin_info string of "a.example.com,b.example.com", a a challenge with an origin_info string of "a.example.com,b.example.com", a
client could redeem a token fetched for this challenge if and only if Client could redeem a token fetched for this challenge if and only if
"b.example.com" also included an origin_info string of "b.example.com" also included an origin_info string of
"a.example.com,b.example.com". On the other hand, if "b.example.com" had an "a.example.com,b.example.com". On the other hand, if "b.example.com" had an
origin_info string of "b.example.com" or "b.example.com,a.example.com" or origin_info string of "b.example.com", "b.example.com,a.example.com", or
"a.example.com,b.example.com,c.example.com", the string would not match and the "a.example.com,b.example.com,c.example.com", the string would not match, and the
client would need to use a different token.</t> Client would need to use a different token.</t>
</section> </section>
<section anchor="timing-correlation-attacks"> <section anchor="timing-correlation-attacks">
<name>Timing Correlation Attacks</name> <name>Timing Correlation Attacks</name>
<t>Context-bound token challenges require clients to obtain matching tok ens when <t>Context-bound token challenges require Clients to obtain matching tok ens when
challenged, rather than presenting a token that was obtained from a different challenged, rather than presenting a token that was obtained from a different
context in the past. This can make it more likely that issuance and redemption context in the past. This can make it more likely that issuance and redemption
events will occur at approximately the same time. For example, if a client is events will occur at approximately the same time. For example, if a Client is
challenged for a token with a unique context at time T1 and then subsequently challenged for a token with a unique context at time T1 and then subsequently
obtains a token at time T2, a colluding issuer and origin can link this to the obtains a token at time T2, a colluding Issuer and Origin can link this to the
same client if T2 is unique to the client. This linkability is less feasible as same Client if T2 is unique to the Client. This linkability is less feasible as
the number of issuance events at time T2 increases. Depending on the "max-age" the number of issuance events at time T2 increases. Depending on the "max-age"
token challenge parameter, clients MAY try to add delay to the time between token challenge parameter, Clients <bcp14>MAY</bcp14> try to add delay to the ti me between
being challenged and redeeming a token to make this sort of linkability more being challenged and redeeming a token to make this sort of linkability more
difficult. For more discussion on correlation risks between token issuance and difficult. For more discussion on correlation risks between token issuance and
redemption, see <xref section="6.3" sectionFormat="of" target="ARCHITECTURE"/>.< /t> redemption, see <xref section="6.3" sectionFormat="of" target="RFC9576"/>.</t>
</section> </section>
<section anchor="cross-context-linkability-attacks"> <section anchor="cross-context-linkability-attacks">
<name>Cross-Context Linkability Attacks</name> <name>Cross-Context Linkability Attacks</name>
<t>As discussed in <xref target="challenge"/>, clients SHOULD discard an <t>As discussed in <xref target="challenge"/>, Clients <bcp14>SHOULD</bc
y context-bound tokens p14> discard any context-bound tokens
upon flushing cookies or changing networks, to prevent an origin using the upon flushing cookies or changing networks, to prevent an Origin from using the
redemption context state as a cookie to recognize clients.</t> redemption context state as a cookie to recognize Clients.</t>
</section> </section>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="authentication-scheme"> <section anchor="authentication-scheme">
<name>Authentication Scheme</name> <name>Authentication Scheme</name>
<t>This document registers the "PrivateToken" authentication scheme in t <t>IANA has registered the "PrivateToken" authentication scheme in the
he "HTTP Authentication Schemes" subregistry of the "Hypertext Transfer Protocol (H
"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defined TTP) Authentication Scheme Registry" as defined
in <xref section="16.4" sectionFormat="comma" target="RFC9110"/>.</t> in <xref section="16.4" sectionFormat="comma" target="RFC9110"/>.</t>
<dl> <dl>
<dt>Authentication Scheme Name:</dt> <dt>Authentication Scheme Name:</dt>
<dd> <dd>PrivateToken</dd>
<t>PrivateToken</t> <dt>Reference:</dt>
</dd> <dd>RFC 9577, <xref target="challenge-redemption"/></dd>
<dt>Pointer to specification text:</dt>
<dd>
<t><xref target="challenge-redemption"/> of this document</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="token-types"> <section anchor="token-types">
<name>Token Type Registry</name> <name>Privacy Pass Token Types Registry</name>
<t>IANA is requested to create a new "Privacy Pass Token Type" registry <t>IANA has created a new "Privacy Pass Token Types" registry in a new
in a new "Privacy Pass" page to list identifiers for issuance protocols
"Privacy Pass Parameters" page to list identifiers for issuance protocols
defined for use with the Privacy Pass token authentication scheme. These defined for use with the Privacy Pass token authentication scheme. These
identifiers are two-byte values, so the maximum possible value is identifiers are 2-byte values, so the maximum possible value is
0xFFFF = 65535.</t> 0xFFFF = 65535.</t>
<t>New registrations need to list the following attributes:</t> <t>New registrations need to list the following attributes:</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Value:</dt> <dt>Value:</dt>
<dd> <dd>
<t>The two-byte identifier for the algorithm</t> The 2-byte identifier for the algorithm.</dd>
</dd>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>Name of the issuance protocol.</dd>
<t>Name of the issuance protocol</t>
</dd>
<dt>Token Structure:</dt> <dt>Token Structure:</dt>
<dd> <dd>The contents of the token structure; see <xref target="redemption"
<t>The contents of the Token structure in <xref target="redemption"/ />.</dd>
></t>
</dd>
<dt>Token Key Encoding:</dt> <dt>Token Key Encoding:</dt>
<dd> <dd>The encoding of the "token-key" parameter; see <xref target="send-
<t>The encoding of the "token-key" parameter in <xref target="redemp challenge"/>.</dd>
tion"/></t>
</dd>
<dt>TokenChallenge Structure:</dt> <dt>TokenChallenge Structure:</dt>
<dd> <dd>The contents of the TokenChallenge structure; see <xref target="ch
<t>The contents of the TokenChallenge structure in <xref target="cha allenge"/>.</dd>
llenge"/></t> <dt>Publicly Verifiable:</dt>
</dd> <dd>A Y/N value indicating if the output tokens have the
<dt>Public Verifiability:</dt> public verifiability property; see <xref section="3.5" sectionFormat="of" target
<dd> ="RFC9576"/>
<t>A Y/N value indicating if the output tokens have the for more details about this property.</dd>
public verifiability property; see <xref section="3.5" sectionFormat="of" target
="ARCHITECTURE"/>
for more details about this property.</t>
</dd>
<dt>Public Metadata:</dt> <dt>Public Metadata:</dt>
<dd> <dd>A Y/N value indicating if the output tokens can contain
<t>A Y/N value indicating if the output tokens can contain public metadata; see <xref section="3.5" sectionFormat="of" target="RFC9576"/>
public metadata; see <xref section="3.5" sectionFormat="of" target="ARCHITECTURE for more details about this property.</dd>
"/>
for more details about this property.</t>
</dd>
<dt>Private Metadata:</dt> <dt>Private Metadata:</dt>
<dd> <dd>A Y/N value indicating if the output tokens can contain
<t>A Y/N value indicating if the output tokens can contain private metadata; see <xref section="3.5" sectionFormat="of" target="RFC9576"/>
private metadata; see <xref section="3.5" sectionFormat="of" target="ARCHITECTUR for more details about this property.</dd>
E"/>
for more details about this property.</t>
</dd>
<dt>Nk:</dt> <dt>Nk:</dt>
<dd> <dd>The length in bytes of an output authenticator.</dd>
<t>The length in bytes of an output authenticator</t>
</dd>
<dt>Nid:</dt> <dt>Nid:</dt>
<dd> <dd>The length of the token key identifier.</dd>
<t>The length of the token key identifier</t> <dt>Change Controller:</dt><dd></dd>
</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>Where this algorithm is defined.</dd>
<t>Where this algorithm is defined</t>
</dd>
<dt>Notes:</dt> <dt>Notes:</dt>
<dd> <dd>Any notes associated with the entry.</dd>
<t>Any notes associated with the entry</t>
</dd>
</dl> </dl>
<t>New entries in this registry are subject to the Specification Require d <t>New entries in this registry are subject to the Specification Require d
registration policy (<xref section="4.6" sectionFormat="comma" target="RFC8126"/ >). Designated experts need to registration policy (<xref section="4.6" sectionFormat="comma" target="RFC8126"/ >). Designated experts need to
ensure that the token type is defined to be used for both token issuance and ensure that the token type is defined to be used for both token issuance and
redemption. Additionally, the experts can reject registrations on the basis redemption. Additionally, the experts can reject registrations on the basis
that they do not meet the security and privacy requirements for issuance that they do not meet the security and privacy requirements for issuance
protocols defined in <xref section="3.2" sectionFormat="of" target="ARCHITECTURE protocols defined in <xref section="3.2" sectionFormat="of" target="RFC9576"/>.<
"/>.</t> /t>
<t><xref target="ISSUANCE"/> defines entries for this registry.</t> <t><xref target="RFC9578"/> defines entries for this registry.</t>
<section anchor="reserved-values"> <section anchor="reserved-values">
<name>Reserved Values</name> <name>Reserved Values</name>
<t>This document defines several Reserved values, which can be used by clients <t>This document defines several reserved values, which can be used by Clients
and servers to send "greased" values in token challenges and redemptions to and servers to send "greased" values in token challenges and redemptions to
ensure that implementations remain able to handle unknown token types ensure that implementations remain able to handle unknown token types
gracefully (this technique is inspired by <xref target="RFC8701"/>). Implementat ions SHOULD gracefully (this technique is inspired by <xref target="RFC8701"/>). Implementat ions <bcp14>SHOULD</bcp14>
select reserved values at random when including them in greased messages. select reserved values at random when including them in greased messages.
Servers can include these in TokenChallenge structures, either as the only Servers can include these in TokenChallenge structures, either as the only
challenge when no real token type is desired, or as one challenge in a list of challenge when no real token type is desired or as one challenge in a list of
challenges that include real values. Clients can include these in Token challenges that include real values. Clients can include these in token
structures when they are not able to present a real token. The structures when they are not able to present a real token. The
contents of the Token structure SHOULD be filled with random bytes when contents of the token structure <bcp14>SHOULD</bcp14> be filled with random byte s when
using greased values.</t> using greased values.</t>
<t>The initial contents for this registry consists of multiple reserve d values, <t>The initial contents of this registry consist of multiple reserved values,
with the following attributes, which are repeated for each registration:</t> with the following attributes, which are repeated for each registration:</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Value:</dt> <dt>Value:</dt>
<dd> <dd>0x0000, 0x02AA, 0x1132, 0x2E96, 0x3CD3, 0x4473, 0x5A63, 0x6D32,
<t>0x0000, 0x02AA, 0x1132, 0x2E96, 0x3CD3, 0x4473, 0x5A63, 0x6D32, 0x7F3F,
0x7F3F, 0x8D07, 0x916B, 0xA6A4, 0xBEAB, 0xC3F3, 0xDA42, 0xE944, 0xF057</dd>
0x8D07, 0x916B, 0xA6A4, 0xBEAB, 0xC3F3, 0xDA42, 0xE944, 0xF057</t>
</dd>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>RESERVED</dd>
<t>RESERVED</t>
</dd>
<dt>Token Structure:</dt> <dt>Token Structure:</dt>
<dd> <dd>Random bytes</dd>
<t>Random bytes</t>
</dd>
<dt>Token Key Encoding:</dt> <dt>Token Key Encoding:</dt>
<dd> <dd>Random bytes</dd>
<t>Random bytes</t>
</dd>
<dt>TokenChallenge Structure:</dt> <dt>TokenChallenge Structure:</dt>
<dd> <dd>Random bytes</dd>
<t>Random bytes</t>
</dd>
<dt>Publicly Verifiable:</dt> <dt>Publicly Verifiable:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>Public Metadata:</dt> <dt>Public Metadata:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>Private Metadata:</dt> <dt>Private Metadata:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>Nk:</dt> <dt>Nk:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>Nid:</dt> <dt>Nid:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t> <dt>Change Controller:</dt>
</dd> <dd>IETF</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>RFC 9577</dd>
<t>This document</t>
</dd>
<dt>Notes:</dt> <dt>Notes:</dt>
<dd> <dd>None</dd>
<t>None</t>
</dd>
</dl> </dl>
</section> </section>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9576" to="ARCHITECTURE"/>
<displayreference target="RFC8446" to="TLS13"/>
<displayreference target="RFC3986" to="URI"/>
<displayreference target="RFC9578" to="ISSUANCE"/>
<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="I-D.ietf-httpbis-rfc6265bis" to="COOKIES"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="ARCHITECTURE">
<front>
<title>The Privacy Pass Architecture</title>
<author fullname="Alex Davidson" initials="A." surname="Davidson">
<organization>LIP</organization>
</author>
<author fullname="Jana Iyengar" initials="J." surname="Iyengar">
<organization>Fastly</organization>
</author>
<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
d">
<organization>Cloudflare</organization>
</author>
<date day="25" month="September" year="2023"/>
<abstract>
<t> This document specifies the Privacy Pass architecture and
requirements for its constituent protocols used for authorization
based on privacy-preserving authentication mechanisms. It describes
the conceptual model of Privacy Pass and its protocols, its security
and privacy goals, practical deployment models, and recommendations
for each deployment model that helps ensure the desired security and
privacy goals are fulfilled.
</t> <!-- draft-ietf-privacypass-architecture (RFC 9576) -->
</abstract> <reference anchor="RFC9576" target="https://www.rfc-editor.org/info/rfc9576">
</front> <front>
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-archit <title>The Privacy Pass Architecture</title>
ecture-16"/> <author initials='A' surname='Davidson' fullname='Alex Davidson'>
</reference> <organization />
<reference anchor="RFC9110"> </author>
<front> <author initials='J' surname='Iyengar' fullname='Jana Iyengar'>
<title>HTTP Semantics</title> <organization />
<author fullname="R. Fielding" initials="R." role="editor" surname=" </author>
Fielding"/> <author initials='C. A.' surname='Wood' fullname='Christopher A. Wood'>
<author fullname="M. Nottingham" initials="M." role="editor" surname <organization />
="Nottingham"/> </author>
<author fullname="J. Reschke" initials="J." role="editor" surname="R <date year='2024' month='May'/>
eschke"/> </front>
<date month="June" year="2022"/> <seriesInfo name="RFC" value="9576"/>
<abstract> <seriesInfo name="DOI" value="10.17487/RFC9576"/>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati </reference>
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"
rminology, and defines aspects of the protocol that are shared by all versions. />
In this definition are core protocol elements, extensibility mechanisms, and the <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
"http" and "https" Uniform Resource Identifier (URI) schemes.</t> />
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t> />
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"
</front> />
<seriesInfo name="STD" value="97"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"
<seriesInfo name="RFC" value="9110"/> />
<seriesInfo name="DOI" value="10.17487/RFC9110"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"
</reference> />
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<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>
<reference anchor="TLS13">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="URI">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"/>
<author fullname="L. Masinter" initials="L." surname="Masinter"/>
<date month="January" year="2005"/>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
aracters that identifies an abstract or physical resource. This specification de
fines the generic URI syntax and a process for resolving URI references that mig
ht be in relative form, along with guidelines and security considerations for th
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
et of all valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements of every pos
sible identifier. This specification does not define a generative grammar for UR
Is; that task is performed by the individual specifications of each URI scheme.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="RFC4648">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
<date month="October" year="2006"/>
<abstract>
<t>This document describes the commonly used base 64, base 32, and
base 16 encoding schemes. It also discusses the use of line-feeds in encoded da
ta, use of padding in encoded data, use of non-alphabet characters in encoded da
ta, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA
CK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference>
<reference anchor="SHS" target="https://doi.org/10.6028/nist.fips.180-4" > <reference anchor="SHS" target="https://doi.org/10.6028/nist.fips.180-4" >
<front> <front>
<title>Secure Hash Standard</title> <title>Secure Hash Standard (SHS)</title>
<author fullname="Quynh H. Dang" surname="Dang"/>
<author> <author>
<organization>National Institute of Standards and Technology</orga nization> <organization>National Institute of Standards and Technology</orga nization>
</author> </author>
<date month="July" year="2015"/> <date month="August" year="2015"/>
</front>
<seriesInfo name="DOI" value="10.6028/nist.fips.180-4"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="26"/> <seriesInfo name="NIST FIPS Publication" value="180-4"/>
<seriesInfo name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<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="3" month="October" 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-16"/> <author initials="S." surname="Celi" fullname="Sofia Celi">
</reference> <organization>Brave Software</organization>
<reference anchor="COOKIES"> </author>
<front> <author initials="A." surname="Davidson" fullname="Alex Davidson">
<title>Cookies: HTTP State Management Mechanism</title> <organization>Brave Software</organization>
<author fullname="Steven Bingler" initials="S." surname="Bingler"> </author>
<organization>Google LLC</organization> <author initials="S." surname="Valdez" fullname="Steven Valdez">
</author> <organization>Google LLC</organization>
<author fullname="Mike West" initials="M." surname="West"> </author>
<organization>Google LLC</organization> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
</author> <organization>Cloudflare</organization>
<author fullname="John Wilander" initials="J." surname="Wilander"> </author>
<organization>Apple, Inc</organization> <date month="May" year="2024"/>
</author> </front>
<date day="10" month="May" year="2023"/> <seriesInfo name="RFC" value="9578"/>
<abstract> <seriesInfo name="DOI" value="10.17487/RFC9578"/>
<t> This document defines the HTTP Cookie and Set-Cookie header </reference>
fields.
These header fields can be used by HTTP servers to store state <!-- draft-ietf-httpbis-rfc6265bis (I-D Exists)
(called cookies) at HTTP user agents, letting the servers maintain a "Long way" to include editor designations -->
stateful session over the mostly stateless HTTP protocol. Although <reference anchor="I-D.ietf-httpbis-rfc6265bis">
cookies have many historical infelicities that degrade their security <front>
and privacy, the Cookie and Set-Cookie header fields are widely used <title>Cookies: HTTP State Management Mechanism</title>
on the Internet. This document obsoletes RFC 6265. <author fullname="Steven Bingler" initials="S." surname="Bingler" role="edit
or">
<organization>Google LLC</organization>
</author>
<author fullname="Mike West" initials="M." surname="West" role="editor">
<organization>Google LLC</organization>
</author>
<author fullname="John Wilander" initials="J." surname="Wilander" role="edit
or">
<organization>Apple, Inc</organization>
</author>
<date day="15" month="November" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-rfc6265bis-13"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9001.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8470.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8701.xml"
/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-rfc6265bis
-12"/>
</reference>
<reference anchor="RFC4086">
<front>
<title>Randomness Requirements for Security</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<author fullname="J. Schiller" initials="J." surname="Schiller"/>
<author fullname="S. Crocker" initials="S." surname="Crocker"/>
<date month="June" year="2005"/>
<abstract>
<t>Security systems are built on strong cryptographic algorithms t
hat foil pattern analysis attempts. However, the security of these systems is de
pendent on generating secret quantities for passwords, cryptographic keys, and s
imilar quantities. The use of pseudo-random processes to generate secret quantit
ies can result in pseudo-security. A sophisticated attacker may find it easier t
o reproduce the environment that produced the secret quantities and to search th
e resulting small set of possibilities than to locate the quantities in the whol
e of the potential number space.</t>
<t>Choosing random quantities to foil a resourceful and motivated
adversary is surprisingly difficult. This document points out many pitfalls in u
sing poor entropy sources or traditional pseudo-random number generation techniq
ues for generating such quantities. It recommends the use of truly random hardwa
re techniques and shows that the existing hardware on many systems can be used f
or this purpose. It provides suggestions to ameliorate the problem when a hardwa
re solution is not available, and it gives examples of how large such quantities
need to be for some applications. This document specifies an Internet Best Curr
ent Practices for the Internet Community, and requests discussion and suggestion
s for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
<reference anchor="RFC9001">
<front>
<title>Using TLS to Secure QUIC</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<author fullname="S. Turner" initials="S." role="editor" surname="Tu
rner"/>
<date month="May" year="2021"/>
<abstract>
<t>This document describes how Transport Layer Security (TLS) is u
sed to secure QUIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9001"/>
<seriesInfo name="DOI" value="10.17487/RFC9001"/>
</reference>
<reference anchor="RFC8470">
<front>
<title>Using Early Data in HTTP</title>
<author fullname="M. Thomson" initials="M." surname="Thomson"/>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/
>
<author fullname="W. Tarreau" initials="W." surname="Tarreau"/>
<date month="September" year="2018"/>
<abstract>
<t>Using TLS early data creates an exposure to the possibility of
a replay attack. This document defines mechanisms that allow clients to communic
ate with servers about HTTP requests that are sent in early data. Techniques are
described that use these mechanisms to mitigate the risk of replay.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8470"/>
<seriesInfo name="DOI" value="10.17487/RFC8470"/>
</reference>
<reference anchor="RFC8701">
<front>
<title>Applying Generate Random Extensions And Sustain Extensibility
(GREASE) to TLS Extensibility</title>
<author fullname="D. Benjamin" initials="D." surname="Benjamin"/>
<date month="January" year="2020"/>
<abstract>
<t>This document describes GREASE (Generate Random Extensions And
Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS
ecosystem. It reserves a set of TLS protocol values that may be advertised to e
nsure peers correctly handle unknown values.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8701"/>
<seriesInfo name="DOI" value="10.17487/RFC8701"/>
</reference>
</references> </references>
</references> </references>
<section anchor="test-vectors"> <section anchor="test-vectors">
<name>Test Vectors</name> <name>Test Vectors</name>
<t>This section includes test vectors for the HTTP authentication scheme s pecified <t>This section includes test vectors for the HTTP authentication scheme s pecified
in this document. It consists of the following types of test vectors:</t> in this document. It consists of the following types of test vectors:</t>
<ol spacing="normal" type="1"><li>Test vectors for the challenge and redem ption protocols. Implementations can <ol spacing="normal" type="1"><li>Test vectors for the challenge and redem ption protocols. Implementations can
use these test vectors for verifying code that builds and encodes use these test vectors for verifying code that builds and encodes
TokenChallenge structures, as well as code that produces a well-formed Token TokenChallenge structures, as well as code that produces a well-formed token
bound to a TokenChallenge.</li> bound to a TokenChallenge.</li>
<li>Test vectors for the HTTP headers used for authentication. Implement ations <li>Test vectors for the HTTP headers used for authentication. Implement ations
can use these test vectors for validating whether they parse HTTP can use these test vectors for validating whether they parse HTTP
authentication headers correctly to produce TokenChallenge structures and the authentication headers correctly to produce TokenChallenge structures and the
other associated parameters, such as the token-key and max-age values.</li> other associated parameters, such as the token-key and max-age values.</li>
</ol> </ol>
<section anchor="challenge-and-redemption-structure-test-vectors"> <section anchor="challenge-and-redemption-structure-test-vectors">
<name>Challenge and Redemption Structure Test Vectors</name> <name>Challenge and Redemption Structure Test Vectors</name>
<t>This section includes test vectors for the challenge and redemption <t>This section includes test vectors for the challenge and redemption
functionalities described in <xref target="challenge"/> and <xref target="redemp tion"/>. Each test vector functionalities described in Sections&nbsp;<xref target="challenge" format="coun ter"/> and <xref target="redemption" format="counter"/>. Each test vector
lists the following values:</t> lists the following values:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>token_type: The type of token issuance protocol, a value from <dt>token_type:</dt><dd>The type of token issuance protocol -- a value
from
<xref target="token-types"/>. For these test vectors, token_type is 0x0002, corr esponding <xref target="token-types"/>. For these test vectors, token_type is 0x0002, corr esponding
to the issuance protocol in <xref target="ISSUANCE"/>.</li> to the issuance protocol discussed in Section <xref target="RFC9578" sectionForm
<li>issuer_name: The name of the issuer in the TokenChallenge structur at="bare" section="6">"Issuance Protocol for Publicly Verifiable Tokens"</xref>
e, of <xref target="RFC9578"/>.</dd>
represented as a hexadecimal string.</li> <dt>issuer_name:</dt><dd> The name of the Issuer in the TokenChallenge
<li>redemption_context: The redemption context in the TokenChallenge s structure,
tructure, represented as a hexadecimal string.</dd>
represented as a hexadecimal string.</li> <dt>redemption_context:</dt><dd>The redemption context in the TokenCha
<li>origin_info: The origin info in the TokenChallenge structure, repr llenge structure,
esented as represented as a hexadecimal string.</dd>
a hexadecimal string.</li> <dt>origin_info:</dt><dd> The Origin information in the TokenChallenge
<li>nonce: The nonce in the Token structure, represented as a hexadeci structure, represented as
mal string.</li> a hexadecimal string.</dd>
<li>token_key: The public token-key, encoded based on the correspondin <dt>nonce:</dt><dd>The nonce in the token structure, represented as a
g token hexadecimal string.</dd>
type, represented as a hexadecimal string.</li> <dt>token_key_id:</dt><dd>The public token key, encoded based on the co
<li>token_authenticator_input: The values in the Token structure used rresponding token
to compute type, represented as a hexadecimal string.</dd>
the Token authenticator value, represented as a hexadecimal string.</li> <dt>token_authenticator_input:</dt><dd>The values in the token structu
</ul> re used to compute
the token authenticator value, represented as a hexadecimal string.</dd>
</dl>
<t>Test vectors are provided for each of the following TokenChallenge <t>Test vectors are provided for each of the following TokenChallenge
configurations:</t> configurations:</t>
<ol spacing="normal" type="1"><li>TokenChallenge with a single origin an <ol spacing="normal" type="1"><li>TokenChallenge with a single Origin an
d non-empty redemption context</li> d non-empty redemption context.</li>
<li>TokenChallenge with a single origin and empty redemption context</ <li>TokenChallenge with a single Origin and empty redemption context.<
li> /li>
<li>TokenChallenge with an empty origin and redemption context</li> <li>TokenChallenge with an empty Origin and redemption context.</li>
<li>TokenChallenge with an empty origin and non-empty redemption conte <li>TokenChallenge with an empty Origin and non-empty redemption conte
xt</li> xt.</li>
<li>TokenChallenge with a multiple origins and non-empty redemption co <li>TokenChallenge with multiple Origins and non-empty redemption cont
ntext</li> ext.</li>
<li>TokenChallenge for greasing</li> <li>TokenChallenge for greasing.</li>
</ol> </ol>
<t>These test vectors are below.</t> <t>These test vectors are below.</t>
<artwork><![CDATA[ <artwork><![CDATA[
// Test vector 1: // Test vector 1:
// token_type(0002), issuer_name(issuer.example), // token_type(0002), issuer_name(issuer.example),
// origin_info(origin.example), redemption_context(non-empty) // origin_info(origin.example), redemption_context(non-empty)
token_type: 0002 token_type: 0002
issuer_name: 6973737565722e6578616d706c65 issuer_name: 6973737565722e6578616d706c65
redemption_context: redemption_context:
476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb 476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb
skipping to change at line 1274 skipping to change at line 1100
483e48a2c494bdef696f943fa992a65303292c25d0d3f62da86a70d0b020f0ff5 483e48a2c494bdef696f943fa992a65303292c25d0d3f62da86a70d0b020f0ff5
b90d0ff0f6abdb097d321fde04f3a1994e63bcd35a88c21236c7dc67600482223 b90d0ff0f6abdb097d321fde04f3a1994e63bcd35a88c21236c7dc67600482223
f54b25e39a250439f27ecb5ae9eb8ed548a3ec1f1d6f510d08281929c8fe08834 f54b25e39a250439f27ecb5ae9eb8ed548a3ec1f1d6f510d08281929c8fe08834
2959e35ea9b3b6f6a96fc1a8edba4ed297f4cf02d0e4482b79a11f671745d7b7d 2959e35ea9b3b6f6a96fc1a8edba4ed297f4cf02d0e4482b79a11f671745d7b7d
b120eddd8a4c2b6501bbc895b2160b8071615d9c1b18f32e056bfee29deac6a7d b120eddd8a4c2b6501bbc895b2160b8071615d9c1b18f32e056bfee29deac6a7d
6cf7b522a5badd63b9cb 6cf7b522a5badd63b9cb
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="http-header-test-vectors"> <section anchor="http-header-test-vectors">
<name>HTTP Header Test Vectors</name> <name>HTTP Header Test Vectors</name>
<t>This section includes test vectors the contents of the HTTP authentic ation <t>This section includes test vectors for the contents of the HTTP authe ntication
headers. Each test vector consists of one or more challenges that comprise headers. Each test vector consists of one or more challenges that comprise
a WWW-Authenticate header, as defined in {(choosing-between-multiple-challenges} a WWW-Authenticate header; see
}. <xref target="choosing-between-multiple-challenges"/>.
For each challenge, the token-type, token-key, max-age, and token-challenge For each challenge, the token-type, token-key, max-age, and token-challenge
parameters are listed. Each challenge also includes an unknown (not specified) parameters are listed. Each challenge also includes an unknown (unspecified)
parameter that implementations are meant to ignore.</t> parameter that implementations are meant to ignore.</t>
<t>The parameters for each challenge are indexed by their position <t>The parameters for each challenge are indexed by their position
in the WWW-Authentication challenge list. For example, token-key-0 denotes in the WWW-Authenticate challenge list. For example, token-key-0 denotes
the token-key parameter for the first challenge in the list, whereas the token-key parameter for the first challenge in the list, whereas
token-key-1 denotes the token-key for the second challenge in the list.</t> token-key-1 denotes the token-key for the second challenge in the list.</t>
<t>The resulting wire-encoded WWW-Authentication header based on this <t>The resulting wire-encoded WWW-Authenticate header based on this
list of challenges is then listed at the end. Line folding is only list of challenges is then listed at the end. Line folding is only
used to fit the document formatting constraints and not supported used to fit the document-formatting constraints and is not supported
in actual requests.</t> in actual requests.</t>
<t>The last challenge on this list includes Basic authentication, a grea <t>The last challenge in this list includes Basic authentication, a grea
se se
challenge, and a valid challenge for token type <tt>0x0001</tt>. Correct client challenge, and a valid challenge for token type <tt>0x0001</tt>. Correct Client
implementations will ignore the Basic and grease challenges.</t> implementations will ignore the Basic and grease challenges.</t>
<artwork><![CDATA[ <artwork><![CDATA[
token-type-0: 0x0002 token-type-0: 0x0002
token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864 token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864
8016503040202a11a301806092a864886f70d010108300b060960864801650304020 8016503040202a11a301806092a864886f70d010108300b060960864801650304020
2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2 2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2
5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9 5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9
ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f
67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b 67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b
f6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6c f6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6c
skipping to change at line 1377 skipping to change at line 1204
token-type-1: 0x0001 token-type-1: 0x0001
token-key-1: ebb1fed338310361c08d0c7576969671296e05e99a17d7926dfc28a token-key-1: ebb1fed338310361c08d0c7576969671296e05e99a17d7926dfc28a
53fabd489fac0f82bca86249a668f3a5bfab374c9 53fabd489fac0f82bca86249a668f3a5bfab374c9
max-age-1: 10 max-age-1: 10
token-challenge-1: 0001000e6973737565722e6578616d706c65208a3e83a33d9 token-challenge-1: 0001000e6973737565722e6578616d706c65208a3e83a33d9
8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696 8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696
e2e6578616d706c65 e2e6578616d706c65
WWW-Authenticate: Basic realm="grease", PrivateToken challenge="AACs WWW-Authenticate: Basic realm="grease", PrivateToken challenge="AACs
w7JXlcY2_Z3YsSmCOUq7qHd9NZeOh3_IhIiSohcjMEWsJaPVXAfFTv5jcpc_7gBz53_G w7JXlcY2_Z3YsSmCOUq7qHd9NZeOh3_IhIiSohcjMEWsJaPVXAfFTv5jcpc_7gBz53_G
G_GauIDyDt9dYnUC",token-key="hW3jxxC4kufMoa5esSGvQsqOd5E3oRIkIoybmbB G_GauIDyDt9dYnUC", token-key="hW3jxxC4kufMoa5esSGvQsqOd5E3oRIkIoybmbB
ym_hNUFfQMAADCbjw0GzP-hdWH56s1MMS6YWmvGD_vqBhAmTcsXJiVTE9qB1mVpJoah2 ym_hNUFfQMAADCbjw0GzP-hdWH56s1MMS6YWmvGD_vqBhAmTcsXJiVTE9qB1mVpJoah2
GRPFRa_YSzqAJ5t_22ampWftTjhtbI0PAkpkpQjgr3eItWzJLHkYY7SHXgGKGws4=", GRPFRa_YSzqAJ5t_22ampWftTjhtbI0PAkpkpQjgr3eItWzJLHkYY7SHXgGKGws4=",
PrivateToken challenge="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6 PrivateToken challenge="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6
a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0z a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0z
gxA2HAjQx1dpaWcSluBemaF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownC gxA2HAjQx1dpaWcSluBemaF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownC
hallengeAttribute="ignore-me", max-age="10" hallengeAttribute="ignore-me", max-age="10"
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+196XbbSJbm/3gKtPJH26dIFgBuoKvdXbS8Kb1bcjoz6/S4
AkBARIokaAKULDvdp19j/s3PeY55lH6SuUtEIACCsrPGNV19ulynUhIJxHrj
3u+u0e/3RZVXS3XHO1so7+U2v5TJtfdSlqX3+OzspTffVQu1rvJEVnmx9k6T
hVopIeN4qy7vNJ9vPirSIlnLFTScbmVW9XNVZf0NP7+Bx/sSHu+X1F4/GAt4
S50X2+s7XlmlAtoeCpFvtne8arsrq9D3Z34oLtT1VbFN7wiv78l1sb5eFbuS
/oDGim3+kbuGD5Lt9aYqhCgruU7fyWWxhpFcq1Js8jven6oi6Xllsa22Kivh
t+sV/vKvQnA72L7w4F++LmFhBjC/3fKaPuEpnRWr1bXzabE9v+PNN5ul8k7W
yYA+K6FxVd3xXqyV/uql3F54byW/kuQVzPV4t1HbKl8XPe9YLvOs2K5z6c3G
fjDip4rdusJFebPOK5V6pxUsU+kVmTdfqS0sNT2lVjJfwkptcEB/lNjZIClW
jVmcDrwf5DJVH51pnFbqUq3dz2kij4riHIb79Omx23p5SY/9MVlsi1W+Ww3g
2UYPxwNvPvDeFkXqdHG82OZlVWwWatv4ljo6Xha7NFvKrXI7SuTVHxdKbvL1
eZxX5WCtKiH6fdjkGNZUJvDX2SIvPSCw3QoIzktVlq9hVeSaaVY2aZZpzIO1
bdBrT0hP0yPQpSrV9hJ6bL+8UslCrvNy5e1KWH9spEFrA4HnprvHfO1VjYEm
MMJYcUvxtZcsc/i0FFXhbVWq1Kp5nqriQq1L7yqvFjg16PI8Xw+8E25HLsvC
aUzw1/iWByNeLtX6XJke8EOaIoyho4sBL+8qT9OlEuI7oOFqW6S7hCbz6bvc
+fOzEF2DhC30dutlvr6Q8bKxHsUWHlrI5uThZNrju7y2Kwov6iF7t0qlxKdP
/zB/ffz45OzB8dmb1w/unvTvD/b5yDZZwNlIqt1Wff58GzakHtK5WqutrHi5
aaheXpY7tYVDX+DuKC+WZU4HqrmHQB0VnLSK/4DFB3YBWwqreJnDoD3Ji1Pu
EticEr5cMvV4x/OXZ8ePgdTneipiU5SlKkv8mh+3I/FosWhzikvFy5RX3pWs
vzlXlXlB0NDTHlFEsYPPl8viCpvFeWzV8hp/38htda3pyXzHA/lHvVviFn7G
9HIb+8Bto36R0vA77EiuEzgz0AFQx/08y9QWt6W63qj2ahW4mjuaX1o/aBeb
GoIJAs8tlnDqXDqAiXbT44EDDvxwtSpuOubiFhDN64fHsyDwe96p4m0KAqCM
HvdVKSKQHi83rWHpHhR9FC/lFjdaXOTrlGbcPdBj/SJImcYW5DDcW/pM3gZO
UCnkXHqZiCtoJoG7r7bAV1a49ILXrT7B2C5/huNabWg6tC1wSrmnZAcctOcZ
BmDfFWZSxLR0K4abdAn3utdbZpxKvH37tu88h4RWbop1qTzg0Slw9SxXy/T2
wDMrgfuLj8ODOGOYHy60qBuHo4h0wcdlra7gwfc7OGp6bLDHW+4jpTHQsOsB
0aBrUW/ePTAYwwAMn6I9X8kqYULnNbMHozHG7W69Nn0eoGZgUP9ycnr6Zv78
+ABzMk9+/jwggIUrArSkmTEvgW4cWPpaNCbndU0O2QaAFQVrhJSBR6hNH9hV
XgpDdNhSrKorhYTF3BWpiueOzZWL4gof4cP+b//2b56U5eW5+F1f//udd+O/
+jnxq/eCm/315ld+1Tvk/Uq9/O4re+HnBLfwdf9+Ffplr03JCONg4Y7tpvf7
//zrX9D2jU/fer3rIJzbf0k3/8SL3DwAehJev19vwm9rG/ZbfLrjfZfl532Q
QoCC4EiSTnD36LjBhxwOZCZCrOgIQAEwI5mmOX0JVAko/QKpm470V0gFlyWK
gvqAnq9BYG42ANNLFBd4cNxjjAIezliR5CThqSsm6n6yKEo8zwUcgQ+aO5cb
leRZnhjCR3xaDrzXLaZNTZuDZ2atVkL3jNwNWofm4eTaJlFI2OH18EwCCN8W
wAmQ9yD/zfUcElkqwow4H5pnyTKInqpXKlWbZXFN0m9VpGppMNwlfVnsAB70
oXvikYBVoPu6lbiAlbCnH4DFrQKhmaoZPIgkfAUgWN95TtyCDvqZAu6o0tu1
jPvuO+9MbQFNFMvi/FoQ4gVNDDcZROPRszenZ0c9/uk9f0G/v37w6s3J6wf3
8ffTx/OnT+0vQj9x+vjFm6f369/qN49fPHv24Pl9fhk+9RofiaNn85/gGxz/
0YuXZycvns+fHu1jbaSOihAyzRBmVhHgEKkqk20ewx/wzr3jl//nfwUjj0FD
GASzz5/1H1EwHcEfVwvaUdzfNRAk/wlM5FrAFiu5Jca9XMLGbvJKIilLw1FB
54G9FuLNegn4z4NdUdurHDZe0w1iueag1TqBzS7r4wUkWkrYL+zl7OmpWBeM
SL0MlDAcKHwYDO/icEejyefPNeQZ7qEoIL+SpRlsJuwbc2BcZObZ+NsJoWPz
Gx3Sl3osR0xmR8RvjnCWDMtoHT99coE6SjtQUwxDwJMsbO9ZYWErjQPeXhVb
VR+mK3ld3gGVxOPBIKnd8Z4oOqUgukHtlct9lcIAm30hjRoRYJGKTmx+vlYa
UaHao7mnPRigxdvDj0dJn3rSnGjJrSJGslfLUw1/BU7vqC1mjhhruTKcBbSD
t/IUn85ywrhmIYSrsBAF7s1t0B5/6TnMM18ny10K/HSNSIfZQpHdgS4cTq55
JClcsI36zz78BGVb63yInaF/UJiXoMwT/K/5rsadhG8sU4MdupTLnWI1DBdD
wEbFxY7grIOpWOcpeZapsyX1EGFP1kbfivEE5qREaSijoVRpgRTui9kkQaiK
N0Bva8+roeRRQ5R2bRRqw4ftYKAb25Xv1wMGcdieA05Rw3xYMh5BR7s3ai9W
PdOaw5GrzhwNNPLqUgAc9d+sEhNzfeg0lUH/9nVUpr0XSG5St+QtJILPRIGw
SJtN6X3ERkhblks4cuk1vSGRFnJ96oS8lPkS1dse6px2+xySKBxsjiNyVhaH
hOIHDkBCPDUTHVga+2zul0sUpHij9cSB0QJeOTLy9Mg0NCBcA1JObV3xy2aO
fJmDoi2TLaj3LsTZynXJ1AqywJh4rnIQEUVWqbWzE7X21tpLFjUFLL2zqzB+
UtRXu2WVb5agKjo9mUUrAdSYk5FnmkvynzS7sn6Kl4pOKTFg4F64RNTpvCRT
Ra1UFrvzBely6gNQDAweYQmygjXafXI4WXp3qT2Yt9xucxYN+Ig9e8hTQS1c
1EQ6YDyxVcxYGAdqwjei2qWO5BAkddQd1H1YqKSqAmrTGIberyGtc3jhxJp1
hr2pSbvuDIWIPk3MUzr4vMs5hD2tra3lw6slQLfdEM9MdVWAsFunaF65RkqB
LYP5gWDE9UQuLfO1S/PNdZFrQhvug3YJ+4jdjDUTjg+a9vCBW/giKAB5hqL2
drcmPqhXiohLA/SumXZPbq1YbwViQ2tjCxHI8oIWuBY/euR7Zgh3sQEtBANg
l0skTZYPmp9BRzBTxm/QJug4O5ZH5gHUAmojCy0NcAMtOXEkex23lpsFX6M5
FGfcAB4A0UG7PCBnGHXveWlMpN6m2ABzqFS3HUYvgCWNAS3Cffx1hWC/U8q7
Yh27cCbaYX0iLJvmZbIrS4PzugHCwN0Bh3vnaxR5sru79qoYWCQJLODQr4lx
s2KzQ0hD3LZvERiCsx7BujV6LBzNjo1OZOnR7MOMqCrVMiNGBAK53RRZygzI
cRVF0TpJjdZw5gieauw9IhdNAxJTl8Ro3UWRMVpysUUjQkDeWmuNO1ukmL0R
43HENyrCXikI85JVSqDyFdCHYxY0+3XTcRKAr7J8W1b7B3CPy5ReQ5NygEOf
3yR7/KDJWB2gut8APtF34Ic+tprtapGPx2nV8bL+2n2fXodxgbyBWRCRftch
B07NaBtwrp7DIWs0bZrKJMhjZ13se/sqCmMFfcjIkg4zXKIt/3wB9M0v1V96
oOiCvK0UGevQDACcmeW36UOQxHQU+z94DOOZn1AzmvLYR3AOpL29do+lYH6J
ro4YCH+h2FriTnKrlvRoucg3ljaPqIt32MWR4WZscMHN0uNqGdi0Ngv7MAc4
1GakHhkQYoXUrU3BYb9IKlWRbD9HNolL6gzNWcseksEaBldsL0BNqBTjNs1T
8Al4ICViL5tODqsoGr5bG40t3fOSaNZaNjeBrUsKpDWcJTt1DWhE41HywRqt
iHdDbZmCgU5O5s/ndo967V00Rm1aJgF6LOIbZ/UYcDjkg0YKoFoPoIAR07Dy
D9Dji1YMWN7z/FKtnXdqE8ENdN0TPL33u3yrVrzbzM4Z2SakbFqjC7M5vSgk
rRnLMrsTGj874x54DxEkfpCrDeoI5HZzp7XKEYrq/pkijpjJvUOyPhKw3WjY
IvnRQziAkgHRkLG05ZW2DNEjGoCaGXeTLGOyBlaxC3KHbOZCc9dPZH7dwfyD
yTtt8aRT8gf2e28kgmUW++9QtPxTMBiE/yOY9IN/bjxSS+93Wub+kz8YDMPm
U87M8Wvb0OfWRP5AY6SZ1oSrt0MSUGZbjiz1FNkE0zjlCFjbR/LAses1OLQA
KXepSLk/cmbOLa69+enxyQkOi2UNKpK1PcQBSbXiztyLDBECHfcGeTUsUvxF
H79g9wsSBuGzztaNJYJohJVC+qZhc9bsnG3C2q2M7Rrn/Jkhco2OAb1TL6jU
8Pw09KmVdLQMgCaaf7BGrD22pxmXmT2+Vy0OMTxa5X3i0dvnDA7+VjlpCT6e
2GFIrYBMag+H0ZUwY+oYi3er2RJo6SeZ1i2bxzHnNYZn+jRmekY0/fQ1vHJd
tO7HRfP8W0enIsce7ZewxibHyqHXgqizAI6oGf5WadJydvpK4QFhWzgJUGIh
1qVgIF83HGY9l1mYZ70Q7Hwk9sWQADAtKggbUltR7z5usfP9bTRmNSD9fM1m
Fd4CKz49Fg1sS2twxsPHzVKC3qXCao6lp62HhFxdROxsjmt7i9E+VWxUe+lL
5WBqWL4HgMrc9jzHQGwPt/f1h1vpGX378wSUrJdFrq+JlrWXyc5NI5kmb6Aj
UNlx2QUVxoDT0C/Yp6BZ8TJf5dalhSEPaJ3qHdWBH2syg8Jh3UggG3Gi7SbW
QYwiX48ZR6B9skQgVgVDuX2l117qbaYBC95ezahQGUI7WNaiJUsfB6cD41gp
uS6b/A6HR3QrKCwBZqKxgVFUnH57erQtpcvR8NMWM73F36126LxboicBt8SY
3Jym0TrGvMgyJ4OdOzQJjCrSqmnj6CJVIxmViKi2ytFVtB+NNRggdStGOBij
Nv05QQf9fmu+zRXn3cU4OEbbaw+NA1sTsMIqoGZ+7Ay1W9q1uJaDGfXIKqhG
5bf6qbEL8JOsRn0Hr9PZfI4E9AAdVzjsT9+5J1OI0/oAl4ZmNODdVymha5c5
GZnLb8ELi6KssCVyRFlHAwLbnt4AgqFoj0IbDHDfnPkQ7NnRaDQ8wl1f5RSL
xTyDx4WOWST8mvNUOqgP1q26phY1ipXem9cne86vWvEP8aF/gGfQJzecRRNU
O+uejI/UHkPpHUHvW95ht5913X8LEWtzegP4WKmi8dVAP41hoEfIvjs+vxPh
kvREDBwFGYZ+5I/uq2avX9empGMtiI5dUxJozl2CkAFnC1J3mKU6RbzVt2rV
8gOdYeMBctWXPeZL55URiP5Oaku1QCuKcfKt0eDdq80dKOzRnwFoKAOusVhe
O0GEW6A7+I5gEno4hQ3E3CrDYzBkkAQm+v8VxxQYLV0b4hUdLTh/qNro1RbO
40jdKwWbnzK72LPFNO2ydhG3ygTx0OSZzWlh8GEhgSfmGoWbPXQwkl7MHIYE
6k1aXN2pd7hzy0pQQx7eSnZbdnvUL942h/EhQ71NqXZpodcu260TjpvtHIVe
Ii2Gv3II/M789Pn/S89783eMTzePR3jOiLqXxDiCfsMgxUv2NlFYJcV7eMY/
Rfo2SxMNg9tH50KpDVOiaEfIsPLeXssB+ljZ4tqx0ExEDqIGqa3p9bpF3NbT
A4eCj8Je3Iqdh0BfQGlAI6pKKdtSFnJrzWUUXKFnxhzPUcVkkqhNZRZjB6u1
FLUpXX3Y5FttfwAxqUMnmJvKWu53zJhgk3CHa841Oua6hq3NGAj3XKDbHDJ6
AUVzzHpPZBeB7/laFmw2aj8HaCsfqEEPladaRyYnn0OldmoUvtR4yvhtycS8
LS7ztPG1g0IMxGSvRpOx9xh2rRWiJ7nNMXyLRsxLp0mVCEih/TFRmiAEr7Cm
EtoiazQGvLsk102ZkxcWyXyjeFdB9oOMAub5ITd0mJdCUw93GquMzWRmysXh
VQTCkPmSjbCi3CU4DfY6lNdrzHpYY4S61uUpnGSdEnTIOVakQS71ZMifwWrS
8V6UsdE4CwJrLxytl/RPjXFlVlEESCOkUwe8sJ/PfZMmqFG3JSQGbMw+Wgbw
kkBbw/QuxFvEl7vS2iblgVDh3mEfp9XoRG00cx2ZqJ7ado56WqxbvUJiaL6a
jHbbZZ/jolIdmTWajKLPbQMXe5613Le2em3Latg0NxiXBGOJ1UJe5rhxjidB
7IM52yMxtYpzBnhgGmA0FCvd/EDMWdtuLtxLswDerT9TBhStyJ9tPFdH8Mcg
xPAPOnANPKNVdoOjiam93xXA6fuMn/lAW2joHEBBcKjxMIcLuHOzBiuaF2ig
d49w35H+YP90kLHdUI5L1j2QkoNBcbWXtLYmIm++cbs5DI4EHY9pAwcLoyyB
p6PLGs/cfq6CjZkzZn5rTHIcjKzymJjtz5+F1Xn2nXILOLF02p3ujXdWt7wf
ySrsKdTGAWkispU7LdGaFtKsgbu29drq3enWIQqjdWgco68mUI8IVHwrAqWT
/q0IlPC6+AYEWnMcge40aLZY5VXFfK0Osm0r8BRbrFNwtgr6UZeNsAHYM8Gi
FmNmdlW/yPox43adL8YEv5If+pK2BZ+zGqtdY6PgloDVrZ6w3q1i+A7+KhV8
x1qA9tM1bSkUVoRLRZiibT7Vno1G9gAuAmkshhrYQoWRJtsU7cZyCQqjHWAP
Vx3WNieD4skeuVN7rAqzgdTh8Np3A9PQRpn2Pg9s9gzTJ7u06gYoEKSWUjbo
GxUao34b16Y5icKygXbwSutI7Rni0StJHNsq2l+MO8H0TPjvsiguQNu6YHCg
3UF72QagJrhSsu747pGMk8FggGfX8Me7R0E4xM/YbfOdK76fGYNbW44LcUJY
HRPOciReszg3T8KJy7CxZc6yHwhJHEwGgQ7HM06TthZiGLEwQULNEPeGH7xO
y9t2DagDyLYdhX8Lu9W74TWg2L3XwuGo3uQW5iVVw6yDsx+tRTQJeXsHQMsG
o1FSRDAePGDRHDdr7A28jtBzJckWwukD+82RpasWnR6gJ1UrCXU/TtMY3xAr
nVoo6lFbLsnTsUFnxnOOu177Y9Id8XknwUmc5siGXG6dbRVH6XFyhkYXdfwe
WtevJJEdMdwdKucYl6wNNzaDZKNDN1f5B4o4NxTYdrXXs6mn7lpxyGe0Vjbr
Q9uaoa8SSGxp3QP6vHCg7IZiUtGJLsz79RwwO8ci/luZS/zApXVfTiA0kIYw
/p1MlhXHw/Fi3yZXHArqksylxiXO0T+OmRhDTJpRO9Jb5OvKcFTeA61hvGTT
+QElY9+wLsSbDeW5JSrfaJePG31mrApk8LSRGy17Yh0No7W9Sl6wZL7WYeM9
m6dLRvk689ACkzpf1ibbrpvZiRS6gYMwiXk2+oHzkBpu8zMjat6xqKGo6eIc
FUht4mCO6GBUmugf9LuHZogtXanlss+B5H+gqPx+k5IaenrD91ppM3TTKeDV
odscxOMdVPZakY21M6UVLDfwjkEvl9u8JOtYszsbned6cA72KM9RO6g8teTV
Fp7p2J2tMXWmeAguc0kHrp/zYaMUKNgwSQHboJomFyV7tC7rHc1A9WcnnKE5
a6pnR44lEnu+EIimOvZFODqGBTUAjYhHZrstHVkMCdrmOmCbo5cbZITmNWHG
hMlzHKXTWH5jCSGbE4I+QqnIQ/G9pki08f9O0hrK1r3QIdoN3kjXwYscxqJO
YcyaMIK1RgHauGwcFZKTzWBcxdYFXWdPT70EuSKpQ+o2pk1LfQzZVNK357LO
8cv3Q0+7A/l0U5++M9/XWdk4cRvNZTm58cTpFAiOHW3bsqzjjgMOcS10iB4w
WY168hUl7pemjgQe5lIhgK3DJvNVnbgo6sR6zplofe+IOB4AIfX9FHV5WeSp
IN8pcHPEONgEJ2Zgx5a1lXQYOjVVvQkmGYrXijCHG99CJEiyk5OmyRjbiOXS
kcPN5bvjcD+D7Sjkp9cR0tBz0pHpONd6gU07IDMr74cdsD1/9aBKM6we5XTg
MnnV9lrTYuv8cjBhoZiIaX4D73lRae5EaQq8bSybdZ6DcQmw48j4oj3rYG5n
/uwlsBDrsaKNQ0zY/kF8Jtsn1Abt1XoQ2eNFM8yiK7OrafJ/53jS9qWpwOIT
Nnzgts1g8XSWJh5J1BRdb7O321BRgl254MA4PG1a4grKckoAcyMm+vTpX45f
vHhy8uC0TpdfVNUmzsv+Nksm4WQMv6KlDREpbSkLPWlcMMhobV2EmlnbbSSG
SyejFaPBoyLc7w5pIN4YW3g9H5L9ZplouevczSsC59hVrDxb8IQ5nY5nIbu0
ibfHp9n62w5g0oDAkoKbpeL4Wz9918wsw1Z21WZn/dQdFrCySeS1KmwThUzl
Ayf8wGQANsIeHEZr46RBUfZMbiLSXjPimQJ4TdkazGPRwTdu5JkNxDVoixkF
HyYSvHWNBhdHdVGsG11bO33FXxStq6dVt/g1sd+tdzw3UPCvHPdNb/32mG9e
aPFNYr49E/NtxnTWsYSt8NpvHlWLX0TvNFP+0zD81+bHlqTfpTngnWr/CW4Q
dPJ3efqn53na+rpR7eZPzy/+1QbY/s3E1dLUj2xwJTemzbFuthjzmv5eUAO9
P2g6ZfRyfbFV3ELYyoUJILNssA2qTh/P++F4cqv5ufWI66+pOxthIwj7/cPp
49O791+cDAJ/MPHD6PfPT07PBg9PXp4Ogsjvjyg+HkVDYzxGMycIUWBMBbqd
WYGmdEfTI3N1E1RKPbe1ROJAdTme+izeKnOdgmPPgucqzXoVdR+xIqflDpfe
mhCWIGm1gVczDtJkSA5pBtH0Jzg0xESr9whI19CRCXLeWlagUxmaGcfwOnsn
eFeLdiihIWDXJ/HOrkXDyCq6QCaMs3F6zEAv9DgbXxq9UJfvO9/KzQKNJYhK
DdipONMgUaRiNFBokx+SoUNP041uc5NfWp4eO2vj+awtUyYluK3bf8UqNCOZ
3IVuVUrT/WOTC85TII2PqYXDyOzLFBSE9qznF+jHoNxeExeicXc7Sq3lPWpX
rmMlctcUs03bg6VcMkU16aEnTCxVi/B79anRxKp3DWukWRzhKrY6wC038tjd
SR3hQP55lZY3bDbn/pY6hLFpY6yzejAOtmMRulzmpesWp8AsXU3JrSLQ6RBv
nTntHzfyFo+643Hhc73vIW04v4xLXLi7RC496xmtkZ3jUmkl+LfcheKL7sLf
4s8WX3IXftGfLX6Lu/AL/mzxJXch5qTt1hdrjIqGznfr2kjnLCDolTfnOScI
1+FPuewKyT+uI4RJYyS20z5pGA5SB+yyEHJrWDjlRpoFwxrujgbkQJTSKhzV
cFTQmlvfBoOahzoNAMM6TezXhU6T1a4KUsvJNNbML7U5D1zsjGomtmwE9Xxp
lrbKgrH11ucU+UTrXZ0j3JXjgdYmHWJpK8rpKi0Y6WrzYU3oJpvRTH2nzJjS
XPsYQbEr02pZhydppRgjjcmKxx5PFC+Iht0yTW5AEAk5/XetqdXlPdBASryU
zUSxws22JpnqilJF7h9oHCax2xqbnmMARI11qzZLeW1ixCkF2tSzdPPZOUiC
H+7LqpLJRXlAgOpQCX5W6GfZCtlNObreUffYcU8MBlvr+EGBvQIaW8klf9Dz
WnjrQ7u2qJbael3ZbAN8tmxosz+4MuXTdw35USu4rmue9jZfo+Z9AJ5wbGRT
nJiKGMYDIQH1nWOlKKpFJHVWaBtmNDomk7VJ1hH7qMHmWREOSaqbRDshayvG
ybxnCh0ic80QtucfjZj87V51S8W1Ssc9a02P1u8/Xbf77IqxYnuCg3I0OReh
lQ11bj/v3LXtMThsEIdoYBfayQZc6wzzMbJyzHUEnHAlzmg330/a39feVNNj
Xkfjl4eDJfZmVTfpFIMh5qSSHedEtMPbmYP2PDU4H/Q0Si9iUyeHrWhrFvYw
DjLhdZKoTnICte+yuGgTosXUPb2KZhEbiw6M/RwdEouVLY/cbSiTN4ddUfkn
nXV9z0QLfvpOq9AmftBES8o6BpoqJDVS59rJLiRUbClVkmAmdFo4dk22POuQ
4mRRAOsnE95KXigyJEDPhJqgG+Tw+1ZudAA0y6w2LIADpw33ZSMYltc2CNU4
RDQz73W4xEzKhH7Fejk6FEPyWnY619ESUJK83nPiUzUXImPHYQuHXSNG3INy
F5c40ToW3bBDrMjINn19rs16ts6jddgbFW2zWZqq0GjRRgesYWftMo3GiGpO
6KE6IHWGlTGb3VD6kc2w3rETxPya192oJZRJ4oyzdPxozXx514vE+XGtymBi
v3iWi84acdFIhWaV2+E40ro7Facq5Yk2jWIUhg55xtrfnEBKrVr4h3uAwUAI
2FI03djUx6WSW5RWwuI9fNQB3S466Wn7+6427dfOE+s9ojrfuK7YknDgO5VY
ZlKxVaANcdS1vTgIz5Q10otqzoWp4XfjCkqHUp+R74KOo+1qr3R97ae4LJaX
FBHPmQbMHijNeEcWp+2F0HHi1xYFuzmGhfEnaeXLAkUnOp3TgY13kMxoObqH
G4VR93bfbDm+6Kw/8bMrAqHYwE4DORgTGqywdkSjopuupl7qo7/lPSEs5eyE
nTptxVadY2Ilhjut6f4E3FVD9to270zS0Te1j5wZKfVkd22VV/m50Uq2eXkh
LDywvZv63+SS1GRgXLJmKRsDkeTT3LALPxNO0fbaJau99Xvig6p1oXRH7y+J
IkInrPVeMxc1Ekm4W4yusvU/1pW79notKJZ7t65L0GsHumMNpVwTzAkqtYGk
JWKcvM1GZUbu7DbDRCQlNBr1gU1c5hw4ZgBDu6TSeBAcYKUmusIYkJgBCtwE
9P9S/lSO4AbmyNXUbOC/ztqxB5mNO/jGzcXemaWS9liHVeydG8oP3pNGpfWp
t6ttldYv5qntFrAD6mUIH4AjJqSk2YGbgitya7yA1o9HBKirUTSOZF47nf/j
3/8nmsU0Miv2qqQTZljrGxCc2qMc5W+y0zlhDzAgJuduSTOTzmC1q5M5MJKJ
oNhaig+7dIOc95aBiEN72zvydITLTROpk3cNYqIahZTsyKa9jlnW4RHI2tCm
jOZM2JblqkYqOnGLIT1NuaSCvsxjLiXSkRMAVFdtrcU3y6+WA50OKquSxmpA
FFt7qjcFLOG1IKYDei8nHe0tWLsgCceoE4g1NRaaqOGeduLZ8OFGbJ7JkOpr
X1/fQLM6Wq8kvViHy1jo2qqKSyyrHbzb3uGB2BMWVcNlUmqyMS11Bg2Lmiwp
3kNDCQfh2ELdG1vqU5MxKkIM8AGFWiuJPctaxa3ZtY7JLWGrygwzC2VSUYlO
ZZI5nLHbiFKtDxLMrOPgb8azxhCFLHjj2bKTmirqEnlW+OsILcd/jPfp1LZL
tvLw9HuN6ois0h56koK/SDEQRrmoT5lzdwnL4c7AnGbgiTnA2FxHecC9ePyv
qU8gjMvDFicAaHwutylX3M60a8duAtakoLJ4eWUOpOtsE9rsQtgbUALzGDap
8Xlz2rIxJ2jAagLPuqxfjVN1hGdLxZ9wktmBUoHWh2ErbJFYElTawIH6lmvZ
8SfXpLzqvEBHedVxMY7yWtcN1pHTstrnyQhcFVu49JkwtGT5oWA9yiQou5oU
Rxc01Ro+HIZtUN+l2CNmJzOgM/HVvckCI0Hr3AHRyB6hcOuaTZWk8HWon71W
eVpNJVSQsg6eR1ql4uUYsazDMFnO2KLhjVi+0g1XFx3h6h1CuFZQ6hopjXw6
s282SK6RJUuBhZpHpHVgmqEUvNPMlCBZXuNdWG6sPMXoaDeJPCyKee9NdrdF
myQSGEc1GIOperrT1vc0NUSOVmkTvG2ZjHCYTBOrO5PXh/iApHQIuNTgoFF2
WXdkI+XaF6ugJ29/2kftPNHh/hG+zRKJIhAtuqAVcS4M0qQtnNJ9FiU6xaIY
4zhybQHca8vhbIhLWNA/2ipJbqHOmtXm7VglxUq7wTBGu6JEIRpAHergHAd7
r5hxdWiJrKNGGifVmnte021qsIwmOPzoHAen0iPBEurWYb+0KXROEOmQcgBA
xLlboKfdve1kPqNy6pQx6y+8ZWzxjMTZhiK39Z1UVkO1GgRe6ODqo7drH5he
GF6Q5fV//Pv/Fk2lYP86Nudmga+YK0l8IJ9NaftsSaR8W6sG2DbVVnaJzVF7
RUtHQYGYm7I8SJTqg9omOa5ELQyXLE1OjfH3uKFrUf540m8qYKZsqqnlbbVB
a0FuPm+N0w235CHHuWOsbtygwUfhNe0FunyAFOsQey47qilX11Frow4nwkc7
b53idDrjs8P9Q5NCXL/bMtTb1kO49enTv2AOuY/FgLQt7zV74ubsMIOBubY7
TVHsUZW21q/2czZKHe/4apGGsKV6AwndlJZy4QXqyzrnuG9H4ddh/G7hBmm3
SRAqZG0YyRJUFhMKUKuWFae4yLJgq0EdHKGLHbh+x7yW3+5BdeWLhVagEaOJ
COnEU6ADJIZzmhjGZtkR7aTRdw+Y6NwB3cFpsyJ1zS5bMSov2XQK8CPvYB1s
HC2tsu33X5+debCykrWH2p63Pw8uro7Sx5nAHuuo3ce4c0Dtfb1g9eWTbQvU
Qm5X5JNETsZPW8ctXQlTB1xE1m2EVDjz/aD+boaxGPvBMl7nIPhqG239Ftxc
NJo6sR3DPeu2bq+Umeo+8bSaHCSul5ROR7bUTdoTcnaD86kNVkk7b6DRK+Pi
cFN1XAtVB7hhrced9IFm+G4PU5ibX2sZXzrqljPrpzD7+qIqq87TAhgXig4Q
qijBRCcAOvcMfeXNbb9z7ghr3QL2pRvcftX7AFNvXyz2pZvc+IODvX7xRrfD
F5nVN7u1gkPwHrcvvNX9PbZ1S699TU+3vZvvhTMXs5mB1Hex/c5e3FY3S5sP
TR6+7e7GvhrXtRm+ype1vXb5vCE9vJvNxjw80FXA3HOlXZd6ExcF1We+kVrd
skME0hv55qitvDAKmXbNOq2hpYdqu8HYTKYN9y20Ecj4E85q8MqxmXgSFnjp
1ppiwRwbeaPmqK5WaxSEW4xtbbEnJ8/oNrNPg6Kuu1OgsPaCFbsvtGV1vgT9
b00Jb4g/88yVGDxhfrTXuBcTZLSQ+lVla7w5MH2Fy2dCkWzwTz0YcqKj9gbc
RbimXVxovey1LDT21npZ2TGvN5ttbBas4uVitTfQGcdeTEHWZJgLmRqZK4qE
8gR1hce9omoDczVSO/vQ6BWdG+XFuQ0h8nStJFOStnWtX0ng5NDNBJhZZHAJ
ex+5GBfSgVvzgLmumwuJmkyd9OqOjcMKBx4VVs9rn7bVnJAk+PVeHd5zgNLc
W4paKr/OQuPEGAOW3ay5PXP/kWyWgSR1s2yo+s3Lpd0JkdrWaKAXN5rr1ddC
JTp6vhkL4NROrlrXnWX1hXp5Jo6aDTfqk6QHRyduHB1iPl4hEtioEfGatPoi
2l2LA/OP9+toNj7qyfYDN46ql7RWsFrY8sB1XpnOtDRXKvAS66+1l3lHVu2W
VVznj+Wk3h9jnBan8NS8/ng/JM89iB0xAkVM3h0akqMxUOEE+yasLEA6m1PR
cSGX9vuXuj2Da5wpuPU92bWFKffW2E1+8rxiexEm8S2vTa6Atnw2b4MSOriS
791CnoSsk0JAPuR4ieDyuo61RP502FkGXThT7bhM2SaGmiKQuvTjWVBX6q39
gEvgkXHTL2pfCKnkQbHU7nnn5j/Hu0KXgNGB0kmHrTu/zkJ23+pLuRyDml5P
9/oy/BMFRIa2I7q5nS5YcUxodoFNuKodLB5RMuuUeO1Qy/RrKx/t3WjtRLob
QsOEN0xRQwU3TbU90MQWYmfaKSVYGjq7UV/Q2iA3DpDiVaL6FjARd9okOZD2
0A6osXq78jFpAvUhQp9/aTPhmsZUKsPQsPe2bPwdBkLtnSOoYMqRPnWGWJsG
9vPgu8RZKz+XAj46InBFM1fXJOZS8IPOntJZZ+xTs8ZdK5fqq8E7dCZdGJGv
asemvUaqqx4sGZPotpM9Q1Iu15Iha+eNi+18THOHSvnlrAtTlVAnrB89vkYV
Egd9hhfpARuyV516t1AhvX3g0sfXOqPyqJWhtp/qMBmMaKO728HC2XdEMw5f
iJcFFXkkJOumfHk4VHzcvWjJDT61qVtmcRzgf4ahuWbcsMquxVUI2gldvk+V
2rVvr0xFs/BRIx6ibvPITS/lZ0XzWZsfUmJVMfZ5crUOm5/GCLOjlJ5b46tR
828/OqN7r/WdpMLti+4jvSqc2ydKW9cReFa+2q1qhcYETQv/w0P45931JuPx
cAxb+pyiXWjumnaNbKbZNSOgQSUDNLqrFGZi0A1AuJFo0bAj6UjXs0Gs0Jsm
ledO9Zb9+4s0tD6tU2i5k85bmdzErnYcs2npCehEprK7aaxdm9Gp6ejUtTvU
ZMetWzeOsrMGTosHwpnhQooc0q8ZKDY79376/XOb1GbvfNDIWmfRa0hjqlmB
8q3rMl66zdl6x20H7nAw3mfu0MieC9e4hOl+Cm5rYIf+DB5C+9dvHTVVdmEr
Vj3wlW7sWw+V+dS3Gqtu7a802OcXhq70DTX5muu26+L6emjNVA3xPE9br7mJ
9lyp0x5UIV6bYl340lvHnGzDz+sEWmi8IAaA1xlT7BxV09ovzg3Nb6/RxIOX
e8Bi3j0iR11SoSmH+A4+kRvfBfFtzYM5nCP+he1M1NppQ4ZobwiClZp16dAS
U+gvCsJJLcNGA3JaAMDjdBWV0hWw28oyPNEOj3CyQZz8YU7Ss6mTVGTuRhQF
inzDx0dro7vmRCGaZ5MJa/QZA5otRW3Y0begrZSqmlkMXH+IpUmjGpMrkhpp
EodvfdjDd41qeSbZ02yeVYvN7uFN8XzVgnae8lVxhypQlIDLtnJZP25kWSON
3BSrtaEHVPxClyTXIR3WOev6xNq6YVO9Ktv73oxlw0mt6MoO7b7ny15tdqUb
xHW+lYniYOhbrNWoZMHKC1UbKzfks4U5aI/D1Oe6kyetLnWgRsl3kG6by4Jq
i3b8kdO3cc/KCmesF8GUpgCMeqrXyQ1p44hfePxgLmPP5rHqcphr0Pgcgwv2
vkZMLJd7J4XKrPIlpGWr9h/BK+1OF4eMZ9QoT3jQsDt2D184GZh1oSfjLjd7
V+cH1GMmYNV926MjqOsAqwzUcMPj3Es02JDAGoXZAD1+9vjk65yC+m1Xe8em
kSnnlAttngrRkZdWozJzaLgw/EYRm7NXVbscxsVv/gcf/vXwZzif488gGIb4
M3wwm+DP4fH9If4cjab0czyf0M/JfX5u+nD4EEuG+h+i+/4UP5kFk3v4cz6Z
j/DnvQdz+vt4+JDevD8f0ZsPZiP6/qE/ntbw8PWD0wevf3hwvxMJvnbW/RDA
63jmAGJrPskoBo6wgWBLhqu/n3ciHP68A07QFyy6+VeWx/R7Q9ieNRUdK1qf
w6k5JDvRQRODTo3K5xlGqf8AjKLYlq1ABRv4hMHPAALpGQvKyVPZrVhqdY31
wWZUgneyX+XZufXa1HB1e+Q7rc+6xtAMVmi6m1lO7XNHDArQkdL433azdXUE
rCrAXCXe5ZT2iDEhVGzghgzuhpe0bsL6v6VbtlJzHyd5u9nuQIQHZk6rz0nu
ZY0lmtuxN3dhU1AOzL1RcdH4d+nS9ZK7FK0NNyPQ+bbLa+aTNNfDksGadAst
Hyz2a9TM1rFJFknRVSZU+IAtajWDpOhulxScqmH1pcZ/MakfIjNR17vNyQV/
2Nuib2Bu5sg+oCS8ukexzDngbS9pmGsl1QnBWmdGeWnd/h2ZoVIrJFSDwtu/
R/chT7BFCz2nIxTHxN7DXqu4i2eAdde9AwhRDOSrC9xpfLmBDe+bhxEf9t3C
iHfsdWSufs+a9E3aMIoPe/mUiV5bqA8S7wLnnHlyT0Fv+yUAudOuC3++WaeO
Y+WOG/BLnpYvddPqBCvTHuiGksP1GlLlhO4aNu0WD7bHpAAnj9vUirU9jz3P
3EjSiHVvJ8cjl/P07dS/qeOGWvqOc+brIk3lgdnZ+gc6vx/7tk91pFp/5aBE
gxUjRuI7glyMtCfTmnuKUDHLz3daTdOyrbntjctmDZkg/7jpoiaSFF/ZzsE2
hgfaMDdiOW10vD36+rdvnMn40ExaF2yWX25qstcUbtS5DRA+2xeEzuVxFGLy
+9+7EtgL7uAnnsMibyF3vN0o7nqrecfg7R6/47CAWzozzT7RwZRu2andFi7r
x/5Eg2NOZtMh/G88GU/DUMF/o0kwSaf+JJmMRQe3E6PpRCZhMhuOs9E4UrM4
TKcyG4apTLI4DcM0nfjhUGXjKJrKaTTLAhkr3x+p6SyOx3EsGtxskk3DyWwy
hf+rve6ZIQnlB7NpFERhMprM1Fj54SSdTMbQuQqiyXgCr4yycDhWo0BlUxUO
p5GaZCE8FkUylrGwjOgdQuFEwlSzaBaFcpbIcBTJoT+eQEtDGPxsmMhgBGOa
BGGQpioew8eJP82CbBokaTj1I3EDe8H1/fJwxc3jjVSQjsdBpJIonE1G4Xg8
DicqS6NslsZRFPpjKaI0TYdZFgdpHM6iLEmGMh1OklE4jOCvr5ihuHGKbdIN
/z+S7l+HbP9OdV+guiBQwTiZBXKahDL1QxnD+xM44nCap8MUKC0S4TBWMvIz
P0pH43A8CrI4jCdhPIZ5xd+e6obfiOr+s+jsvyspxVP4IgniSZb64yxQszGN
duZPJHwMA4tmYpLC2GfTdDxUKpuNgHslswy6GmZTOfr2pDT6q5LSfxFp+9+W
HqNxBouR+BNY4dhXkYriFD4gbpaMMjnyRTScgrhVyMZwMcMkAn44ioKpkkH0
7elx/I3oMSsK83UvlnuP/telVQ+ETwab2Oo4xPr2QceA/puStgzldDqOJpMY
eKufzaLZaDQL/CTKRtE0jNJIhmI6HMezYDydTmAL4izygcf6CmldDtW3J+1J
J2n7QNpWyb7F/ot3ZPneo0P/C6vmj6MRYOB0GKgwmqhoOkriUZj6IEfSsT+a
BFKJqT8EMRTIMAimUazg+1kyGiY+pg+N4Y3xJI3Gk8zPwjjNkjAAfD0bpuMk
DMcKVmKoRAStwvqryXCGexT50RREUxz445GUwBcyf5YmsK4z6at0ks38TAFd
w6L6UZIGSikxGqXjWMEeBEOVylkWwoam8SSAExICkE+nwyyagFD0R6lK/SD0
YY9mALHiNICJjEczgZ0r+Nafjoe+BJpIh1M/A9VgGk+A+qPxNBjHaTQFbUCF
o+FoMh0HsEfDUMIT00BJMfLjWI1lMAyRniI19IfJZBQBFxzCHEbjIQwgzhIY
JqgZfhTEWTjNAN/NYHeBPFUoRtFQAVUAhc5GcaoywMwgr4eZnM1COYFxDcNZ
mITj1AeFBChMRhM59VM/9kMAilk2FvEM/oRGswlgytgHoQ+jyWBWo2wog9ls
BNOMk3Q4llEEWxGCHjNNE0DnwBuiMAyHIhuPYtiY4UyGsMFDWMqpSuKxVDMF
2lI6RqoFZJEFsBHjAHqLwiiYwZZHACmiaDgS4Ww8U3CM5Ay4PjAWCbNIAgkv
x3Kk0nA2zUZJ5iMVjaDTeDqTQZBNprhGKaxlKmLYIAVaVwTwBEDv2A/iOIlm
4xiIx48jfwrAZgygJoiDCJieglMUZ7CAs1TJBJYkFZMkm8bjMJTjWAIvHMaz
JDZXE7JV/jGXnv3N1uaqI/Snw8kitM1933zccKy4FffaXlK0im1zzMA4dE/g
XsnsW19VFuWzrmfSKBzQcyz4bAF0rIfalO9Uxq7bE06x4Tp1QM/bsck7QfKU
6mGc67fQeWt9UbdF67LRtqceu1gpfTEeF5vSvldnHNne9Oi9fJ2qD7ZwYr7F
wDmK2BDaQNla57xxtRdOrH2Ho1mivg/7QDEyoukIqWdj3BR8Y13DU14tuHV9
r4As60vh+4FpuOVhMc3xlavd7emFqS8ovMq3yl5O3TFZXY/ZMRLnpTBJ8W7h
p5LDxHWWiQ6kUWvY9qdYNj4rljoinOMJjKE3y/lJ575rrEBSsSNPpw9XxmJY
1bVe6Ho7kGdyWdfv48ktZWM19aB1zKYht3uyxCqbjcmi34V9+MI5BHSLVbui
slMlg7wtfyZfS/DnAactJJWtANEiVgrnNxXRYLB6HNAH99wskIH8qT6AfV+7
7EOHGuCzIXBcEF8hSIMUBBpIhgikTDTJUBIE8D9AFSDBfJARPkgGeGLiwxMi
8gPgpEN/BMIiBI4LjwVRZwNR40X3PRHKEH6F/uGRIY4D5I7PI4IuQ/oZ+H4S
AzBIESiBPjqOgwTA1xCYeZbIOBQAkUDGqMlI4iRGagSSRgL4jxE1pCCooiQI
Z7OhzIIwDoJghjaQeDQNYpUMA/h1ksyEBP6fgqj3AS5JkJ4zfwhroiYpiOAw
HEHnfgi4QY2T4XSU+glIpyCNsjFIqrEP3YGYzcRkCm1ncgJSCN6C/n3URaBf
mU0BUcdjwMujLJmBzAuGs3A6iaaz6XiaKJDmMVkKZ7HIJomKZ7MZQOtoBJgC
4MkIkRFIn2w4lTKGzsfTISDB8QxQDQg9gFPJFIHJJAKNJ0gmiQDoMPGnaQSw
aQwCDXBplkKbkzQBBAbI0QfYAAgfZDeMfDicpsEUDZJyBmgiAhgDww7FLBgG
02AEKD8DmJmNAVzOpv4McMAkieOZkiPAb3DEwwnIVR8wkRrNpiM/8QPYRRX4
gGYnwp9MZtEwDQM1zqIh4BO020XhMIG5JylsEYBjIK5QwnqDiEfbVQCyHOAr
oJg0DoajeCoUgDs5BiEPxBHgWRFahCAFBxp11jKEaB0oHf6vbtKFQh/RRzSE
FUhnQNH+OA2zIaxNNgpmsI8xIAtAloBmAMFMAEZEoOvEowTG7YPqGQ+RtKGL
2iYp9o2S+5frHrwjdz4/md9fLT8mwx+WST5eqkcPq+TRh+XJiSj655Nns9X8
Xvr043F/dm89ke/Onv/4aP5wFJani3jnf3z+6uXm6Yv78/n4Mlkt1/LtaPfz
j4tF/OO98udXd+/i7bz25N89enZycu/NL/PZvfOL94uL/NHsyr83f1VcPXsy
f/5sXj46fnv86HT+cDm/enU8f/9APrt3/uj49P0jcXoSD++/enDv+P786b3z
5fni4vzez6+ePZifP8nnVyf3ns1fHM9fRXPs4Pj8Cfz+YH79YVvJ8P0Ps/jx
i/nZ5pl496Rc7t6Uu5+fnFw9f/FqebyebF9F97MXxdXp6mz74cmHBz8fPz+F
kz+9//hNVa6q9fNwc2/xJJ9u5sEJ4JG3ufj+ubx6erVeXg3PXn3sz9NfgifJ
m/lmVFz+PD5+uSmeBMX21dX1vcnlo8ukUsF4fBatnjw7u1jLx8sge/H6rDoV
8SUoMy92Py/Huwcn04uXrx89yp9cPp+8v/oYJB9nwXJyeXF29vjxs6oqip8e
P7qejs+zn65evNndW/44W/0cJ28fiOmT4/5i0o+CUfExe60+hJN18eTp5U+P
84uzhx9ev8je5dkPbx/9eBwfv72ert+/9j++91dnx/c+vrtY+vfnj6/uL8Tx
63vnP2/OZyfqx9HLq8XuaXESLcYf37x8Mbu6f1oETza7bbB4+urlE/84/PD8
aZZ/L3+8Ork/fzW/d9Rj/CNqp9fcxHfdPWKR0V/hRez64Nw9Cvwj8Xf58Hf5
8Hf58J8rH5wjGOgjGLiA/Y6n4jjIVDqE5gJ/OAkSIFA/AcKABqFZIN4J6Kxq
BorvNJ3OwgnaRSIpxqDqx+kItkYmfgZEl8DRC0czOZmAngu6LHwN1ArUbVYr
6FytgFYr+JtYrb9L079L079RadrrpkRBpPjgACl+JSWKG0nRpcTJ9HHf/3j+
YR4+nv/y6kOQbuTb5HS5u6dWQj6cqdM4uyo2Z/1tcLKeXL08314XP12sVvLl
i+XlpByefW8mf2Du4jdACb8JJaIxiMthMg38OJqFapokEuT2WAErAAk4CoE9
qekUpMoU8AII1TCMklk8EyBRpuEszqJROvbHU2D+2PYQJE2UAYaYJEmWAesD
8ZOB0AF2AmI7VLNoDDwH2E2WxUqCnAl8EEQpYAXgL+F4DCI2lVGARvsJ8Mxo
IkFgT0ajLBgHwKtAyoDs8kGkAzvNJulMzqSYjWdZPB5GKojHcThEADED6BDO
MHojjNGWG6bjeBiO4kCBUI4UCDYQof4kjCYJNHhAEvkySYZxOJ7OgD8OJyCL
0zSCZZmBIJyNZBzLaDqdpkOQ6JGKxHSaJVEEIArAVAjTGQJcGssEZOAwHY8T
f5qMRypTkyEsG4pd5YP0VfjWJIizYCbjKBJ+hlbRbJxOwunYor6/y6G/WA6x
NQazRFZ3dVLRIZ5ALOG4FFfT739cJj+F734e/lSero5fvHk/ff84nT3/Wb1Y
DN+dLE7y02KR/PLswdvye/nyhx/n2cOzy/EvySZ5Nz2/93E8fPdIPHr3SO5O
7l/fr2bpT+s3x0c9hx0s3g5/+fDheHSxy54VcqzK00eXr8r3L9Lxg2Hx+uTi
pLiOV/E9cb16t3j+5mH26tl8fv84/uXKf/TxZX+Rvn08npTBs2enk5/eri4f
3X93+f7eYr46S8ofv89/OHswe38vWP2w+b6Qi1A8ev3y4Wv57qfTj+/n34+r
dwBJV5u3WXX2y6KKT/yX84vNxebVL+fboTqp3n78/unji59+mp4+/vH80ZNH
V+UIperh9fp6Fip+uzTfZ6Gik4f+RhYqfos2hga7/wtsdj5LksQAAA==
<!-- [rfced] Quoting of some items is applied inconsistently in this
document. Please let us know which form is preferred.
"token_type" / token_type (e.g., 'the token_type', 'relationship
between "token_type" and')
Please compare with usage for "issuer_name", "redemption_context",
and "origin_info".
"WWW-Authenticate" header field / WWW-Authenticate header field
Author asked about using code font. Lots of updates, so am waiting
for confirmation to go ahead. -->
</rfc> </rfc>
 End of changes. 192 change blocks. 
1166 lines changed or deleted 603 lines changed or added

This html diff was produced by rfcdiff 1.48.