Decentralized Identity (DID)
Issuing Tamper-Proof Claims with the Verifiable Credentials Data Model
Explore the technical lifecycle of digital claims, focusing on the cryptographic binding between issuers and holders using the W3C VC 2.0 standard.
In this article
The Evolution of Digital Identity and the Trust Triangle
In our current digital landscape, identity is primarily managed through centralized gatekeepers. When you use a social media account to log into a third-party service, you are relying on a federated identity model where the central provider acts as the ultimate source of truth. This creates a dependency where your digital existence can be revoked or monitored by a single entity without your direct consent.
Decentralized Identity shifts this paradigm by introducing the concept of self-sovereign identity where users own and control their identifiers. This model is built upon the W3C Verifiable Credentials standard which allows for a secure exchange of claims between different parties. Instead of a central database, trust is established through cryptographic signatures and decentralized ledgers or peer-to-peer networks.
The fundamental architectural pattern in this ecosystem is known as the Trust Triangle. This triangle consists of three distinct roles: the Issuer who signs the credential, the Holder who stores and presents it, and the Verifier who checks the validity of the data. By separating these roles, we ensure that the holder remains the central point of data control during any exchange of information.
A critical advantage of this model is the removal of the phone-home requirement found in traditional protocols. In an OAuth flow, the service provider must communicate directly with the identity provider to verify a token. In the decentralized world, a verifier can authenticate a claim using public information found on a registry without ever contacting the original issuer.
The true power of decentralized identity lies not in the storage of data, but in the cryptographic decoupling of the issuer from the verification process, enabling privacy-preserving interactions at scale.
Understanding the Role of the Holder
The holder acts as the custodian of their own digital claims, typically using a specialized software application known as a digital wallet. This wallet does not just store data; it manages the cryptographic keys required to prove ownership of the claims. When a holder receives a credential, they store it locally or in an encrypted cloud backup that only they can access.
This custodial role is vital for privacy because it allows the holder to decide exactly what information is shared and with whom. For example, a holder could share a proof of being over eighteen years old without revealing their exact date of birth or their full legal name. This capability is made possible through advanced cryptographic techniques that the holder controls through their wallet interface.
Deconstructing the W3C Verifiable Credential 2.0 Standard
The W3C Verifiable Credentials Data Model 2.0 provides a standard syntax for expressing digital claims in a machine-readable way. At its core, a credential is a set of one or more claims made by an issuer about a subject. These claims are bundled into a JSON or JSON-LD document that includes metadata such as the issuer identity, expiration dates, and the type of credential being issued.
The standard is designed to be extensible, allowing developers to define custom schemas for any use case imaginable. Whether you are issuing a university diploma, a driver license, or an employee access badge, the underlying structure remains consistent. This consistency is what allows different wallets and verification tools to interoperate seamlessly across different industries and borders.
One of the most important components of a credential is the credential subject property. This object contains the actual data being asserted, such as a name or a professional certification. To ensure this data is linked to the right person, the credential subject usually includes the decentralized identifier of the holder, creating a cryptographic link between the data and the person presenting it.
1{
2 "@context": [
3 "https://www.w3.org/ns/credentials/v2",
4 "https://www.w3.org/ns/credentials/examples/v2"
5 ],
6 "id": "urn:uuid:58172aac-d8ba-11ed-afa1-0242ac120002",
7 "type": ["VerifiableCredential", "UniversityDegreeCredential"],
8 "issuer": "did:example:university123",
9 "validFrom": "2023-01-01T00:00:00Z",
10 "credentialSubject": {
11 "id": "did:example:student456",
12 "degree": {
13 "type": "BachelorDegree",
14 "name": "Bachelor of Science in Computer Science"
15 }
16 },
17 "proof": {
18 "type": "DataIntegrityProof",
19 "cryptosuite": "eddsa-rdfc-2022",
20 "created": "2023-01-02T10:00:00Z",
21 "verificationMethod": "did:example:university123#key-1",
22 "proofPurpose": "assertionMethod",
23 "proofValue": "z58D6asdf...example_signature"
24 }
25}The Proof Object and Data Integrity
The proof object is what transforms a simple JSON document into a verifiable credential. It contains a digital signature generated by the issuer using their private key. This signature covers the entire content of the credential, meaning that if even a single character in the document is modified, the signature will become invalid and the verification will fail.
In version 2.0 of the standard, there is an increased focus on data integrity proofs which offer a more modular approach to signing data. Developers can choose from various cryptosuites depending on their security requirements and the environment where the credential will be used. This flexibility allows for the use of modern algorithms like Ed25519 or NIST-compliant curves while maintaining a standard structure.
Cryptographic Binding and Holder Proofs
A common security concern in decentralized identity is the risk of credential replay or theft. If an attacker manages to copy a verifiable credential, they should not be able to use it as their own. This is prevented through a mechanism called holder binding, where the credential is tied to the unique decentralized identifier of the legitimate owner.
When a holder presents a credential to a verifier, they do not simply send the credential file. Instead, they generate a verifiable presentation which includes the original credential and a new signature created with the holder's private key. This second signature proves that the person presenting the credential is the same person who was originally identified as the subject of the claims.
This two-layer signing process is the backbone of trust in the ecosystem. The first signature from the issuer guarantees the accuracy of the data, while the second signature from the holder proves rightful possession. This ensures that even if a credential document is leaked, it cannot be used by anyone else without access to the holder's private keys stored in their secure wallet.
1async function createPresentation(holderDid, credential, privateKey) {
2 // Wrap the credential in a presentation structure
3 const presentation = {
4 "@context": ["https://www.w3.org/ns/credentials/v2"],
5 "type": ["VerifiablePresentation"],
6 "verifiableCredential": [credential],
7 "holder": holderDid
8 };
9
10 // Sign the presentation to prove possession
11 const signedVP = await signPresentation({
12 presentation,
13 privateKey,
14 challenge: "random-nonce-from-verifier",
15 domain: "example.com"
16 });
17
18 return signedVP;
19}Selective Disclosure and Privacy
Modern decentralized identity systems often implement selective disclosure to enhance user privacy. This allows a holder to share only the specific fields of a credential that are required for a particular transaction. For instance, if a service only needs to know your nationality, you can provide a proof that includes that field while keeping your home address and social security number hidden.
Achieving this requires specific cryptographic algorithms such as BBS+ signatures or Zero-Knowledge Proofs. Unlike standard signatures where changing any data breaks the proof, these advanced methods allow for the creation of derived proofs that remain valid even when parts of the original document are omitted. This represents a significant leap forward in giving users control over their personal information surface area.
Verification Logic and the Resolver Stack
The verification process is the final step in the lifecycle of a digital claim. When a verifier receives a presentation, they must perform several checks to ensure the data is trustworthy. This includes verifying the signatures of both the issuer and the holder, checking the expiration dates, and ensuring that the credential has not been revoked by the issuer.
To verify an issuer's signature, the verifier must resolve the issuer's decentralized identifier to find their public key. This is handled by a DID resolver, a component that knows how to look up identity documents across different types of registries, such as blockchains or web servers. The resolver abstracts the complexity of different network protocols and provides a standardized document for the verifier to use.
Once the public key is retrieved, the verifier performs a cryptographic check against the proof object in the credential. If the signature is valid, the verifier can be certain that the data has not been tampered with since it was issued. The verifier then checks the status of the credential against a revocation list or a status registry to ensure it is still considered active by the issuer.
- Check the cryptographic integrity of the issuer signature using the public key from the resolved DID document.
- Validate the holder binding by checking the presentation signature against the holder's public key.
- Verify the temporal validity by comparing the current time against the validFrom and validUntil timestamps.
- Consult the status registry defined in the credential to ensure the claim has not been revoked.
- Verify the challenge and domain parameters to protect against replay attacks during the presentation flow.
Handling Revocation Efficiently
Revocation is one of the more complex aspects of decentralized identity because there is no central server to query. The W3C standard supports various methods for checking status, such as Status Lists where a single bit in a compressed list represents the status of a specific credential. This allows verifiers to check the status of thousands of credentials in a single highly efficient network request.
Implementing these lists requires the issuer to update a public registry whenever a credential is cancelled. Verifiers must be designed to handle cases where the registry might be temporarily unavailable. Developers should consider implementing caching strategies for status data while respecting the security requirements of the specific use case to avoid using stale information for high-value transactions.