Draft: draft-ietf-privacypass-architecture

Commentary: Section 3.2.1 talks about the need for issuers to trust attesters . This is probably the main trust relationship ( see ) involved regarding attestation . The other trust basis is the extent to which the attester trusts the client , though the point is probably that the attester starts out being extremely skeptical about the client and so acts to validate them . This is fine ( though I would delete the first sentence of the last paragraph of this section ) . However , the remainder of this text talks about how to handle an attester that goes bad . None of this acknowledges the real problem , which is that in a setting where an issuer works with multiple attesters , but issues from a single key , a failure in one attester can not result in tokens being invalidated for just that attester . The information about which attester was involved in token issuance is erased by the issuer , deliberately . It might even be the case ( thanks to consistency requirements ) that the issuer can not revoke tokens at all . The only recourse is the one that is noted , which is that the attester can not be used for future issuance . The doc should probably talk about those tokens that were issued though . 
 Talking about tokens in circulation post - attestation - compromise is a good suggestion . I 'll take this issue and propose text . 
 Approved pending one comment
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.
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 procedure is compromised.  Broken
attestation procedures 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.
From the perspective of an Origin, tokens produced by an Issuer with
at least one compromised Attester cannot be trusted assuming the
Origin does not know which attestation procedure was used for
issuance.  This is because the Origin cannot distinguish between
tokens that were issued via compromised Attesters and tokens that
were issued via uncompromised Attesters absent some distinguishing
information in the tokens themselves or from the Issuer.  As a
result, until the attestation procedure is fixed, the Issuer cannot
be trusted by Origins.  Moreover, as a consequence, any tokens issued
by an Issuer with a compromised attester may no longer be trusted by
Origins, even if those tokens were issued to Clients interacting with
an uncompromised Attester.