Concepts: VCs, DIDs, trust chains, revocation
Background reading for anyone working with OpenCred. If you already know verifiable credentials, DIDs, and credential status, skip ahead to Desktop or Docker.
A typical OpenCred credential answers four questions for a verifier:
Is the data intact? — proven by the cryptographic proof.
Whose key signed it? — answered by resolving the issuer DID.
Should I trust that key? — answered by walking the trust chain.
Is it still valid? — answered by checking validity dates and revocation status.
OpenCred enforces all four during verification.
Verifiable Credentials
A Verifiable Credential (VC) is a tamper-evident, cryptographically-signed set of claims about a subject (a person, business, agent, or asset), structured to the W3C VC Data Model 2.0. OpenCred supports multiple proof formats:
JSON-LD VCs with embedded data-integrity proofs.
vc-jwt — JWT-encoded credentials.
sd-jwt-vc — selective-disclosure JWT credentials.
PixelPass / QR compact encodings, and printable PDF certificates with an embedded QR plus a copy of the payload in the PDF info dictionary.
DIDs (Decentralized Identifiers)
OpenCred uses three DID methods, each encoding the issuer's public key differently:
Method | What it is | When to use |
|---|---|---|
did:key | Public key encoded directly in the identifier. | Fully self-contained; verifies offline. Good for portable, no-infrastructure issuance. |
did:jwk | A JWK embedded in the identifier. | Like did:key, JWK-shaped. |
did:web | Resolves to a DID document hosted at .well-known/did.json on a domain you control. | When you want a stable, domain-anchored identity you can rotate. Requires network access to resolve. |
OpenCred also supports a per-key registry model (the OpenCred key registry) layered on DeDi, with a key lifecycle of active / rotated / revoked and a did.json snapshot stored on each key record.
Trust chains
Trust chains explain how a verifier gets from a credential's signature back to a root anchor. OpenCred supports three issuer types:
Issuer type | How trust flows |
|---|---|
Issuer with a DSC (Digital Signature Certificate) | The credential carries an x5c certificate chain; the verifier walks it back to a CSCA root in a trust store on disk. |
Issuer seeking a DSC | A transitional posture while CA integration for DSC acquisition is finalised. |
Self-published keys | The issuer publishes its public key (via did:web or the DeDi key registry); trust is anchored in domain ownership or the registry record. |
Revocation
OpenCred handles status through DeDi-backed hash lookup, and computes credentialStatus accordingly.
Key revocation vs per-credential revocation are distinct. Revoking a key invalidates everything it signed; per-credential revocation targets a single credential.
The "no DeDi status available" case → the credential stays VALID. If the status source cannot be reached, OpenCred does not fail closed into a false "revoked"; absence of a revocation record is not evidence of revocation.
Where these live in the product
DID resolution and proof verification run inside the shared
@opencred/verificationengine used by both the Desktop app and the Docker server.Revocation status is read from a DeDi Revocation registry — see DeDi → schema templates.