Draft: draft-ietf-privacypass-architecture

Commentary: From Section 3.2.1 : This is a pretty wild equivalence . I stumbled badly on this one . It 's very much like saying " in this context a verb is sometimes referred to as a noun " . Is the goal here to say that " there is a attestation process by which the Attester determines whether a Client meets the requirements for issuance ; if successful , the Attester captures this information using an attestation format " ? That seems to be the case , but that 's not what this says . 
 I think we might just drop the equivalence to avoid confusion , but in the interest of transparency , here 's where it came from . Consider the two following types of attestation procedures : based on , where the client and attester use this mechanism to prove that the client 's device is valid . based on , perhaps where the signature is computed in some client enclave , where the client authenticates its token request with such a ring signature . In ( 1 ) , attestation is some procedure that takes place between client and attester , whereas in ( 2 ) attestation is sort of non - interactive mechanism for producing an attestation format or proof of sorts . Since we do n't specify the details of attestation , the text was written in a way to be maximally accommodating to these types of things . In any case , I think it 's probably fine to just treat attestation as a procedure _ , be it interactive or non - interactive or whatever , and that procedure has certain properties associated with it . I 'll propose text .
An entity that attests to properties of Client for the purposes of
token issuance.
An entity that attests to properties of Clients for the purposes
of token issuance.
The procedure by which an Attester determines whether or not a
Client is trusted with a specific set of properties for token
issuance.
Issuer identity.  Token challenges identify which Issuers are
trusted for a given issuance protocol.  Each Issuer, in turn,
determines which Attesters it is willing to accept in the issuance
protocol.  This means that if an Origin origin.example accepts
tokens issued by Issuer issuer.example, and that Issuer in turn
accepts different types of attestation from more than one trusted
Attester, then a Client may use either of these trusted Attesters
to issue and redeem tokens for origin.example.  However,
origin.example neither explicitly specifies nor learns the
Attesters or their attestation formats used for token issuance.
Issuer identity.  Token challenges identify which Issuers are
trusted for a given issuance protocol.  Each Issuer, in turn,
determines which Attesters it is willing to accept in the issuance
protocol.  This means that if an Origin origin.example accepts
tokens issued by Issuer issuer.example, and that Issuer in turn
accepts different types of attestation from more than one trusted
Attester, then a Client may use either of these trusted Attesters
to issue and redeem tokens for origin.example.  However,
origin.example neither explicitly specifies nor learns the
Attesters or their specific attestation procedures used for token
issuance.
Attesters may support different types of attestation procedures.  A
type of attestation procedure is also referred as an attestation
format.
In general, each attestation format has different security
properties.  For example, attesting to having a valid account is
different from attesting to running on trusted hardware.  In general,
minimizing the set of attestation formats helps minimize the amount
of information leaked through a token.
Each attestation format also has an impact on the overall system
privacy.  Requiring a conjunction of attestation types could decrease
the overall anonymity set size.  For example, the number of Clients
that have solved a CAPTCHA in the past day, that have a valid
account, and that are running on a trusted device is less than the
number of Clients that have solved a CAPTCHA in the past day.
Attesters SHOULD not admit attestation types that result in small
anonymity sets.
Attesters may support different types of attestation procedures.
In general, each attestation procedure has different security
properties.  For example, attesting to having a valid account is
different from attesting to running on trusted hardware.  In general,
minimizing the set of supported attestation procedures helps minimize
the amount of information leaked through a token.
Each attestation procedure also has an impact on the overall system
privacy.  Requiring a conjunction of attestation types could decrease
the overall anonymity set size.  For example, the number of Clients
that have solved a CAPTCHA in the past day, that have a valid
account, and that are running on a trusted device is less than the
number of Clients that have solved a CAPTCHA in the past day.
Attesters SHOULD not admit attestation types that result in small
anonymity sets.
The trustworthiness of Attesters depends on their ability to
correctly and reliably perform attestation during the issuance
protocol.  Indeed, Issuers trust Attesters to correctly and reliably
perform attestation.  However, certain types of attestation can vary
in value over time, e.g., if the attestation process is compromised
or maliciously automated.  These are considered exceptional events
and require configuration changes to address the underlying cause.
For example, if attestation is compromised because of a zero-day
exploit on compliant devices, then the corresponding attestation
format should be untrusted until the exploit is patched.  Addressing
changes in attestation quality is therefore a deployment-specific
task.  In Split Attester and Issuer deployments (see deploy-split),
Issuers can choose to remove compromised Attesters from their trusted
set until the compromise is patched.
The trustworthiness of Attesters depends on their ability to
correctly and reliably perform attestation during the issuance
protocol.  Indeed, Issuers trust Attesters to correctly and reliably
perform attestation.  However, certain types of attestation can vary
in value over time, e.g., if the attestation process is compromised
or maliciously automated.  These are considered exceptional events
and require configuration changes to address the underlying cause.
For example, if attestation is compromised because of a zero-day
exploit on compliant devices, then the corresponding attestation
procedure should be untrusted until the exploit is patched.
Addressing changes in attestation quality is therefore a deployment-
specific task.  In Split Attester and Issuer deployments (see deploy-
split), Issuers can choose to remove compromised Attesters from their
trusted set until the compromise is patched.