Change:
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> <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> <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> <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.

Discussion:
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.