BBS for PrivacyPass

3.1.1. Attribute Values

The Client begins by forming a sequence of strings corresponding to the attributes they wish signed. They engage in the Attestation protocol with the Attestor, and then send the serialized array of attributes to the Issuer. The way with which the list of attributes is communicated to the Issuer is considered protocol specific. An option is to serialize the attributes as a base64 encoded JSON array. The Issuer MUST parse the received attributes list before signing, and verify that each attribute is permitted by their polishes.¶

The Attestor interaction and validation of the attributes is not specified here. In a split instantiation as per [PPARCH], Attestors and Issuers MUST ensure that the claims by the Client are not changeable between attestation and signing.¶

3.1.2. Header Value

Each attribute will be selectively disclosable by the Client during the redemption protocol. Protocol and application critical information (for example, a token type) need to be included in the header input value of the BBS signature generation operation as defined in Section 3.4.1 of [BBS]. The header value will not be selectively disclosable, meaning that the Client will be required to reveal it during redemption. For HTTP based applications it is RECOMMENDED to include the token's type to the header. It is also RECOMMENDED the header value to be protocol or application defined. See Section 7 for more information.¶

3.1.3. Token Response

If parsing and validating the received attributes was successful, the Issuer can sign them together with the selected header using the signature generation function of [BBS]. The Issuer then returns the signature and optionally the selected header (if it is not protocol defined) to the Client. The means with which those values are communicated are considered protocol specific. An option is to encode them using base64. The Client MUST verify the returned signature against their selected set of attributes and header value, using the signature verification operation as defined in Section 3.4.2 of [BBS].¶

4.1.1. Client-to-Issuer Request

The Client first creates an issuance request message using the Issuer key identifier as follows:¶

struct {
  uint16_t token_type = 0x0003;  /* Type BBS with "BLS12-381-SHA-256" */
  uint8_t truncated_token_key_id;
} TokenRequest;

The structure fields are defines bellow:¶

• "token_type" is a 2-octet integer, which matches the type in the challenge.¶
• "truncated_token_key_id" is the least significant byte of the token_key_id in network byte order.¶

Using the constructed TokenRequest, the Client builds an ExtendedTokenRequest, defined in [PPEXT], as follows:¶

struct {
  TokenRequest request;
  Extensions extensions;
} ExtendedTokenRequest;

The contents of the ExtendedTokenRequest.extensions value, MUST match the Client's configured extensions value. The Client then generates an HTTP POST request to send to the Issuer Request URI, with the ExtendedTokenRequest as the content.¶

4.1.2. Issuer-to-Client Response

Upon receiving the Client's request, the Issuer needs to validate the following:¶

• The ExtendedTokenRequest.TokenRequest contains a supported token_type.¶
• The ExtendedTokenRequest.TokenRequest contains a truncated_token_key_id that corresponds to the truncated key ID of an Issuer Public Key.¶
• The ExtendedTokenRequest.extensions value is permitted by the Issuer's policy.¶

If any of these conditions is not met, the Issuer MUST return an HTTP 400 error to the Client. Otherwise, if the Issuer is willing to produce a token for the Client, they will complete the issuance flow by signing the agreed upon extension values. To do so, they first must parse the content value ExtendedTokenRequest.extensions and if successful, yield the extensions array. Then, they must sign those extensions, using the following steps:¶

header = 0x0003
signature = Sign(skI, pkI,  header, extensions)

The Sign function is defined in Section 3.4.1 of [BBS] and is instantiated with the parameters defined by the "BLS12-381-SHA-256" ciphersuite (Section 6.2.2 of [BBS]). The result is encoded and transmitted to the client in the following TokenResponse structure:¶

struct {
  uint8_t signature[octet_point_length + octet_scalar_length];
} TokenResponse;

The octet_point_length and octet_scalar_length constants are defined in Section 6.2 of [BBS].¶

The Issuer generates an HTTP response with status code 200 whose content consists of TokenResponse, with the content type set as "application/private-token-response".¶

4.1.3. Finalization

Upon receipt, the Client handles the response and, if successful, deserializes the content values TokenResponse.signature yielding the signature value. the Client MUST validate the produced signature as follows:¶

result = Verify(pkI, signature, 0x0003, extensions)

The Verify function is defined in Section 3.4.2 of [BBS] and is instantiated with the parameters defined by the "BLS12-381-SHA-256" ciphersuite (Section 6.2.2 of [BBS]). If the result is not VALID, the Client MUST abort.¶

If signature verification is successful, the Client can generate multiple tokens with unlinkable authenticator values, using the procedure defined in Section 4.2.1.¶

4.1.4. Issuer Configuration

//TODO¶

4.2.1. Token Generation

The Client can generate multiple Tokens with unlinkable authenticator values, using the ProofGen function as defined in Section 3.4.3 of [BBS], instantiated with the parameters defined by the "BLS12-381-SHA-256" ciphersuite (Section 6.2.2 of [BBS]).¶

The Client can also select a subset of the extensions to disclose to the Origin. The means with which a Client will negotiate with the Origin the required extensions is outside the scope of this document. Let disclosed_extensions_indexes to be an ordered array of 2 byte integers from 1 to 65535, corresponding to the indexes that the extensions the Client wishes to disclose have, in the Extensions.extensions array. The client produces an authenticator value as follows:¶

nonce = random(32)
challenge_digest = SHA256(challenge)
header = 0x0003
presentation_header = concat(nonce, challenge_digest)

authenticator = ProofGen(pkI,
                         signature,
                         header,
                         presentation_header,
                         extensions,
                         disclosed_extensions_indexes)

If the above calculation succeeds, the Client constructs a Token as follows:¶

struct {
  uint16_t token_type = 0x0003;
  uint8_t nonce[32];
  uint8_t challenge_digest[32];
  uint8_t token_key_id[Nid];
  uint16_t disclosed_extensions_indexes<0..2^16-1>
  uint8_t authenticator<0..Nu>;
} Token;

The maximum length of the authenticator Nu is defined as Nu = 2 * octet_point_length + (2^16 + 2) * octet_scalar_length. Note, the addition of the disclosed_extensions_indexes field to the Token structure defined in [PPAUTH].¶

4.2.2. Token Verification

Upon receiving the Token, the Origin MUST parse it and validate that all the fields have the correct length. Additionally, the Origin MUST parse the Token.disclosed_extensions_indexes content value and verify that it comprised from an ordered array of integers from 1 to 65535. Lastly, the Origin MUST also parse the received (disclosed) Extensions.extensions value and create the array disclosed_extensions. Verifying a Token requires knowledge of the Issuer's public key (pkI) corresponding to the Token.token_key_id value. The Origin can verify the Token and corresponding disclosed extensions as follows:¶

header = 0x0003
presentation_header = concat(Token.nonce, Token.challenge_digest)

res = ProofVerify(pkI,
                  Token.authenticator,
                  header,
                  presentation_header,
                  disclosed_extensions,
                  Token.disclosed_extensions_indexes)

The ProofVerify function is defined in Section 3.4.4 of [BBS], instantiated with the parameters defined by the "BLS12-381-SHA-256" ciphersuite (Section 6.2.2 of [BBS]).¶