Draft: draft-ietf-privacypass-architecture

Commentary: In this image : ! It is n't very clear where messages originate and who gets to see them . In particular , it is n'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 [  ] for example implementations ? 
 Is the suggestion here to describe -- conceptually -- what  and TokenChallenges are in the architecture document ? If so , that seems quite reasonable . 
 Yeah . An architecture is most useful if you do n't have to dig into the details to understand it and those references are somewhat critical to comprehension .
At a high level, the Privacy Pass architecture consists of two
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
authorization.  Depending on the type of token, e.g., whether or not
it can be cached, the Client either presents a previously obtained
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.
This document describes requirements for both issuance and redemption
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.
At a high level, the Privacy Pass architecture consists of two
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
authorization.  Depending on the type of token, e.g., whether or not
it can be cached, the Client either presents a previously obtained
token or invokes an issuance protocol, such as ISSUANCE, to acquire a
token to present as authorization.
This document describes requirements for both issuance and redemption
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.
The Privacy Pass architecture consists of four logical entities -
Client, Origin, Issuer, and Attester - that work in concert as shown
in introduction for token issuance and redemption.  This section
describes the purpose of token issuance and redemption and the
requirements therein on the relevant participants.
Redemption context: The interactions and set of information shared
between the Client and Origin.
Issuance context: The interactions and set of information shared
between the Client, Attester, and Issuer.
Attestation context: The interactions and set of information
shared between the Client and Attester only, for the purposes of
attesting the vailidity of the Client.
The Privacy Pass architecture consists of four logical entities -
Client, Origin, Issuer, and Attester - that work in concert as for
token issuance and redemption.  This section describes the purpose of
token issuance and redemption and the requirements on the relevant
participants.
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.
If the Client already has a token available that satisfies the
token challenge, it can skip to step 6 and redeem its token.
Otherwise, it invokes the issuance protocol to request a token
from the designated Issuer.
The first step in the issuance protocol is attestation.
Specifically, the Attester performs attestation checks on the
Client.  These checks could be proof of solving a CAPTCHA, device
trust, hardware attestation, etc (see attester).
If attestation succeeds, the client creates a Token Request to
send to the designated Issuer (generally via the Attester).  The
Attester and Issuer might be functions on the same server,
depending on the deployment model (see deployment).  Depending on
the details of Attestation, the Client can send the Token Request
to the Attester alongside any attestation information.  If
attestation fails, the Client receives an error and issuance
aborts without a token.
The Issuer generates a Token Response based on the Token Request,
which is returned to the Client (generally via the Attester).
Upon receiving the Token Response, the Client computes a token
from the token challenge and Token Response.  This token can be
validated by anyone with the per-Issuer key, but cannot be linked
to the content of the Token Request or Token Response.
If the Client has a token, it includes it in a subsequent HTTP
request to the Origin, as authorization.  This token is sent only
once.  The Origin validates that the token was generated by the
expected Issuer and has not already been redeemed for the
corresponding token challenge.  If the Client does not have a
token, perhaps because issuance failed, the client does not reply
to the Origin's challenge with a new request.
Issuers MUST NOT issue tokens for Clients through untrusted
Attesters.  This is important because the Attester's role is to vouch
for trust in privacy-sensitive Client information, such as account
identifiers or IP address information, to the Issuer.  Tokens
produced by an Issuer that admits issuance for any type of
attestation cannot be relied on for any specific property.  See
attester-role for more details.
Issuers MUST NOT issue tokens for Clients through untrusted
Attesters.  This is important because the Attester's role is to vouch
for trust in privacy-sensitive Client information, such as account
identifiers or IP address information, to the Issuer.  Tokens
produced by an Issuer that admits issuance for any type of
attestation cannot be relied on for any specific property.  See
attester for more details.