Decentralized Identifiers and Verifiable Credentials: The Building Blocks for Self-Controlled Identities
Judith Kahrer
· 4 min readKey Takeaways
Decentralized identifiers (DIDs) are resolvable URIs (
did:method:id) that resolve to a DID document containing public key material, without revealing who the subject actually is.Verifiable credentials (VCs) add meaning to a DID — assertions about a subject's attributes or capabilities, similar in concept to an X509 certificate but far more flexible and expressive.
Unlike DID documents, VCs are private and held by the individual (e.g., in a wallet), giving users control over when and with whom to share them — the basis of self-sovereign identity.
Verifiable presentations let holders share credentials selectively, including derived claims (e.g., "over 18") without revealing the underlying data (like exact birth date), enabling privacy-preserving proof via zero-knowledge techniques.
Presentations include proof that the holder is the legitimate owner of the credential, not just that the credential itself is valid.
Together, DIDs and VCs form key building blocks of Web5 and self-controlled identity, pointing toward a future of more private, user-controlled authentication and authorization.
On this page
At Curity, we aim to stay up-to-date with technology. However, we do not jump on every emerging trend — instead, we carefully weigh which new features to implement. Decentralized identifiers (DIDs) and verifiable credentials (VCs) are now official standards. Therefore, this is an excellent time to take a closer look at both technologies since, combined, they provide a promising new method for identity management.
What Are Decentralized Identifiers?
Decentralized identifiers are a type of URI. They are identified via the did scheme, followed by a method name and a method-specific identifier. What is more, they are resolvable
did:method:method-specific-id
The details of the resolution process are specific for each DID method, but every DID resolves in one way or another to a DID document. The DID document contains details associated with the DID. For example, it commonly references the DID controller and public key materials for various use cases (authentication being one of them).Â
{"id": "did:example:user123","controller": "did:example:user123","verificationMethod": [{"id": "did:example:user123#key-1""controller": "did:example:user123""type": "JsonWebKey2020""publicKeyJwt": {…}}],"authentication": ["did:example:user123#key-1"]}
Normally, a DID alone does not hint at the subject it refers to. Also, the DID document that a DID resolves to should be designed to maintain the privacy of the DID subject and reveal as little information as possible. This is where verifiable credentials play an essential role.
What Are Verifiable Credentials?
A verifiable credential is a document with assertions about the subject, its capabilities, or achievements. Conceptually, a verifiable credential is comparable to an X509 certificate, where a CA (the issuer) asserts a public key (the DID) with specific attributes (subject name and subject alternative names). However, the verifiable credential is much more expressive and flexible than a certificate limited to X500 names. The subject of a verifiable credential is commonly identified via a DID.Â
Compared to DID documents and publicly available certificates, verifiable credentials are personal and securely stored by the credential holder (such as in a wallet). By keeping verifiable credentials private, the holder can control the timing and context in which context to share a credential, and it can do so without involving the authority. These characteristics enable self-controlled identities, also called self-sovereign identities.
The following example is non-formative and shows a verifiable credential, a fictitious ID card credential issued by an authority with the id "did:example:issuer" for the subject "did:example:user123." The credential contains the name and date of birth of the subject. It is valid for five years from 2022-01-01 until 2026-12-31.
{"@context": ["https://www.w3.org/2018/credentials/v1","https://example.com/contexts/customCredential.jsonld","https://w3id.org/security/suites/ed25519-2020/v1"],"id": "urn:uuid:6f0d2081-9e05-4c8a-bb75-5730591ffe52","type": ["IDCardCredential"],"issuer": "did:example:issuer","issuanceDate": "2022-01-01T00:00:00Z","validUntil": "2026-12-31T23:59:59Z""credentialSubject": {"id": "did:example:user123","familyName": "User","firstName": "Test","dateOfBirth": "1970-01-01"}"proof": {"type": "Ed25519Signature2020","created": "2022-11-28T08:39:17Z","verificationMethod": "did:example:issuer#key-1","proofPurpose": "assertionMethod","proofValue": "..."}}
As shown in the example, a verifiable credential may contain metadata that allows a verifier to determine the validity of the credential beyond signature validation. For example, it may include an expiration date or information about the revocation mechanism.
Upon request, the credential holder will not show the verifiable credential itself but will render a presentation of it. Verifiable presentations contain one or more verifiable credentials or derivations along with a proof of the holder. This way, the holder can present several credentials in a single step or utilize schemas for zero-knowledge proofs.
In this case, the verifiable presentation could contain derived data instead of the original claims. For example, the presentation might include the assertion that the subject is over 18 years old without revealing the birth date from the credential.
In addition, the verifiable presentation includes proof of the holder that allows a verifier to confirm that the presented credentials are not only valid but also issued to the holder.Â
{"@context": ["https://www.w3.org/2018/credentials/v1","https://www.w3.org/2018/credentials/examples/v1"],"id": "urn:uuid:b2b3af01-2d02-46a6-b8bb-a32b87d63e6d","type": ["VerifiablePresentation"],"verifiableCredential": [{"credentialSubject": {"id": "did:example:user123",…}"proof": {"verificationMethod": "did:example:issuer#key-1",…}}],"proof": [{"verificationMethod": "did:example:user123#key-1",…}]}
Since a different data format is used for presentation, credential holders can control whom to share what data with. And they can prove that they are the legitimate holders of a credential. This is an important argument for self-controlled identities.
Evolution of Digital Identities
Decentralized identifiers and verifiable credentials are promising features for privacy-preserving authentication, authorization, and identity management implementations — all areas we value highly at Curity.
Both standards are pillars of Web5 and have the potential to revolutionize how we handle digital identities, as they enable the implementation of a decentralized and self-controlled identity management system that values the privacy of individuals. Particularly, these standards are paving the way for zero-knowledge proofs.
Note: The 8.2 release of the Curity Identity Server introduces the ability to issue verifiable credentials using the OpenID for Verifiable Credential Issuance draft specification. This feature will allow customers to experiment with credentials and plan how to use this new identity paradigm in products and services. Check out the product documentation to get started.
Related resources
Frequently Asked Questions
Who controls or governs a DID method — is there a central authority?
No single central authority governs all DID methods — each method (like did:web, did:key, or blockchain-based methods) is defined by its own specification, often maintained by different communities or organizations, which is part of what makes DIDs "decentralized" rather than reliant on one governing body.
Can a DID be revoked or deactivated if compromised?
This depends on the specific DID method used — some methods support deactivation or key rotation mechanisms, while others (like those anchored to immutable blockchains) may have more limited revocation options, making method choice an important design consideration.
Do verifiable credentials expire automatically, or do they need to be manually revoked?
Both mechanisms typically exist — credentials often include an expiration date as metadata, but issuers may also need a separate revocation mechanism (like a status list) to invalidate a credential before its natural expiration, for example if it was issued in error or the holder's status changed.
How does a verifier know a DID document hasn't been tampered with?
DID documents are typically secured through the cryptographic properties of their specific DID method — for blockchain-anchored methods, this often means the document's integrity is protected by the underlying ledger's consensus mechanism, while other methods use different cryptographic guarantees.