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:
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 isDVLA
. -
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:
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.