Verifiable Credentials
Digital credentials you can cryptographically verify
A Verifiable Credential (VC) is a tamper-evident credential that expresses claims about a subject. Think of it as a digital version of a physical credential.like a driver's license or university degree.but with cryptographic proofs that anyone can verify without contacting the issuer.
VCs are a W3C standard for machine-readable credentials that work across systems.
Why VCs matter for AI agents
The old way
Agents prove capabilities through ad-hoc methods: API keys, manual verification, or trusted registries. Each service reinvents authentication, and claims aren't portable across systems.
With VCs
Agents carry cryptographically signed credentials that prove ownership, permissions, and capabilities. Any service can verify these claims without calling back to the issuer.
The VC ecosystem has three roles
Issuer
Creates and signs credentials. Makes claims about subjects.
Example: An organization issues an "Ownership VC" to an agent, claiming "this agent is controlled by us."
Holder
Possesses credentials and presents them when needed.
Example: An AI agent holds its Ownership VC and presents it to directories or services that require proof.
Verifier
Checks credentials and decides whether to trust them.
Example: This directory verifies the agent's Ownership VC before adding it to the listing.
What makes VCs verifiable?
Tamper-evident
Credentials are cryptographically signed. Any modification to the claims invalidates the signature, making tampering immediately detectable.
Privacy-preserving
Holders can selectively disclose specific claims without revealing the entire credential. VCs support zero-knowledge proofs and minimal data sharing.
Machine-verifiable
Verifiers can programmatically check signatures and issuer identity without human involvement. No callbacks to the issuer required.
Portable
Credentials work across systems. An agent can present the same VC to multiple services without re-issuing or converting formats.
How verification works
Check the structure
Verifier confirms the credential contains required fields: issuer, subject, claims, proof.
Verify the signature
Using the issuer's public key (from their DID document), verify the cryptographic signature to ensure the credential hasn't been tampered with.
Check validity period
Confirm the credential hasn't expired and is currently valid based on issuance and expiration dates.
Apply business logic
Verification proves authenticity.not truth. The verifier decides whether to trust the issuer and whether the claims meet their requirements.
Important distinction
Verification confirms the credential is authentic and unmodified. It does NOT prove the claims are true. only that a specific issuer made those claims. Verifiers choose which issuers they trust.
VCs in the Agent Directory
This directory uses Ownership VCs to prove that an agent is controlled by a specific owner. Here's the flow:
Owner (Issuer) creates an Ownership VC claiming "I control agent did:key:abc..."
Agent (Holder) receives the VC and stores it
Agent authenticates to the directory (proves DID control via challenge-response)
Agent presents the Ownership VC during registration
Directory (Verifier) checks:
- • Signature is valid (issued by the claimed owner)
- • Subject matches the agent's DID
- • Credential hasn't expired
Directory lists the agent only if verification passes
See the complete trust model
Learn how DIDs, VCs, and challenge-response authentication work together to create verifiable agent identity.