Original text:
3.  Issuers MUST provide two parameters for configuration: Issuer Request URI: A token request URL for generating access known/token-issuer-directory; see wkuri-reg for the registration information for this well-known URI. <del> 4. Clients receive challenges for tokens, as described in AUTHSCHEME. The basic token issuance protocols described in this document can be interactive or non-interactive, and per-origin or cross-origin. </del> 5. <del> The Privacy Pass issuance protocol is a two-message protocol that takes as input a TokenChallenge from the redemption protocol (AUTHSCHEME, Section 2.1) and produces a Token (AUTHSCHEME, Section 2.2), as shown in the figure below. This section describes a variant of this issuance protocol for producing privately verifiable tokens using the protocol in OPRF.  In particular, this variant of the issuance protocol uses the OPRF(P-384, SHA-384) ciphersuite. </del>  <del> In this variant, Issuers provide a Private and Public Key, denoted "skI" and "pkI" respectively, used to produce tokens as input to the protocol.  See issuer-configuration for how this key-pair is generated. </del>  Clients provide the following as input to the issuance protocol:  Issuer name: An identifier for the Issuer.  This is typically a host name that can be used to construct HTTP requests to the Issuer. The values "token_input" and "blinded_element" are stored locally and used later as described in private-finalize.  The Client then <del> generates an HTTP POST request to send to the Issuer, with the TokenRequest as the content.  The media type for this request is "application/private-token-request".  An example request is shown below. </del>  5.2. Clients provide the following as input to the issuance protocol:  Issuer name: An identifier for the Issuer.  This is typically a host name that can be used to construct HTTP requests to the Issuer. "blinded_msg" is the Nk-octet request defined above. <del> The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the content.  The media type for this request is "application/private-token-request".  An example request is shown below: </del>  6.2. blind RSA documents also apply in the Privacy Pass use-case. Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are deferred to the <del> Architecture document ARCHITECTURE. </del>  Beyond these considerations, it is worth highlighting the fact that Client TokenRequest messages contain truncated token key IDs.  This browsing history.  Depending on the deployment model, separating these contexts can take different forms.  The Origin, Attester, and Issuer portrayed in fig-overview can be instantiated and deployed in <del> a number of ways.  This section covers some expected deployment models and their corresponding security and privacy considerations. </del>  The discussion below assumes non-collusion between entities that have access to the attestation context and entities that have access to 4.2. In this model, the Attester and Issuer are operated by the same <del> entity that is separate from the Origin, as 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 In this model, the Origin and Issuer are operated by the same entity, separate from the Attester, as shown in the figure below.  The Issuer <del> accepts token requests that come from trusted Attesters.  Depending on the issuance protocol, the Attester may relay these requests between Client and Issuer over an authenticated channel, or trust may be established in some other manner. </del>  This model is useful for Origins that require Client-identifying attestation, e.g., through the use of application-layer account different entities, as shown in the figure below.  As with the joint Origin and Issuer model, the Issuer accepts token requests that come from trusted Attesters, and the details of that trust establishment <del> depend on the issuance protocol. </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:
Split attesters and issuers are not required for the basic issuance protocol, but we should explain (in a sentence or so) that if you are using a split attester, the client sends the request to the attester, and the attester forwards the request to the issuer if it accepts the client.
For better clarity and consistency, I recommend adding a sequence diagram depicting this model considering the sequence diagrams that outline other models.
Agreed. This would be a good thing to include. I'll take this and add it.
In a split attester/issuer scenario, the issuer needs to authenticate the attester in some way (e.g., TLS client cert). In a combined attester/issuer scenario, the actual protocol might be something proprietary (or covered by an as-yet-unwritten spec) that extends the base issuance protocol, e.g., adding an attestation header, user login cookie, or adding extra challenge/response rounds to confirm identity. If these issues are "in scope" then they should be defined here. If they are "out of scope" then it would be helpful context to reader to describe what is expected to be handled by a proprietary extension.
NAME we discuss these things in the architecture document where deployment models are discussed. But we should mention the impact that different deployment models have on the basic issuance protocol in the -protocol spec.

Revised text:
3. <ins> The issuance protocols defined in this document embody the core of Privacy Pass.  Clients receive TokenChallenge inputs from the redemption protocol (AUTHSCHEME, Section 2.1) and use the issuance protocols to produce corresponding Token values (AUTHSCHEME, Section 2.2).  The issuance protocol describes how Clients and Issuers interact to compute a token using a one-round protocol consisting of a TokenRequest from the Client and TokenResponse from the Issuer.  This interaction is shown below. The TokenChallenge inputs to the issuance protocols described in this document can be interactive or non-interactive, and per-origin or cross-origin. The issuance protocols defined in this document are compatible with any deployment model defined in Section 4 of ARCHITECTURE.  The details of attestation are outside the scope of the issuance protocol; see Section 4 of ARCHITECTURE for information about how attestation can be implemented in each of the relevant deployment models. This document describes two variants of the issuance protocol: one that is privately verifiable (private-flow) using the issuance private key based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable (public-flow) using the issuance public key based on the blind RSA signature scheme BLINDRSA. 4. </ins> Issuers MUST provide two parameters for configuration: Issuer Request URI: A token request URL for generating access known/token-issuer-directory; see wkuri-reg for the registration information for this well-known URI.  5.  <ins> The privately verifiable issuance protocol allows Clients to produce Token values that verify using the Issuer Private Key. This protocol is based on the oblivious pseudorandom function from OPRF. </ins>  <ins> Issuers provide a Private and Public Key, denoted "skI" and "pkI" respectively, used to produce tokens as input to the protocol.  See issuer-configuration for how this key pair is generated. </ins> Clients provide the following as input to the issuance protocol: <ins> Issuer Request URI: A URI to which token request messages are sent.  This can be a URL derived from the "issuer-request-uri" value in the Issuer's directory resource, or it can be another Client-configured URL.  The value of this parameter depends on the Client configuration and deployment model.  For example, in the 'Joint Origin and Issuer' deployment model, the Issuer Request URI might be correspond to the Client's configured Attester, and the Attester is configured to relay requests to the Issuer. </ins> Issuer name: An identifier for the Issuer.  This is typically a host name that can be used to construct HTTP requests to the Issuer. The values "token_input" and "blinded_element" are stored locally and used later as described in private-finalize.  The Client then  <ins> generates an HTTP POST request to send to the Issuer Request URI, with the TokenRequest as the content.  The media type for this request is "application/private-token-request".  An example request is shown below. </ins> 5.2. Clients provide the following as input to the issuance protocol: <ins> Issuer Request URI: A URI to which token request messages are sent.  This can be a URL derived from the "issuer-request-uri" value in the Issuer's directory resource, or it can be another Client-configured URL.  The value of this parameter depends on the Client configuration and deployment model.  For example, in the 'Split Origin, Attester, Issuer' deployment model, the Issuer Request URI might be correspond to the Client's configured Attester, and the Attester is configured to relay requests to the Issuer. </ins> Issuer name: An identifier for the Issuer.  This is typically a host name that can be used to construct HTTP requests to the Issuer. "blinded_msg" is the Nk-octet request defined above.  <ins> The Client then generates an HTTP POST request to send to the Issuer Request URI, with the TokenRequest as the content.  The media type for this request is "application/private-token-request".  An example request is shown below: </ins> 6.2. blind RSA documents also apply in the Privacy Pass use-case. Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are deferred to the  <ins> Architecture document ARCHITECTURE.  Moreover, deployment-specific considerations regarding Client privacy when running the issuance protocol, especially with respect to Client-specific identifiers such as IP addresses that are revealed to the Attester and Issuer during issuance, are also discussed in Section 4 of ARCHITECTURE. </ins> Beyond these considerations, it is worth highlighting the fact that Client TokenRequest messages contain truncated token key IDs.  This browsing history.  Depending on the deployment model, separating these contexts can take different forms.  The Origin, Attester, and Issuer portrayed in fig-overview can be instantiated and deployed in  <ins> a number of ways. This section covers some expected deployment models and their corresponding security and privacy considerations.  Each deployment model is described in terms of the trust relationships and communication patterns between Client, Attester, Issuer, and Origin. </ins> The discussion below assumes non-collusion between entities that have access to the attestation context and entities that have access to 4.2. In this model, the Attester and Issuer are operated by the same  <ins> 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 issuance.  This arrangement is shown in the figure below. </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 In this model, the Origin and Issuer are operated by the same entity, separate from the Attester, as shown in the figure below.  The Issuer  <ins> accepts token requests that come from trusted Attesters.  Since the Attester and Issuer are separate entities, the Attester must 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 authentication mechanisms are possible.  This arrangement is shown below. </ins> This model is useful for Origins that require Client-identifying attestation, e.g., through the use of application-layer account different entities, as shown in the figure below.  As with the joint Origin and Issuer model, the Issuer accepts token requests that come from trusted Attesters, and the details of that trust establishment  <ins> depend on the issuance protocol and relationship between Attester and Issuer. </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