Draft: draft-ietf-privacypass-auth-scheme

Commentary: The section references seem to be breaking the build , so I 'll fix that later before we land this . 
 Origins currently choose whether their challenges are per - origin or cross - origin . For cross - origin , double - spend prevention is only as good as the coordination between origins and the Issuer . Per - origin allows double - spend prevention to be isolated to a single origin ; also prevents the cache of tokens being take up by some other origin . 
 Write this as " any origins that share a redemption context must also share double spend state for that context . "
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 enforce double 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 for double spend prevention can allow Clients to
redeem tokens to one Origin that were issued after an interaction
with another Origin that shares the context.
Interactive or non-interactive.  Tokens can either be interactive
or not.  An interactive token is one which requires a freshly
issued token based on the challenge, whereas a non-interactive
token can be issued proactively and cached for future use.
Depending on the use case, Origins may need to maintain state to
track redeemed tokens.  For example, Origins that accept non-
interactive, cross-origin tokens SHOULD track which tokens have been
redeemed already, since these tokens can be issued and then spent
multiple times in response to any such challenge.  See double-spend
for discussion.
Redemption context.  Tokens can be bound to a given redemption
context, which influences a client's ability to pre-fetch and
cache tokens.  For example, an empty redemption context always
allows tokens to be issued and redeemed non-interactively, whereas
a fresh and random redemption context means that the redeemed
token must be issued only after the client receives the challenge.
See Section 2.1.1 of HTTP-Authentication for more details.
Depending on the use case, Origins may need to maintain state to
track redeemed tokens.  For example, Origins that accept cross-origin
across shared redemption contexts tokens SHOULD track which tokens
have been redeemed already in those redemption contexts, since these
tokens can be issued and then spent multiple times in response to any
such challenge.  See Section 2.1.1 of HTTP-Authentication for
discussion.
Attestation and redemption context unlinkability requires that these
events be separated over time, e.g., through the use of non-
interactive tokens that can be issued without a fresh Origin
challenge, or over space, e.g., through the use of an anonymizing
proxy when connecting to the Origin.
Attestation and redemption context unlinkability requires that these
events be separated over time, e.g., through the use of tokens with
an empty redemption context, or over space, e.g., through the use of
an anonymizing proxy when connecting to the Origin.
When applicable for non-interactive tokens, all Origins SHOULD
implement a robust storage-query mechanism for checking that tokens
sent by clients have not been spent before.  Such tokens only need to
be checked for each Origin individually.  But all Origins must
perform global double-spend checks to avoid clients from exploiting
the possibility of spending tokens more than once against distributed
token checking systems.  For the same reason, the global data storage
must have quick update times.  While an update is occurring it may be
possible for a malicious client to spend a token more than once.