For the best web experience, please use IE11+, Chrome, Firefox, or Safari

What are Verifiable Credentials (VC) in cybersecurity?

The definition of Verifiable Credentials (VC)

Verifiable Credentials (VCs) are digital representations of everyday attributes of your identity. A VC is uniquely bound to an individual, who can use it to prove aspects of their identity, just like they would with a physical document.

VCs are standardized by several bodies, including the W3C. They can cater to all typical-use cases of physical credentials, including government-issued IDs, employment letters and academic degrees. They are tamper-evident by design, which means that any attempt to use a VC to make unauthorized access can be easily detected.

Verifiable credentials are a promising new technology that has the potential to revolutionize the way we share personal information. They are secure, trustworthy, standardized, interoperable and easy to use, making them a valuable tool for individuals and organizations alike.

How Verifiable Credentials (VCs) work

The VC lifecycle can be divided into three steps: Issuance, Presentation and Verification. Perhaps the main point of VCs is that they allow the holder to selectively present the appropriate VC for a given task, ensuring the user’s privacy is maintained at the right level and, as far as the presentation is concerned, is under their control.
How Verifiable Credentials (VCs) work
VC Lifecycle
The following diagram is helpful as you read the explanation of the steps below:
Summary of the Steps in VC Usage

Step #1 Issuance of credentials

A user (aka the subject or holder) initiates the process by requesting a credential from an issuer. The issuer generates a digital credential that includes information related to (but not limited to):

  • The subject (designation, title and identifier)
  • The used cryptographic algorithm and verification technique
  • The nature and use case of the credential
  • The status and expiry of the credential

Then, the issuer signs the VC with its private key and sends it to the user. The user receives and stores the key in a digital wallet.

Step #2 Credential presentation

The subject visits a third-party application (or service) that supports VCs. The third-party application (aka verifier) will authenticate the subject using a verifiable presentation (VP). A verifiable presentation is a tamper-evident encoding of the credential generated using the subject’s private key.

However, the entire process of signing is abstracted away from the subject. All they have to do is use their digital wallet to present the right VC to the verifier. The wallet application will handle the VP generation.

Step #3 Credential verification

The verifier retrieves the public keys of the subject and the issuer from a trusted source, known as the Verifiable Data Registry. It then uses cryptographic techniques to verify that:

  • The VC was indeed signed by the subject.
  • The VC was indeed issued by the correct issuer.
  • The VC is still valid for use (it has not expired).

The main components of Verifiable Credentials: Overview

Here is what a VC looks like in practice:
Typical VC shown in a wallet

We can see that this VC contained in a mobile phone wallet is showing various attributes of Ben, including his name and organizational email address. In addition, green is good: it signals that this VC is still valid according to the credential issuer.

Key Components of Verifiable Credentials: Digging Deeper

A VC represents user attributes in the JSON or JSON-LD formats. These formats essentially organize all the necessary information in the form of key-value pairs. Let’s look at a sample VC and discuss its main components:


  "@context": [



  "type": ["VerifiableCredential", "UniversityCardCredential"],

  "id": "urn:credential:46503118-3419",

  "issuer": "",

  "issuanceDate": "2023-06-20T13:58:53Z",

  "credentialSubject": {

    "id": "urn:university:engineering:23212",

    "name": "Anna Jones",

    "title": "Computer engineering",

    "description": "Anna is a student of the computer engineering course",

    "dateOfIssue": "2022-06-15",

    "expiryDate": "2026-06-15",

    "directedBy": "Example University",

    "location": "United States",


  "credentialStatus": {

    "id": "",

    "type": "StudentCredentialStatusList2022"


  "proof": {

    "type": "Ed25519Signature2023",

    "created": "2023-06-20T13:58:53Z",

    "proofPurpose": "assertionMethod",

    "verificationMethod": "",

    "proofValue": "a3n09XOvrkDvBXGoSADG2Az2Jp3p4AnoAZ2eHJKP23ZsqkyeudcatfevHTJNKmOHple4hacrU44ema2JoMbspvR"




The type of a VC is a JSON array that can contain multiple values. This allows for more granular control over the use case of the credential. For example, the value of type in our example VC is:

["VerifiableCredential", "UniversityCardCredential", "Student"]. This indicates that the credential is a university card that can be used by the student to enter the campus.


The issuer field must either contain a URI or an object containing an ID field. It represents the entity that creates and issues the credential. The issuer is responsible for ensuring that the credential is valid and cryptographically secure. The issuer for our example VC is "", which is a URI, specifically a DID (decentralized identifier).

Credential subject

The credential subject section includes information related to the holder(s) of the credential. In the case of multiple holders (E.g., a marriage license), it will likely contain more than one object. The credential subject section of the example VC indicates that the holder is a student named Anna Jones. Anna is a student of computer engineering at Example University in the United States. The credential also includes a date of issue and expiry.


The proof section may contain one or more tamper-evident cryptographic proofs that are used to verify the credential. The type field of the proof section depicts how the proof was generated, including the algorithm used. In our example VC, the value of type is "Ed25519Signature2023", which indicates that the VC relies on Ed25519-based digital signatures for verification.

OpenID Connect (OIDC) for Integration with existing IAM Services

OpenID Connect for Verifiable Credentials is a group of three specifications that define APIs for issuance, presentation and authentication of VCs. The issuance specification details all the steps that an issuer must take to securely generate a verifiable credential (VC), as well as those that a wallet application must take to securely access, retrieve and store the VC.

Integrating VCs with your existing IAM services via OIDC is a great way to get started with the deployment of VCs in your environment.

Here are some key takeaways from the specification:

  • The wallet application will use OAuth 2.0 authorization to access the issuance APIs.
  • The issuer must expose a token endpoint which subjects can use to request an access token.
  • The issuer must also expose a credential endpoint which issues a credential after verifying the access token presented by the subject. Communication with the endpoint must happen on an encrypted channel.
  • If multiple credentials are needed, the wallet may send a separate request for each credential, or a single batch request for all credentials. However, it must be noted that batch endpoints are optional per the specification, and not all issuers support them.


Verifiable credentials are a cryptographically secure, tamper-evident and machine-verifiable mode of digital verification. They hold the potential to bring about a paradigm shift in digital identity management, fostering a safer and more trustworthy digital ecosystem for everyone.