Summary

  • On 24 September, W3C published the first draft of a separate Verifiable Credentials Data Model Threat Model v2.1 Group Note; the 20 September data-model Working Draft had already summarized the risks in a non-normative appendix.
  • The Note details 25 threats in five categories. It distinguishes threats the specification targets from decisions left to implementers, deployers and dependent technologies; the counts do not measure how safe a deployment is.
  • A genuine credential can still be issued to the wrong person, rendered unsafely or relied on in an unsuitable context. The draft is not an endorsed Recommendation or evidence of any product's controls.

Imagine a credential that verifies cleanly. Its issuer really signed it. Its status is current. A verifier can still make the wrong decision if the issuer established the wrong person's identity before signing. In the W3C's new threat-model draft, this is T25: proofing failure at issuance. The interesting governance fact is where the remedy sits. The data model cannot choose the issuer's proofing rigor, and a successful downstream check cannot reconstruct the missing encounter. The issuer chooses an assurance process appropriate to risk; the verifier must decide whether that assurance is adequate for its intended use.

W3C's Verifiable Credentials Working Group published the separate Group Note Draft on 24 September. Four days earlier, the v2.1 data-model Working Draft had already carried a non-normative Appendix A with short summaries of the same categories and risks. The new Note supplies fuller descriptions, proposed responses and affected components. It is therefore wrong to say W3C discovered 25 entirely new hazards this week. The publication matters because it makes the handoffs between roles easier to inspect.

The draft lists two target threats, seven implementation threats, eleven deployment threats, four external threats and one dependency threat. These are classifications, not a scorecard. A target threat is one the specification was designed to address, not a finding that every deployed system has solved it. Indeed, T25 appears under target threats while its detail expressly says proofing strength remains an issuer choice beyond what the data model can enforce. The document's own dictionary warns that entries are starting-point placeholders. Its map is valuable partly because it exposes unfinished work.

Two further cases show why the boundary matters. For T1, altering protected claims is detectable when the securing mechanism is checked; stripping the proof altogether is not a cryptographic failure signal, because there is then nothing to verify. A verifier has to require a proof where it needs an issuer-authenticated statement. The standard also permits unsecured credentials for self-asserted or intermediate uses; such claims must not be silently promoted to issuer testimony. For T2, a perfectly valid signature can protect credential content containing executable markup.

Integrity does not make a wallet's or verifier's rendering path safe. Encoding, sandboxing or avoiding executable content are implementation decisions.

At the final decision point, T24 separates authenticity and status from fitness for purpose. A credential's source and nature may not qualify it for a medical, financial or access-control decision merely because the bits verify. That judgment belongs to the verifier's policy, with the use context made explicit. The Note also discusses privacy risks in status lookups, but this article is not about the shorter status pointer or the statusPurpose choice in the separate Bitstring Status List v1.1 draft. The larger issue here is whether a documented threat has an actual owner and an observable response.

An operator could maintain a small control ledger: threat identifier, responsible actor, decision point, chosen response, evidence that the response runs, and a review date. That is an editorial operating suggestion, not a W3C-prescribed format or a conformance result. It would prevent a threat list from becoming a ceremonial appendix: the issuer would be named for proofing, the wallet and verifier teams for unsafe-content handling, and the relying party for contextual acceptance. Where responsibility crosses systems, a named handoff would matter more than a reassuring signature icon.

The authority boundary is strict. VC Data Model v2.0 became a W3C Recommendation in May 2025; the v2.1 data model is a Working Draft, and this threat model is an unendorsed Group Note Draft on the Note track. Neither draft certifies deployments, establishes a legal obligation or reports an incident at a named provider. The current value is a sharper question for those building credential ecosystems: which risk is actually controlled, by whom, and with what evidence beyond the document that identified it?

Sources