Code change:
Attester: An entity that attests to properties of Client for the purposes of token issuance. <ins> Redemption context: The interactions and set of information shared between the Client and Origin. Issuance context: The interactions and set of information shared between the Client, Attester, and Issuer. Attestation context: The interactions and set of information shared between the Client and Attester only, for the purposes of attesting the vailidity of the Client. </ins> 3. The Privacy Pass architecture consists of four logical entities - <del> Client, Origin, Issuer, and Attester - that work in concert as shown in introduction for token issuance and redemption.  This section describes the purpose of token issuance and redemption and the requirements therein on the relevant participants. </del> <ins> Client, Origin, Issuer, and Attester - that work in concert as for token issuance and redemption.  This section describes the purpose of token issuance and redemption and the requirements on the relevant participants. The typical interaction flow for Privacy Pass tokens uses the following steps: A Client interacts with an Origin by sending an HTTP request.  The Origin sends an HTTP response that contains a token challenge that indicates a specific Issuer to use.  Note that the request might be made as part of accessing a resource normally, or with the specific intent of triggering a token challenge. If the Client already has a token available that satisfies the token challenge, it can skip to step 6 and redeem its token. Otherwise, it invokes the issuance protocol to request a token from the designated Issuer. The first step in the issuance protocol is attestation. Specifically, the Attester performs attestation checks on the Client.  These checks could be proof of solving a CAPTCHA, device trust, hardware attestation, etc (see attester). If attestation succeeds, the client creates a Token Request to send to the designated Issuer (generally via the Attester).  The Attester and Issuer might be functions on the same server, depending on the deployment model (see deployment).  Depending on the details of Attestation, the Client can send the Token Request to the Attester alongside any attestation information.  If attestation fails, the Client receives an error and issuance aborts without a token. The Issuer generates a Token Response based on the Token Request, which is returned to the Client (generally via the Attester). Upon receiving the Token Response, the Client computes a token from the token challenge and Token Response.  This token can be validated by anyone with the per-Issuer key, but cannot be linked to the content of the Token Request or Token Response. If the Client has a token, it includes it in a subsequent HTTP request to the Origin, as authorization.  This token is sent only once.  The Origin validates that the token was generated by the expected Issuer and has not already been redeemed for the corresponding token challenge.  If the Client does not have a token, perhaps because issuance failed, the client does not reply to the Origin's challenge with a new request. </ins> 3.1.

Related discussion:
text: In this image: ! It isn't very clear where messages originate and who gets to see them. In particular, it isn't clear where the TokenRequest originates (the Client) and whether the Attester gets to see it (¯(°_o)/¯).
That's a fair point. It should be clear that the TokenRequest comes from the Attester. I wonder if we also somehow need to illustrate that there's a trust relationship between the Attester and Issuer here. Something to at least imply that the Attester is either implicitly trusted to do attestation, or, perhaps in future versions of Privacy Pass, attestation proofs are sent directly to the Issuer.
Move diagram to section 3 (architecture). Also move much of the second intro paragraph down. Add more text about the actual steps to section 3, such as a numbered list
In here, introduce the basic privacy premise for how the redemption and issuance contexts are separated
The architecture references [AUTHSCHEME] for key concepts far more than I expected. For instance: Or: Can the architecture define the messages in their own right, then point to [AUTHSCHEME] for example implementations?
Is the suggestion here to describe -- conceptually -- what Token and TokenChallenges are in the architecture document? If so, that seems quite reasonable.
Yeah. An architecture is most useful if you don't have to dig into the details to understand it and those references are somewhat critical to comprehension.