Original text:
The Privacy Pass issuance protocol, described in ISSUANCE, is a two- message protocol that takes as input a TokenChallenge from the redemption protocol (AUTHSCHEME, Section 2.1) and produces a Token <del> (AUTHSCHEME, Section 2.2), as shown in the figure below. </del>  The structure and semantics of the TokenRequest and TokenResponse messages depend on the issuance protocol and token type being used; 4.1. In this model, the Origin, Attester, and Issuer are all operated by <del> the same entity, as shown in the figure below. </del>  This model represents the initial deployment of Privacy Pass, as described in PrivacyPassCloudflare.  In this model, the Attester, entity that is separate from the Origin.  The Origin trusts the joint Attester and Issuer to perform attestation and issue Tokens.  Clients interact with the joint Attester and Issuer for attestation and <del> issuance.  This arrangement is shown in the figure below. </del>  This model is useful if an Origin wants to offload attestation and issuance to a trusted entity.  In this model, the Attester and Issuer authenticate itself to the Issuer.  In settings where the Attester is a Client-trusted service, one way Attesters can authenticate to Issuers is via mutually-authenticated TLS.  However, alernative <del> authentication mechanisms are possible.  This arrangement is shown below. </del>  This model is useful for Origins that require Client-identifying attestation, e.g., through the use of application-layer account Origin and Issuer model, the Issuer accepts token requests that come from trusted Attesters, and the details of that trust establishment depend on the issuance protocol and relationship between Attester and <del> Issuer. </del>  This is the most general deployment model, and is necessary for some types of issuance protocols where the Attester plays a role in token

Reviewer comments:
This is a little hard to process... An inbound PR I have proposes a change to the first diagram that might help here. A little work on this is probably necessary. !
A few things: When drawing arrows on lines, the line will connect with the line neatly if there is a connector or if there is an arrow adjacent to the line: This puts the arrow on the line, which renders a gap in the line. Avoid this: The bottom-left corner here is not curved, because the detection of corners needs three characters: the corner and a line either side of that, so... Not:
NAME can you say more about how it's hard to process? As we recently discussed, we're burdened by being too close to this work, so it's hard for me to see a substantial difference between the diagram in this issue and that which you proposed in the recently merged PR. Is it not clear who touches or sees each message? Part of the challenge in this particular diagram -- and any in which the attester is party to the protocol -- is that the attester may be inline or may not be! The architecture does not require the attester to be inline, it really only requires that the token request from a client be somehow blessed by the attester. I'll think about ways to better visualize this, but clarification about the source of confusion would be super helpful.
For me, the hardest part of these diagrams is that the start and end of the end of the arrows aren't really attached to anything in particular. You rely on horizontal alignment a fair bit (the arrow starts approximately under the label "Issuer", so it's probably a message from the issuer). In comparison, the diagram I provided had lines and boxes connecting them. This is probably a more illustrative example: ! Are the TokenRequest and TokenResponse labels on the lines? Where do these arrows start? Is the Client/Attester/Issuer box a single entity (obviously, no) given how the challenge arrows hit it. Which entities perform attestation? Then there are the formatting issues, some of which I will concede are specific to aasvg, see the above comment.
Thanks -- that's helpful. I think should resolve the confusion.

Revised text:
The Privacy Pass issuance protocol, described in ISSUANCE, is a two- message protocol that takes as input a TokenChallenge from the redemption protocol (AUTHSCHEME, Section 2.1) and produces a Token  <ins> (AUTHSCHEME, Section 2.2), as shown in fig-overview. </ins> The structure and semantics of the TokenRequest and TokenResponse messages depend on the issuance protocol and token type being used; 4.1. In this model, the Origin, Attester, and Issuer are all operated by  <ins> the same entity, as shown in fig-deploy-shared. </ins> This model represents the initial deployment of Privacy Pass, as described in PrivacyPassCloudflare.  In this model, the Attester, entity that is separate from the Origin.  The Origin trusts the joint Attester and Issuer to perform attestation and issue Tokens.  Clients interact with the joint Attester and Issuer for attestation and  <ins> issuance.  This arrangement is shown in fig-deploy-joint-issuer. </ins> This model is useful if an Origin wants to offload attestation and issuance to a trusted entity.  In this model, the Attester and Issuer authenticate itself to the Issuer.  In settings where the Attester is a Client-trusted service, one way Attesters can authenticate to Issuers is via mutually-authenticated TLS.  However, alernative  <ins> authentication mechanisms are possible.  This arrangement is shown in fig-deploy-joint-origin. </ins> This model is useful for Origins that require Client-identifying attestation, e.g., through the use of application-layer account Origin and Issuer model, the Issuer accepts token requests that come from trusted Attesters, and the details of that trust establishment depend on the issuance protocol and relationship between Attester and  <ins> Issuer.  This arrangement is shown in fig-overview. </ins> This is the most general deployment model, and is necessary for some types of issuance protocols where the Attester plays a role in token