Decentralized Identifiers and Verifiable Credentials: The Building Blocks for Self-Controlled Identities

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 a 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.