<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?><!-- 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" 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 --> <front> <title abbrev="Privacy Pass Authentication">The Privacy Pass HTTP Authentication Scheme</title> <seriesInfoname="Internet-Draft" value="draft-ietf-privacypass-auth-scheme-15"/>name="RFC" value="9577"/> <author initials="T." surname="Pauly" fullname="Tommy Pauly"> <organization>Apple Inc.</organization> <address> <postal> <street>One Apple Park Way</street><city>Cupertino, California 95014</city><city>Cupertino</city> <region>California</region> <code>95014</code> <country>United States of America</country> </postal> <email>tpauly@apple.com</email> </address> </author> <author initials="S." surname="Valdez" fullname="Steven Valdez"> <organization>Google LLC</organization> <address> <email>svaldez@chromium.org</email> </address> </author> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> <organization>Cloudflare</organization> <address> <email>caw@heapingbits.net</email> </address> </author> <dateyear="2023" month="October" day="23"/>year="2024" month="May"/> <area>sec</area> <workgroup>privacypass</workgroup> <keyword>anonymous</keyword> <keyword>authorization</keyword> <keyword>crypto</keyword> <abstract> <t>This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme specified in this document can be used by clients to redeem Privacy Pass tokens with an origin. It can also be used by origins to challenge clients to present Privacy Pass tokens.</t> </abstract> </front> <middle> <section anchor="introduction"> <name>Introduction</name> <t>Privacy Pass tokens are unlinkable authenticators that can be used to anonymously authorize a client (see <xreftarget="ARCHITECTURE"/>).target="RFC9576"/>). Tokens are generated by token issuers, on the basis of authentication, attestation, or some previous action such as solving a CAPTCHA. A client possessing such a token is able to prove that it was able to get a token issued, without allowing the relying party redeeming the client's token (the origin) to link it with the issuance flow.</t> <t>Different types of authenticators, using different token issuance protocols, can be used as Privacy Pass tokens.</t> <t>This document defines a common HTTP authentication scheme (<xref section="11" sectionFormat="comma" target="RFC9110"/>), PrivateToken, that allows clients to redeem various kinds of Privacy Pass tokens.</t> <t>Clients and relying parties (origins) interact using this scheme to perform the token challenge and token redemption flow. In particular, origins challenge clients for a token with an HTTP Authentication challenge (using the WWW-Authenticate response header field). Clients can then react to that challenge by issuing a new request with a corresponding token (using the Authorization request header field). Clients generate tokens that match the origin's token challenge by running the token issuance protocol <xreftarget="ISSUANCE"/>.target="RFC9578"/>. The act of presenting a token in an Authorization request header field is referred to astoken redemption."token redemption". This interaction between the client and origin is shown below.</t> <!-- [rfced] Please review each artwork element. Specifically, should any of the artwork elements (e.g., the test-vector data in Appendix A) be tagged as sourcecode? Please see <https://www.rfc-editor.org/materials/sourcecode-types.txt>. If the current list of preferred values for "type" does not contain an applicable type, please let us know. Also, it is acceptable to leave the "type" attribute not set. --> <!-- [rfced] The SVG figures in this document have width or height specified, which will make the artwork not scale. Please consider whether scaling should be enabled. Scaling will allow the figures to be resized when viewed on a mobile device; however, there may be aesthetic trade-offs (e.g., a given image may appear too large on a desktop screen, or different figures may scale differently based on their relative sizes). Please review the HTML and PDF outputs, noting that we will need you to update the edited copy of the XML and specify the viewBox item where appropriate. The warning: Warning: Found SVG with width or height specified, which will make the artwork not scale. Specify a viewBox only to let the artwork scale. --> <figure anchor="fig-overview"> <name>Challenge andredemption protocol flow</name>Redemption Protocol Flow</name> <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"> <path d="M 8,32 L 8,64" fill="none" stroke="black"/> <path d="M 40,64 L 40,176" fill="none" stroke="black"/> <path d="M 80,32 L 80,64" fill="none" stroke="black"/> <path d="M 328,32 L 328,64" fill="none" stroke="black"/> <path d="M 360,64 L 360,112" fill="none" stroke="black"/> <path d="M 360,144 L 360,176" fill="none" stroke="black"/> <path d="M 400,32 L 400,64" fill="none" stroke="black"/> <path d="M 8,32 L 80,32" fill="none" stroke="black"/> <path d="M 328,32 L 400,32" fill="none" stroke="black"/> <path d="M 8,64 L 80,64" fill="none" stroke="black"/> <path d="M 328,64 L 400,64" fill="none" stroke="black"/> <path d="M 40,96 L 56,96" fill="none" stroke="black"/> <path d="M 336,96 L 352,96" fill="none" stroke="black"/> <path d="M 48,160 L 96,160" fill="none" stroke="black"/> <path d="M 280,160 L 360,160" fill="none" stroke="black"/> <polygon class="arrowhead" points="360,96 348,90.4 348,101.6" fill="black" transform="rotate(0,352,96)"/> <polygon class="arrowhead" points="56,160 44,154.4 44,165.6" fill="black" transform="rotate(180,48,160)"/> <g class="text"> <text x="44" y="52">Origin</text> <text x="364" y="52">Client</text> <text x="136" y="100">WWW-Authenticate:</text> <text x="268" y="100">TokenChallenge</text> <text x="284" y="132">(Run</text> <text x="340" y="132">issuance</text> <text x="416" y="132">protocol)</text> <text x="164" y="164">Authorization:</text> <text x="248" y="164">Token</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ +--------+ +--------+ | Origin | | Client | +---+----+ +---+----+ | | +-- WWW-Authenticate: TokenChallenge -->| | | | (Run issuance protocol) | | |<------ Authorization: Token ----------+ | | ]]></artwork> </artset> </figure> <t>In addition to working with different token issuance protocols, this scheme optionally supports the use of tokens that are associated with origin-chosen contexts and specific origin names. Relying parties that request and redeem tokens can choose a specific kind of token, as appropriate for its use case. These options allow for different deployment models to prevent double-spending, and allow for both interactive (online challenges) and non-interactive (pre-fetched)tokens.</t>tokens. <!-- [rfced] Section 1: Does "and allow for" refer to the options or the deployment models? Original: These options allow for different deployment models to prevent double-spending, and allow for both interactive (online challenges) and non-interactive (pre-fetched) tokens. Perhaps (the options): These options (1) allow for different deployment models to prevent double-spending and (2) allow for both interactive (online challenges) and non-interactive (pre-fetched) tokens. Or possibly (the deployment models): These options allow for different deployment models to (1) prevent double-spending and (2) allow for both interactive (online challenges) and non-interactive (pre-fetched) tokens. --> </t> <section anchor="terminology"> <name>Terminology</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 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 in TLS notation from <xreftarget="TLS13"/>, Section 3.</t>target="RFC8446" sectionFormat="comma" section="3"/>.</t> <t>This document uses the terms "Client", "Origin", "Issuer","Issuance Protocol","issuance protocol", and "Token" as defined in <xreftarget="ARCHITECTURE"/>.target="RFC9576"/>. It additionally uses the following terms in more specific ways:</t><ul<dl spacing="normal"><li>Issuer key: Keying<dt>Issuer key:</dt><dd>Keying material that can be used with an issuance protocol to create a signedtoken.</li> <li>Token challenge: Atoken.</dd> <dt>Token challenge:</dt><dd>A request for tokens sent from an origin to a client, using the "WWW-Authenticate" HTTP header field. This challenge identifies a specific token issuer and issuance protocol. Token challenges optionally include one or bothof:of the following: a redemption context (see <xreftarget="context-construction"/>),target="context-construction"/>) and a list of associated origins. These optional valuesarecan then be bound to the token that isissued.</li> <li>Token redemption: Anissued.</dd> <dt>Token redemption:</dt><dd>An action by which a client presents a token to an origin in an HTTP request, using the "Authorization" HTTP headerfield.</li> </ul>field.</dd> </dl> </section> </section> <section anchor="challenge-redemption"> <name>HTTP Authentication Scheme</name> <t>Token redemption is performed using HTTP Authentication (<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"/>). Once a client has received a token from thatissuer,issuer or already has a valid token available, it presents the token to the origin (<xref target="redemption"/>). The process of presenting a token as authentication to an origin is also referred to as "spending" a token.</t> <t>In order to prevent linkability across different transactions, clients will often present a particular "PrivateToken" only once. Origins can link multiple transactions to the same client if that client spends the same token value more than once. As such, origins ought to expect at most one unique token value, carried in one request, for each challenge.</t> <t>The rest of this section describes the token challenge and redemption interactions in more detail.</t> <section anchor="challenge"> <name>Token Challenge</name> <t>Origins send a token challenge to clients inana "WWW-Authenticate" header field with the "PrivateToken" scheme. This authentication scheme has two mandatory parameters: one containing a token challenge and another containing the token-key used for producing (and verifying) a corresponding token.</t> <t>Origins that support the "PrivateToken" authentication scheme need to handle the following tasks in constructing the WWW-Authenticate header field:</t> <ol spacing="normal" type="1"><li>Select which issuer to use, and configure the issuer name and token-key to 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 WWW-Authenticate header parameter.</li> <li>Determine a redemption context construction to include in the token challenge, as discussed in <xref target="context-construction"/>.</li> <li>Select the origin information to include in the token challenge. This can be empty to allow fully cross-origin tokens, a single origin name that matches the origin itself for per-origin tokens, or a list of origin names containing the origin itself. See <xref section="3.4" sectionFormat="of"target="ARCHITECTURE"/>target="RFC9576"/> for more information about the difference between cross-origin and per-origin tokens.</li> </ol> <t>Once these decisions are made, origins construct the WWW-Authenticate header by first constructing the token challenge as described in <xref target="challenge-structure"/>. Origins send challenges as described in <xref target="send-challenge"/>, and clients process them as described in<xref target="process-challenge"/>Sections <xref target="process-challenge" format="counter"/> and <xreftarget="caching"/>.</t>target="caching" format="counter"/>.</t> <section anchor="challenge-structure"> <name>Token Challenge Structure</name> <t>This document defines the default challenge structure that can be used across token types, although future token typesMAY<bcp14>MAY</bcp14> extend or modify the structure of the challenge; see <xref target="token-types"/> for the registry informationwhichthat establishes and defines the relationship between "token_type" and the contents of the TokenChallenge message.</t> <t>All token challengesMUST<bcp14>MUST</bcp14> begin with a 2-octet integer that defines the token type, in network byte order. This type indicates the issuance protocol used to generate the token and determines the structure and semantics of the rest of the structure. Values are registered in an IANAregistry,registry; see <xref target="token-types"/>.Client MUSTClients <bcp14>MUST</bcp14> ignore challenges with token types they do not support.</t> <t>Even when a given token type uses the default challenge structure, the requirements on the presence or interpretation of the fields can differ across token types. For example, some token types might require that "origin_info" is non-empty, while others allow it to be empty.</t> <t>The default TokenChallenge message has the following structure:</t> <artwork><![CDATA[ struct { uint16_t token_type; opaque issuer_name<1..2^16-1>; opaque redemption_context<0..32>; opaque origin_info<0..2^16-1>; } TokenChallenge; ]]></artwork> <t>The structure fields are defined as follows:</t> <ul spacing="normal"> <li>"token_type" is a 2-octet integer, in network byte order, as described above.</li> <li>"issuer_name" is an ASCII string that identifies theissuerissuer, using the format of a server name as defined in <xref target="server-name"/>. This name identifies the issuer that is allowed to issue tokens that can be redeemed by this origin. The field that stores this string in the challenge is prefixed with a 2-octet integer indicating the length, in network byte order.</li> <li>"redemption_context" is a field that is either 0 or 32 bytes, prefixed with a single octet indicating the length (either 0 or 32). If the value is non-empty, it is a 32-byte value generated by the origin that allows the origin to require that clients fetch tokens bound to a specific context, as opposed to reusing tokens that were fetched for other contexts. See <xref target="context-construction"/> for example contexts that might be useful in practice. Challenges with redemption_context values of invalid lengthsMUST<bcp14>MUST</bcp14> be ignored.</li> <li>"origin_info" is an ASCII string thatiseitherempty,is empty or contains one or more origin names that allow a token to be scoped to a specific set of origins. Each origin name uses the format of a server name as defined in <xref target="server-name"/>. The string is prefixed with a 2-octet integer indicating the length, in network byte order. If empty, any non-origin-specific token can be redeemed. If the string contains multiple origin names, they are delimited with commas","(",") without any whitespace. If this field is not empty, the OriginMUST<bcp14>MUST</bcp14> include its own name as one of the names in the list.</li> </ul> <t>If "origin_info" contains multiple origin names, this means the challenge is valid for any of the origins in the list, including the originwhichthat issued the 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 particular challenge -- including the "origin_info" field -- and then later redeem these tokens with one of the origins in the list. See <xref target="caching"/> for more discussion about token caching.</t> <section anchor="server-name"> <name>Server Name Encoding</name> <t>Server names contained in a token challenge are ASCII strings that contain a hostname and optional port, where the port is implied to be "443" if missing. The names use the format of the authority portion of a URI as defined in <xref section="3.2" sectionFormat="of"target="URI"/>.target="RFC3986"/>. The namesMUST NOT<bcp14>MUST NOT</bcp14> include a "userinfo" portion of an authority. For example, a valid server name might be "issuer.example.com" or "issuer.example.com:8443", but not "issuer@example.com".</t> </section> <section anchor="context-construction"> <name>Redemption Context Construction</name> <t>The TokenChallenge redemption context allows the origin to determine the context in which a given token can be redeemed. This value can be a unique per-request nonce, constructed from 32 freshly generated random bytes. It can also represent state or properties of the client session. Some example properties and methods for constructing the corresponding context are below. This list is not exhaustive.</t><ul<dl spacing="normal"><li>Context<dt>Context bound to a given timewindow: Constructwindow:</dt><dd>Construct the redemption context as F(current time window), where F is a pseudorandomfunction.</li> <li>Contextfunction.</dd> <dt>Context bound to a client network:</dt><dd>Construct the redemption context as F(client ASN), where F is a pseudorandom function.</dd> <dt>Context bound to a given time window and client network:</dt><dd>Construct the redemption context as F(current time window, client ASN), where F is a pseudorandom function.</dd> <!-- [rfced] Section 2.1.1.2: Is the "ASN" in "client ASN" an abbreviation? If yes, should it be defined for readers (perhaps "Autonomous System Number")? Original: * Context bound to a client network: Construct redemption context as F(client ASN), where F is a pseudorandomfunction.</li> <li>Contextfunction. * Context bound to a given time window and client network: Construct redemption context as F(current time window, client ASN), where F is a pseudorandomfunction.</li> </ul>function. --> </dl> <t>Preventingdouble spendingdouble-spending on tokens requires the origin to keep state associated with the redemption context. An empty redemption context is not bound to any property of the client request, so state to preventdouble spendingdouble-spending needs to be stored and shared across all origin servers that can accept tokens until token-key expiration or rotation. For a non-empty redemption context, thedouble spenddouble-spend state only needs to be stored across the set of origin servers that will accept tokens with that redemption context.</t> <t>Origins that share redemption contexts, i.e., by using the same redemption context, choosing the same issuer, and providing the same origin_info field in the TokenChallenge, must necessarily share state required to enforcedouble spenddouble-spend prevention. Origins should consider the operational complexity of this shared state before choosing to share redemption contexts. Failure to successfully synchronize this state and use it fordouble spenddouble-spend prevention can allow Clients to redeem tokens to one Origin that were issued after an interaction with another Origin that shares the context.</t> </section> </section> <section anchor="send-challenge"> <name>Sending Token Challenges</name> <t>When used in an authentication challenge, the "PrivateToken" scheme uses the following parameters:</t> <ul spacing="normal"> <li>"challenge", which contains abase64url-encoded <xref target="RFC4648"/>base64url TokenChallengevalue.value, encoded per <xref target="RFC4648"/>. This document follows the default padding behavior described in <xref section="3.2" sectionFormat="of" target="RFC4648"/>, so the base64url valueMUST<bcp14>MUST</bcp14> include padding. As anAuthentication Parameterauthentication parameter (<tt>auth-param</tt> from <xref section="11.2" sectionFormat="comma" target="RFC9110"/>), the value can be either a token or aquoted-string,quoted-string and might be required to be a quoted-string if the base64url string includes "=" characters. This parameter is required for all challenges.</li> <li>"token-key", which contains a base64url encoding of the public key for use with the issuance protocol indicated by the challenge. See <xreftarget="ISSUANCE"/>target="RFC9578"/> for more information about how this public key is used by the issuance protocols described in that specification. The encoding of the public key is determined by the token type; see <xref target="token-types"/>. As with "challenge", the base64url valueMUST<bcp14>MUST</bcp14> include padding. As anAuthentication Parameterauthentication parameter (<tt>auth-param</tt> from <xref section="11.2" sectionFormat="comma" target="RFC9110"/>), the value can be either a token or aquoted-string,quoted-string and might be required to be a quoted-string if the base64url string includes "=" characters. This parameterMAY<bcp14>MAY</bcp14> be omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism.</li> <li>"max-age", which is an optional parameter that consists of the number of seconds for which the challenge will be accepted by the origin.</li> </ul> <t>The header fieldMAY<bcp14>MAY</bcp14> also include the standard "realm" parameter, if desired. Issuance protocolsMAY<bcp14>MAY</bcp14> define other parameters, some of which might be required. ClientsMUST<bcp14>MUST</bcp14> ignore parameters in challenges that are not defined for the issuance protocol corresponding to the token type in the challenge.</t> <t>As an example, the WWW-Authenticate header field could look like this:</t> <artwork><![CDATA[ WWW-Authenticate: PrivateToken challenge="abc...", token-key="123..." ]]></artwork> <section anchor="sending-multiple-token-challenges"> <name>Sending Multiple Token Challenges</name> <t>It is possible for the WWW-Authenticate header field to include multiple challenges (<xref section="11.6.1" sectionFormat="comma" target="RFC9110"/>). This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts. For example, the WWW-Authenticate header field could look likethis:</t>this: <!-- [rfced] Section 2.1.2.1: This sentence does not parse. If neither suggestion below is correct, please provide clarifying text. Original: This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts. Suggestion #1 (support for different token types or different issuers): This allows the origin to indicate support for different token types or different issuers, or to include multiple redemption contexts. Suggestion #2 (support for different token types or for issuers in general): This allows the origin to indicate support for different token types or for issuers, or to include multiple redemption contexts. --> </t> <artwork><![CDATA[ WWW-Authenticate: PrivateToken challenge="abc...", token-key="123...", PrivateToken challenge="def...", token-key="234..." ]]></artwork> <t>Origins should only include challenges for different types of issuance protocols with functionally equivalent properties. For instance, both issuance protocols in <xreftarget="ISSUANCE"/>target="RFC9578"/> have the same functional properties, albeit with different mechanisms for verifying the resulting tokens during redemption. Since clients are free to choose which challenge they want to consume when presented with options, mixing multiple challenges with different functional properties for one use case is nonsensical. If the origin has a preference for one challenge over another (for example, if one uses a token type that is faster to verify), it can sort it to be first in the list of challenges as a hint to the client.</t> </section> </section> <section anchor="process-challenge"> <name>Processing Token Challenges</name> <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 in a new request. Validation requirements are as follows:</t> <ul spacing="normal"> <li>The token_type is recognized and supported by the client;</li> <li>The TokenChallenge structure is well-formed; and</li> <li>If the origin_info field is non-empty, the name of the origin that issued the authentication challenge is included in the list of origin names. Comparison of the origin name that issued the authentication challenge against elements in the origin_info list is done via case-insensitive equality checks.</li> </ul> <t>If validation fails, the clientMUST NOT<bcp14>MUST NOT</bcp14> fetch or redeem a token based on the challenge. ClientsMAY<bcp14>MAY</bcp14> have further restrictions and requirements around validating when a challenge is considered acceptable or valid. For example, clients can choose to ignore challenges that list origin names for which the current connection is not authoritative (according to the TLS certificate).</t> <t>Caching and pre-fetching of tokensisare discussed in <xref target="caching"/>.</t> </section> <section anchor="caching"> <name>Token Caching</name> <t>Clients can generate multiple tokens from a singleTokenChallenge,TokenChallenge and cache them for future use. This improves privacy by separating the time of token issuance from the time of token redemption, and also allows clients to avoidanythe overhead of receiving new tokens via the issuance protocol.</t> <t>Cached tokens can only be redeemed when they match all of the fields in the TokenChallenge: token_type, issuer_name, redemption_context, and origin_info. Clients ought to store cached tokens based on all of these fields, to avoid trying to redeem a token that does not match. Note that each token has a unique client nonce, which is sent in token redemption (<xref target="redemption"/>).</t> <t>If a client fetches a batch of multiple tokens for future use that are bound to a specific redemption context (the redemption_context in the TokenChallenge was not empty), clientsSHOULD<bcp14>SHOULD</bcp14> discard these tokens upon flushing state such as HTTP cookies <xreftarget="COOKIES"/>,target="I-D.ietf-httpbis-rfc6265bis"/>, or if there is a network change and the client does not have any origin-specific state like HTTP cookies. Using these tokens in a context that otherwise would not be linkable to the original context could allow the origin to recognize a client.</t> </section> </section> <section anchor="redemption"> <name>Token Redemption</name> <t>The output of the issuance protocol is a token that corresponds to the origin's challenge (see <xref target="challenge"/>).</t> <section anchor="token-structure"> <name>Token Structure</name> <t>A token is a structure that begins with a two-octet field that indicates a token type, whichMUST<bcp14>MUST</bcp14> match the token_type in the TokenChallenge structure. This value 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 token types, although future token typesMAY<bcp14>MAY</bcp14> extend or modify the structure of the token; see <xref target="token-types"/> for the registry informationwhichthat establishes and defines the relationship between "token_type" and the contents of the Token structure.</t> <t>The default Token message has the following structure:</t> <artwork><![CDATA[ struct { uint16_t token_type; uint8_t nonce[32]; uint8_t challenge_digest[32]; uint8_t token_key_id[Nid]; uint8_t authenticator[Nk]; } Token; ]]></artwork> <t>The structure fields are defined as follows:</t> <ul spacing="normal"> <li>"token_type" is a 2-octet integer, in network byte order, as described above.</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 the original TokenChallenge, SHA-256(TokenChallenge), where SHA-256 is as defined in <xref target="SHS"/>. Changing the hash function to something other than SHA-256 would require defining a new token type and token structure (since the contents of challenge_digest would be computed differently), which can be done in a future specification.</li> <li>"token_key_id" is a Nid-octet identifier for the token authentication key. The value of this field is defined by the token_type and corresponding issuance protocol.</li> <li>"authenticator" is a Nk-octet authenticator that is cryptographically bound 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 corresponding issuance protocol determine the value of the authenticator field and how it is computed. The value of constant Nk depends on token_type, as defined in <xref target="token-types"/>.</li> </ul> <t>The authenticator value in the Token structure is computed over the token_type, nonce, challenge_digest, and token_key_id fields. A token is considered a valid if token verification using succeeds; see <xref target="verification"/> for details about verifying the token and its authenticatorvalue.</t>value. <!-- [rfced] Section 2.2.1: This sentence does not parse. If the suggested text is not correct, please provide clarifying text. Original: A token is considered a valid if token verification using succeeds; see Section 2.2.3 for details about verifying the token and its authenticator value. Suggested: A token is considered valid if token verification succeeds; see Section 2.2.3 for details about verifying the token and its authenticator value. --> </t> </section> <section anchor="sending-tokens"> <name>Sending Tokens</name> <t>When used for client authorization, the "PrivateToken" authentication scheme defines one parameter, "token", which contains the base64url-encoded Tokenstruct.structure. As with the challenge parameters (<xref target="challenge"/>), the base64url valueMUST<bcp14>MUST</bcp14> include padding. As anAuthentication Parameterauthentication parameter (<tt>auth-param</tt> from <xref section="11.2" sectionFormat="comma" target="RFC9110"/>), the value can be either a token or aquoted-string,quoted-string and might be required to be a quoted-string if the base64url string includes "=" characters. All unknown or unsupported parameters to "PrivateToken" authentication credentialsMUST<bcp14>MUST</bcp14> be ignored.</t> <t>Clients present this Token structure to origins in a new HTTP request using the Authorization header field as follows:</t> <artwork><![CDATA[ Authorization: PrivateToken token="abc..." ]]></artwork> <t>For context-bound tokens, origins store or reconstruct the contexts of previous TokenChallenge structures in order to validate the token. A TokenChallenge can be bound to a specific TLS session with a client, but origins can also accept tokens for valid challenges in new sessions. OriginsSHOULD<bcp14>SHOULD</bcp14> implement some form of double-spend prevention that prevents a token with the same nonce from being redeemed twice. Double-spend prevention ensures that clients cannot replay tokens for previous challenges. See <xref target="replay-attacks"/> for more information about replay attacks. For context-bound tokens, this double-spend prevention can require no state or minimal state, since the context can be used to verify token uniqueness.</t> </section> <section anchor="verification"> <name>Token Verification</name> <t>A token consists of some input cryptographically bound to an authenticator value, such as a digital signature. Verifying a token consists of checking that the authenticator value is correct.</t> <t>The authenticator value is as computed when running and finalizing the issuance protocol corresponding to the token type with the followingvaluevalues as the input:</t> <artwork><![CDATA[ struct { uint16_t token_type; uint8_t nonce[32]; uint8_t challenge_digest[32]; uint8_t token_key_id[Nid]; } AuthenticatorInput; ]]></artwork> <t>Thevaluevalues of these fields are as described in <xreftarget="redemption"/>.target="token-structure"/>. The cryptographic verification check depends on the token type; see<xrefSections <xref target="RFC9578" section="5.4"sectionFormat="of" target="ISSUANCE"/>sectionFormat="bare"/> and <xref target="RFC9578" section="6.4"sectionFormat="of" target="ISSUANCE"/>sectionFormat="bare"/> of <xref target="RFC9578"/> for verification instructions for the issuance protocols described in<xref target="ISSUANCE"/>.that specification. As such, the security properties of the token, e.g., the probability that one can forge an authenticator value without invoking the issuance protocol, depend on the cryptographic algorithm used by the issuance protocol as determined by the tokentype.</t>type. <!-- [rfced] Section 2.2.3: Because the cited information is in Section 2.2.1 and this text is also part of Section 2.2, we updated this sentence as follows. If this is incorrect, please provide clarifying text. Original: The value of these fields are as described in Section 2.2. Currently (also fixed the subject-verb disagreement): The values of these fields are as described in Section 2.2.1. --> </t> </section> </section> </section> <section anchor="client-behavior"> <name>Client Behavior</name> <t>When a client receives one or more token challenges in response to a request, the client has a set of choices to make:</t> <ul spacing="normal"> <li>Whether or not to redeem a token via a new request to the origin.</li> <li>Whether to redeem a previously issued and cachedtoken,token or redeem a token freshly issued from the issuance protocol.</li> <li>If multiple challenges were sent, which challenge to use for redeeming a token on a subsequent request.</li> </ul> <t>The approach to these choices depends on the use case of the application, as well as the deployment model (see <xref section="4" sectionFormat="of"target="ARCHITECTURE"/>target="RFC9576"/> for discussion of the different deployment models).</t> <section anchor="choosing-to-redeem-tokens"> <name>Choosing to Redeem Tokens</name> <t>Some applications of tokens might require clients to always present a token as authentication in order to successfully make requests. For example, a restricted service that wants to only allow access to validusers,users but wants to do so without learning specific user credentialinformation,information could use tokens that are based on attesting user credentials. In these kinds of use cases, clients will need to always redeem a token in order to successfully make a request.</t> <t>Many other use cases for Privacy Pass tokens involve open services that must work with any client, including those that either cannot redeemtokens,tokens or can only sometimes redeem tokens. For example, a service can use tokens as a way to reduce the incidence of presenting CAPTCHAs to users. In such use cases, services will regularly encounter clients that cannot redeem a token or choose not to. In order to mitigate the risk of these services relying on always receiving tokens, clients that are capable of redeeming tokens can ignore token challenges (and instead behave as if they were a client that either doesn't support redeeming tokens or is unable to generate a new token, by not sending a new request that contains a token to redeem) with some non-trivial probability. See <xref section="5.1" sectionFormat="of"target="ARCHITECTURE"/>target="RFC9576"/> for further considerationsonregarding avoiding discriminatory behavior across clients when using Privacy Pass tokens.</t> <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 challenging origin. For example, if a client's ability to generate tokens via anattesterAttester and issuer is limited to a certain rate, a malicious origin could send an excessive number of token challenges with unique redemption contexts in order tocause(1) cause the client to exhaust its ability to generate newtokens,tokens orto overwhelm(2) overwhelm issuance servers.The limits here will vary basedBased on the specific deployment, the limits here will vary, but clientsSHOULD<bcp14>SHOULD</bcp14> have some implementation-specific policy to minimize the number of tokens that can be retrieved by origins.</t> </section> <section anchor="choosing-between-multiple-challenges"> <name>ChoosingBetweenbetween Multiple Challenges</name> <t>A single response from an origin can include multiple token challenges. For example, a set of challenges could include different token types and issuers, to allow clients to choose a preferred issuer or type.</t> <t>If clients choose to respond, clients should satisfy exactly one of the challenges presented. The choice of which challenge to use for redeeming tokens is up to client policy. This can involve which token types are supported or preferred, which issuers are supported or preferred, or whether or not the client is able to use cached tokens based on the redemption context or origin information in the challenge. See <xref target="caching"/> for more discussion on token caching. Regardless of how the choice is made, itSHOULD<bcp14>SHOULD</bcp14> be done in a consistent manner to ensure that the choice does not reveal information about the specific client; see <xref section="6.2" sectionFormat="of"target="ARCHITECTURE"/>target="RFC9576"/> for more details on the privacy implications of issuance consistency.</t> </section> </section> <section anchor="origin-behavior"> <name>Origin Behavior</name> <t>Origins choose what token challenges to send toclients, whichclients; these token challenges willvaryvary, depending on the use case and deployment model. The origin chooses which token types, issuers, redemption contexts, and origininfoinformation to include in challenges. If an origin sends multiple challenges, each challengeSHOULD<bcp14>SHOULD</bcp14> be equivalent in terms of acceptability for token redemption, since clients are free to choose to generate tokens based on any of the challenges.</t> <t>Origins ought to consider the time involved in token issuance. Particularly, a challenge that includes a unique redemption context will prevent a client from using cachedtokens,tokens and thus can add more delay before the client is able to redeem a token.</t> <t>OriginsSHOULD<bcp14>SHOULD</bcp14> minimize the number of challenges sent to a particular client context (referred to as the "redemption context" in <xref section="3.3" sectionFormat="of"target="ARCHITECTURE"/>),target="RFC9576"/>), to avoid overwhelming clients and issuers with token requests that might cause clients to hit rate limits.</t> <section anchor="greasing"> <name>Greasing</name> <t>In order to prevent clients from becoming incompatible with new token challenges, originsSHOULD<bcp14>SHOULD</bcp14> include random token types, from the Reserved list of "greased" types (defined in <xref target="token-types"/>), with some non-trivial probability.</t> <t>Additionally, for deployments where tokens are not required (such as when tokens are used as a way toavoidingavoid showing CAPTCHAs), originsSHOULD randomly<bcp14>SHOULD</bcp14> randomly choose to not challenge clients for tokens with some non-trivial probability. This helps origins ensure that their behavior for handling clients that cannot redeem tokens is maintained and exercised consistently.</t> </section> </section> <section anchor="sec-considerations"> <name>Security Considerations</name> <t>This section contains security considerations for the PrivateToken authentication scheme described in this document.</t> <section anchor="randomness-requirements"> <name>Randomness Requirements</name> <t>All random values in the challenge and tokenMUST<bcp14>MUST</bcp14> be generated using a cryptographically secure source of randomness(<xref target="RFC4086"/>).</t><xref target="RFC4086"/>.</t> </section> <section anchor="replay-attacks"> <name>Replay Attacks</name> <t>ApplicationsSHOULD<bcp14>SHOULD</bcp14> constrain tokens to a single origin unless the use case can accommodate replay attacks. Replaying tokens is not necessarily a security or privacy problem. As an example, it is reasonable for clients to replay tokens in contexts where token redemption does not induce side effects and in which client requests are already linkable. One possible setting where this applies is where tokens are sent as part of 0-RTT data.</t> <t>If successful token redemption produces side effects, originsSHOULD<bcp14>SHOULD</bcp14> implement an anti-replay mechanism to mitigate the harm of such replays. See <xref section="8" sectionFormat="comma"target="TLS13"/>target="RFC8446"/> and <xref section="9.2" sectionFormat="comma" target="RFC9001"/> for details about anti-replay mechanisms, as well as <xref section="3" sectionFormat="comma" target="RFC8470"/> for discussion about safety considerations for 0-RTT HTTP data.</t> </section> <section anchor="reflection-attacks"> <name>Reflection Attacks</name> <t>The security properties of token challengesvaryvary, depending on whether the challenge contains a redemption context or not, as well as whether the challenge is a per-origin challenge or not. For example, cross-origin tokens with empty contexts can be reflected from one party by another, as shown below.</t> <!-- [rfced] Figure 2: a) As the title of Section 5.3 is "Reflection Attacks" as opposed to Section 5.2 ("Replay Attacks"), should the title of Figure 2 be "Reflection Attack Example" instead of "Replay Attack Example"? Original: Figure 2: Replay attack example Currently: Figure 2: Replay Attack Example Possibly: Figure 2: Reflection Attack Example b) 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. --> <figure anchor="fig-replay"> <name>Replayattack example</name>Attack Example</name> <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"> <path d="M 8,32 L 8,64" fill="none" stroke="black"/> <path d="M 40,64 L 40,160" fill="none" stroke="black"/> <path d="M 80,32 L 80,64" fill="none" stroke="black"/> <path d="M 176,32 L 176,64" 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 392,32 L 392,64" 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 8,32 L 80,32" fill="none" stroke="black"/> <path d="M 176,32 L 264,32" fill="none" stroke="black"/> <path d="M 392,32 L 464,32" fill="none" stroke="black"/> <path d="M 8,64 L 80,64" fill="none" stroke="black"/> <path d="M 176,64 L 264,64" fill="none" stroke="black"/> <path d="M 392,64 L 464,64" fill="none" stroke="black"/> <path d="M 40,96 L 56,96" fill="none" stroke="black"/> <path d="M 192,96 L 208,96" fill="none" stroke="black"/> <path d="M 216,112 L 232,112" fill="none" stroke="black"/> <path d="M 224,128 L 288,128" fill="none" stroke="black"/> <path d="M 352,128 L 424,128" fill="none" stroke="black"/> <path d="M 48,144 L 64,144" fill="none" stroke="black"/> <polygon class="arrowhead" points="232,128 220,122.4 220,133.6" fill="black" transform="rotate(180,224,128)"/> <polygon class="arrowhead" points="216,96 204,90.4 204,101.6" fill="black" transform="rotate(0,208,96)"/> <polygon class="arrowhead" points="56,144 44,138.4 44,149.6" fill="black" transform="rotate(180,48,144)"/> <g class="text"> <text x="44" y="52">Origin</text> <text x="220" y="52">Attacker</text> <text x="428" y="52">Client</text> <text x="124" y="100">TokenChallenge</text> <text x="276" y="116">(reflect</text> <text x="356" y="116">challenge)</text> <text x="412" y="116">-></text> <text x="320" y="132">Token</text> <text x="108" y="148">(reflect</text> <text x="172" y="148">token)</text> <text x="208" y="148">-</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ +--------+ +----------+ +--------+ | Origin | | Attacker | | Client | +---+----+ +----+-----+ +---+----+ | | | +-- TokenChallenge -->| | | +-- (reflect challenge) ->| | |<-------- Token ---------+ |<-- (reflect token) -+ | | | ]]></artwork> </artset> </figure> </section> <section anchor="token-exhaustion-attacks"> <name>Token Exhaustion Attacks</name> <t>When a Client holds cross-origin tokens with empty contexts, it is possible for any Origin in the cross-origin set to deplete thatClientClient's 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 a single Origin. Alternatively, if tokens arecross-Origin,cross-Origin tokens, Clients can use alternate methods to prevent many tokens from being redeemed at once. For example, if the Origin requests an excess of tokens, the Client could choose to not present any tokens for verification if a redemption had already occurred in a given time window.</t> <t>Token challenges that include non-empty origin_info bind tokens to one or more specific origins. As described in <xref target="challenge"/>, clients only accept such challenges from origin names listed in the origin_info string. 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 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 "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 origin_info string of"b.example.com" or "b.example.com,a.example.com""b.example.com", "b.example.com,a.example.com", or "a.example.com,b.example.com,c.example.com", the string would notmatchmatch, and the client would need to use a differenttoken.</t>token. <!-- [rfced] Section 5.4: Apologies if we're missing something obvious, but it appears to us that this sentence conflicts with item 3. in Section 2.1 ("Select the origin information to include in the token challenge. This can be empty ..."). Please confirm that this sentence and the citation will be clear to readers. Original (the previous sentence is included for context): Token challenges that include non-empty origin_info bind tokens to one or more specific origins. As described in Section 2.1, clients only accept such challenges from origin names listed in the origin_info string. --> </t> </section> <section anchor="timing-correlation-attacks"> <name>Timing Correlation Attacks</name> <t>Context-bound token challenges require clients to obtain matching tokens when challenged, rather than presenting a token that was obtained from a different context in the past. This can make it more likely that issuance and redemption events will occur at approximately the same time. For example, if a client is challenged for a token with a unique context at time T1 and then subsequently obtains a token at time T2, a colluding issuer and origin can link this to the same client if T2 is unique to the client. This linkability is less feasible as the number of issuance events at time T2 increases. Depending on the "max-age" token challenge parameter, clientsMAY<bcp14>MAY</bcp14> try to add delay to the time between being challenged and redeeming a token to make this sort of linkability more difficult. For more discussion on correlation risks between token issuance and redemption, see <xref section="6.3" sectionFormat="of"target="ARCHITECTURE"/>.</t>target="RFC9576"/>.</t> </section> <section anchor="cross-context-linkability-attacks"> <name>Cross-Context Linkability Attacks</name> <t>As discussed in <xref target="challenge"/>, clientsSHOULD<bcp14>SHOULD</bcp14> discard any context-bound tokens upon flushing cookies or changing networks, to prevent an origin from using the redemption context state as a cookie to recognize clients.</t> </section> </section> <section anchor="iana"> <name>IANA Considerations</name> <section anchor="authentication-scheme"> <name>Authentication Scheme</name><t>This document registers<t>IANA has registered the "PrivateToken" authentication scheme in the "HTTP Authentication Schemes" subregistry of the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" as defined in <xref section="16.4" sectionFormat="comma" target="RFC9110"/>.</t> <dl> <dt>Authentication Scheme Name:</dt><dd> <t>PrivateToken</t> </dd> <dt>Pointer to specification text:</dt> <dd> <t><xref target="challenge-redemption"/> of this document</t> </dd><dd>PrivateToken</dd> <dt>Reference:</dt> <dd>RFC 9577, <xref target="challenge-redemption"/></dd> </dl> </section> <section anchor="token-types"><name>Token<name>Privacy Pass Token Type Registry</name> <t>IANAis requested to createhas created a new "Privacy Pass Token Type" registry in a new "PrivacyPass Parameters"Pass" page to list identifiers for issuance protocols defined for use with the Privacy Pass token authentication scheme. These identifiers are two-byte values, so the maximum possible value is 0xFFFF =65535.</t>65535. <!-- [rfced] We have included some specific questions about the IANA text in the document. In addition to responding to those questions, please review all of the IANA-related updates carefully and let us know if any further updates are needed. a) Section 6.2: FYI - We updated "Privacy Pass Parameters" to "Privacy Pass" to match the title on the IANA page: <https://www.iana.org/assignments/privacy-pass>. IANA notes, 'Whenever possible, we're trying to leave the words "Parameters" and "Registry" out of titles, except where doing so causes confusion.' b) Section 6.2: Because the "Privacy Pass Token Type" registry contains multiple entries, we suggest changing the registry name from "Privacy Pass Token Type" to "Privacy Pass Token Types" (plural "Types"). If you agree, we will ask IANA to to update the registry at <https://www.iana.org/assignments/privacy-pass/> accordingly. Original: 6.2. Token Type Registry IANA is requested to create a new "Privacy Pass Token Type" registry in a new "Privacy Pass Parameters" page to list identifiers for issuance protocols defined for use with the Privacy Pass token authentication scheme. Perhaps: 6.2. Privacy Pass Token Types Registry IANA has created a new "Privacy Pass Token Types" registry in a new "Privacy Pass" page to list identifiers for issuance protocols defined for use with the Privacy Pass token authentication scheme. c) Sections 6.2 and 6.2.1: The "Privacy Pass Token Type" registry (https://www.iana.org/assignments/privacy-pass) includes a "Change Controller" column, but "Change Controller" is not included in the lists in these sections. Should it be included? If so, we'll place it after "Nid" and before "Reference" to correspond with the order in the registry. We will also need you to provide an appropriate description to include for Section 6.2. d) Sections 6.2 and 6.2.1: Section 6.2 uses "Public Verifiability" while Section 6.2.1 and the "Privacy Pass Token Type" registry (https://www.iana.org/assignments/privacy-pass) use "Publicly Verifiable". Which phrasing is preferred? If needed, we will ask IANA to update the registry. We will also update Sections 8.2.1 and 8.2.2 of RFC-to-be 9578 if needed. Section 6.2: Public Verifiability Section 6.2.1: Publicly Verifiable Registry: Publicly Verifiable e) Section 6.2: Please confirm that "Section 2.2" is correct here. We do not see "token-key" in Section 2.2, but we do see it defined in Section 2.1. We see "token_key_id" in Section 2.2. Original: Token Key Encoding: The encoding of the "token-key" parameter in Section 2.2 --> </t> <t>New registrations need to list the following attributes:</t> <dl spacing="compact"> <dt>Value:</dt> <dd><t>TheThe two-byte identifier for thealgorithm</t> </dd>algorithm.</dd> <dt>Name:</dt><dd> <t>Name<dd>Name of the issuanceprotocol</t> </dd>protocol.</dd> <dt>Token Structure:</dt><dd> <t>The<dd>The contents of the Tokenstructure instructure; see <xreftarget="redemption"/></t> </dd>target="redemption"/>.</dd> <dt>Token Key Encoding:</dt><dd> <t>The<dd>The encoding of the "token-key"parameter inparameter; see <xreftarget="redemption"/></t> </dd>target="redemption"/>.</dd> <dt>TokenChallenge Structure:</dt><dd> <t>The<dd>The contents of the TokenChallengestructure instructure; see <xreftarget="challenge"/></t> </dd>target="challenge"/>.</dd> <dt>Public Verifiability:</dt><dd> <t>A<dd>A Y/N value indicating if the output tokens have the public verifiability property; see <xref section="3.5" sectionFormat="of"target="ARCHITECTURE"/>target="RFC9576"/> for more details about thisproperty.</t> </dd>property.</dd> <dt>Public Metadata:</dt><dd> <t>A<dd>A Y/N value indicating if the output tokens can contain public metadata; see <xref section="3.5" sectionFormat="of"target="ARCHITECTURE"/>target="RFC9576"/> for more details about thisproperty.</t> </dd>property.</dd> <dt>Private Metadata:</dt><dd> <t>A<dd>A Y/N value indicating if the output tokens can contain private metadata; see <xref section="3.5" sectionFormat="of"target="ARCHITECTURE"/>target="RFC9576"/> for more details about thisproperty.</t> </dd>property.</dd> <dt>Nk:</dt><dd> <t>The<dd>The length in bytes of an outputauthenticator</t> </dd>authenticator.</dd> <dt>Nid:</dt><dd> <t>The<dd>The length of the token keyidentifier</t> </dd>identifier.</dd> <dt>Reference:</dt><dd> <t>Where<dd>Where this algorithm isdefined</t> </dd>defined.</dd> <dt>Notes:</dt><dd> <t>Any<dd>Any notes associated with theentry</t> </dd>entry.</dd> </dl> <t>New entries in this registry are subject to the Specification Required 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 redemption. Additionally, the experts can reject registrations on the basis that they do not meet the security and privacy requirements for issuance protocols defined in <xref section="3.2" sectionFormat="of"target="ARCHITECTURE"/>.</t>target="RFC9576"/>.</t> <t><xreftarget="ISSUANCE"/>target="RFC9578"/> defines entries for this registry.</t> <section anchor="reserved-values"> <name>Reserved Values</name> <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 ensure that implementations remain able to handle unknown token types gracefully (this technique is inspired by <xref target="RFC8701"/>). ImplementationsSHOULD<bcp14>SHOULD</bcp14> select reserved values at random when including them in greased messages. Servers can include these in TokenChallenge structures, either as the only challenge when no real token type isdesired,desired or as one challenge in a list of challenges that include real values. Clients can include these in Token structures when they are not able to present a real token. The contents of the Token structureSHOULD<bcp14>SHOULD</bcp14> be filled with random bytes when using greased values.</t> <t>The initial contentsforof this registryconsistsconsist of multiple reserved values, with the following attributes, which are repeated for each registration:</t> <dl spacing="compact"> <dt>Value:</dt><dd> <t>0x0000,<dd>0x0000, 0x02AA, 0x1132, 0x2E96, 0x3CD3, 0x4473, 0x5A63, 0x6D32, 0x7F3F, 0x8D07, 0x916B, 0xA6A4, 0xBEAB, 0xC3F3, 0xDA42, 0xE944,0xF057</t> </dd>0xF057</dd> <dt>Name:</dt><dd> <t>RESERVED</t> </dd><dd>RESERVED</dd> <dt>Token Structure:</dt><dd> <t>Random bytes</t> </dd><dd>Random bytes</dd> <dt>Token Key Encoding:</dt><dd> <t>Random bytes</t> </dd><dd>Random bytes</dd> <dt>TokenChallenge Structure:</dt><dd> <t>Random bytes</t> </dd><dd>Random bytes</dd> <dt>Publicly Verifiable:</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>Public Metadata:</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>Private Metadata:</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>Nk:</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>Nid:</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>Reference:</dt><dd> <t>This document</t> </dd><dd>RFC 9577</dd> <dt>Notes:</dt><dd> <t>None</t> </dd><dd>None</dd> </dl> </section> </section> </section> </middle> <back> <displayreference target="RFC9576" to="ARCHITECTURE"/> <displayreference target="RFC8446" to="TLS13"/> <displayreference target="RFC3986" to="URI"/> <displayreference target="RFC9578" to="ISSUANCE"/> <displayreference target="I-D.ietf-httpbis-rfc6265bis" to="COOKIES"/> <references> <name>References</name> <references> <name>Normative References</name> <!-- draft-ietf-privacypass-architecture (RFC 9576) --> <referenceanchor="ARCHITECTURE">anchor="RFC9576" target="https://www.rfc-editor.org/info/rfc9576"> <front> <title>The Privacy Pass Architecture</title> <authorfullname="Alex Davidson" initials="A." surname="Davidson"> <organization>LIP</organization>initials='A' surname='Davidson' fullname='Alex Davidson'> <organization /> </author> <authorfullname="Jana Iyengar" initials="J." surname="Iyengar"> <organization>Fastly</organization>initials='J' surname='Iyengar' fullname='Jana Iyengar'> <organization /> </author> <authorfullname="Christopherinitials='C. A.' surname='Wood' fullname='Christopher A.Wood" initials="C. A." surname="Wood"> <organization>Cloudflare</organization>Wood'> <organization /> </author> <dateday="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> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-architecture-16"/> </reference> <reference anchor="RFC9110"> <front> <title>HTTP Semantics</title> <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/> <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/> <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/> <date month="June" year="2022"/> <abstract> <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t> <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t> </abstract> </front> <seriesInfo name="STD" value="97"/> <seriesInfo name="RFC" value="9110"/> <seriesInfo name="DOI" value="10.17487/RFC9110"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract>year='2024' month='May'/> </front> <seriesInfoname="BCP" value="14"/> <seriesInfoname="RFC"value="2119"/>value="9576"/> <seriesInfo name="DOI"value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="TLS13"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <date month="August" year="2018"/> <abstract> <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="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 characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="66"/> <seriesInfo name="RFC" value="3986"/> <seriesInfo name="DOI" value="10.17487/RFC3986"/> </reference> <reference anchor="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 data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4648"/> <seriesInfo name="DOI" value="10.17487/RFC4648"/>value="10.17487/RFC9576"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> <reference anchor="SHS" target="https://doi.org/10.6028/nist.fips.180-4"> <front> <title>Secure HashStandard</title> <author fullname="Quynh H. Dang" surname="Dang"/>Standard (SHS)</title> <author> <organization>National Institute of Standards and Technology</organization> </author> <datemonth="July"month="August" year="2015"/> </front> <seriesInfoname="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 constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t> <t>This is the third edition of this document; it obsoletes RFC 5226.</t> </abstract> </front> <seriesInfo name="BCP" value="26"/> <seriesInfo name="RFC" value="8126"/>name="NIST FIPS Publication" value="180-4"/> <seriesInfo name="DOI"value="10.17487/RFC8126"/>value="10.6028/NIST.FIPS.180-4"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> </references> <references> <name>Informative References</name> <!-- draft-ietf-privacypass-protocol (RFC 9578) --> <referenceanchor="ISSUANCE">anchor="RFC9578" target="https://www.rfc-editor.org/info/rfc9578"> <front> <title>Privacy Pass Issuance Protocol</title> <authorfullname="Sofia Celi"initials="S."surname="Celi">surname="Celi" fullname="Sofia Celi"> <organization>Brave Software</organization> </author> <authorfullname="Alex Davidson"initials="A."surname="Davidson">surname="Davidson" fullname="Alex Davidson"> <organization>Brave Software</organization> </author> <authorfullname="Steven Valdez"initials="S."surname="Valdez">surname="Valdez" fullname="Steven Valdez"> <organization>Google LLC</organization> </author> <authorfullname="Christopher A. Wood"initials="C. A."surname="Wood">surname="Wood" fullname="Christopher A. Wood"> <organization>Cloudflare</organization> </author> <dateday="3" month="October" year="2023"/> <abstract> <t> This document specifies two variants of the two-message issuance 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> </abstract>month="May" year="2024"/> </front> <seriesInfoname="Internet-Draft" value="draft-ietf-privacypass-protocol-16"/>name="RFC" value="9578"/> <seriesInfo name="DOI" value="10.17487/RFC9578"/> </reference> <!-- draft-ietf-httpbis-rfc6265bis (I-D Exists) "Long way" to include editor designations --> <referenceanchor="COOKIES">anchor="I-D.ietf-httpbis-rfc6265bis"> <front> <title>Cookies: HTTP State Management Mechanism</title> <author fullname="Steven Bingler" initials="S."surname="Bingler">surname="Bingler" role="editor"> <organization>Google LLC</organization> </author> <author fullname="Mike West" initials="M."surname="West">surname="West" role="editor"> <organization>Google LLC</organization> </author> <author fullname="John Wilander" initials="J."surname="Wilander">surname="Wilander" role="editor"> <organization>Apple, Inc</organization> </author> <dateday="10" month="May"day="15" month="November" year="2023"/><abstract> <t> This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. </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 3rd"/> <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 that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t> <t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="106"/> <seriesInfo name="RFC" value="4086"/> <seriesInfo name="DOI" value="10.17487/RFC4086"/> </reference> <reference anchor="RFC9001"> <front> <title>Using TLS to Secure QUIC</title> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/> <author fullname="S. Turner" initials="S." role="editor" surname="Turner"/> <date month="May" year="2021"/> <abstract> <t>This document describes how Transport Layer Security (TLS) is used to secure QUIC.</t> </abstract> </front> <seriesInfo name="RFC" value="9001"/> <seriesInfo name="DOI" value="10.17487/RFC9001"/> </reference> <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 communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.</t> </abstract> </front> <seriesInfo name="RFC" value="8470"/> <seriesInfo name="DOI" value="10.17487/RFC8470"/> </reference> <reference anchor="RFC8701"> <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 ensure peers correctly handle unknown values.</t> </abstract> </front> <seriesInfo name="RFC" value="8701"/> <seriesInfo name="DOI" value="10.17487/RFC8701"/>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"/> </references> </references> <section anchor="test-vectors"> <name>Test Vectors</name> <t>This section includes test vectors for the HTTP authentication scheme specified in this document. It consists of the following types of test vectors:</t> <ol spacing="normal" type="1"><li>Test vectors for the challenge and redemption protocols. Implementations can use these test vectors for verifying code that builds and encodes TokenChallenge structures, as well as code that produces a well-formed Token bound to a TokenChallenge.</li> <li>Test vectors for the HTTP headers used for authentication. Implementations can use these test vectors for validating whether they parse HTTP authentication headers correctly to produce TokenChallenge structures and the other associated parameters, such as the token-key and max-age values.</li> </ol> <section anchor="challenge-and-redemption-structure-test-vectors"> <name>Challenge and Redemption Structure Test Vectors</name> <t>This section includes test vectors for the challenge and redemption functionalities described in<xref target="challenge"/>Sections <xref target="challenge" format="counter"/> and <xreftarget="redemption"/>.target="redemption" format="counter"/>. Each test vector lists the following values:</t><ul<dl spacing="normal"><li>token_type: The<dt>token_type:</dt><dd>The type of token issuanceprotocol,protocol -- a value from <xref target="token-types"/>. For these test vectors, token_type is 0x0002, corresponding to the issuance protocol in <xreftarget="ISSUANCE"/>.</li> <li>issuer_name:target="RFC9578"/>. <!-- [rfced] Appendix A.1: Because two issuance protocols are defined in [ISSUANCE] and we see "both issuance protocols in [ISSUANCE]" in Section 2.1.2.1, may we clarify this text by updating as suggested below? Original (the previous phrase is included for context): * token_type: The type of token issuance protocol, a value from Section 6.2. For these test vectors, token_type is 0x0002, corresponding to the issuance protocol in [ISSUANCE]. Suggested: token_type: The type of token issuance protocol - a value from Section 6.2. For these test vectors, token_type is 0x0002, corresponding to token issuance protocol 2; see Appendix B of [ISSUANCE]. --> </dd> <dt>issuer_name:</dt><dd> The name of the issuer in the TokenChallenge structure, represented as a hexadecimalstring.</li> <li>redemption_context: Thestring.</dd> <dt>redemption_context:</dt><dd>The redemption context in the TokenChallenge structure, represented as a hexadecimalstring.</li> <li>origin_info:string.</dd> <dt>origin_info:</dt><dd> The origininfoinformation in the TokenChallenge structure, represented as a hexadecimalstring.</li> <li>nonce: Thestring.</dd> <dt>nonce:</dt><dd>The nonce in the Token structure, represented as a hexadecimalstring.</li> <li>token_key:string.</dd> <!-- [rfced] Appendix A.1: Is "token_key" here correct? "token_key_id" is used in the test vectors in this section. We do not see "token_key" elsewhere in the document (though we do see "token-key"). Original: * token_key: The public token-key, encoded based on the corresponding token type, represented as a hexadecimalstring.</li> <li>token_authenticator_input: Thestring. --> <dt>token_key:</dt><dd>The public token-key, encoded based on the corresponding token type, represented as a hexadecimal string.</dd> <dt>token_authenticator_input:</dt><dd>The values in the Token structure used to compute the Token authenticator value, represented as a hexadecimalstring.</li> </ul>string.</dd> </dl> <t>Test vectors are provided for each of the following TokenChallenge configurations:</t> <ol spacing="normal" type="1"><li>TokenChallenge with a single origin and non-empty redemptioncontext</li>context.</li> <li>TokenChallenge with a single origin and empty redemptioncontext</li>context.</li> <li>TokenChallenge with an empty origin and redemptioncontext</li>context.</li> <li>TokenChallenge with an empty origin and non-empty redemptioncontext</li>context.</li> <li>TokenChallenge withamultiple origins and non-empty redemptioncontext</li>context.</li> <li>TokenChallenge forgreasing</li>greasing.</li> <!-- [rfced] Appendix A.1: We changed "a multiple origins" to "multiple origins" here. Should "and non-empty redemption context" be "and a non-empty redemption context" (as appears to be the case for the "// Test vector 5" entry), or should it be "and non-empty redemption contexts"? Original: 5. TokenChallenge with a multiple origins and non-empty redemption context Currently: 5. TokenChallenge with multiple origins and non-empty redemption context. --> </ol> <t>These test vectors are below.</t> <artwork><![CDATA[ // Test vector 1: // token_type(0002), issuer_name(issuer.example), // origin_info(origin.example), redemption_context(non-empty) token_type: 0002 issuer_name: 6973737565722e6578616d706c65 redemption_context: 476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb origin_info: 6f726967696e2e6578616d706c65 nonce: e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab token_key_id: ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708 token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686 14f235e41ef7e2378e6f202688abab8e1d5518ec82964255526efd8f9db88205a 8ddd3ffb1db298fcc3ad36c42388fca572f8982a9ca248a3056186322d93ca147 266121ddeb5632c07f1f71cd2708 // Test vector 2: // token_type(0002), issuer_name(issuer.example), // origin_info(origin.example), redemption_context(empty) token_type: 0002 issuer_name: 6973737565722e6578616d706c65 redemption_context: origin_info: 6f726967696e2e6578616d706c65 nonce: e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab token_key_id: ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708 token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686 14f235e41ef7e2378e6f202688abab11e15c91a7c2ad02abd66645802373db1d8 23bea80f08d452541fb2b62b5898bca572f8982a9ca248a3056186322d93ca147 266121ddeb5632c07f1f71cd2708 // Test vector 3: // token_type(0002), issuer_name(issuer.example), // origin_info(), redemption_context(empty) token_type: 0002 issuer_name: 6973737565722e6578616d706c65 redemption_context: origin_info: nonce: e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab token_key_id: ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708 token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686 14f235e41ef7e2378e6f202688ababb741ec1b6fd05f1e95f8982906aec161289 6d9ca97d53eef94ad3c9fe023f7a4ca572f8982a9ca248a3056186322d93ca147 266121ddeb5632c07f1f71cd2708 // Test vector 4: // token_type(0002), issuer_name(issuer.example), // origin_info(), redemption_context(non-empty) token_type: 0002 issuer_name: 6973737565722e6578616d706c65 redemption_context: 476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb origin_info: nonce: e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab token_key_id: ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708 token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686 14f235e41ef7e2378e6f202688ababb85fb5bc06edeb0e8e8bdb5b3bea8c4fa40 837c82e8bcaf5882c81e14817ea18ca572f8982a9ca248a3056186322d93ca147 266121ddeb5632c07f1f71cd2708 // Test vector 5: // token_type(0002), issuer_name(issuer.example), // origin_info(foo.example,bar.example), // redemption_context(non-empty) token_type: 0002 issuer_name: 6973737565722e6578616d706c65 redemption_context: 476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb origin_info: 666f6f2e6578616d706c652c6261722e6578616d706c65 nonce: e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab token_key_id: ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708 token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686 14f235e41ef7e2378e6f202688ababa2a775866b6ae0f98944910c8f48728d8a2 735b9157762ddbf803f70e2e8ba3eca572f8982a9ca248a3056186322d93ca147 266121ddeb5632c07f1f71cd2708 // Test vector 6: // token_type(0000), structure(random_bytes) token_type: 0000 token_authenticator_input: 000058405ad31e286e874cb42d0ef9d50461ae 703bb71a21178beb429c43c0effe587456d856f0f2bdfc216ef93d5c225e2a93e 84cb686e63919788087f7ab1054aa817f09dcb919a0ed6f90fe887e8b08cd1eee 44d5be8d813eda9f2656db61c932db8d73f8690604ded0120157923bbd19d5549 e639e4de07530aee1d370f5187b678685715bd878dde24346751eb532a87b71ea 40bbe5a13218658e303c648eb03817453690bfcbe8255081bf27ff0891cd02ee2 483e48a2c494bdef696f943fa992a65303292c25d0d3f62da86a70d0b020f0ff5 b90d0ff0f6abdb097d321fde04f3a1994e63bcd35a88c21236c7dc67600482223 f54b25e39a250439f27ecb5ae9eb8ed548a3ec1f1d6f510d08281929c8fe08834 2959e35ea9b3b6f6a96fc1a8edba4ed297f4cf02d0e4482b79a11f671745d7b7d b120eddd8a4c2b6501bbc895b2160b8071615d9c1b18f32e056bfee29deac6a7d 6cf7b522a5badd63b9cb ]]></artwork> </section> <section anchor="http-header-test-vectors"> <name>HTTP Header Test Vectors</name> <t>This section includes test vectors the contents of the HTTP authentication headers. Each test vector consists of one or more challenges that comprise a WWW-Authenticateheader, as defined in {(choosing-between-multiple-challenges}}.header; see <xref target="choosing-between-multiple-challenges"/>. For each challenge, the token-type, token-key, max-age, and token-challenge parameters are listed. Each challenge also includes an unknown(not specified)(unspecified) parameter that implementations are meant toignore.</t>ignore. <!-- [rfced] Appendix A.2: This sentence does not parse. If the suggested text is not correct, please clarify. Original: This section includes test vectors the contents of the HTTP authentication headers. Suggested (per item 2. in Appendix A): This section includes test vectors for the HTTP authentication headers. --> </t> <t>The parameters for each challenge are indexed by their position in the WWW-Authentication challenge list. For example, token-key-0 denotes 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> <t>The resulting wire-encoded WWW-Authentication header based on this list of challenges is then listed at the end. Line folding is only used to fit thedocument formattingdocument-formatting constraints and is not supported in actual requests.</t> <t>The last challengeonin this list includes Basic authentication, a grease challenge, and a valid challenge for token type <tt>0x0001</tt>. Correct client implementations will ignore the Basic and grease challenges.</t> <artwork><![CDATA[ token-type-0: 0x0002 token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864 8016503040202a11a301806092a864886f70d010108300b060960864801650304020 2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2 5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9 ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f 67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b f6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6c bbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b1dba9e828bbd81e2 91317144e7ff89f55619709b096cbb9ea474cead264c2073fe49740c01f00e109106 066983d21e5f83f086e2e823c879cd43cef700d2a352a9babd612d03cad02db134b7 e225a5f0203010001 max-age-0: 10 token-challenge-0: 0002000e6973737565722e6578616d706c65208a3e83a33d9 8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696 e2e6578616d706c65 WWW-Authenticate: PrivateToken challenge="AAIADmlzc3Vlci5leGFtcGxlII o-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqG SIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM _KsluUsuZKIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi7pA1I-beWi JNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwyB6vGvcte155T8mKMTknaHl1fORTtS bvm_bOuZl5uEI7kPRGGiKvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE 7KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0zq0mTCBz_kl0DAHwDh CRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo1Kpur1hLQPK0C2xNLfiJaXwIDAQAB",unknow nChallengeAttribute="ignore-me", max-age="10" token-type-0: 0x0002 token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864 8016503040202a11a301806092a864886f70d010108300b060960864801650304020 2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2 5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9 ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f 67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b f6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6c bbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b1dba9e828bbd81e2 91317144e7ff89f55619709b096cbb9ea474cead264c2073fe49740c01f00e109106 066983d21e5f83f086e2e823c879cd43cef700d2a352a9babd612d03cad02db134b7 e225a5f0203010001 max-age-0: 10 token-challenge-0: 0002000e6973737565722e6578616d706c65208a3e83a33d9 8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696 e2e6578616d706c65 token-type-1: 0x0001 token-key-1: ebb1fed338310361c08d0c7576969671296e05e99a17d7926dfc28a 53fabd489fac0f82bca86249a668f3a5bfab374c9 max-age-1: 10 token-challenge-1: 0001000e6973737565722e6578616d706c65208a3e83a33d9 8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696 e2e6578616d706c65 WWW-Authenticate: PrivateToken challenge="AAIADmlzc3Vlci5leGFtcGxlII o-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqG SIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM _KsluUsuZKIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi7pA1I-beWi JNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwyB6vGvcte155T8mKMTknaHl1fORTtS bvm_bOuZl5uEI7kPRGGiKvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE 7KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0zq0mTCBz_kl0DAHwDh CRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo1Kpur1hLQPK0C2xNLfiJaXwIDAQAB",unknow nChallengeAttribute="ignore-me", max-age="10", PrivateToken challeng e="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPp LODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0zgxA2HAjQx1dpaWcSluBem aF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownChallengeAttribute="ig nore-me", max-age="10" token-type-0: 0x0000 token-key-0: 856de3c710b892e7cca1ae5eb121af42ca8e779137a11224228c9b9 9b0729bf84d5057d030000309b8f0d06ccffa17561f9eacd4c312e985a6bc60ffbea 0610264dcb1726255313da81d665692686a1d8644f1516bf612cea009e6dff6d9a9a 959fb538e1b5b2343c092992942382bdde22d5b324b1e4618ed21d7806286c2ce token-challenge-0: 0000acc3b25795c636fd9dd8b12982394abba8777d35978e8 77fc8848892a217233045ac25a3d55c07c54efe6372973fee0073e77fc61bf19ab88 0f20edf5d627502 token-type-1: 0x0001 token-key-1: ebb1fed338310361c08d0c7576969671296e05e99a17d7926dfc28a 53fabd489fac0f82bca86249a668f3a5bfab374c9 max-age-1: 10 token-challenge-1: 0001000e6973737565722e6578616d706c65208a3e83a33d9 8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696 e2e6578616d706c65 WWW-Authenticate: Basic realm="grease", PrivateToken challenge="AACs w7JXlcY2_Z3YsSmCOUq7qHd9NZeOh3_IhIiSohcjMEWsJaPVXAfFTv5jcpc_7gBz53_G G_GauIDyDt9dYnUC",token-key="hW3jxxC4kufMoa5esSGvQsqOd5E3oRIkIoybmbB ym_hNUFfQMAADCbjw0GzP-hdWH56s1MMS6YWmvGD_vqBhAmTcsXJiVTE9qB1mVpJoah2 GRPFRa_YSzqAJ5t_22ampWftTjhtbI0PAkpkpQjgr3eItWzJLHkYY7SHXgGKGws4=", PrivateToken challenge="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6 a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0z gxA2HAjQx1dpaWcSluBemaF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownC hallengeAttribute="ignore-me", max-age="10" ]]></artwork> </section> </section> </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] Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, and let us know if any changes are needed. For example, please consider whether the following should be updated: whitespace --> <!-- [rfced] Please let us know if any changes are needed for the following: a) The following term was used inconsistently in this document. We chose to use the latter form. Please let us know any objections. Issuance Protocol (1 instance in text) / issuance protocol (27 instances in text) (per the rest of Cluster 450) b) The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Reserved value / reserved value the token key / the token-key (e.g., "the token-key used", "the token key identifier", "the token-key parameter") (We also see "token_key: The public token-key", which reads a bit oddly.) token structure / Token structure WWW-Authenticate / WWW-Authentication (header / response header) (We also see "WWW-Authentication challenge list". Also, it appears that RFC 7616 is the only published RFC to date that uses "WWW-Authentication header field".) c) Quoting of some items is applied inconsistently in this document. Please let us know which form is preferred. "PrivateToken" / PrivateToken (mostly quoted, but not quoted where first used) PrivateToken authentication scheme / "PrivateToken" authentication scheme "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 (One option might be to quote the field name only when first used (Section 1), as was done for the "origin_info" field.) d) Please let us know how/if the following should be made consistent: 2-octet / two-octet (We also see "two-byte" in Section 6.2.) Spacing (or not) after the comma for this item: ",token-key=" / ", token-key=" e) We see "HTTP authentication headers" but "HTTP Authentication challenge", "HTTP Authentication ([RFC9110], Section 11)", and "HTTP authentication scheme". Should capitalization of "Authentication"/"authentication" be made consistent among these expressions, or all they all distinct from each other? --> </rfc>