Draft: draft-ietf-privacypass-auth-scheme

Commentary: We should consider renaming to . This value does n'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 .
In addition to working with different token issuance protocols, this
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.
In addition to working with different token issuance protocols, this
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.
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.
Token challenge: A requirement for tokens sent from an origin to a
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.
Token challenge: A requirement for tokens sent from an origin to a
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.
"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.
"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.
"context" is a 32-octet message containing the hash of the
original TokenChallenge, SHA256(TokenChallenge).
"challenge_digest" is a 32-octet message containing the hash of
the original TokenChallenge, SHA256(TokenChallenge).
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
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.
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
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.
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
given token type and issuer per client request.  If an origin issues
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.
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
given token type and issuer per client request.  If an origin issues
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.
The security properties of token challenges vary depending on whether
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.
Interactive token challenges require clients to obtain matching
tokens when challenged, rather than presenting a token that was
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.
The security properties of token challenges vary depending on whether
the challenge contains a redemption context or not, as well as
whether the challenge is per-origin or not.  For example, cross-
origin tokens with empty contexts can be replayed from one party by
another, as shown below.
Context-bound token challenges require clients to obtain matching
tokens when challenged, rather than presenting a token that was
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.