Original text:
initially issued. At a high level, the Privacy Pass architecture consists of two <del> protocols: issuance and redemption.  The issuance protocol runs between an endpoint referred to as a Client and two functions in the Privacy Pass architecture: Attestation and Issuance.  These two network functions can be implemented by the same protocol participant, but can also be implemented separately.  The entity that implements Issuance, referred to as the Issuer, is responsible for issuing tokens in response to requests from Clients.  The entity that implements Attestation, referred to as the Attester, is responsible for attesting to properties about the Client for which tokens are issued.  The Issuer needs to be trusted by the server that later redeems the token.  Attestation can be performed by the Issuer or by an Attester that is trusted by the Issuer.  Clients might prefer to select different Attesters, separate from the Issuer, to be able to use preferred authentication methods or to improve privacy by not directly communicating with an Issuer.  Depending on the attestation, Attesters can store state about a Client, such as the number of overall tokens issued thus far.  As an example of an issuance protocol, in the original Privacy Pass protocol PPEXT, tokens were only issued to Clients that solved CAPTCHAs.  In this context, the Attester attested that some client solved a CAPTCHA and the resulting token produced by the Issuer was proof of this fact. The redemption protocol runs between Client and Origin (server).  It allows Origins to challenge Clients to present one or more tokens for </del>  authorization.  Depending on the type of token, e.g., whether or not it can be cached, the Client either presents a previously obtained <del> token or invokes the issuance protocol to acquire one for authorization. The issuance and redemption protocols operate in concert as shown in the figure below. </del>  This document describes requirements for both issuance and redemption <del> protocols.  It also provides recommendations on how the architecture should be deployed to ensure the privacy of clients and the security of all participating entities. The privacypass working group is working on AUTHSCHEME as an instantiation of a redemption protocol and ISSUANCE as an instantiation of the issuance protocol. </del>  2.

Reviewer comments:
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.

Revised text:
initially issued. At a high level, the Privacy Pass architecture consists of two  <ins> protocols: issuance and redemption.  The redemption protocol AUTHSCHEME runs between Client and Origin (server).  It allows Origins to challenge Clients to present one or more tokens for </ins> authorization.  Depending on the type of token, e.g., whether or not it can be cached, the Client either presents a previously obtained  <ins> token or invokes an issuance protocol, such as ISSUANCE, to acquire a token to present as authorization. </ins> This document describes requirements for both issuance and redemption  <ins> protocols and how they interact.  It also provides recommendations on how the architecture should be deployed to ensure the privacy of clients and the security of all participating entities. </ins> 2.