Introduction: Beyond the Product Label

When a consumer scans a QR code on a product, they see information: materials, origin, sustainability data. What they don't see is the infrastructure that makes it trustworthy and secure.

Beneath that simple scan lies a sophisticated trust architecture built on three pillars:

This document explains how these technologies converge to create a unified approach to product identity infrastructure, and why EPCIS serves as the universal glue layer that ties everything together.

The RFID Origin Story: Why EPCIS Exists

To understand why EPCIS matters, we need to understand the problem it was designed to solve.

The Data Integration Nightmare

1970s-1990s: The Barcode Revolution

Barcodes revolutionized point-of-sale operations but had a fundamental limitation: they identified product types, not individual items. Every can of soup with the same barcode was indistinguishable from every other can.

1990s-2000s: The RFID Promise

Radio-Frequency Identification (RFID) promised item-level visibility. Each product could have a unique identifier, enabling:

• Real-time inventory tracking
• Anti-counterfeiting at the item level
• Automated supply chain operations

But RFID created a new problem: data integration chaos. Different RFID systems used different data formats. A tag read at a manufacturer's warehouse couldn't be meaningfully combined with a tag read at a retailer's distribution center.

The Gap: How do you capture what happened to products when the identification technology keeps changing?

MIT Auto-ID Center (1999-2003)

The MIT Auto-ID Center was founded at MIT in 1999 to address this challenge. The consortium drew in researchers, partner universities, and dozens of sponsor companies from retail, consumer goods, and logistics.

Their key insight: RFID needs a common language for describing events, independent of the specific hardware or protocol used.

Timeline:

Technology-Agnostic by Design

Here's what makes EPCIS so valuable: it was designed to be technology-agnostic from the very beginning.

While RFID made the need for such a standard undeniably clear, organizations still working with barcodes recognised the same potential. The event model was intentionally designed to work regardless of the underlying identification technology.

The standard's RFID-oriented origins didn't constrain its adoption: EPCIS is in use today in deployments that rely entirely on barcodes, or on barcodes in combination with RFID. The same event model works for any auto-ID technology — barcodes, RFID, QR codes, NFC, or IoT sensors.

EPCIS 2.0 continued this tradition by bridging to GS1 Digital Link and full 2D code support - again, not by coincidence but by intentional design to meet the evolving needs of global supply chains.

Why the standard matters today

RFID adoption keeps accelerating — pushed by retailer mandates for item-level tagging, by item-level inventory and anti-shrinkage programmes, and by the spread of battery-free sensor tags that report temperature, humidity, and other supply-chain conditions. Each new wave of carriers and sensors lands in the same event model.

That's the point: as auto-ID technologies evolve, organisations need one event model that works regardless of the data carrier. EPCIS is that model.

2D Codes: The Consumer Bridge

While RFID excels in logistics and warehouses, 2D codes provide the essential bridge to consumers.

Why Both Technologies Matter

QR Code vs DataMatrix

Both 2D code types can carry GS1 Digital Link URIs, but they serve different use cases:

Use case differentiation:

• QR Code: Consumer scans DPP on product packaging, marketing campaigns, retail displays
• DataMatrix: Small electronics components, pharmaceutical vials, medical devices, PCB marking
• Both: Encode GS1 Digital Link URIs that resolve to the same product information

The Key Principle

flowchart LR
    qr["Consumer QR scan"] --> dl["GS1 Digital Link URI"]
    dm["DataMatrix in factory"] --> dl
    rfid["RFID at warehouse dock"] --> dl
    nfc["NFC at retail checkout"] --> dl
    dl --> ev["EPCIS Events"]

EPCIS doesn't care HOW you identified the product. It captures WHAT happened.

This technology-agnostic design is why a system built in 2007 for RFID handles 2D codes, NFC, and IoT sensors without architectural changes.

Industry 4.0 and Web 3.0: The Convergence

Two major technology movements are converging on the same infrastructure needs that EPCIS addresses.

Industry 4.0 (Smart Manufacturing)

Industry 4.0 refers to the fourth industrial revolution: cyber-physical systems, IoT, and data-driven manufacturing.

Characteristics:

• RFID/IoT sensors on production lines generating real-time events
• Digital twins synchronized with physical products
• Predictive maintenance from sensor data
• Cyber-physical systems: physical products with digital identities

EPCIS Connection: The "How" dimension (sensor data) in EPCIS 2.0 was designed precisely for this use case. Temperature, humidity, location, and other sensor readings are captured as part of the event model.

Web 3.0 (Decentralized Web)

Web 3.0 encompasses technologies for decentralized trust and self-sovereign identity.

Core concepts:

• DIDs: Self-sovereign identifiers (no central authority required)
• VCs: Cryptographically verifiable claims
• Selective disclosure: Privacy-preserving data sharing
• Trustless verification: Verify without trusting the data provider

EPCIS Connection: EPCIS 2.0's JSON-LD format and Web URI identifiers align with the semantic web foundation of Web 3.0 technologies.

Where They Meet

flowchart TD
    i4["<b>Industry 4.0</b><br/>RFID / IoT sensors<br/>real-time tracking<br/>digital twin sync<br/>predictive analytics<br/>smart-factory events"]
    w3["<b>Web 3.0</b><br/>DIDs for product identity<br/>VCs for attestation<br/>selective disclosure<br/>trustless verification<br/>decentralized trust"]
    epcis["<b>EPCIS 2.0 — the glue</b><br/>tech-agnostic events<br/>JSON-LD data model<br/>sensor data (How)<br/>Web URI identifiers<br/>5 dimensions: What · When · Where · Why · How"]
    i4 --> epcis
    w3 --> epcis

Practical example:

1. Smart factory: RFID tag on component triggers EPCIS event
2. EPCIS event updates digital twin representation
3. Quality test passes → Verifiable Credential issued
4. Downstream buyer scans QR → sees selective disclosure based on authorization

UN Transparency Protocol (UNTP)

The UN Transparency Protocol is a UN/CEFACT initiative to enable interoperable digital credentials for global trade.

Background

UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) has developed standards for international trade for decades. UNTP is their approach to supply-chain transparency in the digital age.

UNTP Goals

UNTP aims to:

• Enable interoperable sustainability credentials across borders
• Provide common vocabulary for product footprint data
• Support verifiable claims about origin, materials, and environmental impact
• Remain technology-neutral while providing clear implementation patterns

OpenEPCIS Alignment

OpenEPCIS aligns with UNTP through semantic property mappings:

These mappings use owl:equivalentProperty declarations, enabling data to flow between systems without loss of semantic meaning.

For detailed mapping information, see the Interoperability Guide.

Decentralized Identifiers (DIDs)

Decentralized Identifiers represent a fundamental shift in how we think about digital identity.

The Problem with Centralized Identifiers

Traditional identifiers depend on central authorities:

• Domain names require DNS registries
• Product codes require GS1 membership
• User accounts require platform operators

This creates:

• Single points of failure - Registry down = identifiers unusable
• Permission dependencies - Need approval to create identifiers
• Censorship vectors - Authorities can revoke identifiers

DID Structure

A DID is a URI that resolves to a DID Document containing verification methods and service endpoints:

did:method:identifier
│   │      │
│   │      └── Unique identifier within the method
│   └── DID method (defines resolution mechanism)
└── DID scheme

Example:

did:web:example.com:products:12345

This DID uses the web method and resolves to a DID Document hosted at example.com.

DIDs in Supply Chains

GS1 Digital Link Relationship

Currently, GS1 Digital Link provides resolver-based resolution:

https://id.gs1.org/01/09521141012345 → Resolves via GS1 infrastructure

DIDs provide decentralized resolution:

did:web:company.com:product:09521141012345 → Resolves via DID Document

The convergence: Organizations can use both approaches. GS1 Digital Link provides immediate compatibility with existing infrastructure, while DIDs enable decentralized verification when needed.

Verifiable Credentials (VCs)

Verifiable Credentials are the trust layer that makes claims about products and organizations cryptographically verifiable.

The Credential Model

VCs follow a three-party model:

flowchart LR
    issuer["<b>Issuer</b><br/>certifier · lab · auditor"]
    holder["<b>Holder</b><br/>manufacturer · brand · supplier"]
    verifier["<b>Verifier</b><br/>buyer · customs · consumer"]
    issuer -- "issues VC" --> holder
    holder -- "presents VC" --> verifier

Issuer — creates and cryptographically signs the credential. Holder — stores the credential and presents it when needed. Verifier — checks the credential's validity and the issuer's authority.

Why VCs Matter for Supply Chains

VC Types in Supply Chains

Conformity Credentials:

• Lab test results
• Certification assessments (ISO, organic, fair trade)
• Regulatory compliance attestations

Traceability Events:

• EPCIS events signed as VCs
• Chain of custody attestations
• Transformation records

Digital Product Passports:

• DPP as a comprehensive VC
• Contains product identity + sustainability data + supply chain history
• Issued by manufacturer, verified by anyone

Selective Disclosure: The Game Changer

Selective disclosure may be the most underestimated capability in this stack. It solves the fundamental tension between transparency and confidentiality.

The Problem: All-or-Nothing Doesn't Work

Traditional data sharing is binary: either you share everything or nothing.

Real business scenarios:

• A consumer wants to know if a product is sustainable; the manufacturer wants to surface the headline claim without naming individual suppliers downstream.
• Customs needs to verify origin and certification; the importer wants to keep tier-2 supplier identities and contract details out of the customs payload.
• A recycler needs full material composition for safe processing; the brand wants to surface that without disclosing the specific manufacturing recipe or tooling.

What Selective Disclosure Enables

With selective disclosure, the same credential can reveal different information to different requestors:

Technical Approaches

BBS+ Signatures: Prove specific claims from a signed credential without revealing the entire credential. A holder can prove "recycled content > 30%" without revealing the exact percentage.

Zero-Knowledge Proofs: Prove properties about values without revealing the values themselves. Prove "carbon footprint < 50 kg CO2e" without revealing it's actually 42.5 kg CO2e.

Derived Credentials: Create limited-scope credentials from full credentials for specific sharing contexts.

Real-World Implementation

flowchart TD
    qr["Same QR code on product"] --> auth["<b>Authorisation check</b><br/>who is scanning? · what role? · what context?"]
    auth --> consumer["Consumer app<br/>sustainability score, repair info"]
    auth --> customs["Customs system<br/>origin, certifications, HS codes"]
    auth --> recycler["Recycler portal<br/>material breakdown, disassembly"]
    auth --> auditor["Authorised auditor<br/>full credential, all data"]

Why This Is Underestimated

Most DPP discussions focus on what data to share. Selective disclosure answers the harder question: how to share different data with different parties from the same source.

This is the missing piece for enterprise adoption. Businesses won't participate in transparency initiatives if it means revealing trade secrets to competitors. Selective disclosure enables:

• Contextual authorization: Same QR code, different data based on who scans it
• Graduated trust: More access with stronger credentials
• Compliance without exposure: Prove compliance without revealing how

The Digital Twin Continuum

"Digital twin" has become a buzzword that obscures more than it illuminates. Let's demystify it.

What People Mean by "Digital Twin"

The term covers a spectrum of concepts:

DPP Is One Flavor

A Digital Product Passport is a specific regulatory flavor of digital twin:

• Mandated by ESPR (Ecodesign for Sustainable Products Regulation)
• Focused on sustainability and circularity data
• Accessed via data carriers (QR, NFC, RFID)
• Updated at key lifecycle events

The Spectrum

flowchart LR
    ds["<b>Product datasheet</b><br/>basic specs · one-time<br/>(marketing)"]
    dpp["<b>Digital Product Passport</b><br/>lifecycle data · event updates<br/>(compliance)"]
    cp["<b>Connected product</b><br/>operational data · periodic updates<br/>(service)"]
    dt["<b>Live digital twin</b><br/>continuous sync · real-time<br/>(operations)"]
    ds --> dpp --> cp --> dt

Static → real-time, increasing in data richness and update frequency.

Why Terminology Matters

Different audiences use different terms for overlapping concepts:

• Regulators talk about Digital Product Passports
• Manufacturers talk about digital twins
• IT vendors talk about connected products
• Sustainability teams talk about product footprints

They're all describing variations of the same infrastructure need: a digital representation of a physical product that can be accessed, updated, and verified throughout its lifecycle.

OpenEPCIS provides the event backbone that works across this entire spectrum.

EPCIS: The Universal Event Glue

EPCIS serves as the universal glue layer that connects all these technologies.

The Architecture

flowchart TD
    subgraph carriers["Physical data carriers"]
        bc["Barcode (1974)"]
        rfid["RFID at supply-chain scale (~1999)"]
        dm["DataMatrix (2000s)"]
        qr["QR (2010s)"]
        nfc["NFC (2020s)"]
        iot["IoT / BLE (future)"]
    end
    carriers --> events

    subgraph events["EPCIS 2.0 events — five dimensions"]
        what["<b>What</b><br/>product ID"]
        when["<b>When</b><br/>timestamp"]
        where["<b>Where</b><br/>location · GLN"]
        why["<b>Why</b><br/>business step"]
        how["<b>How</b><br/>sensor data"]
    end
    events --> apps

    subgraph apps["Application layer"]
        dpp["Digital Product Passport"]
        vc["Verifiable Credentials"]
        comp["Regulatory compliance<br/>(ESPR, DSCSA, …)"]
        twin["Digital twin systems"]
    end

Why EPCIS Is the Glue

The Five Dimensions

EPCIS captures events across five dimensions:

What: Product identifiers (GTIN, SGTIN, SSCC) When: Timestamp with timezone Where: Location identifiers (GLN, geo-coordinates) Why: Business context (bizStep, disposition) How: Sensor data (temperature, humidity, conditions)

The "How" Dimension (EPCIS 2.0)

EPCIS 2.0 added a place for sensor data on each event — temperature, humidity, location, whatever the auto-ID hardware reports. This enables:

• Cold-chain monitoring (a sensor reading attached to every receive event).
• Environmental-condition tracking across the supply chain.
• Battery-free sensor tags that harvest energy from the RFID reader and report on every read.
• Quality-assurance data captured at the point of the event rather than reconciled later.

Real Scenarios

The Key Insight

EPCIS doesn't care HOW you identify the product. It cares WHAT happened, WHEN, WHERE, WHY, and under what conditions (HOW).

This technology-agnostic design is why EPCIS scales from a barcode-only retailer to an RFID-heavy warehouse to an IoT-enabled smart factory.

The Complete Stack

Here's how all the technologies fit together:

flowchart TD
    L5["<b>5. Access — Selective disclosure</b><br/>who sees what, by role and context<br/>BBS+ signatures · ZK-proofs"]
    L4["<b>4. Credentials — Verifiable Credentials (VCs)</b><br/>certifications, conformity assessments<br/>cryptographic proof · issuer → holder → verifier"]
    L3["<b>3. Events — EPCIS 2.0</b><br/>what happened: tracking · tracing · transformation<br/>five dimensions · technology-agnostic"]
    L2["<b>2. Identity — GS1 identifiers + DIDs</b><br/>GTIN, GLN, SSCC for products / locations / shipments<br/>DIDs for organisations · GS1 Digital Link for resolution"]
    L1["<b>1. Physical — data carriers</b><br/>RFID · QR · DataMatrix · NFC · barcode · IoT sensors<br/>carrier-agnostic · future-proof"]
    L5 --> L4 --> L3 --> L2 --> L1

What This Stack Delivers

OpenEPCIS Position

Where OpenEPCIS Fits

OpenEPCIS provides the event layer (Layer 3 in the stack above) with a GS1-native architecture:

What OpenEPCIS Provides Today

Core Tools:

• EPCIS repository and API
• Format conversion (XML ↔ JSON-LD)
• Event hash generator (integrity verification)
• Test data generator

DPP Vocabulary:

• Battery DPP (EU Battery Regulation 2023/1542)
• Textile DPP (EU Sustainable Textiles Strategy)
• EUDR (EU Deforestation Regulation 2023/1115)
• Electronics DPP (Repairability, WEEE, energy efficiency)

Where the stack stands today

OpenEPCIS already ships the identity layer (GS1 identifiers + Digital Link), the event layer (EPCIS 2.0) and the credential transport layer (Keycloak OID4VCI / OID4VP / SIOPv2 — every tenant realm is a Verifiable Credential Issuer; every OID4VC-compliant wallet works as a holder; sd-jwt-vc is the lead format for selective disclosure). The named-credential layer — published credential schemas for EPCIS events and DPP attestations, the bridge that mints a VC the moment the underlying capture or save happens, UNTP Digital Conformity Credential compatibility, and a globally-scoped issuer trust list — is the work in flight on the roadmap.

The build order is deliberate. Identity and events are nailed down against GS1; the credential transport is open, wallet-agnostic protocol (OID4VC) instead of a proprietary stack; the named-credential layer on top is then a question of schema + pipeline rather than re-architecture.

Resources

Standards and Specifications

Core Standards:

• GS1 EPCIS 2.0 Standard - Event model specification
• GS1 Digital Link - Product identification and resolution
• W3C Verifiable Credentials Data Model - Credential structure
• W3C Decentralized Identifiers (DIDs) - DID specification

Trade Standards:

• UN Transparency Protocol (UNTP) - UN/CEFACT supply-chain transparency (moved to GitLab; the old GitHub repo is archived)
• ISO/IEC 19987 - EPCIS standard (ISO version)
• ISO/IEC 19988 - Core Business Vocabulary (ISO version)

OpenEPCIS Documentation

• EPCIS 2.0 Guide - Event model and dimensions
• Digital Product Passport - DPP implementation
• Interoperability Guide - UNTP and standards alignment
• DPP Resolution Flow - How QR scanning leads to DPP data

External Resources

Industry Context:

• MIT Auto-ID Center history - Origins of EPCIS
• GS1 EPCIS resources - Implementation guides
• RFID market analysis - Market data

Emerging Technologies:

• BBS+ Signatures - Selective disclosure cryptography
• did:web Method Specification - Web-based DIDs