Original text:
An entity that issues tokens to Clients for properties attested to by the Attester. <del> An entity that attests to properties of Client for the purposes of token issuance. </del>  3. 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 <del> Attesters or their attestation formats used for token issuance. </del>  Redemption context.  Challenges can be bound to a given redemption context, which influences a client's ability to pre-fetch and state include the Client's geographic region and whether the Client has a valid application-layer account. <del> Attesters may support different types of attestation procedures.  A type of attestation procedure is also referred as an attestation format. </del>  <del> In general, each attestation format has different security </del>  properties.  For example, attesting to having a valid account is different from attesting to running on trusted hardware.  In general, <del> minimizing the set of attestation formats helps minimize the amount of information leaked through a token. </del>  <del> Each attestation format also has an impact on the overall system </del>  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 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 <del> 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. </del>  3.2.2.

Reviewer comments:
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: Attestation based on , where the client and attester use this mechanism to prove that the client's device is valid. Attestation 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 don'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.

Revised text:
An entity that issues tokens to Clients for properties attested to by the Attester.  <ins> 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. </ins> 3. 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  <ins> Attesters or their specific attestation procedures used for token issuance. </ins> Redemption context.  Challenges can be bound to a given redemption context, which influences a client's ability to pre-fetch and state include the Client's geographic region and whether the Client has a valid application-layer account.  <ins> Attesters may support different types of attestation procedures. </ins>  <ins> In general, each attestation procedure has different security </ins> properties.  For example, attesting to having a valid account is different from attesting to running on trusted hardware.  In general,  <ins> minimizing the set of supported attestation procedures helps minimize the amount of information leaked through a token. </ins>  <ins> Each attestation procedure also has an impact on the overall system </ins> 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 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  <ins> 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. </ins> 3.2.2.