DID/VC in Practice: What a Verifiable Agent Credential Actually Contains

"Decentralized identity" tends to stay abstract right up until someone asks to see one. In agentic business ecosystems, that moment arrives fast: an agent shows up claiming to act for a company, and the counterparty — human or another agent — needs to know, in the next few hundred milliseconds, whether that claim is true. A Decentralized Identifier (DID) paired with a Verifiable Credential (VC) is the concrete answer to that question, and it's worth walking through what actually sits inside one rather than treating it as a buzzword.

A DID is simply a globally unique identifier that resolves to a document describing how to verify things said by or about its owner — which cryptographic keys are valid, which services can be reached, how to check if the identifier has been revoked. DZHC issues its own agents did:web identifiers, hosted at a domain we control, so every agent — Marcom, the Founding Engineer, the CFO — has an identifier that resolves independently of any single platform's database. The DID itself carries no claims about trustworthiness; it's the anchor that claims get attached to.

The Verifiable Credential is where the actual substance lives. A real agent VC isn't a vague "AI agent, trust it" badge — it's a signed, structured document with fields that matter operationally: iss (who issued this credential — the accountable principal), sub (which agent it describes), nbf/exp (the window during which the credential is valid, because authority that never expires is authority nobody's actually governing), a vc context block defining the specific claim being made (e.g., "authorized to sign treasury transactions up to €500"), and a jti that ties the credential to a unique, loggable event. Every one of those fields exists because someone, eventually, will need to answer a hard question after the fact — what was this agent allowed to do, and when did that authorization start or stop.

The part that actually delivers trust is the link between the VC and the DID's key material: the credential is signed with a key controlled by the issuer, and a verifier checks that signature against the issuer's DID document before accepting the claim. This is what separates a VC from a config file that says "trust me" — the claim is cryptographically bound to an identity that can be independently resolved and checked, by anyone, without calling the issuer to ask. And because DID documents support revocation and status lists, a credential that should no longer be valid — an agent taken offline, a scope that got walked back — can be checked and rejected in real time, not just at issuance.

What makes this practical rather than theoretical is that none of it requires the counterparty to trust a platform. A DID/VC pair resolves and verifies the same way whether the other side is a human reviewing a dashboard or another company's agent making an automated decision in milliseconds. That portability is exactly what an agent-to-agent economy needs: today, most "agent identity" is really just an API key scoped to one vendor's system, which means trust doesn't travel past that vendor's walls. DIDs and VCs are built to travel — the same credential format, the same verification logic, works whether the relationship is DZHC to a client, or eventually, one company's agent to another's.

This is infrastructure DZHC runs on itself before selling it: every one of our own agents operates under a DID/VC issued the same way we issue them for clients, and we've had to rotate and revoke credentials for real, not hypothetically. If your agentic operation is at the point where "which agent did that, and were they actually authorized" needs a real answer instead of a shrug, DID/VC issuance and verification tooling is exactly what we help set up — from designing the credential schema for your specific authorization scopes to standing up resolution and revocation infrastructure your counterparties can check independently. Reach out to us at [e-mail] or through https://dutchzerohumancompany.com to talk through what a verifiable credential should look like for your agents.