Original text:
Privacy Pass is an architecture for authorization based on privacy- preserving authentication mechanisms.  Typical approaches for <del> authorizing clients, such as through the use of long-term cookies, are not privacy-friendly since they allow servers to track clients across sessions and interactions.  Privacy Pass takes a different approach: instead of presenting linkable state-carrying information to servers, e.g., a cookie indicating whether or not the client is an authorized user or has completed some prior challenge, clients present unlinkable proofs that attest to this information.  These proofs, or tokens, are private in the sense that a given token cannot be linked to the protocol interaction where that token was initially issued. </del>  At a high level, the Privacy Pass architecture consists of two protocols: redemption and issuance.  The redemption protocol, The typical interaction flow for Privacy Pass uses the following steps: <del> 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. </del>  If the Client already has a token available that satisfies the token challenge, e.g., because the Client has a cache of

Reviewer comments:
The interaction model here doesn't really need to use HTTP as far as I can tell. Obviously, the specific protocols need to be more concrete, but the architecture works without specifically saying that the interactions use HTTP. The overview specifically mentions HTTP only with respect to the Client-Origin interactions, not other interactions, but I can't see how this is necessary.
No, it doesn't need to use HTTP. The auth scheme document that instantiates the challenges and redemption does use HTTP, but other mechanisms can be used.
I'm OK de-emphasizing HTTP in the architecture if it helps simplify the presentation. Beyond it overly restrictive, was there another reason that led to this issue, NAME
Only that I know that this has obvious applications beyond HTTP and the architecture has no direct need to use it.
Request/response is still a bit implying HTTP, but I'm OK with this change.

Revised text:
Privacy Pass is an architecture for authorization based on privacy- preserving authentication mechanisms.  Typical approaches for  <ins> authorizing clients, such as through the use of long-term state (cookies), are not privacy-friendly since they allow servers to track clients across sessions and interactions.  Privacy Pass takes a different approach: instead of presenting linkable state-carrying information to servers, e.g., a cookie indicating whether or not the client is an authorized user or has completed some prior challenge, clients present unlinkable proofs that attest to this information. These proofs, or tokens, are private in the sense that a given token cannot be linked to the protocol interaction where that token was initially issued. </ins> At a high level, the Privacy Pass architecture consists of two protocols: redemption and issuance.  The redemption protocol, The typical interaction flow for Privacy Pass uses the following steps:  <ins> A Client interacts with an Origin by sending a request or otherwise interacting with the Origin in a way that triggers a response containing a token challenge.  The token challenge indicates a specific Issuer to use. </ins> If the Client already has a token available that satisfies the token challenge, e.g., because the Client has a cache of