The gap between "we should look at verifiable credentials" and a working demo is usually not cryptography. It's the setup tax: key ceremonies, DID hosting, wallet compatibility, and picking a stack before you understand the problem. Here's the weekend version, in the order we'd actually do it.
Saturday morning: define one schema
Resist the urge to model your whole domain. Pick a single credential with three to five claims — an employee badge, a course completion, a membership. Register it once, and let the API host the issuer DID for you under did:web. That alone deletes the two tasks that most often stall pilots: key generation and DID document hosting.
POST /v1/schemas
{
"type": "EmployeeCredential",
"claims": {
"role": { "type": "string" },
"clearance": { "type": "string" }
}
}Saturday afternoon: issue your first credential
With a schema registered, issuance is one authenticated POST — claims plus a holder DID in, signed credential out. For a POC you don't need a production wallet yet: generate a did:key locally and hold the credential in a file. The point of the afternoon is seeing a real, verifiable object come back.
Sunday: verify with someone else's code
This is the step that turns a demo into an argument. Verify your credential with a stack you didn't write — walt.id's verifier, Credo-TS, or the OpenID4VP test suite. When a third-party verifier accepts your credential, you've demonstrated the actual value proposition: no phone call to the issuer, no shared database, just a signature check.
- Issue to a test wallet (or a did:key you control).
- Verify with walt.id or Credo-TS — not with our code.
- Revoke it, verify again, and watch the check fail.
Monday: what to tell your team
You now have a credential a third party can check without trusting your infrastructure, and you built it without storing personal data anywhere new. The free tier — one issuer, a thousand credentials a month — exists precisely so this weekend never needs a procurement conversation.