Rate-Limited Token Issuance Protocol

Rate-Limited Token Issuance Protocol Google LLC

scott@shendrickson.com

Fastly

jri@fastly.com

Apple Inc.

One Apple Park Way Cupertino, California 95014 United States of America tpauly@apple.com

Google LLC

svaldez@chromium.org

Cloudflare

caw@heapingbits.net

Internet-Draft This document specifies a variant of the Privacy Pass issuance protocol that allows for tokens to be rate-limited on a per-origin basis. This enables origins to use tokens for use cases that need to restrict access from anonymous clients. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction This document specifies a variant of the Privacy Pass issuance protocol (as defined in ) that allows for tokens to be rate-limited on a per-origin basis. This enables origins to use tokens for use cases that need to restrict access from anonymous clients. The base Privacy Pass issuance protocol defines stateless anonymous tokens, which can either be publicly verifiable or not. This variant build upon the publicly verifiable issuance protocol that uses RSA Blind Signatures , and allows tokens to be rate-limited on a per-origin basis. This means that a client will only be able to receive a limited number of tokens associated with a given origin server within a fixed period of time. This issuance protocol registers the Rate-Limited Blind RSA token type (), to be used with the PrivateToken HTTP authentication scheme defined in .

Motivation A client that wishes to keep its IP address private can hide its IP address using a proxy service or a VPN. However, doing so severely limits the client's ability to access services and content, since servers might not be able to enforce their policies without a stable and unique client identifier. Privacy Pass tokens in general allow clients to provide anonymous attestation of various properties. The tokens generated by the base issuance protocol () can be used to verify that a client meets a particular bar for attestation, but cannot be used by a redeeming server to rate-limit specific clients. There are several use cases for rate-limiting anonymous clients that are common on the Internet. These routinely use client IP address tracking, among other characteristics, to implement rate-limiting. One example of this use case is rate-limiting website accesses to a client to help prevent fraud. Operations that are sensitive to fraud, such as account creation on a website or logging into an account, often employ rate-limiting as a defense-in-depth strategy. Additional verification can be required by these pages when a client exceeds a set rate-limit. Another example of this use case is a metered paywall, where an origin limits the number of page requests from each unique user over a period of time before the user is required to pay for access. The origin typically resets this state periodically, say, once per month. For example, an origin may serve ten (major content) requests in a month before a paywall is enacted. Origins may want to differentiate quick refreshes from distinct accesses. For some applications, the basic issuance protocol from could be used to implement rate limits. In particular, the 'Joint Attester and Issuer' model from could be used to restrict the number of tokens issued to individual clients over a time window. However, in this deployment model, the Attester and Issuer would learn all origins used by a participating client. In some cases this might be a significant portion of browsing history. The issuance protocol defined in this document employs the 'Split Origin, Attester, Issuer' model to combat this, where the issuer would know all per-origin policies, and the attester would mantain per-client state without knowing all origins a client visits.

Properties and Requirements For rate-limited token issuance, the Attester, Issuer, and Origin as defined in each have partial knowledge of the Client's identity and actions, and each entity only knows enough to serve its function (see for more about the pieces of information):

The Attester knows the Client's identity and learns the Client's public key (Client Key), the Issuer being targeted (Issuer Name), the period of time for which the Issuer's policy is valid (Issuer Policy Window), the number of tokens the Issuer is willing to issue within the current policy window, and the number of tokens issued to a given Client for the claimed Origin in the policy window. The Attester does not know the identity of the Origin the Client is trying to access (Origin Name), but knows a Client-anonymized identifier for it (Anonymous Origin ID).
The Issuer knows the Origin's secret (Issuer Origin Secret) and policy about client access, and learns the Origin's identity (Origin Name) during issuance. The Issuer does not learn the Client's identity or information about the Client's access pattern.
The Origin knows the Issuer to which it will delegate an incoming Client (Issuer Name), and can verify that any tokens presented by the Client were signed by the Issuer. The Origin does not learn which Attester was used by a Client for issuance.

Since an Issuer enforces policies on behalf of Origins, a Client is required to reveal the Origin's identity to the delegated Issuer. It is a requirement of this protocol that the Attester not learn the Origin's identity so that, despite knowing the Client's identity, an Attester cannot track and concentrate information about Client activity. An Issuer expects an Attester to verify its Clients' identities correctly, but an Issuer cannot confirm an Attester's efficacy or the Attester-Client relationship directly without learning the Client's identity. Similarly, an Origin does not know the Attester's identity, but ultimately relies on the Attester to correctly verify or authenticate a Client for the Origin's policies to be correctly enforced. An Issuer therefore chooses to issue tokens to only known and reputable Attesters; the Issuer can employ its own methods to determine the reputation of a Attester. An Attester is expected to employ a stable Client identifier, such as an IP address, a device identifier, or an account at the Attester, that can serve as a reasonable proxy for a user with some creation and maintenance cost on the user. For the Issuance protocol, a Client is expected to create and maintain stable and explicit secrets for time periods that are on the scale of Issuer policy windows. Changing these secrets arbitrarily during a policy window can result in token issuance failure for the rest of the policy window; see for more details. A Client can use a service offered by its Attester or a third-party to store these secrets, but it is a requirement of this protocol that the Attester not be able to learn these secrets. The privacy guarantees of this issuance protocol, specifically those around separating the identity of the Client from the names of the Origins that it accesses, are based on the expectation that there is not collusion between the entities that know about Client identity and those that know about Origin identity. Clients choose and share information with Attesters, and Origins choose and share policy with Issuers; however, the Attester is generally expected to not be colluding with Issuers or Origins. If this occurs, it can become possible for an Attester to learn or infer which Origins a Client is accessing, or for an Origin to learn or infer the Client identity. For further discussion, see .

Terminology 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. Unless otherwise specified, this document encodes protocol messages in TLS notation from , Section 3. This draft includes pseudocode that uses the functions and conventions defined in . Encoding an integer to a sequence of bytes in network byte order is described using the function "encode(n, v)", where "n" is the number of bytes and "v" is the integer value. The function "len()" returns the length of a sequence of bytes. The following terms are defined in and are used throughout this document:

Client: An entity that provides authorization tokens to services across the Internet, in return for authorization.
Issuer: An entity that produces Privacy Pass tokens to clients.
Attester: An entity that can attest to properties about the client, including previous patterns of access.
Origin: The server from which the client can redeem tokens.
Issuance Protocol: The protocol exchange that involves the client, attester, and issuer, used to generate tokens.

The following terms are defined in , which defines the interactions between clients and origins:

Issuer Name: The name that identifies the Issuer, which is an entity that can generate tokens for a Client using one or more issuance protocols.
Token Key: Keying material that can be used with an issuance protocol to create a signed token.
Origin Name: The name that identifies the Origin, as included in a TokenChallenge.

Additionally, this document defines several terms that are unique to the rate-limited issuance protocol:

Issuer Policy Window: The period over which an Issuer will track access policy, defined in terms of seconds and represented as a uint64. The state that the Attester keeps for a Client is specific to a policy window. The effective policy window for a specific Client starts when the Client first sends a request associated with an Issuer.
Origin Name Key: The public key used to encrypt values such as Origin Name in requests from Clients to the Issuer, so that Attesters cannot learn the Origin Name value. Each Origin Name Key is used across all requests on the Issuer, for different Origins.
Anonymous Origin ID: An identifier that is generated by the Client and marked on requests to the Attester, which represents a specific Origin anonymously. The Client generates a stable Anonymous Origin ID for each Origin Name, to allow the Attester to count token access without learning the Origin Name.
Client Key: A public key chosen by the Client and shared only with the Attester; see for more details about this restriction.
Client Secret: The secret key used by the Client during token issuance, whose public key (Client Key) is shared with the Attester.
Issuer Origin Secret: A per-origin secret key used by the Issuer during token issuance, whose public key is not shared with anyone.
Anonymous Issuer Origin ID: An identifier that is generated by Issuer based on an Issuer Origin Secret that is per-Client and per-Origin. See for details of derivation.

Configuration Issuers MUST provide three parameters for configuration:

Issuer Policy Window: a uint64 of seconds as defined in .
Issuer Request URI: a token request URL for generating access tokens. For example, an Issuer URL might be https://issuer.example.net/token-request. This parameter uses resource media type "text/plain".
Origin Name Key: a NameKey structure as defined below to use when encrypting the Origin Name in issuance requests. This parameter uses resource media type "application/issuer-name-key". The Npk parameter corresponding to the HpkeKdfId can be found in .

The Issuer parameters can be obtained from an Issuer via a directory object, which is a JSON object whose field names and values are raw values and URLs for the parameters.

Field Name	Value
issuer-policy-window	Issuer Policy Window as a JSON number
issuer-request-uri	Issuer Request URI resource URL as a JSON string
origin-name-key-uri	Origin Name Key URI resource URL as a JSON string

As an example, the Issuer's JSON directory could look like: Issuer directory resources have the media type "application/json" and are located at the well-known location /.well-known/token-issuer-directory.

Token Challenge Requirements Clients receive challenges for tokens, as described in . For the rate-limited token issuance protocol described in this document, the name of the origin is sent in an encrypted message from the Client to the Issuer. If the TokenChallenge.origin_info field contains a single origin name, that origin name is used. If the origin_info field contains multiple origin names, the client selects the single origin name that presented the challenge. If the origin_info field is empty, the encrypted message is the empty string "". The HTTP authentication challenge also SHOULD contain the following additional attribute:

"origin-name-key", which contains a base64url encoding of a NameKey as defined in to use when encrypting the Origin Name in issuance requests.

Issuance Protocol This section describes the Issuance protocol for a Client to request and receive a token from an Issuer. Token issuance involves a Client, Attester, and Issuer, with the following steps:

The Client sends a token request containing a token request, encrypted origin name, and one-time-use public key and signature to the Attester
The Attester validates the request contents, specifically checking the request signature, and proxies the request to the Issuer
The Issuer validates the request against the signature, and processes its contents, and produces a token response sent back to the Attester
The Attester verifies the response and proxies the response to the Client

The Issuance protocol is designed such that Client, Attester, and Issuer learn only what is necessary for completing the protocol; see for more details. The Issuance protocol has a number of underlying cryptographic dependencies for operation:

RSA Blind Signatures , for issuing and constructing Tokens. This support is the same as used in the base publicly verifiable token issuance protocol
, for encrypting the origin server name in transit between Client and Issuer across the Attester.
signatures with key blinding, as described in , for verifying correctness of Client requests.

Clients and Issuers are required to implement all of these dependencies, whereas Attesters are required to implement ECDSA signature with key blinding support.

State Requirements The Issuance protocol requires each participating endpoint to maintain some necessary state, as described in this section.

Client State A Client is required to have the following information, derived from a given TokenChallenge:

Origin Name, a hostname referring to the Origin . This is the name of the Origin that issued the token challenge. One or more names can be listed in the TokenChallenge.origin_info field. Rate-limited token issuance relies on the client selecting a single origin name from this list if multiple are present.
Token Key, a blind signature public key corresponding to the Issuer identified by the TokenChallenge.issuer_name.
Origin Name Key, a public key used to encrypt request information corresponding to the Issuer identified by TokenChallenge.issuer_name.

Clients maintain a stable Client Key that they use for all communication with a specific Attester. Client Key is a public key, where the corresponding private key Client Secret is known only to the client. If the client loses this (Client Key, Client Secret), they may generate a new tuple. The Attester will enforce if a client is allowed to use this new Client Key. See for details on this enforcement. Clients also need to be able to generate an Anonymous Origin ID value that corresponds to the Origin Name, to send in requests to the Attester. Anonymous Origin ID MUST be a stable and unpredictable 32-byte value computed by the Client. Clients MUST NOT change this value across token requests for the same Origin Name. Doing so will result in token issuance failure (specifically, when an Attester rejects a request upon detecting two Anonymous Origin ID values that map to the same Origin). One possible mechanism for implementing this identifier is for the Client to store a mapping between the Origin Name and a randomly generated Anonymous Origin ID for future requests. Alternatively, the Client can compute a PRF keyed by a per-client secret (Client Secret) over the Origin Name, e.g., Anonymous Origin ID = HKDF(secret=Client Secret, salt="", info=Origin Name).

Attester State An Attester is required to maintain state for every authenticated Client. The mechanism of identifying a Client is specific to each Attester, and is not defined in this document. As examples, the Attester could use device-specific certificates or account authentication to identify a Client. Attesters must enforce that Clients don't change their Client Key frequently, to ensure Clients can't regularily evade the per-client policy as seen by the issuer. Attesters MUST NOT allow Clients to change their Client Key more than once within a policy window, or in the subsequent policy window after a previous Client Key change. Alternative schemes where the Attester stores the encrypted (Client Key, Client Secret) tuple on behalf of the client are possble but not described here. Attesters are expected to know the Issuer Policy Window for any Issuer Name to which they allow access. This information can be retrieved using the URIs defined in . For each Client-Issuer pair, an Attester maintains a policy window start and end time for each Issuer from which a Client requests a token. For each tuple of (Client Key, Anonymous Origin ID, policy window), the Attester maintains the following state:

A counter of successful tokens issued
Whether or not a previous request was rejected by the Issuer
The last received Anonymous Issuer Origin ID value for this Anonymous Origin ID, if any

Issuer State Issuers maintain a stable Issuer Origin Secret that they use in calculating values returned to the Attester for each origin. If this value changes, it will open up a possibility for Clients to request extra tokens for an Origin without being limited, within a policy window. See for details about generating and rotating the Issuer Origin Secret. Issuers are expected to have the private key that corresponds to Origin Name Key, which allows them to decrypt the Origin Name values in requests. Issuers also need to know the set of valid Token Key public keys and corresponding private key, for each Origin Name that is served by the Issuer. Origins SHOULD update their view of the Token Key regularly to ensure that Client requests do not fail after Token Key rotation.

Issuance HTTP Headers The Issuance protocol defines four new HTTP headers that are used in requests and responses between Clients, Attesters, and Issuers (see ). The "Sec-Token-Origin" is an Item Structured Header . Its value MUST be a Byte Sequence. This header is sent both on Client-to-Attester requests () and on Issuer-to-Attester responses (). Its ABNF is: The "Sec-Token-Client" is an Item Structured Header . Its value MUST be a Byte Sequence. This header is sent on Client-to-Attester requests (), and contains the bytes of Client Key. Its ABNF is: The "Sec-Token-Request-Blind" is an Item Structured Header . Its value MUST be a Byte Sequence. This header is sent on Client-to-Attester requests (), and contains a per-request nonce value. Its ABNF is: The "Sec-Token-Limit" is an Item Structured Header . Its value MUST be an Integer. This header is sent on Issuer-to-Attester responses (), and contains the number of times a Client can retrieve a token for the requested Origin within a policy window, as set by the Issuer. Its ABNF is:

Client-to-Attester Request The Client and Attester MUST use a secure and Attester-authenticated HTTPS connection. They MAY use mutual authentication or mechanisms such as TLS certificate pinning, to mitigate the risk of channel compromise; see for additional about this channel. Requests to the Attester need to indicate the Issuer Name to which issuance requests will be forwarded. Attesters SHOULD provide Clients with a URI template that contains one variable that contains the Issuer Name, "issuer", using Level 3 URI template encoding as defined in Section 1.2 of . An example of an Attester URI templates is shown below: Attesters and Clients MAY agree on other mechanisms to specify the Issuer Name in requests. The Client first creates an issuance request message for a random value nonce using the input TokenChallenge challenge and the Issuer key identifier key_id as follows: The Client then uses Client Key to generate its one-time-use request public key request_key and blind request_blind as described in . The Client then encrypts the origin name using Origin Name Key, producing encrypted_origin_name as described in . Finally, the Client uses Client Secret to produce request_signature as described in . The Client then constructs a TokenRequest structure. This TokenRequest structure is based on the publicly verifiable token issuance path in , adding fields for the encrypted origin name and request signature. ; uint8_t request_signature[96]; } TokenRequest; ]]> The structure fields are defined as follows:

"token_type" is a 2-octet integer, which matches the type in the challenge.
"token_key_id" is the least significant byte of the Token Key key ID, which is generated as SHA256(public_key), where public_key is a DER-encoded SubjectPublicKeyInfo object carrying Token Key.
"blinded_msg" is the Nk-octet request defined above.
"request_key" is computed as described in .
"origin_name_key_id" is a collision-resistant hash that identifies the Origin Name Key, generated as SHA256(NameKey).
"encrypted_origin_name" is an encrypted structure that contains Origin Name, calculated as described in .
"request_signature" is computed as described in .

The Client then generates an HTTP POST request to send through the Attester to the Issuer, with the TokenRequest as the body. The media type for this request is "message/token-request". The Client includes the "Sec-Token-Origin" header, whose value is Anonymous Origin ID; the "Sec-Token-Client" header, whose value is Client Key; and the "Sec-Token-Request-Blind" header, whose value is request_blind. The Client sends this request to the Attester's proxy URI. An example request is shown below, where Nk = 512, the Issuer Name is "issuer.net", and the Attester URI template is "https://attester.net/token-request{?issuer}" sec-token-origin = Anonymous Origin ID sec-token-client = Client Key sec-token-request-blind = request_blind ]]> If the Attester detects a token_type in the TokenRequest that it does not recognize or support, it MUST reject the request with an HTTP 400 error. The Attester also checks to validate that the origin_name_key_id in the client's TokenRequest matches a known Origin Name Key public key for the Issuer. For example, the Attester can fetch this key using the API defined in . This check is done to help ensure that the Client has not been given a unique key that could allow the Issuer to fingerprint or target the Client. If the key does not match, the Attester rejects the request with an HTTP 400 error. Note that this can lead to failures in the event of Issuer Origin Name Key rotation; see for considerations. The Attester finally validates the Client's stable mapping request as described in . If this fails, the Attester MUST return an HTTP 400 error to the Client. If the Attester accepts the request, it will look up the state stored for this Client. It will look up the count of previously generate tokens for this Client using the same Anonymous Origin ID. See for more details. If the Attester has stored state that a previous request for this Anonymous Origin ID was rejected by the Issuer in the current policy window, it SHOULD reject the request without forwarding it to the Issuer. If the Attester detects this Client has changed their Client Key more frequently than allowed as described in , it SHOULD reject the request without forwarding it to the Issuer.

Attester-to-Issuer Request Assuming all checks in succeed, the Attester generates an HTTP POST request to send to the Issuer with the Client's TokenRequest as the body. The Attester MUST NOT add information that will uniquely identify a Client, or associate the request with a small set of possible Clients. Extensions to this protocol MAY allow Attesters to add information that can be used to separate large populations, such as providing information about the country or region to which a Client belongs. An example request is shown below. ]]> The Attester and the Issuer MUST use a secure and Issuer-authenticated HTTPS connection. Also, Issuers MUST authenticate Attesters, either via mutual TLS or another form of application-layer authentication. They MAY additionally use mechanisms such as TLS certificate pinning, to mitigate the risk of channel compromise; see for additional about this channel. Upon receipt of the forwarded request, the Issuer validates the following conditions:

The TokenRequest contains a supported token_type
The TokenRequest.token_key_id and TokenRequest.origin_name_key_id correspond to known Token Keys and Origin Name Keys held by the Issuer.
The TokenRequest.encrypted_origin_name can be decrypted using the Issuer's private key (the private key associated with Origin Name Key), and matches an Origin Name that is served by the Issuer. This name might be the empty string "", as described in , in which case the Issuer applies a cross-origin policy if supported. If a cross-origin policy is not supported, this condition is not met.
The TokenRequest.blinded_msg is of the correct size

If any of these conditions is not met, the Issuer MUST return an HTTP 400 error to the Attester, which will forward the error to the client. The Issuer determines the correct Issuer Key by using the decrypted Origin Name value and TokenRequest.token_key_id. If there is no Token Key whose truncated key ID matches TokenRequest.token_key_id, the Issuer MUST return an HTTP 401 error to Attester, which will forward the error to the client. The Attester learns that the client's view of the Origin key was invalid in the process.

Issuer-to-Attester Response If the Issuer is willing to give a token to the Client, the Issuer decrypts TokenRequest.encrypted_origin_name to discover "origin". If this fails, the Issuer rejects the request with a 400 error. Otherwise, the Issuer validates and processes the token request with Issuer Origin Secret corresponding to the designated Origin as described in . If this fails, the Issuer rejects the request with a 400 error. Otherwise, the output is index_key. The Issuer completes the issuance flow by computing a blinded response as follows: skP is the private key corresponding to Token Key, known only to the Issuer. The Issuer generates an HTTP response with status code 200 whose body consists of blind_sig, with the content type set as "message/token-response", the index_key set in the "Sec-Token-Origin" header, and the limit of tokens allowed for a Client for the Origin within a policy window set in the "Sec-Token-Limit" header. This limit SHOULD NOT be unique to a specific Origin, such that the Attester could use the value to infer which Origin the Client is accessing (see ). sec-token-origin = index_key sec-token-limit = Token limit ]]>

Attester-to-Client Response Upon receipt of a successful response from the Issuer, the Attester extracts the "Sec-Token-Origin" header, and uses the value to determine Anonymous Issuer Origin ID as described in . If the "Sec-Token-Origin" is missing, or if the same Anonymous Issuer Origin ID was previously received in a response for a different Anonymous Origin ID within the same policy window, the Attester MUST drop the token and respond to the client with an HTTP 400 status. If there is not an error, the Anonymous Issuer Origin ID is stored alongside the state for the Anonymous Origin ID. The Attester also extracts the "Sec-Token-Limit" header, and compares the limit against the previous count of accesses for this Client for the Anonymous Origin ID. If the count is greater than or equal to the limit, the Attester drops the token and responds to the client with an HTTP 429 (Too Many Requests) error. For all other cases, the Attester forwards all HTTP responses unmodified to the Client as the response to the original request for this issuance. When the Attester detects successful token issuance, it MUST increment the counter in its state for the number of tokens issued to the Client for the Anonymous Origin ID. Upon receipt, the Client handles the response and, if successful, processes the body as follows: If this succeeds, the Client then constructs a token as described in as follows:

Encrypting Origin Names Given a NameKey (Origin Name Key), Clients produce encrypted_origin_name and authenticate the contents of the TokenRequest using the following values:

the one octet key identifier from the Name Key, keyID, with the corresponding KEM identified by kemID, the public key from the configuration, pkI, and;
a selected combination of KDF, identified by kdfID, and AEAD, identified by aeadID.

Beyond the key configuration inputs, Clients also require the following inputs defined in : token_key_id, blinded_msg, request_key, and origin_name_key_id. Together, these are used to encapsulate Origin Name (origin_name) and produce Encrypted Origin Name (encrypted_origin). origin_name contains the name of the origin that initiated the challenge, as taken from the TokenChallenge.origin_info field. If the TokenChallenge.origin_info field is empty, origin_name is set to the empty string "". The process for generating encrypted_origin from origin_name is as follows:

Compute an context using pkI, yielding context and encapsulation key enc.
Construct associated data, aad, by concatenating the values of keyID, kemID, kdfID, aeadID, and all other values of the TokenRequest structure.
Pad origin_name with N zero bytes, where N = 31 - ((L - 1) % 32) and L is the length of origin_name. Denote this padding process as the function pad.
Encrypt (seal) the padded origin_name with aad as associated data using context, yielding ciphertext ct.
Concatenate the values of aad, enc, and ct, yielding encrypted_origin_name.

Note that enc is of fixed-length, so there is no ambiguity in parsing this structure. In pseudocode, this procedure is as follows: Issuers reverse this procedure to recover the (padded) Origin Name by computing the AAD as described above and decrypting encrypted_origin_name with their private key skI (the private key corresponding to pkI), and stripping off padding bytes. In pseudocode, this procedure is as follows: The resulting value of origin_name is used by the Issuer to determine which rate-limit values to send to the Attester for enforcement. If the decrypted origin_name is the empty string "", the Issuer applies a cross-origin rate-limit policy, if supported. If the decrypted origin_name is the empty string "" and the Issuer does not support cross-origin rate limiting, then it MUST abort the protocol as described in .

Anonymous Issuer Origin ID Computation This section describes the Client, Attester, and Issuer behavior in computing Anonymous Issuer Origin ID, the stable mapping based on client identity and origin name. At a high level, this functionality computes y = F(x, k), where x is a per-Client secret and k is a per-Origin secret, subject to the following constraints:

The Attester only learns y if the Client in possession of x engages with the protocol;
The Attester prevents a Client with private input x from running the protocol for input x' that is not equal to x;
The Issuer does not learn x, nor does it learn when two requests correspond to the same private value x; and
Neither the Client nor Attester learn k.

The interaction between Client, Attester, and Issuer in computing this functionality is shown below. (request, signature) ----------------------> (response) <---------------------- ]]> The protocol for computing this functionality is divided into sections for each of the participants. describes Client behavior for initiating the computation with its per-Client secret, describes Attester behavior for verifying Client requests, describes Issuer behavior for computing the mapping with its per-Origin secret, and describes the final Attester step for computing the client-origin index. The index computation is based on ECDSA instantiated with P-384 and SHA-384 and extended with key blinding support as described in . It uses the following functions:

ECDSA-KeyGen(): Generate a random ECDSA private and public key pair (sk, pk).
ECDSA-BlindPublicKey(pk, r): Produce a blinded public key based on the input public key pk and blind r according to , Section 6.1.
ECDSA-Verify(pk, msg, sig): Verify the DER-encoded ECDSA-Sig-Value signature sig over input message msg against the ECDSA public key pk, producing a boolean value indicating success.
ECDSA-BlindKeySign(sk_sign, sk_blind, msg): Sign input message msg with signing key sk_sign and blind sk_blind according to , Section 6.2, and serializes the resulting signature pair (r, s) in "raw" form, i.e., as the concatenation of two 48-byte, big endian scalars.
ECDSA-SerializePrivatekey(sk): Serialize an ECDSA private key using the Field-Element-to-Octet-String conversion according to .
ECDSA-DeserializePrivatekey(buf): Attempt to deserialize an ECDSA private key from a 48-byte string buf using Octet-String-to-Field-Element from . This function can fail if buf does not represent a valid private key.
ECDSA-SerializePublicKey(pk): Serialize an ECDSA public key using the compressed Elliptic-Curve-Point-to-Octet-String method according to .
ECDSA-DeserializePublicKey(buf): Attempt to deserialize a public key using the compressed Octet-String-to-Elliptic-Curve-Point method according to , and then performs partial public-key validation as defined in section 5.6.2.3.4 of . This validation includes checking that the coordinates are in the correct range, that the point is on the curve, and that the point is not the point at infinity.

Client Behavior This section describes the Client behavior for generating an one-time-use request key and signature. Clients provide their Client Secret as input to the request key generation step, and the rest of the token request inputs to the signature generation step.

Request Key Clients produce request_key by masking Client Key and Client Secret with a randomly chosen blind. Let pk_sign and sk_sign denote Client Key and Client Secret, respectively. This process is done as follows:

Generate a random ECDSA private key, sk_blind.
Blind pk_sign with sk_blind to compute a blinded public key, request_key.
Output the blinded public key.