Change:
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 cannot 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 cannot revoke tokens at all. The only recourse is the one that is noted, which is that the attester cannot 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

Discussion:
Attesters SHOULD not admit attestation types that result in small anonymity sets. <del> 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. </del> <ins> 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. </ins> 3.2.2.