Verifiable Credential¶
Holder-presented digital credential — instantiates Restricted-Issuance / Open-Verification Design
A cryptographically-signed claim the holder carries and presents directly, letting a verifier check the issuer's signature — and often just the one attribute needed — without contacting the issuer or seeing the rest.
A verifiable credential is a signed set of claims about a subject that the subject themselves carries and presents — a digital diploma, membership, or license held in a wallet rather than fetched from the issuer at check time. Its defining idea is present, don't phone home, and reveal only what's asked: the holder shows the credential directly, the verifier checks the issuer's signature against a key it already trusts, and — through selective disclosure — the holder can prove a single attribute ("over 21," "licensed to practise") without exposing the rest of the credential or alerting the issuer that a check occurred. Where a certificate binds a key to a name, a verifiable credential binds claims to a holder and hands control of what gets shown to the person the claims are about.
Example¶
A patron proves their age at a bar with a mobile driver's license. Their phone presents a proof, signed by the issuing motor-vehicle authority, that establishes exactly one fact — over 21 — while revealing neither their name, address, nor license number, and without the bar's reader contacting the authority at all. The bouncer's app checks the authority's signature against its known public key and, through holder binding, that the phone presenting it is the one the credential was issued to. Thousands of venues verify the same government-issued fact, offline and instantly, and the state learns nothing about where its residents drink — because verification happens between holder and verifier, not by calling back to the issuer.[n1]
How it works¶
- Issue claims bound to a holder. The issuer signs a set of attributes about a subject and ties the credential to something the holder controls — a device key or biometric — so it can't simply be handed off.
- Present directly, verify against a trusted issuer key. The holder shows the credential; the verifier checks the signature against the issuer's public key it already trusts, needing no live call to the issuer.
- Disclose the minimum. The distinguishing move is selective disclosure: reveal only the required attributes, or a zero-knowledge predicate proof (age ≥ 21) that answers the question without exposing the underlying data.
- Prove holder control. A proof of possession shows the presenter is the credential's subject, not just someone who obtained a copy.
Tuning parameters¶
- Disclosure granularity — whole credential, selected attributes, or a predicate proof. Finer disclosure protects privacy but needs more capable credential formats and verifier support.
- Holder-binding strength — bearer (whoever holds it) versus bound to a device or biometric. Tight binding stops replay and sharing but complicates recovery and delegation.
- Issuer-contact model — fully offline verification versus a live status check. Offline maximizes privacy and reach; a status check catches revocation at the cost of reintroducing a callback.
- Trust framework — which issuers, schemas, and assurance levels a verifier accepts. A broad framework interoperates widely; a narrow one is easier to reason about but more siloed.
When it helps, and when it misleads¶
Its strength is putting the subject in control: they present only what a situation requires, to whoever asks, with no issuer in the loop — which is what lets credential-checking scale to strangers while reducing rather than expanding what everyone learns. Anyone who trusts the issuer's key can verify, offline, on the spot.
Its central limitation is that a credential is valid as of issuance. If it has since been revoked or the underlying facts have changed, the signature still checks out — so it leans on a separate status/revocation channel it does not itself provide, and a purely bearer credential can be replayed by anyone who obtains it. The characteristic misuse runs the mechanism backwards on privacy: a verifier demands the full credential when a single predicate would do, re-creating exactly the over-identification that minimum disclosure exists to prevent, or insists on a phone-home check that hands the issuer a tracking signal. The discipline is to request the least that answers the question, enforce holder binding, and use a privacy-preserving status channel rather than a callback.
How it implements the components¶
Verifiable Credential realizes the holder-held-token and privacy side — the components that make an issued claim portable and minimally revealing:
issued_artifact_or_claim_token— the credential is the issued token: a signed set of claims the holder carries and presents as portable proof.minimum_disclosure_payload— selective disclosure and predicate proofs let the holder reveal only the attribute a verifier needs and nothing more.
It consumes rather than creates the signature it carries (unforgeable_binding, public_verification_rule — that's Digital Signature) and the issuer-key identity behind it (issuance_scope_policy, delegation_boundary — that's Public-Key Certificate); it is not the scan surface that transports a presentation (verifier_interface_surface — QR Verification Code) nor the channel that reports revocation (revocation_and_freshness_channel — Certificate Revocation List or Status Endpoint).
Related¶
- Instantiates: Restricted-Issuance / Open-Verification Design — only the issuer can sign a valid credential, yet any verifier who trusts the issuer's key can check one, and the holder controls what it reveals.
- Consumes: Digital Signature — the issuer's signature over the claims is what makes the credential verifiable; the trusted issuer key is named by a Public-Key Certificate.
- Sibling mechanisms: QR Verification Code · Notary or Official Stamp · Digital Signature · Public-Key Certificate · Certificate Revocation List or Status Endpoint · Issuer Key Ceremony · Secure Hardware Issuer Module · Serial Number or Registry Lookup · Signed Manifest or Checksum · Tamper-Evident Seal
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Verifiable Credential is defined in the frozen evidence as: A cryptographically-signed claim the holder carries and presents directly, letting a verifier check the issuer's signature — and often just the one attribute needed — without contacting the issuer or seeing the rest. Its operative deployed or enacted form is therefore Record, Log & Register.
Nearest alternative: Representation, Specification & Plan — Representation, Specification & Plan can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: W3C Verifiable Credentials Data Model v2.0 documents that the standard defines issuer-signed, holder-presented, cryptographically verifiable credentials. This is direct, mechanism-specific evidence for computer science as the best-evidenced historical home of the operation—A cryptographically-signed claim the holder carries and presents directly, letting a verifier check the issuer's signature — and often just the one attribute needed — without contacting the issuer or seeing the rest.—rather than evidence merely that the operation is useful there. The retained alternates record genuine adjacent lineages; later portability is represented separately by domain_reach=specialized.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: a cryptographically-signed claim the holder carries and presents directly, letting a verifier check the issuer's signature — and often just the one attribute needed — without….
- Law & Governance — Legal doctrine, regulatory governance, and procedural accountability supplies a parallel or contributing lineage for the mechanism's defining operation: a cryptographically-signed claim the holder carries and presents directly, letting a verifier check the issuer's signature — and often just the one attribute needed — without….
- Organizational & Management Science — Organizational Management supplies a historically relevant adjacent lineage or formative practice for the operation—A cryptographically-signed claim the holder carries and presents directly, letting a verifier check the issuer's signature — and often just the one attribute needed — without contacting the issuer or seeing the rest.—but the adjudicated evidence more directly locates the defining lineage in computer science.
- Security Studies & Intelligence Analysis — Security engineering, threat analysis, and intelligence practice supplies a parallel or contributing lineage for the mechanism's defining operation: a cryptographically-signed claim the holder carries and presents directly, letting a verifier check the issuer's signature — and often just the one attribute needed — without….
- Systems Thinking & Cybernetics — Systems science's feedback, boundaries, control, and regulation tradition contributes a separate formative lineage to the mechanism's verifiable credential logic.
Review resolution: The blind reviewers disagree on primary lineage (organizational_management versus computer_science). The defining operation is: A cryptographically-signed claim the holder carries and presents directly, letting a verifier check the issuer's signature — and often just the one attribute needed — without contacting the issuer or seeing the rest. The researched W3C Verifiable Credentials Data Model v2.0 establishes that the standard defines issuer-signed, holder-presented, cryptographically verifiable credentials. That source therefore supports computer science as the historical origin. organizational management remains in the uncapped alternates where it contributes a formative practice, but application or governance is not itself proof of origin. origin_mode=single_lineage records lineage construction; domain_reach=specialized separately records later applicability.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
A verifiable credential proves the issuer attested these claims and — with holder binding — that the presenter is the subject; it does not prove the claims are still true. Currency is a separate question answered by a status channel, and selective disclosure only protects privacy if the verifier actually asks for the minimum. The mechanism enables least-disclosure verification; it cannot by itself compel a verifier to want less.
[n1] Selective disclosure — including zero-knowledge predicate proofs, as used in the W3C Verifiable Credentials model and ISO mobile-driving-license work — lets a holder prove a fact derived from a credential (such as being over an age threshold) without revealing the underlying attribute (the birthdate). It is what makes "prove one thing, expose nothing else" cryptographically possible. ↩