Original text:
issuance protocol to actually fetch tokens to redeem. In addition to working with different token issuance protocols, this <del> scheme supports both interactive (online challenges) and non- interactive (pre-fetched) token redemption, as well as the ability to scope a token to a specific resource or origin.  Relying parties that request and redeem tokens can choose a specific kind of token, as appropriate for its use case.  For example, non-interactive token redemption that is not scoped to a specific origin can be used as a replacement for CAPTCHAs, as exemplified by the original Privacy Pass work DGSTV18. </del>  1.1. Unless otherwise specified, this document encodes protocol messages in TLS notation from TLS13, Section 3. <del> This document uses the following terms to refer to various roles and functions in the Privacy Pass architecture: Client: A client is a application or device, generally operated by a user, that can be issued tokens via an issuance protocol, and can redeem these tokens with an origin. Origin: An HTTP server that acts as the relying party and can redeem tokens presented by a client.  When used in a web context, this represents the origin the client is accessing. Token: A signed message that can be issued to a client and redeemed without allowing token redemption to be linked to issuance. Interactive / non-interactive token: An interactive token signs a nonce generated by an origin as part of a challenge for tokens. This means that the client needs to fetch a new token for this challenge in order to redeem it and cannot use a pre-fetched token.  A non-interactive token is one that can be pre-fetched. Issuance protocol: A protocol by which the client fetches tokens. Every issuance protocol includes two functions: validating or authenticating the client, and issuing a token to the client. Issuer: An entity that generates tokens for clients using one or more issuance protocols.  An Issuer is identified by an Issuer name. </del>  Issuer key: Keying material that can be used with an issuance protocol to create a signed token. Token challenge: A requirement for tokens sent from an origin to a <del> client, using the "WWW-Authenticate" HTTP header.  This may be a challenge for an interactive token or a non-interactive token.  A challenge defines the issuance protocol and issuer name to use for a token. </del>  Token redemption: An action by which a client presents a token to an origin, using the "Authorization" HTTP header. is a hostname that is used to identify the issuer that is allowed to issue tokens that can be redeemed by this origin. <del> "redemption_nonce" is an optional field.  If present, it indicates that a client needs to present an interactive token, generated specifically in response to this challenge.  If empty, the client can use a non-interactive token.  When present, this valid is a fresh 32-byte nonce generated by the origin for each challenge. Valid lengths for this field are either 0 or 32 bytes.  Challenges with redemption_nonce values of invalid lengths MUST be ignored. </del>  "origin_name" is an optional string containing the name of the origin.  This allows a token to be scoped to a specific origin. "nonce" is a 32-octet message containing a client-generated random nonce. <del> "context" is a 32-octet message containing the hash of the original TokenChallenge, SHA256(TokenChallenge). </del>  "token_key_id" is an Nid-octet identifier for the the token authentication key.  The value of this field is defined by the For token types that support public verifiability, origins verify the token authenticator using the public key of the issuer, and validate that the signed message matches the concatenation of the client nonce <del> and the hash of a valid TokenChallenge.  For interactive tokens, origins store the nonces of previous TokenChallenge structures in order to validate uniqueness.  A TokenChallenge MAY be bound to a specific HTTP session with client, but origins can also accept tokens for valid challenges in new sessions.  For non-interactive tokens, origins SHOULD implement some form of double spend prevention that prevents a token with the same nonce from being redeemed twice.  This prevents clients from "replaying" tokens for previous challenges. </del>  If a client is unable to fetch a token, it MUST react to the challenge as if it could not produce a valid Authorization response. Note that the issuance protocol may separately involve user interaction if the client needs to be newly validated. <del> The use of interactive tokens can add user-perceivable latency, since such tokens cannot be pre-fetched.  Origins need not block useful work on token authentication.  Instead, token authentication can be used in similar ways to CAPTCHA validation today, but without the need for user interaction.  If issuance is taking a long time, a website could show an indicator that it is waiting, or fall back to another method of user validation. An origin MUST NOT issue more than one interactive challenge for a </del>  given token type and issuer per client request.  If an origin issues <del> a large number of challenges, such as more than once for each request, this can indicate that the origin is either not functioning correctly or is trying to attack or overload the client or issuance server.  In such cases, a client MUST ignore redundant token challenges for the same request and SHOULD alert the user if possible. </del>  Origins MAY include multiple challenges, where each challenge refers to a different issuer or a different token type, to allow clients to 5. The security properties of token challenges vary depending on whether <del> the challenge is interactive or not, as well as whether the challenge is per-origin or not.  For example, non-interactive, cross-origin tokens can be replayed from one party by another, as shown below. </del>  <del> Interactive token challenges require clients to obtain matching </del>  tokens when challenged, rather than presenting a token that was <del> obtained in the past.  This means that issuance and redemption events will occur at approximately the same time.  For example, if a client is challenged for an interactive token 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 attribute, clients MAY try to augment the time between getting challenged then redeeming a token so as to make this sort of linkability more difficult.  For more discussion on correlation risks between token issuance and redemption, see I-D.ietf-privacypass- architecture. </del>  Applications SHOULD constrain tokens to a single origin unless the use case can accommodate such replay attacks.

Reviewer comments:
We should consider renaming to . This value doesn't need to be a nonce, it's just some origin-selected context that it is binding to. We can also rename the in the Token struct to to make it clear what role it has.

Revised text:
issuance protocol to actually fetch tokens to redeem. In addition to working with different token issuance protocols, this  <ins> scheme supports optionally associating tokens 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. </ins> 1.1. Unless otherwise specified, this document encodes protocol messages in TLS notation from TLS13, Section 3.  <ins> This document uses the terms "Client", "Origin", "Issuer", "Issuance Protocol", and "Token" as defined in I-D.ietf-privacypass- architecture.  It additionally uses the following terms in more specific ways: </ins> Issuer key: Keying material that can be used with an issuance protocol to create a signed token. Token challenge: A requirement for tokens sent from an origin to a  <ins> client, using the "WWW-Authenticate" HTTP header.  This challenge is bound to a specific token issuer and issuance protocol, and may be additionally bound to a specific context or origin name. </ins> Token redemption: An action by which a client presents a token to an origin, using the "Authorization" HTTP header. is a hostname that is used to identify the issuer that is allowed to issue tokens that can be redeemed by this origin.  <ins> "redemption_context" is an optional field.  If present, it 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.  When present, this value is a 32-byte context generated by the origin.  This value can be a unique per-request nonce, or represent some state such as properties of the client session or current time window.  Valid lengths for this field are either 0 or 32 bytes.  Challenges with redemption_context values of invalid lengths MUST be ignored. </ins> "origin_name" is an optional string containing the name of the origin.  This allows a token to be scoped to a specific origin. "nonce" is a 32-octet message containing a client-generated random nonce.  <ins> "challenge_digest" is a 32-octet message containing the hash of the original TokenChallenge, SHA256(TokenChallenge). </ins> "token_key_id" is an Nid-octet identifier for the the token authentication key.  The value of this field is defined by the For token types that support public verifiability, origins verify the token authenticator using the public key of the issuer, and validate that the signed message matches the concatenation of the client nonce  <ins> and the hash of a valid TokenChallenge.  For context-bound tokens, origins store or reconstruct the contexts of previous TokenChallenge structures in order to validate the token.  A TokenChallenge MAY be bound to a specific HTTP session with client, but origins can also accept tokens for valid challenges in new sessions.  Origins SHOULD implement some form of double-spend prevention that prevents a token with the same nonce from being redeemed twice.  This prevents clients from "replaying" tokens for previous challenges.  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. </ins> If a client is unable to fetch a token, it MUST react to the challenge as if it could not produce a valid Authorization response. Note that the issuance protocol may separately involve user interaction if the client needs to be newly validated.  <ins> If a client cannot use cached tokens to respond to a challenge (either because it has run out of cached tokens or the associated context is unique), the token issuance process can add user- perceivable latency.  Origins need not block useful work on token authentication.  Instead, token authentication can be used in similar ways to CAPTCHA validation today, but without the need for user interaction.  If issuance is taking a long time, a website could show an indicator that it is waiting, or fall back to another method of user validation. An origin MUST NOT use more than one redemption context value for a </ins> given token type and issuer per client request.  If an origin issues  <ins> a large number of challenges with unique contexts, such as more than once for each request, this can indicate that the origin is either not functioning correctly or is trying to attack or overload the client or issuance server.  In such cases, a client MUST ignore redundant token challenges for the same request and SHOULD alert the user if possible. </ins> Origins MAY include multiple challenges, where each challenge refers to a different issuer or a different token type, to allow clients to 5. The security properties of token challenges vary depending on whether  <ins> the challenge contains a redemption context or not, as well as whether the challenge is per-origin or not.  For example, cross- origin tokens with empty contexts can be replayed from one party by another, as shown below. </ins>  <ins> Context-bound token challenges require clients to obtain matching </ins> tokens when challenged, rather than presenting a token that was  <ins> obtained 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 attribute, clients MAY try to augment the time between getting challenged then redeeming a token so as to make this sort of linkability more difficult.  For more discussion on correlation risks between token issuance and redemption, see I- D.ietf-privacypass-architecture. </ins> Applications SHOULD constrain tokens to a single origin unless the use case can accommodate such replay attacks.