§ Non-Revocation Token

Specification Status: Draft

Latest Draft: https://identity.foundation/revocation/non-revocation-token

Editors:
Andrew Whitehead
Brian Richter
Participate:
GitHub repo
File a bug
Commit history

§ Abstract

A non-revocation token contains a cryptographic accumulator signed by the credential issuer, following the signing and proving processes laid out in zk-SAM. This allows for the holder to prove non-revocation of the credential for a particular timestamp, without revealing any extra correlating information. Like current BBS+ signature implementations the pairing-friendly BLS12-381 elliptic curve is used.

This approach to proving the non-revocation of a verifiable credential has characteristics that meet some practical requirements for a number of important use cases. See the Requirements and Characteristics section later in this document.

§ Linking Issued Credentials

Each issued credential must contain two additional signed messages in order to enable revocation support, both represented as opaque 32-byte scalar values:

In addition to these two signed messages, the prover will require the following:

The signed credential envelope must reference a verification method which requires validation of the revocation status (example TBD). This is asserted by the prover in deriving a signature proof of knowledge for the issued credential, with known blinding factors for the two revocation messages, and then deriving the related token’s non-revocation proof of knowledge using the same blinding factors. Both proofs must be included in the same challenge value calculation.

The verifier is responsible for choosing and enforcing the earliest accepted timestamp (method also TBD).

§ Token Registry Metadata

The token registry metadata is likely unchanged for the duration of the registry and may be cached by provers. It is not required by verifiers. It includes the following:

§ Token Registry State

The token registry state is updated each time outstanding revocations are published, or the number of issuable credentials is increased. It is not required by verifiers, although the latest timestamp (or guidelines regarding timestamp freshness) will need to be accessible.

Each registry state contains the following:

The number of data blocks will depend on the number of issuable credentials. There are three block types:

§ Signature Generation

§ Expected Data Sizes

§ Implementation

See sample implementation in Rust at GitHub.

§ Current Timings

Tested on a 2017 Macbook Pro, with block size 1024. Further optimizations are yet to be applied:

§ Requirements and Characteristics

§ Open Issues

Table of Contents