Verifiable Credential Barcodes Threat Model v1.0

W3C Group Note Draft

More details about this document
This version:
https://www.w3.org/TR/2026/DNOTE-vc-barcodes-threat-model-1.0-20261008/
Latest published version:
https://www.w3.org/TR/vc-barcodes-threat-model-1.0/
Latest editor's draft:
https://w3c.github.io/vc-barcodes/threat-model/
History:
https://www.w3.org/standards/history/vc-barcodes-threat-model-1.0/
Commit history
Editor:
Wesley Smith (Digital Bazaar)
Feedback:
GitHub w3c/vc-barcodes (pull requests, new issue, open issues)

Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

Abstract

This document describes a threat model for the Verifiable Credential Barcodes specification. It identifies and analyzes security and privacy threats specific to ecosystems that embed verifiable credentials in optical barcodes in order to provide authenticity, integrity, and real-time status management for physical documents.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index.

This threat model is a work in progress. It is published alongside the Verifiable Credential Barcodes specification to inform implementers and ecosystem designers of the security and privacy considerations relevant to deployments of the specification. Feedback and proposed additions are welcome via the issue tracker.

This document was published by the Verifiable Credentials Working Group as a Group Note Draft using the Note track.

Group Note Drafts are not endorsed by W3C nor its Members.

This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.

The W3C Patent Policy does not carry any licensing requirements or commitments on this document.

This document is governed by the 18 August 2025 W3C Process Document.

1. Introduction

This document provides a threat model for the Verifiable Credential Barcodes specification, which supports two use cases:

In both cases, a credential that successfully verifies is guaranteed to have originated from the claimed issuing authority (authenticity) and to carry data unmodified since issuance (integrity), and the document's revocation or suspension status can be checked in real time - all without a privacy-invasive "phone home" to a source-of-truth database. The two use cases differ in what the digital signature covers: a generic credential's signature covers only the credential's own claims, while an OpticalBarcodeCredential's signature also covers selected optical data on the document.

This threat model follows the methodology described in the W3C Threat Modeling Guide and uses the STRIDE taxonomy for classifying threats. Threats are grouped into four categories:

1.1 Description

The Verifiable Credential Barcodes ecosystem enables an issuing authority — such as a state motor vehicle agency, a passport authority, or another document-issuing body - to either encode generic Verifiable Credentials as barcodes (O4) or issue a specific type of Verifiable Credentials, OpticalBarcodeCredentials (O1), that secure non-Verifiable Credential optical data on a physical document. In the first case, the issuer signs the credential with an ordinary Data Integrity proof over the claims it contains. In the second, the issuer signs with the ecdsa-xi-2023 cryptosuite, which covers selected fields of the barcode - the optical data bytes - as "extra information". In both cases, the credential is compressed with CBOR-LD, character-encoded, and printed into a barcode (a PDF417, a QR code, or a machine-readable zone) on a document carried by the holder.

A verifier who scans a physical document must be able to cryptographically verify whether the credential was issued by a trusted authority, whether its signed content has been tampered with, and (optionally) whether the document remains valid — and, for an OpticalBarcodeCredential, whether the document's other signed optical data matches what was signed. The specification addresses this by signing over the credential (and, for OpticalBarcodeCredentials, the optical data), by carrying a TerseBitstringStatusListEntry for status checks, and by advising verifiers to compare the signed data against the data visible on the document and against the physical attributes of the person presenting it — while trusting only what each credential's proof actually covers.

For this threat model, we consider a minimal instantiation of the Verifiable Credential Barcodes ecosystem consisting of four external roles: the Issuing Authority (E1) who creates and signs OpticalBarcodeCredentials and/or generic verifiable credentials and publishes status information, the Holder (E2) who carries and presents the physical document, the Verifier (E3) who scans, verifies, and cross-checks the document, and the Document Manufacturer (E4) who renders the encoded credential onto a physical card. In this instantiation we assume that the holder and presenter of a physical document containing a Verifiable Credential Barcode are the same individual.

Both use cases appear in the data flow diagram below. The specification's general algorithms can encode any Generic Verifiable Credential Expressed as Barcode into a barcode; that flow bypasses the optical data binding entirely - the credential's proof covers only its own claims. All threats that do not depend on the ecdsa-xi-2023 binding (issuer spoofing, revocation, duplication, status, privacy, key management, and encoding threats, among others) apply to both flows.

1.2 Data Flow Diagram for the Verifiable Credential Barcodes Ecosystem

The data flow diagram below illustrates the key elements and data flows in a minimal Verifiable Credential Barcodes ecosystem, organized into three system boundaries: the issuer system (C1), the manufacturer system (C2), and the verifier system (C3). An issuing authority (E1) creates and signs either a generic verifiable credential (O4) or an OpticalBarcodeCredential (O1) - in the latter case taking the optical data bytes (O2) as an input to signing - then compresses and encodes the credential (P2) and delivers it via F1 to the document manufacturer (E4). Within the manufacturer system, the manufacturer renders and personalizes the physical document (S4) at P8; custody of that document then transfers across the boundary to the holder (E2). The holder presents the document to a verifier (E3), who scans and decodes it (P3) and verifies the proof (P4), obtaining key material either from the verifier trust store (F3a) or through external verification-method resolution (F3b). Proof verification passes its verified claims and protected-field coverage to the identity and attribute cross-check (P5) and the validated status entry and issuer context to the status check (P6), which may optionally fetch the status list (O3) to confirm the document has not been revoked or suspended.

Data flow diagram of the Verifiable Credential Barcodes ecosystem

The following notation is used in the diagram description and dictionary. Every element is labelled with a type letter and an index (for example, P4 or F3a), and every data flow carries an identifier so it can be referenced from threats and responses.

The diagram records the following assumptions, which constrain its scope and are called out here rather than left implicit:

1.3 Dictionary

E1 Issuing Authority An entity - such as a state motor vehicle agency, a passport authority, or another document-issuing body - that creates and cryptographically signs credentials for optical barcodes - both generic verifiable credentials and OpticalBarcodeCredential resources - and operates the status infrastructure for the documents it issues. The issuing authority controls the signing keys and the verification method against which its credentials are validated, and is the authority for any credential it issues.
E2 Holder The person who carries a physical document bearing a Verifiable Credential Barcode - for example the person named on a driver's license, employment authorization document, or travel document - and who presents that document to a verifier. The holder does not operate a system in this model; they carry the physical document.
E3 Verifier An entity - such as a law enforcement officer, a border control or customs agent, an age-verification clerk, or an automated inspection kiosk - that scans the optical barcode, verifies the credential it carries - a generic verifiable credential or an OpticalBarcodeCredential - cross-checks the signed data against the visible document and the person when relevant, and optionally checks status information. The verifier is configured to determine from each credential's type and proof what its signature actually covers.
E4 Document Manufacturer An organization or entity that renders an encoded credential — a generic verifiable credential or an OpticalBarcodeCredential - into an optical barcode on a physical card or document.
P1 Credential Creation and Signing The process by which an issuing authority assembles and signs a credential for an optical barcode. For a generic verifiable credential, the issuer signs an ordinary Data Integrity proof over the claims the credential contains. For an OpticalBarcodeCredential, the issuer computes the optical data bytes over the fields selected by the credential type's component extraction rules (for example using protectedComponentIndex against PDF417 key-value pairs) and signs with the ecdsa-xi-2023 cryptosuite so the proof covers both the credential and the optical data.
P2 CBOR-LD Compression and Encoding The process by which a signed credential - a generic verifiable credential or an OpticalBarcodeCredential - is compressed using CBOR-LD and then character-encoded so that it can be rendered into an optical barcode.
P3 Barcode Scan and Decode The process by which a verifier optically scans the barcode, reverses the character encoding, and decompresses the CBOR-LD payload to recover the credential and, when it is an OpticalBarcodeCredential, to reconstruct the optical data bytes from the document for verification.
P4 Proof Verification The process by which a verifier checks the credential's proof. For a generic verifiable credential, it verifies a standard Data Integrity proof over the credential's claims. For an OpticalBarcodeCredential, it additionally recomputes the hash of the reconstructed optical data bytes as required by ecdsa-xi-2023. In both cases it resolves the issuer's verificationMethod and confirms the signature is valid and that the resolving issuer is trusted. The process produces an error if any check fails.
P5 Identity and Attribute Cross-Check The process by which a verifier confirms that the signed data matches the data visible on the document, that the signed data matches the physical attributes of the person presenting it, and that the visible data matches that person. Only fields protected by the signature are relied upon for fraud detection — for a generic verifiable credential, that is solely the credential's own claims, since its signature covers no other data on the document.
P6 Status Check The process by which a verifier expands the TerseBitstringStatusListEntry into a BitstringStatusListEntry and checks the corresponding entry in the issuer's status list to determine whether the document has been revoked or suspended. This process is performed after proof verification succeeds.
P7 Status List Publication The process by which an issuing authority creates and updates the BitstringStatusListCredential that records the status of the documents it has issued, and makes it available for retrieval.
P8 Barcode Rendering and Personalization The process, operated by the document manufacturer within the manufacturer system, that receives the encoded credential via Render and Print Barcode, renders it as an optical barcode, and creates the physical document that carries it.
F1 Render and Print Barcode The data flow by which an encoded credential is delivered to the document manufacturer and rendered as an optical barcode on a physical document.
F2 Present Document The data flow by which a holder presents a physical document with an optical barcode to a verifier for scanning. This flow crosses the security boundary between the holder's possession and the verifier's system.
F3 Resolve Verification Method The data flow by which a verifier obtains the issuer's public key material in order to verify the credential. The model distinguishes two sub-flows: F3a, a lookup in the verifier's local trust store of already-trusted key material and policy; and F3b, external verification-method resolution, such as resolving a did:web identifier from the external verification method store. This threat model treats threats in resolving an external verification method as largely out of scope, as they are not specific to barcodes or other optical media in any way.
F4 Fetch Status List The data flow by which a verifier retrieves, typically with a standard HTTP GET request, the BitstringStatusListCredential Verifiable Credential from the host identified by terseStatusListBaseUrl, receiving the status list in response, in order to perform a status check. This flow is optional: it occurs only when a verifier performs an online status check, and is omitted when status is not checked or a cached result is reused.
F5 Publish Status The data flow by which an issuing authority writes revocation and suspension updates into the status list store from which verifiers retrieve them.
S1 Issuer Key Store The persistent storage within the issuer system that holds the issuing authority's private signing keys. Compromise of this store undermines the authenticity guarantees of every credential signed with the affected key.
S2 Status List Store The persistent storage, typically a publicly retrievable web endpoint, where the issuing authority publishes BitstringStatusListCredential resources. Verifiers retrieve status lists from this store via Fetch Status List.
S3 Verifier Trust Store The storage within the verifier system that holds the set of issuing authorities and verification methods the verifier considers authoritative. It is consulted during proof verification to decide whether a resolving issuer is trusted.
S4 Physical Document / Barcode The physical document that carries the printed optical barcode. As a data store, it persistently holds one or more encoded Verifiable Credentials and is the medium presented by the holder and scanned by the verifier. It is outside any compute boundary and is readable by anything with optical access to it. This store moves from the custody of the Document Manufacturer, inside the manufacturer system boundary, to the custody of the holder.
S5 External Verification Method The external storage from which a verifier obtains issuer key material via F3b when the verification method is not already present in the verifier trust store. This document treats this store outside the existing boundaries for generality, although in many deployments this store will be controlled by a modelled entity such as the issuer.
O1 OpticalBarcodeCredential A compact, cryptographically-signed verifiable credential that secures the contents of an optical barcode. It carries the issuer, a proof produced by the ecdsa-xi-2023 cryptosuite, a credentialSubject whose type is a subclass of the general MachineReadableInformation superclass and optionally a TerseBitstringStatusListEntry. Each subclass defines the optical data it secures, its component extraction rules, and its character encoding.
O2 Optical Data Bytes (xi) The canonicalized "extra information" that is hashed and bound into the ecdsa-xi-2023 signature. It extends the credential's digital signature to cover other machine readable data on the document rather than covering the credential alone.
O3 BitstringStatusListCredential A verifiable credential, published by the issuing authority, that encodes status information of a large set of Verifiable Credentials as a compressed bitstring. Verifiers consult it during status check after expanding the credential's TerseBitstringStatusListEntry.
O4 Generic Verifiable Credential Expressed as Barcode Generic verifiable credentials can be encoded into a barcode using this specification's general encoding algorithms (CBOR-LD compressed, base45-multibase-encoded, prefixed with VC1-). Here, the credential's Data Integrity proof covers only the claims explicitly included in the credential itself and the digital signature covers no other machine-readable data on the physical document.
C1 Issuer System The system boundary - typically the servers and key-management infrastructure operated by the issuing authority - that runs the Credential Creation and Signing, CBOR-LD Compression and Encoding (in part), and Status List Publication processes and maintains the Issuer Key Store and Status List Store.
C2 Manufacturer System The supply-chain system boundary controlled by the document manufacturer. Its controlling authority is the manufacturer; its input is the encoded credential delivered by Render and Print Barcode; its process is Barcode Rendering and Personalization; and it holds the physical document while that document is in production, before custody transfers to the holder. The manufacturer is frequently a distinct organization from the issuer, so the boundary between C1 and C2 is a genuine supply-chain trust boundary.
C3 Verifier System The system boundary that runs the Barcode Scan and Decode, Proof Verification, Identity and Attribute Cross-Check, and Status Check processes and holds the Verifier Trust Store.

2. Stakeholders

2.1 E1 Issuing Authority

An issuing authority creates and signs credentials for optical barcodes - both generic verifiable credentials and OpticalBarcodeCredential resources - and operates the status infrastructure for the documents it issues.

Issuing authorities typically have an interest in ensuring that only unmodified documents they genuinely issued can pass verification, that their signing keys are not compromised, and that they can revoke or suspend documents after issuance. They bear operational responsibility for the availability and integrity of the status lists they publish and for the consequences of signing documents that remain in circulation for years.

2.2 E2 Holder

A holder is a person carrying a physical document that bears a Verifiable Credential Barcode - examples include an importer presenting credentials at a border, a driver presenting a license, or an employee presenting an employment authorization document.

A holder's primary goal is for their genuine documents to be accepted while their personal information is not over-exposed. Because a barcode can be read at a distance and discloses all of its signed contents at once, holders' privacy considerations here differ slightly from Verifiable Credential ecosystems where credentials are stored and presented digitally.

2.3 E3 Verifier

A verifier receives a physical document from a holder and must determine whether to accept it. Verifiers range from automated border-control kiosks processing travelers at high volume to human officers and clerks checking a license or permit by hand.

The verifier's primary goal is to confirm that the document was issued by a genuinely trusted authority, that its signed data has not been tampered with, (optionally) that its status entries do not render it invalid, and that it belongs to the person presenting it. Because the two credential kinds differ in what their proofs cover, the verifier must also determine whether a given barcode carries an OpticalBarcodeCredential that binds the document's optical data or a generic verifiable credential whose signature covers only its own claims, and scope trust accordingly. Verifiers also have a strong interest in availability - a denial of service against the status lists they depend on directly impairs their ability to function - and in the trustworthiness of the verification software they run.

2.4 E4 Document Manufacturer

A document manufacturer is the organization that renders the encoded credential into a barcode on a physical document. In many cases this is a distinct organization from the issuing authority.

The manufacturer handles the encoded credential and the physical medium, and it may inject data, such as serial numbers, that the issuer did not sign. Faithful rendering and correct application of the specification's encoding conventions are essential to the document verifying as intended.

3. Threats

3.1 Threat List

Target Threats

  1. Barcode Data Tampering security
  2. Forgery of Documents Without Machine-Readable Information security
  3. Issuer Spoofing via Forged Barcode security safety
  4. Acceptance of a Revoked or Suspended Document security

Implementation Threats

  1. Optical Data Duplication safety security
  2. Unsigned-Field Substitution safety security
  3. Untrusted Verification Software security privacy
  4. Failure to Surface Signed-vs-Unsigned Coverage safety
  5. Verifier Trust Anchor Misconfiguration security
  6. Denial of Service against Status Services security
  7. Stale Status via Aggressive Caching security privacy
  8. Under-Inclusive Protected Component Index security
  9. Confusion among Types of Credential Subject security interoperability

External Threats

  1. Theft Of or Information Leakage Through Physical Media privacy
  2. Correlation via Status List Retrieval privacy
  3. Over-Disclosure due to Compelled Presentation privacy
  4. Cross-Verifier Linkage of the Holder privacy

Dependency Threats

  1. Cryptographically Relevant Quantum Computer Breaks ECDSA security
  2. Quishing via Malicious Barcode Injection security
  3. Biometric Falsification security safety
  4. Compromise of the Issuer's Signing Key security
  5. Spoofing of Key Resolution and/or Key Management security
  6. Confusion between Base-Encoding and Multibase Header interoperability security

3.2 Threat Details

Target Threats

3.2.1 T1. Barcode Data Tampering

T1. Barcode Data Tampering security

[Threat List]
An attacker alters the machine-readable data on a physical document, such as a PDF417 on a driver's license or a machine-readable zone of a travel document, after it has been issued in order to change attributes such as date of birth, expiration date, or document number. Because off-the-shelf barcode generation and scanning libraries make optical data trivial to generate, a barcode with unsecured contents offers no assurance that its data matches what the issuing authority originally encoded.
R1. Digital Signature over Optical Data
The ecdsa-xi-2023 cryptosuite extends ecdsa-rdfc-2019 by hashing canonicalized machine-readable information (optical data bytes) as "extra information" and including that hash in the data protected by the issuer's signature. During proof verification, the verifier reconstructs the optical data bytes from the freshly scanned document and recomputes the hash; any modification of a protected field causes signature verification to fail. This makes tampering with signed optical data detectable.
Affected Components: S4: Physical Document, O1: OpticalBarcodeCredential, O2: Optical Data Bytes (xi), P1: Credential Creation and Signing, P4: Proof Verification
Threat Taxonomy: STRIDE (Tampering)

3.2.2 T2. Forgery of Documents Without Machine-Readable Information

T2. Forgery of Documents Without Machine-Readable Information security

[Threat List]
Many physical documents are issued with no machine-readable information at all. Often, their authenticity can only be checked by human inspection of physical anti-counterfeiting technologies, which have been outmoded by advances in printing technology. An attacker fabricates such a document, or alters a genuine one, and a verifier has no cryptographic means by which to test whether the document was issued by the claimed authority or whether its contents match what was issued.
R2. Machine-Verifiable Claims via a Generic Verifiable Credential Barcode
Encoding a generic verifiable credential as a barcode on the document gives the verifier a machine-readable, cryptographically verifiable statement of the issuer's claims: proof verification establishes that the claims originate from the claimed issuer and have not been modified since issuance, and an optional TerseBitstringStatusListEntry enables a real-time status check. The credential's signature covers only the claims it contains, so verifiers scope trust to the credential itself rather than to other content on the document.
Affected Components: E1: Issuing Authority, E3: Verifier, O4: Generic Verifiable Credential Expressed as Barcode, P1: Credential Creation and Signing, P4: Proof Verification, P6: Status Check, S4: Physical Document
Threat Taxonomy: STRIDE (Spoofing)

3.2.3 T3. Issuer Spoofing via Forged Barcode

T3. Issuer Spoofing via Forged Barcode security safety

[Threat List]
An attacker fabricates a credential — a generic verifiable credential or an OpticalBarcodeCredential — from scratch and prints it onto a counterfeit document so that it appears to have been issued by a legitimate issuing authority such as a state motor vehicle agency or a passport authority. If a verifier accepts the contents of a barcode without verifying a cryptographic proof using a key controlled by a trusted issuer, the attacker can manufacture documents that assert any claims they choose.
R3. Mandatory Proof Verification Against a Trusted Issuer
A Verifiable Barcode Credential carries a Data Integrity proof whose verificationMethod resolves to public key material controlled by the issuing authority. During proof verification, the verifier confirms the proof is valid and that the resolved issuer appears in its trust store of authoritative issuers. A barcode that does not verify against an acceptable key is rejected, so a forged barcode cannot impersonate a legitimate authority without also compromising that authority's signing key or key distribution mechanism.
Affected Components: E1: Issuing Authority, E3: Verifier, F3: Resolve Verification Method, O1: OpticalBarcodeCredential, O4: Generic Verifiable Credential Expressed as Barcode, P4: Proof Verification, S3: Verifier Trust Store
Threat Taxonomy: STRIDE (Spoofing)

3.2.4 T4. Acceptance of a Revoked or Suspended Document

T4. Acceptance of a Revoked or Suspended Document security

[Threat List]
A physical document undergoes a status change that should render it unusable — a driver's license is suspended for cause, a travel document is reported lost or stolen, an authorization is withdrawn — but the document itself remains in circulation. An attacker, including the original holder, continues to use the document as though it were still valid. A verifier with no ability to check the document's status in real time therefore has no way to detect the change, and continues to accept a document the issuing authority no longer stands behind.
R4. Real-Time Status via TerseBitstringStatusListEntry
A credential of either kind carries a TerseBitstringStatusListEntry that the verifier expands into a BitstringStatusListEntry and uses to perform a status check against the issuer's status list — equipping verifiers with the real-time status capability that many physical documents lack, without a privacy-invasive per-document "phone home" to a source-of-truth database. A status change that renders the document invalid is thereby detectable at verification time. Verifiers in high-assurance contexts should treat a missing or unreachable status result as cause to decline rather than accept the document.
Affected Components: E1: Issuing Authority, E2: Holder, E3: Verifier, F4: Fetch Status List, O1: OpticalBarcodeCredential, O3: BitstringStatusListCredential, O4: Generic Verifiable Credential Expressed as Barcode, P6: Status Check, S2: Status List Store, S4: Physical Document
Threat Taxonomy: STRIDE (Elevation of Privilege)

Implementation Threats

3.2.5 T5. Optical Data Duplication

T5. Optical Data Duplication safety security

[Threat List]
Optical barcode technologies provide no inherent protection against copying: the exact bytes of a barcode can be read with commodity scanners and reproduced with commodity generators, so a byte-for-byte copy verifies identically to the original. An attacker exploits this by copying a valid, signed barcode from a genuine document and reproducing it on a fraudulent document. Because the duplicated barcode contains an authentic issuer signature — over the same optical data for an OpticalBarcodeCredential, or over the credential's own claims for a generic verifiable credential — it passes proof verification exactly like the original. The duplication defense — confirming the signed data matches the person presenting it and/or the document the barcode is present on — is only as strong as how uniquely the signed fields identify a holder or document. For identity documents whose signed attributes are coarse and not biometrically bound, a cloned barcode can be presented by a different person who happens to match those coarse attributes.
R5.1. Three-Way Match Strengthened by Uniquely-Identifying Signed Data
During identity and attribute cross-check, the verifier confirms that the signed data matches the human-readable data on the document, that the signed data matches the physical attributes of the person presenting it, and that the visible data matches that person. To make this match meaningful, issuers include uniquely-identifying or biometrically-bound data among the signed fields wherever the use case permits, and verifiers treat documents whose signed data is only coarsely identifying as providing weaker holder-binding assurance, since a clone matching coarse attributes is more likely to succeed.
R5.2. Do Not Rely on Barcode Unclonability
Because the optical medium cannot prevent copying, remaining defenses are transferred to other layers: verification-time checks match the credential to the holder and document and status checks limit the useful lifetime of a copied credential. Issuers and verifiers do not treat the barcode itself as unclonable.
Affected Components: E2: Holder, E3: Verifier, O1: OpticalBarcodeCredential, O2: Optical Data Bytes (xi), O4: Generic Verifiable Credential Expressed as Barcode, P3: Barcode Scan and Decode, P4: Proof Verification, P5: Identity and Attribute Cross-Check, S4: Physical Document
Threat Taxonomy: STRIDE (Spoofing)

3.2.6 T6. Unsigned-Field Substitution

T6. Unsigned-Field Substitution safety security

[Threat List]
Not all data in an optical barcode is necessarily covered by a Verifiable Credential Barcode's digital signature. The protectedComponentIndex selects which data are integrated into the optical data bytes, and some data, such as a serial number injected after credential issuance time by a document manufacturer, may be unsignable. For a generic verifiable credential, the signature covers nothing outside the credential at all, so every other machine-readable and printed element of the document is effectively unsigned. An attacker can modify any unsigned data without invalidating the credential's proof, such altering unsigned barcode fields, changing visible document content, or pairing a genuine barcode with an otherwise-altered or substituted document, and a verifier who relies on that data for fraud detection can be deceived even though the signature still verifies.
R6. Rely Only on Signed Fields
Implementers of verifier software determine exactly which fields are protected by the signature and base all fraud-detection decisions solely on those fields, no matter how commonly an unsigned field is used on legacy documents without cryptographic security. For example, if eye color and hair color are signed but the portrait is not, the verifier emphasizes the signed attributes when checking the holder. Unsigned data (including, for a generic verifiable credential, everything on the document beyond the credential's own claims) is treated as potentially tampered.
Affected Components: E3: Verifier, E4: Document Manufacturer, O1: OpticalBarcodeCredential, O2: Optical Data Bytes (xi), O4: Generic Verifiable Credential Expressed as Barcode, P5: Identity and Attribute Cross-Check, S4: Physical Document
Threat Taxonomy: STRIDE (Tampering)

3.2.7 T7. Untrusted Verification Software

T7. Untrusted Verification Software security privacy

[Threat List]
A verifier uses an untrusted application or interface to scan and validate a Verifiable Credential Barcode. Malicious verification software can falsely report a fraudulent credential as valid, suppress a failed status check, or exfiltrate the personal data read from the document.
R7. Use Trusted Verification Programs and Interfaces
Verifiers use only trusted, vetted programs and interfaces to perform scanning and verification. Deployers establish provenance for verification software (for example signed builds from a known supplier and controlled distribution channels), and treat the verification tool itself as a security-sensitive component whose compromise would defeat the protections this specification provides.
Affected Components: C3: Verifier System, E3: Verifier, O1: OpticalBarcodeCredential, O4: Generic Verifiable Credential Expressed as Barcode, P3: Barcode Scan and Decode, P4: Proof Verification, P5: Identity and Attribute Cross-Check
Threat Taxonomy: STRIDE (Tampering)

3.2.8 T8. Failure to Surface Signed-vs-Unsigned Coverage

T8. Failure to Surface Signed-vs-Unsigned Coverage safety

[Threat List]
Not all information on a physical document is necessarily covered by a credential's digital signature: an OpticalBarcodeCredential's signature covers only selected machine-readable data, and a generic verifiable credential's signature covers nothing outside the credential at all. If a verifier's software presents decoded data without indicating which fields are protected or unprotected, a human operator may give unsigned, tamperable data the same trust as signed data, defeating the integrity guarantee even though the proof verifies.
R8. Correctly Surface What Is and Is Not Covered
Verifier software derives the protected field set from the component extraction rules of the credentialSubject type and clearly surfaces, per field, what is and is not secured by the signature: displaying only signed data during verification, or explicitly marking unsigned values as unverified. For a generic verifiable credential, the software makes clear that only the credential's own claims are attested. Discrepancies between the signed data, the visible document, and the holder are surfaced to the operator rather than silently resolved. Operators are thereby prevented from basing trust decisions on data not digitally signed by the issuer.
Affected Components: E2: Holder, E3: Verifier, E4: Document Manufacturer, O1: OpticalBarcodeCredential, O2: Optical Data Bytes (xi), O4: Generic Verifiable Credential Expressed as Barcode, P5: Identity and Attribute Cross-Check, S4: Physical Document
Threat Taxonomy: STRIDE (Spoofing)

3.2.9 T9. Verifier Trust Anchor Misconfiguration

T9. Verifier Trust Anchor Misconfiguration security

[Threat List]
A high-assurance verifier's trust store determines which issuing authorities are considered authoritative. If that store is configured with an overly broad set of issuers, with a stale or attacker-supplied key, or with no effective constraint at all, the verifier may accept credentials signed by entities that are not legitimately authoritative for the document type being presented.
R9. Curated, Maintained Trust Store
During verifier configuration, deployers populate the trust store with a curated set of issuer identifiers and verification methods appropriate to the documents they accept and the level of assurance they require, and maintain it as issuer keys rotate. The verifier scopes acceptance to issuers authoritative for the presented document type, so a key valid for one ecosystem cannot be used to vouch for documents in another.
Affected Components: E1: Issuing Authority, E3: Verifier, O1: OpticalBarcodeCredential, O4: Generic Verifiable Credential Expressed as Barcode, P4: Proof Verification, S3: Verifier Trust Store
Threat Taxonomy: STRIDE (Spoofing)

3.2.10 T10. Denial of Service against Status Services

T10. Denial of Service against Status Services security

[Threat List]
When a verifier performs an online status check, it depends on the status services named by terseStatusListBaseUrl that host the status list. An attacker who renders those services unreachable — through network disruption, volumetric attack, or compromise of the status list store or its hosting infrastructure, for example — prevents verifiers from performing status checks, creating a tension between availability and assurance.
R10. Resilient Status Hosting and an Explicit Failure Policy
Issuers host status lists on resilient, scalable infrastructure (for example, static files behind a content distribution network) so the bitstring format's efficient, cacheable retrieval can absorb load. Verifiers adopt an explicit policy for coping with unreachable status — e.g., declining in high-assurance contexts, rather than failing open — and use short-lived cached results to ride out transient outages without indefinitely trusting stale data.
Affected Components: S2: Status List Store, F4: Fetch Status List, P6: Status Check, O3: BitstringStatusListCredential, E3: Verifier
Threat Taxonomy: STRIDE (Denial of Service)

3.2.11 T11. Stale Status via Aggressive Caching

T11. Stale Status via Aggressive Caching security privacy

[Threat List]
To reduce load and protect privacy, a verifier may cache a retrieved status list. If caching is too aggressive, a document invalidated by a status change after the cache was populated could continue to be accepted, creating a window in which the holder benefits from a status the issuer no longer stands behind. The longer the validity period assumed for cached status, the larger this window.
R11. Match Cache Lifetimes to Risk
Verifiers set status list cache lifetimes according to the risk of the decision, refreshing more frequently for higher-stakes verifications. Issuers publish status updates promptly and communicate expected refresh cadence so that verifiers can size cache lifetimes appropriately, balancing timeliness of updates against the load and correlation costs of frequent fetches.
Affected Components: P6: Status Check, O3: BitstringStatusListCredential, F4: Fetch Status List, E3: Verifier
Threat Taxonomy: STRIDE (Repudiation)

3.2.12 T12. Under-Inclusive Protected Component Index

T12. Under-Inclusive Protected Component Index security

[Threat List]
The protectedComponentIndex lets an issuer choose which machine-readable data are bound into optical data bytes and thus covered by a digital signature. An issuer that selects too few bits — protecting only a small subset of fields — produces credentials that successfully verify although most of the document's data is outside the signature and therefore freely modifiable. A verifier that does not check how much data is actually protected may overvalue the assurance provided by a passing signature.
R12. Maximize Protection Coverage and Surface It to Verifiers
Issuers set protectedComponentIndex to cover as much data as the issuance pipeline permits. Verifier software decodes the index, surfaces which fields are protected, and lets deployers require a minimum protected set before accepting a document — so a sparsely signed credential cannot silently pass as fully protected. Malformed indices are rejected.
Affected Components: O1: OpticalBarcodeCredential, O2: Optical Data Bytes (xi), P1: Credential Creation and Signing, P5: Identity and Attribute Cross-Check, E1: Issuing Authority, E3: Verifier
Threat Taxonomy: STRIDE (Tampering)

3.2.13 T23. Confusion among Types of Credential Subject

T23. Confusion among Types of Credential Subject security interoperability

[Threat List]
Every credentialSubject appearing on an OpticalBarcodeCredential is typed as a subclass of the general MachineReadableInformation superclass, and other specifications may define additional subclasses. Each subclass carries its own definition of the optically readable data it secures the contents of, its component extraction rules, and its character encoding. A verifier that processes a credential under the wrong subclass's rules can reconstruct different optical data bytes than the issuer signed, mis-scope which fields are protected, or accept a credential whose type-specific checks were never performed.
R23. Verify Only Under Recognized, Exactly-Matched Types
Verifiers with specific assurance requirements only verify OpticalBarcodeCredentials with credentialSubjects whose types they recognize and support, applying that type's component extraction and encoding rules exactly. Credentials for which this value is unrecognized, ambiguous, or otherwise inconsistent with the presentation are rejected rather than processed generically, and deployers vet third-party subclass definitions before adding them to the set a verifier accepts.
Affected Components: O1: OpticalBarcodeCredential, O2: Optical Data Bytes (xi), P3: Barcode Scan and Decode, P4: Proof Verification, E3: Verifier, E1: Issuing Authority
Threat Taxonomy: STRIDE (Spoofing)

External Threats

3.2.14 T14. Theft Of or Information Leakage Through Physical Media

T14. Theft Of or Information Leakage Through Physical Media privacy

[Threat List]
Presenting a Verifiable Credential Barcode exposes information through the physical, optical medium in ways a digital credential presentation does not. The barcode can be captured without the holder's awareness or consent. For example, a high-resolution camera at a convenience store, or a scanner reading at a distance, can record the encoded bytes from the surface of the document. Any data placed in the barcode can therefore be harvested by parties the holder never intended to read it and combined across locations to track the holder. Physical documents can also be stolen.
R14.1. Minimize Sensitive Data and Handle Documents Appropriately
Issuers minimize the amount of highly sensitive data that is placed in the barcode to only that necessary for the document's purpose. Holders are made aware that careless display of a document containing a barcode with sensitive data in it can result in data leakage. The residual risk that data in a barcode can be captured from the physical medium without the holder's awareness is acknowledged as out of scope for this specification.
R14.2. Do Not Treat Verifiable Credential Barcodes as Defense Against Physical Theft
Physical documents can be stolen. The digital signature mechanisms that Verifiable Credential Barcodes use to add security to the contents of a physical document are not protection against theft of the document.
Affected Components: E2: Holder, O1: OpticalBarcodeCredential, O4: Generic Verifiable Credential Expressed as Barcode, S4: Physical Document
Threat Taxonomy: STRIDE (Information Disclosure)

3.2.15 T15. Correlation via Status List Retrieval

T15. Correlation via Status List Retrieval privacy

[Threat List]
The terseStatusListBaseUrl and terseStatusListIndex position a document within a specific status list. When a verifier performs an online status check, the host of the status list store observes the request, learns that a verification involving that list is occurring, and can correlate it with the verifier's network origin and time. Over many verifications, the issuer or list host can build a picture of where and when documents are checked.
R15. Group Privacy in Status Lists and Cacheable Retrieval
The design of the bitstring status list groups many documents into a single shared list so that fetching it only reveals interest in the list, not in a specific holder. Status lists are sized to preserve adequate herd privacy. Static, cacheable hosting behind a content distribution network (CDN) lets a verifier retrieve a whole list and reuse it, reducing the frequency and granularity observable by the verification list host.
Affected Components: E1: Issuing Authority, F4: Fetch Status List, O1: OpticalBarcodeCredential, O3: BitstringStatusListCredential, O4: Generic Verifiable Credential Expressed as Barcode, P6: Status Check, S2: Status List Store
Threat Taxonomy: STRIDE (Information Disclosure)

3.2.16 T16. Over-Disclosure due to Compelled Presentation

T16. Over-Disclosure due to Compelled Presentation privacy

[Threat List]
A Verifiable Credential embedded in an optical barcode is a static, all-or-nothing artifact: presenting the barcode discloses every signed attribute it carries, with no mechanism for selective disclosure. A holder compelled to present the document for one purpose necessarily reveals all of its signed contents, potentially exposing more personal information than the interaction requires.
R16.1. Data Minimization at Issuance
Issuers can mitigate over-disclosure up front by encoding only the attributes essential to a document's purpose, and ecosystems that require minimal disclosure at presentation time can consider complementary credentials in other forms.
R16.2. Do Not Use Optical Barcodes When Selective Disclosure is a Requirement
Because the optical barcode carries a static signature over a fixed field set, selective disclosure at presentation time is not possible through this specification. The lack of a selective disclosure capability in a static barcode is acknowledged and accepted for the use cases this specification targets.
Affected Components: E2: Holder, E3: Verifier, O1: OpticalBarcodeCredential, O4: Generic Verifiable Credential Expressed as Barcode, S4: Physical Document
Threat Taxonomy: STRIDE (Information Disclosure)

3.2.17 T17. Cross-Verifier Linkage of the Holder

T17. Cross-Verifier Linkage of the Holder privacy

[Threat List]
The signed barcode value on a given document is static and identical every time it is presented. Distinct collaborating verifiers who scan the same document can use the unchanging credential bytes (and unique identifiers such as embedded status information) to persistently correlate and thereby link a holder's separate interactions into a single profile.
R17.1. Acknowledge Static-Value Linkability
A printed barcode is a fixed value and is therefore inherently linkable when presented repeatedly; this specification cannot make a static optical artifact unlinkable across verifiers. The linkability of a static barcode is acknowledged and accepted as a property of the optical medium.
R17.2. Limit Linkage, Retention and Sharing of Credentials by Verifiers
Deployments can limit retention and sharing of scanned credential data through policy and governance, and ecosystems needing presentation-time unlinkability can adopt complementary mechanisms.
Affected Components: E2: Holder, E3: Verifier, O1: OpticalBarcodeCredential, O4: Generic Verifiable Credential Expressed as Barcode, S4: Physical Document
Threat Taxonomy: STRIDE (Information Disclosure)

Dependency Threats

3.2.18 T18. Cryptographically Relevant Quantum Computer Breaks ECDSA

T18. Cryptographically Relevant Quantum Computer Breaks ECDSA security

[Threat List]
The authenticity and integrity guarantees of credentials signed with the ecdsa-xi-2023 cryptosuite or other ECDSA-based Data Integrity cryptosuites rely on non-compromise of the ECDSA signature scheme. A sufficiently powerful cryptographically relevant quantum computer (CRQC) could forge ECDSA signatures without the issuer's private key and/or allow for direct key compromise.
R18. Algorithm Agility and Post-Quantum Migration Planning
Deployers monitor post-quantum signature standardization and rely on the cryptosuite-based, algorithm-agile design so that signature suites can be swapped without redesigning the encoding pipeline. Issuers plan migration timelines that account for the long validity periods of physical documents. Generic defenses against Verifiable Credential forgery or signing key compromise such as the publication of indexed hash witness lists can also be applied to mitigate the quantum threat.
Affected Components: E1: Issuing Authority, E3: Verifier, O1: OpticalBarcodeCredential, O2: Optical Data Bytes (xi), O4: Generic Verifiable Credential Expressed as Barcode, P1: Credential Creation and Signing, P4: Proof Verification
Threat Taxonomy: STRIDE (Tampering)

3.2.19 T13. Quishing via Malicious Barcode Injection

T13. Quishing via Malicious Barcode Injection security

[Threat List]
A verifier expects to scan a Verifiable Credential Barcode (VCB) but is presented with a barcode that is not a VCB and is instead crafted to hijack the interaction. Because the verifier's pipeline must process untrusted optical input before and during verification, the malicious payload can target any external technologies the verifier depends on, such as the optical barcode scanner and decoder, the JSON-LD and CBOR-LD processors (through malformed, deeply nested, or term-confusing input), the HTTP client (by inducing requests to attacker-controlled endpoints via fields such as terseStatusListBaseUrl or verificationMethod, enabling server-side request forgery, phishing, or tracking), and the cryptographic hardware or software. A defect anywhere in this chain can be exploited even though no valid VCB is ever involved.
R13. Treat Scanned Barcodes as Untrusted Across the Whole Pipeline
Verifier implementations treat scanned bytes as untrusted at every stage with hardened, bounded decoding that fails closed on malformed input and an allowlist so that key resolution and status requests reach only pre-configured trusted hosts rather than URLs taken from the scanned payload. Processing is isolated, and no scanned data is surfaced or acted upon until a valid VCB proof from a trusted issuer has been confirmed.
Affected Components: P3: Barcode Scan and Decode, P4: Proof Verification, F3: Resolve Verification Method, F4: Fetch Status List, S2: Status List Store, C3: Verifier System, E3: Verifier
Threat Taxonomy: STRIDE (Elevation of Privilege)

3.2.20 T22. Biometric Falsification

T22. Biometric Falsification security safety

[Threat List]
Where the connection between a holder and a credential relies on biometric data such as a facial image, that biometric can itself be cloned or replayed. Images of individuals are easy to copy and present, so a verifier or an automated check that relies on such a biometric can be induced to register a false positive, undermining defenses such as the three-way match. This weakness is inherited from the biometric technologies themselves rather than introduced by this specification.
R22.1. Replay-Resistant, Multi-Factor Biometric Verification
Where biometric checks is used, verifiers employ checks resistant to replay and presentation attacks (for example, liveness detection and/or trained human review); avoid relying on a single easily-cloned modality; and combine biometric evidence with other signed identifying attributes carried by the credential.
R22.2. Do Not Assume Infallibility of Biometric Verification
Even when R22.1 is used, there is residual risk that sufficiently advanced attacks against a biometric defeat the check. This risk is acknowledged as inherited from the biometric dependency.
Affected Components: E2: Holder, E3: Verifier, O1: OpticalBarcodeCredential, O4: Generic Verifiable Credential Expressed as Barcode, P5: Identity and Attribute Cross-Check, S4: Physical Document
Threat Taxonomy: STRIDE (Spoofing)

3.2.21 T19. Compromise of the Issuer's Signing Key

T19. Compromise of the Issuer's Signing Key security

[Threat List]
The Verifiable Credential Barcode trust model depends on the secrecy of the issuing authority's private signing key held in the issuer key store. An attacker who obtains that key can mint valid credentials over any claims they choose, producing fraudulent documents that pass verification indistinguishably from genuine documents.
R19. Protect Keys and Enable Rapid Revocation and Rotation
Issuers generate and use signing keys within hardware security modules, enforce strict access control around the key store, and monitor for misuse. On suspicion of compromise, the affected verification method is rotated and removed from verifier trust stores, and documents signed by the compromised key are revoked or suspended through the status list. Defensive techniques for Verifiable Credential key compromise and forgery - such as the publication of indexed hash witness lists - can also be applied.
Affected Components: E1: Issuing Authority, O1: OpticalBarcodeCredential, O4: Generic Verifiable Credential Expressed as Barcode, P1: Credential Creation and Signing, P6: Status Check, S1: Issuer Key Store, S3: Verifier Trust Store
Threat Taxonomy: STRIDE (Spoofing)

3.2.22 T20. Spoofing of Key Resolution and/or Key Management

T20. Spoofing of Key Resolution and/or Key Management security

[Threat List]
To check a proof, the verifier obtains the issuer's key material from wherever the verificationMethod points, such as a did:web identifier backed by DNS and a web server. An attacker who controls or redirects where keys are made available — through domain hijacking, DNS subversion, web-host compromise, or weaknesses in the issuer's key management and publication practices — can cause the verifier to validate attacker-signed credentials of either kind as if they came from the legitimate issuer.
R20.1. Pin Trust Anchors
Verifiers pin trusted issuer keys in the trust store rather than trusting whatever a live resolution returns, and treat unexpected key changes as cause to decline pending out-of-band confirmation.
R20.2. Govern Key Management
Issuers harden the infrastructure they use to publish their keys and adopt clear key-management governance such as defined authoritative key locations, documented provenance, and routine rotation.
Affected Components: F3: Resolve Verification Method, P4: Proof Verification, S3: Verifier Trust Store, E1: Issuing Authority, E3: Verifier
Threat Taxonomy: STRIDE (Spoofing)

3.2.23 T21. Confusion between Base-Encoding and Multibase Header

T21. Confusion between Base-Encoding and Multibase Header interoperability security

[Threat List]
Before reaching a barcode, a credential of either kind is compressed with CBOR-LD and then character-encoded according to rules that are defined per credentialSubject type. A mismatch between what the document manufacturer encoded and what the verifier assumes for that type — such as a missing prefix, an unexpected header, a wrong base alphabet, or the rules for a different subclass applied incorrectly — causes the verifier to decode different bytes than were signed, producing failures or, in adversarial cases, decoding ambiguities that can be exploited.
R21. Strict, Convention-Conformant Encoding and Decoding
Implementations follow the character-encoding requirements of the specific credentialSubject type exactly as defined in the specification that defines that type. Verifiers determine the expected encoding from the document and barcode formats, validate the expected prefix and header before decoding, and reject inputs that do not conform, so that the bytes verified are unambiguously the bytes that were signed.
Affected Components: E3: Verifier, E4: Document Manufacturer, O1: OpticalBarcodeCredential, O4: Generic Verifiable Credential Expressed as Barcode, P2: CBOR-LD Compression and Encoding, P3: Barcode Scan and Decode, S4: Physical Document
Threat Taxonomy: STRIDE (Tampering)

4. Contributing

This threat model is maintained alongside the Verifiable Credential Barcodes specification. Feedback, bug reports, and proposed additions are welcome via the issue tracker.