In this article, I will explain how Verifiable Credentials (VCs) can be used to satisfy certain Cameron’s laws of Identity to provide privacy-preserving security. I explained these laws in my “Self Sovereign Digital Identity: The Idea” article.
Let me begin with some concepts.
Verifiable Credential
Examples of credentials are driver’s licenses, passports, movie tickets, educational certificates, etc. In the physical world, a physical form of these credentials is presented to receive the required service. For example, the driver’s license may be presented to an authority to assert the ability of the subject to drive a vehicle, the passport may be presented to immigration authority to assert the ability to travel, the movie ticket may be presented to the person at the gate to asserts admission to the movie theatre and a seat. In all these cases, the physical document is verified to provide the requested service. In the case of a driver’s license and passport, the picture on the document is matched with the presenter of the document to verify the authenticity of the presenter and the document. In the case of a movie ticket, whoever is the holder of the ticket is given admission to the theatre and a seat — the admission is not for a specific person but rather for whoever has the ticket.
In the digital world, these credentials are presented in digital form. The VCs use cryptography to provide the ability to verify these digital credentials.
The credentials carry the proofs along with them, and these proofs are used to verify the authenticity of the credentials. The issuer specifies the credentials as attributes and values — also known as claims. The claims are digitally signed by the issuer which is the proof. There are credential metadata that provides information such as the issuer, validity of the credential, etc. All these three together make up the verifiable credential (VC). Figure 1 is a reproduction of the diagram from Verifiable Credentials Data Model v2.0 that depicts the basic components of VC.
The VC contains information about the issuer either as a URI or a DID (Decentralised Identity) that can be dereferenced to obtain more information about the issuer, and the most relevant information is the public key to verify the authenticity of the VC. It will be more privacy-preserving if the issuer information is specified as a DID, and the DID and DID documents are available in a VDR (Verifiable Data Registry). The verifier then uses the VDR to retrieve the required information rather than connecting with the issuer directly. This reduces the chances of the verifier colluding with the issuer and aggregating information about the subjects. This also keeps the relationship between the subject and verifier confidential from the issuer.
General Lifecycle of Credentials:
Credential is for a subject. It’s issued by an issuing authority known as an issuer.
In the physical world, the issuer provides a physical document that stays in the possession of the holder. Holders are authorized subjects to keep the credentials for themselves or another subject. The parent may keep the passport for their children. In this article, I will use the most common scenario to keep it simple and more focus on features of VCs that provide privacy-preserving security. The most common scenario is subject and holder are the same — interchangeable in this article.
In the digital world, the issuer provides a digital document that the holder stores on a device. It’s preferred that the credential is stored on a private device that’s in the possession of the holder rather than on a centralized repository. The former provides more security and privacy than the latter. The software on the device that provides this capability for storing credentials in a secure and privacy-preserving way is known as a digital wallet. For this article, the holder means a software agent or wallet that’s running on the device. Holder, Software Agent, and Wallet are interchangeable in this article.
Whenever the subject needs a service the holder presents the credential to the service provider or an authorized representative, they are known as verifiers. The holder digitally signs the verifiable credential and attaches the signature as proof. There is also presentation metadata. The metadata, verifiable credentials, and proof make up the verifiable presentation (VP). The verifiable presentation can contain multiple VCs issued by different issuers. Figure 2 is a reproduction of a diagram from Verifiable Credentials Data Model v2.0 that depicts the basic components of VP.
Figure 3 below shows the lifecycle of a digital credential
Trusts
In the digital world, one of the ways to establish trust is to exchange cryptographic keys and use those keys in subsequent interactions. Each party in the relationship creates a private public key pair. They store the private key and exchange the public key with the other party in a secure way. Whenever the parties want to exchange information confidentially, they use the public key of the other party to encrypt the data — the one with the private key can only decipher this encrypted data. Whenever one of the parties wants to give confidence to the other that they are the sender of the information, they sign it using their private key. The receiver verifies the signature using the sender’s public key. No one else can produce the same signature except the one in possession of the private key.
Whenever the parties want to keep their relationship private, they create public private key pair exclusively for that relationship and no one else knows about the public keys outside of that relationship. In decentralized identity, this is accomplished using peer DID and DID Documents. Whenever a party wants to maintain a public identity, they publish their DID and DID Document in a verifiable data registry (VDR) — the DID Document contains the public key.
Since the focus of this article is the most common scenarios, let us assume the following conditions have been established to create a trust framework without going into the details of how. I may cover the trust framework in detail in one of my future articles.
- The issuer has a public DID in a VDR that can be accessed by the verifier
- Issuer and Subject and their respective Wallets: Peer DID [I have described Peer and Public DIDs in my article “Decentralised Identifiers (DIDs)”]. A private relationship between issuer and subject is more privacy-preserving. This protects from aggregating information about the subject. The software agents manage and exchange digital assets on behalf of the issuer and subject. It’s very much possible that the software agents may change. It becomes easier to replace software agents by keeping them independent of their users. The software agents will have their own DID and DID Documents. For the same reason that the issuer and subject have a private relationship, their software will have a private relationship too.
- Subject and Verifier and their respective Wallets: Peer DID
- Issuer and Verifier: The verifier trusts the issuer. They rely on issuer DID and DID Documents stored in a VDR to verify the credentials issued by them.
Figure 4 shows the established trust among Issuer, Holder, and Verifier
Privacy-Preserving Verifiable Credential
Let us now examine how VC satisfies the following Cameron’s laws of Identity to provide privacy-preserving security.
- User Control and Consent
- Minimal Disclosure for Constrained Use
- Justifiable Parties
- Directed Identity
User Control and Consent, and Justifiable Parties:
In a typical digital interaction, the holder initiates the request for a service using the service provider App. The holder indicates that it will use its wallet to authenticate itself. The service provider displays a QR Code that the holder device scans the code — the service provider and holder devices establish a trusted relationship or connection between them.
The verifier App will request the holder to provide certain credentials to access the service. The wallet alerts the holder about the verifier and credentials being requested. The holder will have the option either to provide consent or decline the request. Only upon receiving the consent of the holder, the wallet will exchange the requested credentials with the verifier.
The holder has complete awareness of the verifier (Justifiable parties) and control of exchanging credentials. There may be a question — what if the verifier shares these credentials with others without the knowledge of the holder? There are various options to deal with such a situation such as not providing any identity information in the VP rather than providing a pseudonym — essentially it will come down to the content of the VP and signatures that will make it useless if it’s shared with anyone else. I will cover the details of dealing with such situations in one of my future articles.
Minimal Disclosure for Constrained Use, and Directed Identity:
These are important features of VC/VP to provide privacy-preserving security. To understand these features, I will use the use case that I described in my article “Self-Sovereign Digital Identity: How it Works?”.
Alice is the holder in this example who needs to obtain three different credentials from three different issuers. The typical workflow is
- Alice uses her Wallet to establish a secure connection with the issuer’s Wallet.
- Alice uses her Wallet to request credentials from each of the issuers.
- The issuer issues credentials after completing the required validations.
- Alice’s Wallet stores the credentials.
The table below shows the minimum required information each of the example credentials contains.
The metadata section provides information for the machine to be able to read and interpret the credentials. The claims section provides information about the subject. The proofs section provides information for the machine to be able to validate the authenticity and integrity of the credentials.
The algorithms used to provide proofs play an important role in satisfying minimal disclosure and directed identity. There are two ways to provide proofs:- a) the proof is embedded in the credential itself b) the proof that wraps the credential. One of the recommended approaches for embedded proof is Verifiable Credential Data Integrity. I am using this approach for my example. The examples in the table above show the minimum required information to be provided for Data Integrity Proofs.
One thing to observe in the above table is that the identity of Alice (DID) has not been provided. How is the credential associated with Alice then? One of the options is to provide her DID as the “id” value in the Credential Subject section. However, that will not be privacy-preserving since that will reveal her relationship with the issuer. This can be also used to aggregate information about Alice across different credentials. Hence we need a mechanism (attribute) that’s privacy-preserving and
- Associates the credential to Alice the Holder
- No one else knows about this attribute other than Alice the Holder — hence it is privacy-preserving
- It can be used to link all credentials issued to her — we need this ability to take information from multiple credentials and create one presentation for the verifier. We need to prove that these multiple credentials are issued to the same holder.
This attribute is known as “Link Secret” — it’s only known to Alice and hence is a secret, it links all credentials issued to her and hence is a link. How does it get associated with the credentials while maintaining its secrecy?
The idea of minimal disclosure is only to disclose the attributes of a credential that are truly required for that interaction. The “Link Secret” is considered an attribute of a credential that’s never revealed. The credential is created by the issuer. How will the issuer make the “Link Secret” attribute part of the credential without the knowledge of the secret itself? This problem is solved by using “Pederson Commitment” which is a cryptographic technique. Pedersen commitments are cryptographic algorithms that allow a holder to commit to a certain value without revealing it or being able to change it. What makes it possible for the holder to commit to the value of “Link Secret” without revealing or being able to change is the Camenisch-Lysyanskaya Signature scheme — also commonly referred to as the CL Signature Scheme.
In the CL Signature Scheme, the issuer generates a public key which will have variables equal to the number of attributes in the credential plus two — the additional two variables are required for the underlying math. In our example passport credential, the issuer needs to create a public key with twelve variables — nine for the nine claims, one for “Link Secret”, and an additional two for the math. The algorithm works like this
- The holder creates an initial commitment for the nine attributes using the nine corresponding variables from the public key and shares it with the issuer. The issuer can validate the commitment since they are aware of the nine claims.
- Then the Holder can create a commitment for the “Link Secret” value using the tenth corresponding public key variable. The Holder can add this commitment to the earlier commitment, and share the new overall commitment with the issuer. The math helps the issuer to validate the new commitment without having to know the value of the “Link Secret”.
- The issuer signs the new commitment assuring the authenticity and integrity of the credential.
With the addition of “Link Secret” to the credential, we can keep the DID relationship between the holder and the issuer private which is one of the requirements of the directed identity.
Like the Holder was able to keep the “Link Secret” secret by creating a commitment for it, they would be able to keep any of the claims secret by creating a commitment for it and not revealing the actual value. Then issuer validates the overall commitment and signs the credential that includes both the revealed and committed values. The Holder includes this credential in a verifiable presentation, signs it with their private key, and shares it with the verifier. The verifier verifies the VP signature to verify that it’s coming from the intended holder and that the integrity of the VP was not compromised. It verifies the credential signature to verify that it was issued by the trusted issuer and that the integrity of the credential was not compromised. The verifier can validate the credential even though some of the claims are hidden because of the underlying math used in the CL Signature scheme.
So far we have seen that by using the CL Signature scheme and commitments, we can satisfy minimum disclosure and directed identity requirements. One of the attributes will remain the same every time the credential is generated — that’s the signature. Suppose for different iterations of the credential different claims are being revealed. The signature, which remains the same, can be used to correlate all these revealed claims. One of the techniques used to address this problem is called Blinded Signatures. Using this algorithm, the Holder will be able to demonstrate to the verifier that they know the signature without revealing it. This itself will be sufficient for the verifier to verify the authenticity and integrity of the entire presentation while keeping the VP unique every time it’s generated, hence preventing any chance of correlation.
Now let us apply the above concepts to our use case where the DPS (Depart of Public Safety), the Verifier, wants to verify certain claims about Alice, the Holder. The DPS Wallet knows that the required claims can be obtained from the following credentials
- Social Security Card issued by Social Security Administrator whose DID is “did:gov:ssa”
- A passport issued by the Department of State whose DID is “did:gov:dos”
- A bank statement issued by BankA whose DID is “did:vdrA:bank”
The DPS Wallet retrieves the credential definition for Social Security Card and Passport from VDR “gov”, and Bank Statement from VDR “vdrA”. Once again, these are my made-up VDRs and DIDs for my example use case. Using these credential definitions, the DPS Wallet creates a presentation request something like this
- Get “Full Name” from Social Security Card
- Get “Full Name” from Passport
- Get “Full Name”, “Address Line1”, “Address Line2”, “State”, and “ZIP” from Bank Statement
- Check that the Holder, Alice, is older than 16 by using the rule: “DOB” from Passport + 16 > current date
- Check that the passport is valid by using the rule: “Date of Expiration” from passport > current date
- Check that the bank statement is not older than sixty days by using the rule: “Start Date” from Bank Statement > current date — 60 days
Note that DPS Wallet didn’t request values in DOB, Date of Expiration, or Start Date, but it requested results from the rules using those values — this is an example of minimal disclosure for constrained use.
The DPS Wallet sends this presentation request to Alice’s Wallet. Alice’s Wallet creates commitments (hides) all attributes except for “Full Name” on Social Security Card, Passport, and Bank Statement, and “Address Line1”, “Address Line2”, “State”, and “ZIP” on Bank Statement. It runs the rules from the presentation request. The results of the rules are verified using algorithms like Bullet Proofs or SNARKs. An aggregate proof is provided to prove that the same “Linked Secret” was used in all credentials that are part of the verifiable presentation. The Wallet uses the “Blinded Signature” scheme to prove that it knows the signatures without revealing them. The Wallet combines all these into a Verifiable Presentation and shares it with DPS, the verifier. DPS verifies the authenticity and integrity using the cryptographic signatures. It may then execute some business rules such as the same name across all credentials, the address fields matching with the address Alice provided on the original request, etc. After successful validation, it issues a RealID.
Conclusion:
The focus of this article was to show how Verifiable Credentials and Presentations support privacy-preserving security by meeting Cameron’s laws of Identity. We saw the use of Wallets by the Holder, Issuer, and Verifier to exchange requests, VCs, and VPs. The protocol that supports the secure exchange of these artifacts is known as DIDComm. I also touched on various concepts like CL Signatures, Pederson Commitment, Blinded Signatures, Bullet Proofs, SNARK, etc. to show their use in creating VCs and VPs to support Minimal Disclosure for Constrained Use and Directed Identity. I plan to cover the following topics in my future articles.
- DIDComm Protocol
- Implementation examples of concepts: CL Signatures, Pederson Commitment, Blinded Signatures, Bullet Proofs, SNARK
- Trust Framework
References:
[1] Verifiable Credentials Data Model v2.0
[2] Verifiable Credential Data Integrity
[5] Bullet Proofs
[6] Verifiable Credentials Flavors Explained by Kaliya Young
[7] Toward a Post-Quantum Zero-Knowledge Verifiable Credential System for Self-Sovereign Identity by Dutto, Simone, et.al
[8] Blockchain-based Verifiable Credential Sharing with Selective Disclosure by Mukta, Rahma, et.al
[9] Blockchain-Based Decentralized Verifiable Credentials: Leveraging Smart Contracts for Privacy-Preserving Authentication Mechanisms to Enhance Data Security in Scientific Data Access by Faruk, Md Jobair Hossain, et.al
[10] Information privacy?! by Camenisch, Jan
[11] Designated Attribute Proofs with the Camenisch–Lysyanskaya Signature by Papagiannopoulos, Kostas, et.al
[12] A signature Scheme with Efficient Protocols by Camenisch, Jan Lysyanskaya, Anna
[13] Decentralized Identity: Verifiable Credentials Deep Dive by Dingle, Pamela
[14] An Efficient System for Non-transferable Anonymous Credentials with Optional Anonymity Revocation by Camenisch, Jan Lysyanskaya, Anna
