Background and Motivation

Global supply chains are among the most complex information systems humans operate. They span hundreds of organizations, dozens of jurisdictions, and thousands of individual product movements per day. Despite this complexity, the underlying data infrastructure remains fragmented: proprietary formats, bilateral EDI agreements, and centralized intermediary platforms are the norm rather than the exception.

The GS1 [[EPCIS]] standard, widely adopted across retail, healthcare, and logistics, provides a common vocabulary for supply chain events — captures of who did what to which item, where, and when. However, EPCIS defines what to record, not how to prove it. A receiving party cannot cryptographically verify that an EPCIS record was created by an authorized party, has not been tampered with, or corresponds to any real-world act of authority.

Simultaneously, the W3C Verifiable Credentials Data Model and [[DID-CORE]] provide a mature, widely deployed infrastructure for cryptographically signed, decentralized identity. These technologies have been adopted in digital credentials for education, healthcare records, and government identity, but have not yet been systematically applied to supply chain event data.

Regulatory pressure is accelerating the need. The US [[DSCSA]] mandates electronic, interoperable tracing of prescription drug products across the entire pharmaceutical distribution chain by 2023. The EU [[EUDR]] requires due diligence documentation for commodities associated with deforestation. The EU [[EU-BEV]] requires battery passport data covering the full material supply chain. These regulations require auditable, tamper-evident records — a property EPCIS alone cannot provide.

The Verifiable Supply Chain (VSC) framework addresses this gap by defining how [[EPCIS]] events can be represented as [[VC-DATA-MODEL]] credentials, binding event data to the issuing party's [[DID-CORE]] identifier and enabling cryptographic verification across organizational boundaries without requiring a shared central database.

Problem Statement

Current supply chain data systems exhibit three structural deficiencies that VSC is designed to address:

Fragmentation

No standard mechanism exists to exchange verifiable supply chain event records across organizational boundaries in a vendor-neutral way. Point-to-point integrations and proprietary platforms create data silos that prevent end-to-end visibility (see [[ISO28000]] Section 4.2 on supply chain security risk assessment).

Lack of verifiability

EPCIS provides rich event semantics but contains no native mechanism for a receiver to verify the identity of the asserting party, the integrity of the record, or the authority of the issuer to make the claimed assertion. A well-formed EPCIS document is indistinguishable from a fabricated one without out-of-band authentication mechanisms.

Regulatory non-compliance risk

Regulations including [[DSCSA]], [[EUDR]], and [[EU-BEV]] require auditable, tamper-evident records of product provenance and chain of custody. Existing data systems cannot satisfy these requirements without significant bespoke engineering, creating compliance risk for supply chain participants.

The VSC Approach

VSC addresses the deficiencies identified in Problem Statement by:

• Preserving EPCIS semantics: The Event-to-Credential Mapping is a normative, lossless transformation. All EPCIS event fields (event type, temporal context, business context, product identifiers, read points) are preserved. The resulting Verifiable Credential is a superset of the source EPCIS event.
• Binding identity to events: Each event credential is signed by the asserting Supply Chain Actor using a [[DID-CORE]] identifier. Verifiers can resolve the DID to retrieve the public key and verify the signature without contacting the issuer.
• Enabling selective disclosure: Using [[VC-DATA-MODEL]] mechanisms (e.g., [[BBS-2023]] proofs or [[SD-JWT]]), holders can reveal only the event fields required by a given verification context, protecting commercially sensitive data while satisfying regulatory requirements.
• Supporting chain-of-custody reconstruction: Individual event credentials can be linked by reference, enabling a verifier to reconstruct the full custody chain from issuance through delivery.
• Aligning with existing community work: VSC builds on [[TRACEABILITY-V1]], [[TRACEABILITY-INTEROP]], and [[UNTP]], maximizing reuse of existing credential vocabularies and interoperability profiles.

VSC does not require distributed ledger technology. DID methods backed by web infrastructure (e.g., did:web) are explicitly supported and are expected to be the dominant deployment pattern for enterprise supply chains. Ledger-based DID methods MAY be used but are not privileged.

Document Conventions

Requirement identifiers take the form REQ-Xn where X is F (functional) or NF (non-functional) and n is a two-digit sequence number. Every requirement includes a rationale, a testability statement, and normative references to inform conformance test development.

Use case identifiers take the form UC-n. Each use case cross-references the requirements it motivates.

Defined terms appear in small-caps style and are linked on first use in each section.

Document Structure

• Conformance — conformance language
• Scope — in-scope and out-of-scope topics
• Terminology — normative definitions
• Conceptual Architecture — conceptual model and roles
• Related Work — alignment with existing standards
• Use Cases — motivating scenarios with actors, flows, and failure modes
• Requirements — functional and non-functional requirements with testability statements
• Security Considerations — threat model and mitigations
• Privacy Considerations — privacy considerations
• Accessibility Considerations — accessibility considerations
• Internationalization Considerations — internationalization considerations
• Future Work — planned follow-on work
• Contributing — contributor guidance

In Scope

• Event-to-credential mapping: A normative, field-level mapping from each [[EPCIS]] event type (ObjectEvent, AggregationEvent, TransformationEvent, TransactionEvent, AssociationEvent) to a corresponding [[VC-DATA-MODEL]] credential schema.
• Identity binding: Specification of how Supply Chain Actors are identified using [[DID-CORE]] and how their authority to assert events for a given business context is established.
• Verification model: Rules for verifying the integrity, authenticity, and provenance of Supply Chain Events represented as Verifiable Credentials.
• Selective disclosure: Mechanisms allowing holders to reveal only a subset of event fields to a given verifier.
• Event linking: Conventions for chaining event credentials to reconstruct provenance and custody histories.
• Interoperability requirements: Normative requirements enabling VSC-conformant implementations from different vendors to exchange and verify event credentials without bilateral agreements.
• Use cases and requirements: Motivating scenarios grounded in regulatory obligations and industry practice, with corresponding testable requirements.

Out of Scope

• Credential transport protocols: How credentials are transmitted between parties (e.g., HTTPS, messaging queues, DIDComm) is out of scope. Implementers SHOULD follow [[TRACEABILITY-INTEROP]] for HTTP-based exchange.
• Storage and persistence: Database schemas, file formats, and retention policies for event credentials are implementation-specific.
• Business workflow automation: Rules engines, approval workflows, and ERP integrations are out of scope.
• Identity governance: Frameworks for issuing, revoking, or governing organizational DID identifiers are defined externally (e.g., by sector trust frameworks).
• Distributed ledger technology: VSC does not define or require any specific DLT, blockchain, or consensus mechanism.
• Physical IoT and sensor integration: How physical readings (temperature logs, GPS coordinates) are captured and bound to credentials is out of scope, though VSC credentials can carry such data.

Roles

VSC defines three primary roles, aligned with [[VC-DATA-MODEL]] Section 1.3. In supply chain deployments these roles are typically held by different organizations.

Issuer

A Supply Chain Actor that asserts a Supply Chain Event and creates the corresponding Verifiable Credential. The issuer signs the credential using the cryptographic key material associated with its [[DID-CORE]] identifier. The issuer is responsible for the accuracy of the event claims and for maintaining Credential Status information.

Holder

An entity that receives and stores Verifiable Credentials and may assemble them into Verifiable Presentations for submission to verifiers. In supply chain contexts, holders are typically downstream trading partners, freight forwarders, customs agents, or regulatory bodies. A holder may also be an issuer (e.g., a manufacturer issues a provenance credential and later presents it to a retailer).

Verifier

An entity that accepts Verifiable Credentials or Presentations and validates their integrity, authenticity, and policy compliance. Verifiers check the issuer's DID resolution, cryptographic signature, credential status, and — where a Trust Framework is in scope — whether the issuer is authorized to assert events in the claimed business context.

EPCIS Event Types and VSC Mapping

[[EPCIS]] v2.0 defines five event types. VSC requires a normative credential schema for each:

The schema names in the table above are placeholders. Normative schema identifiers and JSON-LD context URIs will be defined in the VSC Core Data Model specification.

Object Model

The core objects in VSC are:

Supply Chain Event

The occurrence being recorded, conforming to one of the five [[EPCIS]] event types. The event carries the event-time, record-time, business step, disposition, read point, business location, and EPC or product class lists.

Verifiable Credential

The cryptographically signed representation of the event. The credential's issuer is the asserting Supply Chain Actor's DID. The credentialSubject contains the EPCIS Event fields. The credential carries a credentialStatus endpoint for revocation checks.

Event Chain

A directed graph of Verifiable Credentials linked by credential identifier references. The chain enables reconstruction of provenance or custody histories.

Verifiable Presentation

A holder-assembled collection of event credentials (and optionally other credentials, e.g., certification credentials) submitted to a verifier for a specific verification context such as customs clearance or regulatory audit.

Information Flow

The canonical VSC information flow is:

Step 4 (verification) may fail if the DID cannot be resolved, the signature is invalid, the credential has been revoked, or the issuer is not in the required issuer registry. Verifier behavior in each failure case is defined in Requirements.

UC-01: Raw Material Provenance for Deforestation Due Diligence

Regulatory driver

EU Deforestation Regulation [[EUDR]], Article 3 — operators must ensure commodities are deforestation-free and legally produced.

Actors

Raw material supplier (issuer); first processor (holder/issuer); EU market operator / importer (holder/verifier); EU competent authority (verifier).

Preconditions

Supplier holds a did:web identifier registered with a sector trust framework. Importer has declared a reference DID set of accepted supplier issuers.

Nominal flow:

1. A soy supplier in Brazil harvests a batch and records an ObjectEvent in their EPCIS system with the batch EPC, harvest timestamp, geo-coordinates of the plot, and species information.
2. The supplier's VSC-conformant software applies the Event-to-Credential Mapping and signs a VscObjectEventCredential, with an extension for geospatial data and the relevant commodity type.
3. The credential includes a reference to the supplier's deforestation-free certification credential (issued by a certification body) as a linked credential.
4. The signed credential is transmitted to the first processor (crusher), who stores it and issues their own ObjectEvent credential for the crushing step, referencing the supplier's credential.
5. The EU importer requests a Verifiable Presentation from the processor containing the full Event Chain from harvest to processed shipment.
6. The importer's system verifies each credential in the chain: DID resolution, signature, revocation status, and presence in the sector Issuer Registry.
7. The importer submits the presentation to the EU Information System for EUDR due diligence statements.

Failure modes:

• Missing link: The processor's credential does not reference the supplier's credential. The importer's system SHOULD detect the gap in the Event Chain and flag the presentation as incomplete.
• Revoked certification: The certification credential referenced in step 3 has been revoked. The verifier MUST treat the linked certification as invalid; the event credential itself remains valid but the claim of deforestation-free status is unsupported.
• DID not resolvable: The supplier's DID cannot be resolved. The verifier MUST NOT accept the credential and SHOULD surface a specific error indicating DID resolution failure.

Requirements motivated: REQ-F01, REQ-F02, REQ-F03, REQ-F04, REQ-F07, REQ-NF03.

UC-02: Pharmaceutical Custody Transfer (DSCSA Compliance)

Regulatory driver

US Drug Supply Chain Security Act [[DSCSA]] Section 582 — electronic, interoperable product tracing at the package level by November 2023.

Actors

Manufacturer (issuer); wholesaler (holder/issuer); dispenser / pharmacy (holder/verifier); US FDA (verifier).

Preconditions

All actors are registered in an FDA-recognized DSCSA authorized trading partner registry that maps GLN identifiers to DIDs.

Nominal flow:

1. The manufacturer applies a serialized SGTIN (GS1 item-level identifier) to each drug package and records an ObjectEvent (bizStep: commissioning) as a signed VSC credential.
2. At shipping, the manufacturer records an ObjectEvent (bizStep: shipping) credential for the pallet SSCC, referencing the commissioned item credentials via AggregationEvent.
3. The wholesaler records an ObjectEvent (bizStep: receiving) and issues their own credential referencing the manufacturer's shipping credential by its credential identifier.
4. The process repeats at each custody transfer (repackaging, onward shipment, final delivery to pharmacy).
5. The pharmacy's dispensing system requests a Verifiable Presentation covering the product's full custody chain before dispensing.
6. The presentation is verified: each credential's signature, issuer DID, revocation status, and authorized trading partner registration are confirmed.
7. In the event of a recall, the manufacturer revokes the relevant event credentials. Verifiers checking revocation status MUST reject these credentials and SHOULD surface a specific recall indicator.

Failure modes:

• Salami injection attack: An adversary inserts a fabricated custody transfer credential between two legitimate steps. The verifier MUST detect that the fabricated credential's issuer is not in the authorized trading partner registry.
• Credential replay: A credential valid for one shipment is replayed against a different shipment. Credentials SHOULD carry a transaction-scoped identifier binding them to a specific shipment context.
• Revocation propagation delay: The recall is issued but the pharmacy has cached a stale revocation status. Implementations SHOULD define maximum cache lifetimes for revocation status (see REQ-F08).

Requirements motivated: REQ-F01, REQ-F02, REQ-F03, REQ-F04, REQ-F05, REQ-F08, REQ-NF01.

UC-03: Automated Customs Clearance

Regulatory driver

WCO SAFE Framework; EU Union Customs Code Article 163 (supporting documents requirement).

Actors

Exporter (issuer); freight forwarder (holder); customs authority (verifier).

Preconditions

Customs authority publishes a trusted issuer registry of accepted certification and origin credential issuers.

Nominal flow:

1. The exporter assembles a Verifiable Presentation containing: an origin credential (country of origin declaration), an inspection credential (phytosanitary or product safety), and transport event credentials covering the journey from factory to port.
2. The presentation uses Selective Disclosure to reveal only the fields required by customs (e.g., tariff codes, declared value, origin) without exposing commercially sensitive pricing or supplier identity data.
3. The freight forwarder's system submits the presentation to the customs authority's automated clearance API.
4. The customs system verifies each credential against its trusted issuer registry, checks signatures and revocation status, and runs automated rules (e.g., sanctions screening, tariff classification validation).
5. Clearance is granted or a referral for physical inspection is issued, with the verification result recorded.

Failure modes:

• Partial presentation: The presentation is missing the inspection credential. The customs system SHOULD surface a specific missing-credential error rather than a generic verification failure.
• Selective disclosure proof failure: A malformed [[BBS-2023]] or [[SD-JWT]] proof is submitted. The verifier MUST reject the credential and SHOULD indicate the proof type and failure reason.

Requirements motivated: REQ-F05, REQ-F06, REQ-F07, REQ-NF02, REQ-NF03.

UC-04: Battery Passport for EV Supply Chain

Regulatory driver

EU Battery and Electric Vehicle Regulation [[EU-BEV]], Article 77 — battery passport required for EV batteries from February 2027.

Actors

Cathode material supplier (issuer); cell manufacturer (holder/issuer); battery pack manufacturer (holder/issuer); vehicle OEM (holder/verifier); EU market surveillance authority (verifier); end consumer (verifier).

Preconditions

Battery identifier issued using GS1 Digital Link [[GS1-DIGITAL-LINK]] scheme resolving to the battery passport.

Nominal flow:

1. The cathode material supplier issues ObjectEvent credentials for each batch, including cobalt and lithium provenance data, mine location, and responsible sourcing certification references.
2. The cell manufacturer issues TransformationEvent credentials mapping input material batches (cathode, anode, electrolyte) to output cell identifiers.
3. The battery pack manufacturer assembles cell credentials into AggregationEvent credentials and issues a composite battery passport presentation referencing all upstream event credentials.
4. The vehicle OEM's system verifies the full passport presentation and stores it linked to the Vehicle Identification Number (VIN).
5. A consumer or recycler can scan a GS1 Digital Link QR code on the battery, resolve the battery passport, and verify the event chain.

Failure modes:

• TransformationEvent linking gap: The cell manufacturer fails to reference upstream cathode credentials. The OEM system SHOULD flag the TransformationEvent as having unverified input provenance.
• Performance at scale: A battery contains thousands of cells; each cell may have multiple upstream event credentials. Verifier performance MUST NOT degrade unacceptably at this scale (see REQ-NF01).

Requirements motivated: REQ-F01, REQ-F04, REQ-F06, REQ-NF01, REQ-NF04.

UC-05: Product Recall Propagation

Regulatory driver

General Product Safety Regulation (EU) 2023/988; US CPSC recall authority.

Actors

Manufacturer (issuer, revocation authority); downstream holders; regulators; retailers.

Preconditions

All event credentials for the affected product batch are known and the manufacturer controls the credential status service.

Nominal flow:

1. A safety defect is identified. The manufacturer's system identifies all event credentials linked to the affected batch using batch-level identifiers.
2. The manufacturer revokes the ObjectEvent credential for the affected batch via the Credential Status service. The revocation is cryptographically signed by the manufacturer's DID.
3. Any downstream verifier checking an affected credential against the status service receives a revoked status and MUST reject the credential.
4. Downstream holders receive a recall notification (out-of-band) and can verify the revocation independently by resolving the credential status.
5. The regulator can independently verify the breadth of the recall by querying which credentials issued by the manufacturer have been revoked for the affected lot.

Requirements motivated: REQ-F03, REQ-F08, REQ-NF01.

UC-06: Regulatory Audit Trail

Regulatory driver

General requirement across regulated industries (pharma, food, aerospace) for multi-year auditable records.

Actors

Multiple supply chain actors (issuers/holders); sector regulator (verifier).

Preconditions

Credentials have been issued and held for up to 10 years. Some issuer DIDs may have changed or been retired.

Nominal flow:

1. A regulator issues a data request to a holder for all event credentials related to a specific product class over a 5-year period.
2. The holder assembles a Verifiable Presentation with selective disclosure applied to protect third-party business data.
3. The regulator's system verifies each credential. For credentials where the issuer DID is no longer resolvable, the system checks a historical DID log maintained by the sector trust framework.
4. The audit result is recorded as a signed audit event credential by the regulator, completing the audit trail.

Failure modes:

• Historical DID resolution: If a DID was deactivated, verifiers MUST have a mechanism to obtain the historical public key material needed to verify credentials signed before deactivation (see REQ-NF05).

Requirements motivated: REQ-F05, REQ-F07, REQ-NF02, REQ-NF05.

Requirements Summary

Functional Requirements

Non-Functional Requirements

Threat Model

VSC threats are analyzed at the four primary trust boundaries: (1) issuer key material, (2) event credential content, (3) event chain linkage, and (4) issuer registry integrity.

Fraudulent Event Injection (T-01)

A malicious actor may attempt to inject fabricated Supply Chain Events by creating validly signed credentials from an authorized DID for events that never occurred, or from an unauthorized DID. VSC implementations MUST verify issuer identity and authority as specified in REQ-F03 and REQ-F07. Verification SHOULD include checking the issuer's DID against the Issuer Registry referenced in the credential or the verifier's trust framework configuration.

Physical-world corroboration (IoT sensor data, GPS timestamps, third-party inspection certificates referenced as linked credentials) provides additional assurance that event credentials correspond to actual physical events. VSC implementations SHOULD support referencing corroboration evidence as linked credentials in the credential evidence property.

Credential Replay (T-02 / T-01)

A valid Verifiable Credential for one shipment may be replayed in a presentation for a different shipment, or a credential may be presented outside its intended time window.

Implementations SHOULD include one or more of the following context-binding mechanisms to mitigate replay:

• Presentation challenge: Verifiers SHOULD provide a cryptographic challenge nonce that the holder must include in the Verifiable Presentation's proof, binding the presentation to the specific verification session. This is supported by [[VC-DATA-MODEL]] Section 6.3.
• Audience binding: Credentials SHOULD include an audience or equivalent field identifying the intended verifier DID, preventing use of the credential by a different verifier.
• Temporal constraints: Credentials MUST include validFrom and SHOULD include validUntil values. Verifiers MUST reject credentials outside their validity period.

Broken Custody Chains (T-02)

A verifier may receive an Event Chain from which one or more credentials have been omitted — either accidentally (data loss) or deliberately (to conceal an unauthorized custody transfer). VSC-conformant verifiers MUST detect gaps in event chains and signal non-verifiability with specific error codes as defined in REQ-F09. Implementations SHOULD treat a broken chain as a verification failure unless the verification context explicitly permits incomplete chains (e.g., for partial audit queries).

Issuer Key Compromise

If an issuer's DID private key is compromised, an adversary can issue fraudulent event credentials indistinguishable from legitimate ones. Issuers MUST implement key management practices consistent with [[NIST-SP800-53]] IA-5, including:

• Hardware Security Module (HSM) storage for signing keys;
• Key rotation schedules with DID Document update;
• Revocation of all credentials issued after suspected compromise.

The VSC Trust Framework specification SHOULD define sector-specific key management requirements and mandatory incident response procedures for key compromise events.

Commercially Sensitive Supply Chain Data

Supply chain event credentials frequently contain information that is commercially sensitive: supplier identities, production volumes, pricing signals embedded in batch sizes, and logistics routing. Disclosing this information beyond the minimum required by a verification context:

• Violates [[GDPR]] Article 5(1)(c) data minimization principle for EU-based participants;
• May constitute trade secret misappropriation under applicable national law; and
• Undermines commercial trust between supply chain participants, reducing adoption of VSC.

VSC implementations MUST support selective disclosure (REQ-F05) and SHOULD use pairwise DIDs (REQ-NF02) to minimize information disclosure.

Credential Linkability

If all credentials issued by a given Supply Chain Actor use the same long-lived DID, a verifier can correlate all events asserted by that actor across time and contexts. This enables surveillance of supply chain participants' business activity beyond the scope of individual verification requests. Implementations SHOULD use pairwise DIDs per trading relationship, or short-lived credential identifiers, to limit cross-context correlation. Zero-knowledge proof mechanisms (e.g., [[BBS-2023]]) SHOULD be preferred for contexts where correlation risk is high.

Personal Data in Event Credentials

Some supply chain events may involve personally identifiable information (e.g., the name of a quality inspector, a driver's identity, or patient-level pharmaceutical dispensing data). VSC credential schemas MUST NOT require PII fields beyond the regulatory minimum. Where PII is required by regulation, issuers MUST apply selective disclosure to prevent disclosure of PII to parties who do not require it, consistent with [[GDPR]] Article 25 and analogous data protection frameworks.