By Dr Paul Ashley, co-CEO and CTO, Anonyome Labs
This article was originally published in Michael Bazzell’s Unredacted magazine, January 2023. To learn more, view the latest issue.
I’ve been exploring decentralized identity in Unredacted (Issue 2 and Issue 4) so we can better understand this new technology that’s giving users greater control over their personal data and identity. This time, I go straight to decentralized identity’s killer feature: verifiable credentials (VCs). What makes VCs the standout? Simple: VCs are what will make decentralized identity ubiquitous on the internet in the next decade.
What are VCs?
VCs are cryptographically protected and privacy-respecting digital documents that convey information about a user. [1] Trusted identity providers (called issuers) create these digital documents. Any physical car or document that a person can carry (e.g. in a wallet) could be replaced with a digital VC—think: digital driver license, digital passport, digital health card, digital travel visa, or even something as mundane as a digital gym membership card or a digital library card.
Every credential has an identifier and some metadata but, most importantly, it also has the claims or attributes the issuer is asserting about the holder (user). The issuer digitally signs the credential so verifiers receiving proofs based on the credential can confirm any credential information that is asserted plus the credential’s authenticity.
Decentralized identity-based VCs are designed to be privacy preserving. The holder (user) maintains absolute control over which elements of their personal information (contained within the credential) they choose to provide. This is very different from physical credentials (e.g. a driver license), where the verifier can always see everything contained within the credential the user presents. Another key benefit of VCs is that the verifier can independently verify them without any communication with the credential’s issuer, which ensures issuers cannot track when the holder uses their credentials.
How do VCs work?
You’ll see here the parties involved in VCs, plus the data flow between those parties:
The VC process starts on the left with the issuer. An issuer is an entity (e.g. government or business) that wants to issue VCs. To do that, the issuer must first register some specification information on the blockchain (termed the verifiable data registry). Using the Hyperledger Indy network as an example, the issuer writes their decentralized identifier (DID), the credential schema [2] (which defines the elements of the VC), and the credential definition (linking the issuer DID and credential schema) to the blockchain.
Once the issuer has registered information on the blockchain, they can create and issue VCs. It begins with the holder (a user) and issuer forming a DIDComm connection (e.g. Aries RFC 0160: Connection Protocol). Over that connection the issuer sends the VC (e.g. Aries RFC 0036: Issue Credential Protocol 1.0), which will be stored in the holder’s wallet (e.g. Aries RFC 0050: Wallets).
At this point, the holder can present their information from the VC to service providers who require it. To do this, the holder establishes a DIDComm connection to the verifier and transfers the VC proof presentation (e.g. Aries RFC 0037: Present Proof Protocol 1.0). The verifier must connect to the blockchain to read the issuer DID (which includes their public key), credential definition, and credential schema, so they can verify the presentation proof.
The key privacy-preserving capabilities of this process include:
- The verifier can determine that the credential has not been altered and is authentic.
- Verification happens without the verifier communicating with the issuer.
- The holder (user) can select which information from a credential they present to the verifier.
What are AnonCreds?
The AnonCreds or anonymous credentials specification is based on the open source verifiable credential implementation stemming from the Hyperledger Indy project. Extensive use of AnonCreds worldwide has made it a de facto standard for VCs.
Some important concepts around AnonCreds make it a very attractive solution for VCs, such as:
- Anonymity—Using unrevealed identifiers for holder-to-VC binding prevents correlation based on those identifiers. [3] This prevents colluding organizations from correlating user-specific identity information.
- Revocation—AnonCreds provides a revocation scheme that proves a presentation is based on credentials that the issuer has not revoked.
- Reduced PII exposure—An implementation of zero knowledge proofs (predicate proofs) helps eliminate the need to share specific PII (e.g. holders can prove they are over age 21 without disclosing their specific birth date).
The current AnonCreds specification matches the existing Hyperledger Indy SDK (“libindy”) and Indy Credential Exchange (“credx”) implementations, [4] but recently there was a proposal to make AnonCreds a standalone Hyperledger project, which will help it to grow with future enhanced capabilities.
One key factor to note is the use of the term proof presentation. This term describes the holder presenting one of three items to the verifier:
- all of the data in the credential
- part of the data in the credential (a partial disclosure)
- a zero knowledge proof for some data in their credential.
Using ZKPs is a critical aspect of AnonCreds—that is, it is not the actual VC that is presented to the verifier, but rather a cryptographically derived proof that allows the data in the credential to be presented securely. As such, the user can keep more of their PII private while still answering questions such as, “Are you over 21?”, “Do you live in this country?”, or “Do you have a college degree?”
What are W3C VCs?
In addition to AnonCreds, the World Wide Web Consortium (W3C) has created the Verifiable Credentials Data Model v1.1. [5] This W3C recommendation is published and being used in government and commercial applications.
W3C VCs are also open source and provide the same basic functionality as AnonCreds—that is, this standard provides holder, issuer, subject, verifier, and verifiable data registry roles and supporting functionality. Some of the main target use cases [6] are:
- education—transcripts, test taking, transferring schools, online classes
- retail—address verification, adult beverages, fraud detection
- finance—Know Your Customer, money transfer, closing an account, trying a new service, create a bank account from home
- healthcare—prescriptions, pharmacy, insurance, traveling illnesses, proving legal disability status
- professional credentials—find a doctor, quality training, job applications
- legal identity—driver license, immigration, air travel, refugee status
- intelligent devices—manufacturing, delivery, autonomous.
The W3C VCs standard also supports ZKPs, [7] but not all W3C VCs support being asserted as ZKP responses. The choice of whether to enable this capability is left up to the credential issuer. In order for a holder to assert a ZKP response, they must use a credential that has been created to allow for this purpose. Using W3C VCs for ZKPs requires the issuer to do two things:
- Add a proof property to the VC.
- Where they use a credential definition, also define it in the credential schema property.
So long as those two requirements are met, W3C VCs can be asserted in a zero knowledge fashion, as we covered.
AnonCreds and W3C VCs have a lot of similarities and some key distinctions, but that’s a topic for another time. The main point is that both standards describe great implementations of VCs and mainstream platforms will be using both for the foreseeable future.
[1] This is the most common case. It is also possible for other scenarios such as the user issuing a credential related to an organization.
[2] In the future it may be uncommon for issuers to write their own schemas. Instead a standards body could write the schemas and issuers would only write credential definitions.
[3] This paper by Kaliya Young challenges the notion of “link secrets” as a viable alternative to including the credential subject information. This opinion is in turn refuted by this paper by Daniel Hardman.
[4] It is also argued in the paper by Kaliya Young that not having a mature specification is a weakness not allowing sufficient analysis by the industry and it also lacks a standard for interoperability testing.
[5] Verifiable Credentials Data Model v1.1, World Wide Web Consortium, 3 March 2022, https://www.w3.org/TR/vc-data-model/
[6] Verifiable Credentials Use Cases, World Wide Web Consortium, 24 September 2019, https://www.w3.org/TR/vc-use-cases/
[7] Verifiable Credentials Data Model v1.1, World Wide Web Consortium, 3 March 2022, https://www.w3.org/TR/vc-datamodel/#zero-knowledge-proofs
