Draft: draft-ietf-privacypass-protocol

Commentary: 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 . 
 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 .
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.
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.
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.
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.
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.
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.
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.
The values "token_input" and "blinded_element" are stored locally and
used later as described in private-finalize.  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.
The values "token_input" and "blinded_element" are stored locally and
used later as described in private-finalize.  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.
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.
This document outlines how to instantiate the Issuance protocol based
on the VOPRF defined in OPRF and blind RSA protocol defined in
BLINDRSA.  All security considerations described in the VOPRF and
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
Architecture document ARCHITECTURE.
This document outlines how to instantiate the Issuance protocol based
on the VOPRF defined in OPRF and blind RSA protocol defined in
BLINDRSA.  All security considerations described in the VOPRF and
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
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.
A Client uses Privacy Pass to separate attestation context and
redemption context.  Linking or combining these contexts can reveal
sensitive information about the Client, including their identity or
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
a number of ways.  This section covers some expected deployment
models and their corresponding security and privacy considerations.
A Client uses Privacy Pass to separate attestation context and
redemption context.  Linking or combining these contexts can reveal
sensitive information about the Client, including their identity or
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
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.
In this model, the Attester and Issuer are operated by the same
entity that is separate from the Origin, as shown in the figure
below.
In this model, the Attester and Issuer are operated by the same
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.
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
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.
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
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.
In this model, the Origin, Attester, and Issuer are all operated by
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
depend on the issuance protocol.
In this model, the Origin, Attester, and Issuer are all operated by
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
depend on the issuance protocol and relationship between Attester and
Issuer.