Draft: draft-ietf-privacypass-architecture

Commentary: Supercede 's . 
 Section 6 states : But there 's just one subsection . : smiley : More importantly , it 's not clear that the Clients are the malicious ones in the examples provided for token exhaustion . 
 Resolved in by removing the section header . 
 The security considerations section starts : But only one item , Token Exhaustion , is listed . Should there be more items listed here ? Or should the section be collapsed to not have a subsection ? 
 Resolved in by collapsing .
The most basic Privacy Pass protocol provides a set of cross-origin
authorization tokens that protect the client's anonymity during
interactions with a server.  This allows clients to communicate an
attestation of a previously authenticated server action without
having to reauthenticate manually.  The tokens retain anonymity in
the sense that posession of a token cannot be linked to the session
in which that token was initially issued.
The most basic Privacy Pass protocol provides a set of cross-origin
authorization tokens that protect the Clients' anonymity during
interactions with a server.  This allows clients to communicate an
attestation of a previously authenticated server action without
having to reauthenticate manually.  The tokens retain anonymity in
the sense that posession of a token cannot be linked to the session
in which that token was initially issued.
Capable of solving a CAPTCHA.  Clients that solve CAPTCHA
challenges can be attested to have this capability for the
purposes of being ruled out as a bot or otherwise automated
Client.
Each of these attestation types have different security properties.
For example, attesting to having a valid account is different from
attesting to running on trusted hardware.  In general, Attesters
should accept a limited form of attestation formats.
Capable of solving a CAPTCHA.  Clients that solve CAPTCHA
challenges can be attested to have this capability for the purpose
of being ruled out as a bot or otherwise automated Client.
Each of these attestation types has different security properties.
For example, attesting to having a valid account is different from
attesting to running on trusted hardware.  In general, Attesters
should accept a limited form of attestation formats.
Split Attester and Issuer deployments, Issuers can choose to remove
compromised Attesters from their trusted set until the compromise is
patched, without needing to modify Origin allow-lists.
Split Attester and Issuer deployments (see deploy-split), Issuers can
choose to remove compromised Attesters from their trusted set until
the compromise is patched, without needing to modify Origin allow-
lists.
To facilitate issuance, the Issuer MUST hold an Issuance key pair at
any given time.  The Issuer public key MUST be made available to all
Clients in such a way that key rotations and other updates are
publicly visible.  The key material and protocol configuration that
an Issuer uses to produce tokens corresponds to a number of different
pieces of information.
To facilitate issuance, the Issuer MUST hold an Issuance key pair at
any given time.  The Issuer public key MUST be made available to all
Clients in such a way that key rotations and other updates are
publicly visible.  The key material and protocol configuration that
an Issuer uses to produce tokens corresponds to two different pieces
of information.
Another option to allow a large number of Issuers in the ecosystem,
while preventing the joining of a number of different tokens, is for
the Client to maintain sharded "redemption partitions".  This would
allow the Client to redeem the tokens it wishes to use in a
particular context, while still allowing the Client to maintain a
large variety of tokens from many Issuers.  Within a redemption
partition, the Client limits the number of different Issuers used to
a small number to maintain the privacy properties the Client
requires.  As long as each redemption partition maintains a strong
privacy boundary with each other, the verifier will only be able to
learn a number of bits of information up to the limits within that
"redemption partition".
Another option to allow a large number of Issuers in the ecosystem,
while preventing the joining of a number of different tokens, is for
the Client to maintain sharded "redemption partitions".  This would
allow the Client to redeem the tokens it wishes to use in a
particular context, while still allowing the Client to maintain a
large variety of tokens from many Issuers.  Within a redemption
partition, the Client limits the number of different Issuers used to
a small number to maintain the privacy properties the Client
requires.  As long as each redemption partition maintains a strong
privacy boundary with the others, the number of bits of information
the verifier can learn is bounded by the number of "redemption
partitions".
We present a number of security considerations that prevent malicious
Clients from abusing the protocol.
When a Client holds tokens for an Issuer, it is possible for any
verifier to cause that client to redeem tokens for that Issuer.  This
can lead to an attack where a malicious verifier can force a Client
to spend all of their tokens from a given Issuer.  To prevent this
from happening, tokens can be scoped to single Origins such that they
can only be redeemed within for a single Origin.
Beyond the aforementioned security gaols for the Issuance protocol
(issuance-protocol), it is important for Privacy Pass deployments to
mitigate the risk of abuse by malicious Clients.
When a Client holds tokens for an Issuer, it is possible for any
verifier to cause that client to redeem tokens for that Issuer.  This
can lead to an attack where a malicious verifier can force a Client
to spend all of their tokens from a given Issuer.  To prevent this
from happening, tokens can be scoped to single Origins such that they
can only be redeemed for a single Origin.