]> Google

scott@shendrickson.com

Cloudflare Inc.

ot-ietf@thibault.uk

TODO Abstract About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction This document specifies the protocol between the Attester and Issuer as defined in . This draft is intended for those deploying the split Attester Issuer as defined in Section 4.4 of . The base Privacy Pass issuance protocol defines stateless anonymous tokens, which can either be publicly verifiable or not. This draft is agnostic to all cryptographic protocols and public/private verifiability. This draft defines the protocol that will occur behind the issuer as defined in .

Protocol Overview shows how this draft is only specifying a protocol between the Attester and Issuer, and makes no changes to the protocols between Attesters and Clients, or Attesters and Origins.

Issuance Protocol Overview | | Issuer | | | | | | | | | | | | | | TokenRequest | | | | | | +-----------------> | | | | | | | | | | | | | | | | | | TokenRequest | | | | | | | +-------------------> | | | | | | | | | | | | | | | | | | | | | | | | | TokenResponse | | | | | | | <-------------------+ | | | | | | | | | | | | | | TokenResponse | | | | | | <-----------------+ | | | | | | | | | | | | | | | | | +-------------+ +----------+ | | | | | | | | | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | | | | | | Redeem | | +----------------------------------------------------> | | | +-----------+ ]]>

Attester Issuer Protocol This section describes the Issuance protocol for an Attester to request and receive a token from an Issuer. This protocol occurs entirely between Section 5.1 and 5.2 of or Section 6.1 and 6.2 of .

1. The Client sends a token request to the attester as defined in Section 5.1 or 6.1 of .
2. The Attester authenticates the client as defined in Section 3.5.1 of .
3. The Attester sends an IssuerTokenRequest to the Issuer
4. The Issuer signs the token, and returns an IssuerTokenResponse to the Attester.
5. The Attester parses the signature from the IssuerTokenResponse, and sends the client a TokenResponse as defined in 5.2 or 6.2 of .
6. The client uses the TokenResponse to particpate in a redemption protocol.

The Attester Issuer issuance protocol is designed such that the Issuer learns only enough to satisfy issuance requirements, which can be as simple as the token to sign. Notably the Issuer should not learn any information that may be uniquely identifying at the Origin, especially if the Origin and Issuer are the same entity, as defined in section 4.3 of .

Attester-to-Issuer Request The Attester and Issuer MUST use a mutually authenticated and secure HTTPS connection. They MAY use Mutual TLS for mutual authentication. The "IssuerTokenRequest" defined below is written in TLS Presentation Layer (Section 4 of ), although the Attester and Issuer may instead choose to use another equivelent data interchange format such as JSON (). The structure fields are defined as follows:

• "token_type" is a 2-octet integer. TokenRequest MUST be prefixed with a uint16 "token_type" indicating the token type.
• The rest of the structure after "token_type" is based on that type, within the inner opaque token_request attribute. The above definition corresponds to TokenRequest from . For TokenRequest not defined in , they MAY be used as long as they are prefixed with a 2-octet token_type.

The Attester will encode the IssuerTokenRequest in the chosen interchange format, and send the IssuerTokenRequest to the issuer over the chosen connection.

Issuer behavior In the simplest case, the issuer will recieve the IssuerTokenRequest, sign the message, and return it to the Attester. The signature may be defined by Sections 5 or 6 of , depending on the token_type used.

Issuer-to-Attester Response After signing the request, the issuer assembles and returns an "IssuerTokenResponse" to the attester. The response should be sent in the same HTTPS connection as the request was delivered on. Like the request, the response below is written in TLS Presentation Language, but any data interchange format is acceptable. struct { uint8_t blinded_signature[Ne]; } IssuerTokenResponse; The structure fields are defined as follows:

• "blinded_signature" is a Ne-octet blinded signature over "blinded_msg".

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

Normative References This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model, to help ensure that the desired security and privacy goals are fulfilled. This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer Public Key. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol. This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme specified in this document can be used by Clients to redeem Privacy Pass tokens with an Origin. It can also be used by Origins to challenge Clients to present Privacy Pass tokens. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments TODO acknowledge.