Verifiable credentials

The tdx Volt supports the W3C Verifiable Credentials data model for issuing, presenting, and verifying credentials. Verifiable credentials are a way to express and exchange credentials in a way that is cryptographically secure and privacy-preserving.

What is a verifiable credential?

A verifiable credential is a tamper-evident credential that has cryptographic proof of its authenticity. It is a digital representation of a credential that can be used to prove claims about a subject. Verifiable credentials are issued by an issuer to a holder, and can be presented to a verifier to prove a claim.

A verifiable credential consists of three main parts:

  • Issuer: The entity that issues the credential.
  • Holder: The entity that holds the credential.
  • Subject: The entity that the credential is about.

Within the tdx Volt architecture, the Issuer is typically (although not limited to) a tdx Volt instance, the Holder is the tdx Volt instance or identity that holds the credential, and the Subject is the identity that the credential is about.

Usage within the tdx Volt

The tdx Volt uses verifiable credentials to represent claims about the identity of the holder. These claims can be used to prove the identity of the holder to other entities in the tdx Volt ecosystem, and to define rules and policies that govern the access permissions and behavior of the holder to the various resources and services within the tdx Volt.

The identities and claims within the verifiable credential leverage the Decentralized Identifiers (DIDs) and DID Registries to provide a secure and decentralized way to manage and verify the identity of the holder.

Example credential

Below is an example of a Verifiable Credential, issued by the DVLA, that contains a claim that the subject is over 18:

{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://tdxvolt.com/credentials/v1"
],
"credentialSubject": {
"id": "did:volt:0847915a-6bdf-478c-9d82-f96df58c7856",
"isOver18": true
},
"id": "http://192.168.1.195:62597/credential/c590d690-e665-428e-8cbc-d47a1b405f06",
"issuanceDate": "2024-05-30T16:12:43",
"issuer": {
"id": "did:volt:0847915a-6bdf-478c-9d82-f96df58c7856",
"name": "DVLA"
},
"proof": {
"created": "2024-05-30T15:12:43Z",
"jws": "eyJhbGciOiJFZERTQSIsImI2NCI6IGZhbHNlfQ..JeByn3x1XpcQ3OmookNy-V4v079xpOoqBE8Nkf0298vRmYGstMvqFyAR661k46SgBMsWDGXZJcxvCvW9bLU6BQ",
"proofPurpose": "assertionMethod",
"type": "Ed25519Signature2018",
"verificationMethod": "did:volt:0847915a-6bdf-478c-9d82-f96df58c7856#key-1"
},
"type": ["VerifiableCredential", "AgeVerification"]
}

Let’s break down the parts of the Verifiable Credential shown above:

  • @context

    The context in which the credential is issued. This is a list of URIs that define the terms used in the credential.

  • credentialSubject

    The subject of the credential, along with the claims made about the subject.

    In this case the subject is the DID did:volt:0847915a-6bdf-478c-9d82-f96df58c7856, and the credential contains a claim that the subject is over 18.

  • id

    The identifier of the credential. This is a URI that uniquely identifies the credential.

  • issuanceDate

    The date and time the credential was issued.

  • issuer

    The entity that issued the credential. This includes the ID of the issuer and the name of the issuer.

    In this case the issuer is the DID did:volt:0847915a-6bdf-478c-9d82-f96df58c7856, and the name of the issuer is DVLA.

  • proof

    The cryptographic proof of the authenticity of the credential.

  • type

    The type of the credential. This is a list of URIs that define the type of the credential.

Verifying a credential

In order for a verifier to trust the authenticity of the credential, a verifier must be able to verify the cryptographic proof provided in the proof section. This proof is generated using the private key of the issuer, and can be verified using the public key of the issuer.

Within the tdx Volt ecosystem, peers and entities make use of the DID Registry to resolve the DIDs of the subject and issuer, and to acquire their public keys in order to verify the proof and securely communicate.

Policy-based access control

Policy rules within the tdx Volt can be created to allow or deny access to a resource based on the presence of a verifiable credential that meets certain criteria.

For example, a policy rule could be created to allow access to a resource only if the holder of the credential is over 18, and the credential is issued by a trusted issuer such as the DVLA. This policy rule would be evaluated at runtime, and the access decision would be made based on the verifiable credential presented by the holder.

Non-DID subjects

Verifiable Credential subjects do not necessarily have to reference a DID. For example, the following Verifiable Credential is issued by coreid.com and contains an email address and public key as the subject:

{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://tdxvolt.com/credentials/v1"
],
"credentialSubject": {
"email": "alice@example.com",
"id": "alice@example.com",
"keyId": "BG4EZ1fgP7FoEyRycniTZKPneddSLxv8wkhvHv5nXcdo",
"publicKey": "-----BEGIN PUBLIC KEY-----\nMCowBQYDK2VwAyEAotWPJoA/nQ6gaIbsu77u5vQ/auhV717aEN1o/0ZJoio=\n-----END PUBLIC KEY-----\n"
},
"id": "https://coreid.com/credential/d662fbfa-986d-4505-9367-6e2c10b01809",
"issuanceDate": "2024-05-21T07:00:50",
"issuer": {
"id": "did:volt:bed919ab-6081-40e7-9677-88d1cd37a0c0",
"name": "coreid.com"
},
"proof": {
"created": "2024-05-21T06:00:50Z",
"jws": "eyJhbGciOiJFZERTQSIsImI2NCI6IGZhbHNlfQ..TWCHI2_LG8xYbx6-EYBEnBLf2D_6pdFowzH2fdxuaw2z3Im8gOTv3hL3l-Urz3_3rZt5hG_iMB7Hjzy-R-4ECA",
"proofPurpose": "assertionMethod",
"type": "Ed25519Signature2018",
"verificationMethod": "did:volt:bed919ab-6081-40e7-9677-88d1cd37a0c0#key-1"
},
"type": [
"VerifiableCredential",
"VoltIdentityCredential",
"VoltEmailCredential"
]
}

The credential was issued by https://coreid.com after verifying that the holder of the public key also has control over the email address alice@example.com.

This credential could be used to prove the identity of the holder in a variety of scenarios, such as authenticating to a service or a web application.

The flow would involve the browser or client creating a key pair using the web crypto API, and then presenting the public key and email address to the coreid.com identity provider service, along with a signature. The service would then send an email to the address containing a verification link, which the holder would then click and return to the service. The service would then issue the credential to the holder.