AnonCreds (ZKCreds)
Much of the work in this page is influenced, iterated or directly replicated from Kaliya Young's excellent document on Verifiable Credential Flavors Explained. We intend to give appropriate credit to this work, as expressed under a Creative Commons Attribution 4.0 International License.
AnonCreds are a type or flavour of Verifiable Credentials that were originally developed by the company Evernym, and were subsequently adopted by the Sovrin Foundation as part of the 'Indy' codebase that was contributed to Hyperledger, a Linux Foundation project. This codebase was forked into the Hyperledger Indy project for ledger code, Hyperledger Ursa for cryptographic libraries, and the ledger-agnostic Hyperledger Aries codebase for agent, wallet, and credentialing code.
AnonCreds are now far more widely adopted, through organisations such as the Government of British Colombia, IDunion and the IATA Travel Pass.
How are AnonCreds different to other Credential types?
AnonCreds were designed to provide additional privacy benefits, compared with JSON and JSON-LD based Verifiable Credentials. There are a series of differences that can be summarised as follows:
Camenisch-Lysyanskaya (ZKP CL-Signatures): a Credential format which is not defined in the W3C Verifiable Credential Data Model. Rather it is a bespoke data expression format coupled with a particular digital signature algorithm.
Link Secrets: A mechanism to link ZKP-CL credentials to DIDs, by including a DID for the holder in the credential’s schema. Holders can prove that Credentials are not tampered with and that they are authentic, since holders are the only party that knows the Link Secrets made at the point of issuance.
Schemas: The schemas are defined in a document and they are written to an Indy ledger where they can’t be changed. To update a schema, a new version must be created and written to the ledger for future use. This schema is fetched from the ledger by verifiers when calculating the verification.
Credential definitions: Each issuer of a Verifiable Credential must post a credential definition that says to the world, "I intend to publish credentials from schema X, signed using keys Y[0]...Y[N], and with revocation strategy Z". This helps verifiers prove that the Credential has not been tampered with.
Predicate proofs: Through the use of link secrets and Indy schemas, it is possible to present an assertion, such as "date_of_birth is more than 18 years ago)", without revealing any additional information.
Privacy preserving revocation: Using cryptographic accumulators and 'tails files', revocation statuses can be queried without creating a chain of correlation through which a user's privacy can be compromised.
The ZKP-CL processing model requires that the credential’s schema is defined and posted to an Indy ledger. The credential issuer follows the pre-defined schema. They leverage the CL Signature suite to sign each statement in the credential. The credential is anchored to a link secret that is known only to the holder (stored in the holder’s software), and when the holder is issued a credential, it packages up a cryptographic commitment to the link secret within another long number that the issuer uses for the credential ID.
A metaphor for this is that of a digital watermark; the link secret is like a stamp that is used to create a watermark. The stamp used to create the watermark is NOT packaged up or put in the credential in any form; all that is in the credential is very-hard-to-fake evidence that the holder possesses the stamp and is capable of generating such watermarks. Unlike non-ZKP methods, zero-knowledge methods generally do not share a correlatable identifier (such as a persistent or public DID) and also do not reveal actual signatures. Instead, they only reveal a cryptographic proof of a valid signature. This means the holder of the credential cannot be correlated just by presenting a proof of the credential (this is the primary privacy problem with public/private key cryptography that ZKP-CL Signatures were invented to solve over a decade ago).
All other non-ZKP Signature formats require a resolvable DID—which is a correlatable globally unique identifier—and also produce the same signature on all equivalent presentations, which is a second fully correlatable globally unique identifier
Why are AnonCreds a contentious issue?
AnonCreds have been the subject of heavy debate within the decentralized identity community for the following reasons:
Interoperability: AnonCreds are intrinsically tied to Hyperledger Indy, and largely to Hyperledger Aries. Historically, they cannot be written to other Layer 1 Utilities, nor are they compliant with the W3C Verifiable Credential data model, given their core architectural differences. As such, this shoehorns adopters into a particular tech stack, which although open source, is largely reliant on the Indy/Aries community for updates, since there is no formal Standard.
AnonCreds v1 is being proposed as a Standard and is in the process of being taken to the Internet Engineering Task Force (IETF).
Scalability: The use of ZKP-CL signatures, whilst certainly containing benefits from a privacy perspective, are very large files which can lead to inefficiencies when used at scale in production environments.
Hyperledger Indy has performance and scalability issues when it comes to running more than 25 nodes in terms of its throughput. Its method of revocation also generates very large files, which is very slow to compute in a low-latency environment.
Nonetheless, many proponents of SSI contend that AnonCreds are still the most production-ready Credential types at this present instance. Certainly, AnonCreds are the only off-the-shelf Credential type that can provide privacy-preserving functionality such as predicate proofs, which is why, for example, Governments such as BC-Gov are large proponents of AnonCreds.
Link secrets
Supported
Indirectly supported
Supported via SDKs
CL-Schemas on-ledger
Supported
Supported
CL-Schemas as resource on ledger linked to a DID Document.
Credential definition
Supported
Supported
CL-CredDef as resource on ledger linked to a DID Document
Predicate proofs
Supported
Supported
Supported via SDKs
Privacy preserving revocation
Supported
Supported
Revocation Registry Definitions, indexes and Entries as resources on ledger linked to DID Documents
Last updated
