⚙️ Structural Elements and Main Actors

The HTTP URI architecture connects physical products and digital data through a network of interoperable elements:

• Responsible Economic Operators (REOs)
• The EU‑Registry
• Validation and control engines
• Data carriers and scanning devices
• UID‑to‑URI transformation modules and digital link standards
• Resolvers, decentralized data repositories, and archives

👥 Responsible Economic Operator (REO)

The Responsible Economic Operator is any actor placing a product on the market or putting it into service, including manufacturers, authorized representatives, importers, distributors, dealers, and fulfillment service providers.

Within the HTTP URI‑based Digital Product Passport system, the REO must:

• Generate and assign the Product Unique Identifier (Product UID).
• Ensure that mandatory Digital Product Passport data are created, maintained, and accessible via HTTP URIs.
• Manage access permissions for modifications (for example, repair, refurbishment, or remanufacture entries).

Lifecycle aspects introduce complexity:

• New products: assigning a Product UID and creating DPP data is relatively straightforward.
• Refurbished or remanufactured products: when a product becomes “new” in legal terms after significant processing, responsibilities and possibly the Product UID and DPP may change.
• Shared responsibility: delegated acts under Article 4 ESPR will further clarify handover points between initial and subsequent REOs.

Decentralized DPP data repositories allow multiple authorized stakeholders to update Digital Product Passport information while preserving provenance and integrity.

🧾 Core Identifiers in the HTTP URI‑Based System

Identifiers are central to the structure of the DPP system using HTTP URIs.

🧩 REO ID

Article 11 ESPR requires REOs that create or update a Digital Product Passport to obtain a unique operator identifier, such as:

• Global Trade Item Numbers (GTINs)
• Global Location Numbers (GLNs)

This ensures reliable linking of Digital Product Passport data to the economic operator responsible for compliance.

🏭 Facility ID

Annex III ESPR introduces facility identifiers for production sites.
They support origin tracing in complex manufacturing arrangements, such as contract production or multi‑brand facilities.

🏷️ Product UID

The Product UID links each tangible product to its Digital Product Passport and is the primary anchor for HTTP URI resolution.

Key characteristics:

• Global uniqueness: the Product UID must be globally unique or be reliably converted into a globally unique HTTP URI.
• Flexible physical format: due to label constraints, the initial identifier may be compact and not in URI form, provided it is transformable into a URI compliant with RFC 3986 or RFC 3987.
• Machine readability: typically encoded into a QR code, barcode, or RFID tag attached to the product or packaging.

For online marketplaces, Article 9(3) ESPR requires that the Product UID be supplied so that DPP information can be discovered from product listings.

Where products are only individualized at a later stage, early links may point to model‑level DPP data, with item‑level Product UIDs introduced at customization or final sale.

🏛️ EU‑Registry and SHACL Control Engine

📜 EU‑Registry as Central Identifier Hub

Article 12(1) ESPR mandates the creation of an EU‑Registry to record key identifiers and related metadata.

In the HTTP URI architecture, the EU‑Registry:

• Contains Product UIDs, Facility IDs, REO IDs, and a unique registration number.
• May store links to current resolvers or other attributes specified in delegated acts.
• Provides standardized application programming interfaces for REOs to register and update entries.
• Can host transformation logic or store already generated HTTP URIs derived from non‑URI identifiers.

The registry functions as a central information node, even within a largely decentralized architecture, and could evolve into a “resolver of resolvers” similar to the Domain Name System.

🛡️ SHACL‑Based Validation and Control Engine

Digital Product Passports are expressed as knowledge graphs using W3C RDF 1.2.

A SHACL‑based control engine validates these graphs to ensure compliance and structural consistency.

The control engine:

• Distributes SHACL templates (“shapes”) to REOs to validate data before submission.
• Enables Market Authorities and Customs to automatically check DPP content during surveillance.
• Translates selected regulatory requirements from delegated acts under Article 4 ESPR into machine‑readable constraints.

By integrating validation capabilities into the EU‑Registry, the system supports pre‑ and post‑registration checks, helping all actors maintain compliant data structures.

📡 From Data Carrier to HTTP URI

📦 Data Carrier

The data carrier physically holds the Product UID and forms the bridge between the product and its HTTP URI.

Key expectations include:

• Placement on the product, its packaging, or accompanying documentation in line with sector‑specific delegated acts.
• Sufficient durability, readability, and storage capacity for the intended use environment.
• Suitability for the product category (for example, textiles require wash‑resistant tags; electronics allow more options).

Typical technologies:

• QR codes and linear barcodes
• RFID tags
• Other machine‑readable carriers adapted to the product material and lifecycle

For online sales, the Digital Product Passport must still be reachable, for instance via a digital copy of the data carrier or a clickable HTTP URI.

Any embedded link must be a canonical URI as defined in RFC 6596.

📷 Scanning Devices and Internet‑Connected Devices

Scanning devices read the Product UID from the data carrier by optical or radio‑frequency methods.

An Internet‑connected device (such as a smartphone, tablet, or industrial terminal) then:

• Interprets the extracted identifier.
• Performs or requests the transformation from UID to HTTP URI.
• Sends HTTP requests to resolvers or repositories to obtain Digital Product Passport data.

🔗 UID to HTTP URI Transformation and GS1 Digital Link

Many existing codes and numbering systems are not directly HTTP URIs. The architecture includes transformation modules that convert such identifiers into canonical URIs.

Common approaches include:

• GS1 Digital Link: defines how GTINs in barcodes are converted into URIs that point to resolvers hosting DPP data.
• Decentralized Identifiers (DIDs): inherently URI‑based but requiring dedicated resolution mechanisms.
• Web Link and ID‑Link (IEC 61406): allow item‑ or batch‑level identifiers based on domain names, without needing a central registration authority for each identifier.
• Sector‑specific schemes: custom numbering systems that include defined rules for secure transformation into HTTP URIs.

These mechanisms preserve investment in existing coding practices while enabling participation in the HTTP URI‑based DPP system.

🌐 Resolution, Data Repositories, and Archives

🧭 Resolvers and REO Resolvers

Resolvers are key HTTP components that receive URIs derived from Product UIDs and direct the client to the appropriate data source.

• REOs may run their own resolvers, outsource this function, or participate in shared sectoral resolver services.
• Resolvers can adapt responses to the requester’s role (consumer, service provider, regulator, recycler) to support circular‑economy interactions while respecting data protection and confidentiality.

Default EU Resolver

If an REO or its resolver infrastructure becomes unavailable, a default EU‑level resolver ensures continuity of access.
In cooperation with the EU‑Registry, it allows Digital Product Passport data to remain retrievable for the remaining lifetime of the product.

🛡️ Policy Decision Point (PDP)

A Policy Decision Point manages authorization and usage control for Digital Product Passport data.

• Policies, potentially expressed in languages such as the Open Digital Rights Language, define who may read, update, or append data.
• These rules are enforced consistently across decentralized repositories and resolvers.

🗄️ Decentralized DPP Data Repositories and Archives

Decentralized DPP Data Repositories are the primary storage layer in the HTTP URI architecture. They:

• Can be deployed by individual REOs or industry consortia.
• Apply linked‑data principles for interoperability and federation.
• Support multi‑actor updates (for example, repair logs, refurbishment records, end‑of‑life treatments).

Archives complement these repositories by preserving DPP data beyond the operational life of businesses or systems.

They provide a “service of last resort,” ensuring that essential information remains available for recycling, due diligence, and historical verification, even with reduced performance to control costs.

🤝 How ComplyMarket Supports HTTP URI‑Based DPP Implementation

Implementing the HTTP URI-based DPP architecture requires coordination across compliance, IT, and supply chain teams.

ComplyMarket supports you with:

• Identifier strategy (Product UID, REO ID, Facility ID) aligned with GS1 Digital Link, IEC 61406, and sector schemes
• EU Registry integration (APIs) and SHACL-based validation routines
• Data carrier + scanning workflows and UID-to-URI transformation
• Resolver, decentralized repository, fallback (Default EU Resolver), and archiving models