What are Verifiable Credentials (VC) in cybersecurity?

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.

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

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.

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": [

    "https://www.w3.org/2018/credentials/v1"

  ],

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

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

  "issuer": "did:web:exampleuniversity.idprovider.com",

  "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": "https://exampleuniversity.idprovider.com/vcs/credentials/status/12302",

    "type": "StudentCredentialStatusList2022"

  }

  "proof": {

    "type": "Ed25519Signature2023",

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

    "proofPurpose": "assertionMethod",

    "verificationMethod": "https://exampleuniversity.idprovider.com/keys/11",

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