---
title: "EU Digital Product Passport identifier and data carrier design"
canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/unique-identifier-and-data-carrier-design"
source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/unique-identifier-and-data-carrier-design"
author: "Sorena AI"
description: "How to design Digital Product Passport identifiers, QR or other data carriers, resolver links, registry records, access paths, and evidence without overclaiming the EU rules."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "EU Digital Product Passport"
  - "ESPR"
  - "unique product identifier"
  - "data carrier"
  - "QR code"
  - "NFC"
  - "RFID"
  - "GS1 Digital Link"
  - "resolver"
  - "DPP registry"
  - "customs access"
  - "Digital Product Passport"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# EU Digital Product Passport identifier and data carrier design

How to design Digital Product Passport identifiers, QR or other data carriers, resolver links, registry records, access paths, and evidence without overclaiming the EU rules.

*DPP* *Identifier design* *EU*

## EU Digital Product Passport Identifier and Data Carrier Design

Design the passport entry point before choosing labels or portals: identifier level, carrier placement, resolver behavior, registry submission, and access rights all need to work together.

This page focuses on the technical design choices that make a Digital Product Passport discoverable, durable, interoperable, and usable by customers, value-chain actors, authorities, and customs.

A Digital Product Passport is not just a QR code. Under the ESPR, the passport is connected through a data carrier to a persistent unique product identifier, and the detailed product-group delegated act will decide whether the passport data refers to a model, batch, or item. Treat identifier and carrier design as a system architecture decision: the physical mark must survive the product context, the encoded identifier must resolve to the right passport views, and the registry record must support market surveillance and customs checks.

## Start with the identifier level, not the carrier format

The first design decision is the granularity of the unique product identifier. ESPR allows the passport data to refer to a product model, batch, or item as specified in the relevant delegated act. Do not serialize every unit by default unless the product rule, lifecycle risk, repair model, or traceability use case needs item-level identity.

A practical design record should name the identifier level, the standard or issuing route, the product data model fields that depend on it, and the downstream systems that must keep it stable. If the passport may be recreated after repair, remanufacturing, repurposing, or another lifecycle event, define how the new passport links to the original passport record.

- Model-level identifiers fit products where the required passport data is shared by all units of the same model.
- Batch-level identifiers fit production lots, material lots, or release groups where passport claims differ by batch.
- Item-level identifiers fit serialized goods, products with long service lives, high-value reuse, regulated repair histories, or product-specific state data.
- Operator and facility identifiers should be managed separately from product identifiers, because ESPR treats them as traceability elements with their own lifecycle rules.
- Identifier ownership should sit with the economic operator responsible for placing the product on the market, while data stewardship may be split across product compliance, master data, sustainability, supply chain, and IT.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - ESPR Article 10 connects the DPP through a data carrier to a persistent unique product identifier and says passport data refers to the model, batch, or item level set by the delegated act.
- [CIRPASS D3.2 DPP System Architecture](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - CIRPASS explains that identifiers can be implemented at item, product model, or batch level and that the identifier is central to the system architecture.

*Recommended next step*

*Placement: after evidence section*

## Validate the passport entry point before printing carriers

Use this DPP guide to test identifier level, carrier placement, resolver routing, registry mapping, and access rights before labels, tags, or product pages are released.

- [Open Research Copilot](/solutions/research-copilot.md): Answer Digital Product Passport implementation questions with cited source material.
- [Discuss DPP architecture](/contact.md): Review identifier, carrier, resolver, registry, and access design with Sorena.

## Choose the data carrier for scanability, durability, and access

ESPR requires the data carrier to be physically present on the product, packaging, or accompanying documentation as specified by the delegated act. Where possible, design for product-level placement so the passport remains available through use, repair, resale, and end of life. If product placement is not practical, document why packaging or documentation is the controlled alternative.

QR codes are usually the easiest public entry point because common smartphones can scan a URI. NFC can be useful where a tap interaction or protected tag is better than an exposed printed code. RFID can support logistics, repair, or industrial scanning where automatic identification at distance matters. The carrier choice should be validated against surface material, wear, weather exposure, replacement parts, packaging loss, privacy expectations, and whether basic public data can be reached without a vendor-specific app.

- For QR, test contrast, size, quiet zone, curved surfaces, abrasion, lighting, and scan distance on production materials rather than on a design mockup.
- For NFC, confirm that the tag can be read by expected devices, that metal or liquid interference is handled, and that the encoded target remains updateable or resolvable over the product life.
- For RFID, separate supply-chain automation needs from public passport access; RFID may identify the object, but customers and authorities still need an accessible passport path.
- For packaging or documentation placement, add controls for lost packaging and distance selling so dealers and marketplaces can still expose a digital copy or link.
- Keep visible human-readable fallback text where it helps users recognise that the carrier opens official passport information.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - ESPR Article 10 requires physical presence of the carrier on the product, packaging, or accompanying documentation, and Recital 37 names examples such as a watermark or QR code.
- [GS1 General Specifications](https://ref.gs1.org?ref=sorena.io) - GS1 definitions distinguish QR Code, NFC, and RFID carrier behavior, including QR scanning by imaging devices, NFC returning data such as a web URL, and RFID returning an identifier such as an EPC.
- [CIRPASS D3.2 DPP System Architecture](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - CIRPASS describes a user scanning a QR code containing a product identifier encoded into a web link and also recognises QR, RFID, or other data carriers.

## Design the resolver before publishing the mark

The data carrier should not be treated as a static web-page pointer. A resolver lets the same identifier route different users to the right passport view or machine-readable resource, based on link type, role, language, format, or access rights. For a customer scan, the default path should return public passport information in a mobile-accessible web format; for authorities, recyclers, repairers, or automated systems, the same identifier may need typed links to structured data, restricted views, or delegated supplier resources.

A resilient design keeps the product identifier stable while allowing service endpoints to change. That means maintaining DNS, redirect rules, link-type responses, backup hosting, and failure handling. If a responsible operator, service provider, or supplier endpoint disappears, users should not be stranded with an unreadable code or a 404.

- Encode or transform the product identifier into a resolvable URI using a documented standard route, such as GS1 Digital Link where it fits the product identifier scheme.
- Make the default scan path serve public information without login, registration, payment, or proprietary software.
- Use resolver link types or equivalent routing to separate consumer HTML, machine-readable data, authority views, repair information, recycling information, and supplier component links.
- Log resolver tests for normal scans, inaccessible endpoints, changed URLs, expired certificates, supplier redirects, language negotiation, and fallback behavior.
- Do not put confidential data directly in the carrier; encode the identifier or resolvable link and enforce access rules at the passport service layer.

Sources for this answer:

- [CIRPASS D3.2 DPP System Architecture](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - CIRPASS treats the resolver as a core DPP architecture component that redirects a product identifier request to role-appropriate targets and supports machine-readable data reuse.
- [GS1 General Specifications](https://ref.gs1.org?ref=sorena.io) - GS1 describes indirect mode as a carrier containing an identifier that must be resolved to obtain content or a service, and describes GS1 Digital Link URI use in QR codes.

## Connect the carrier to registry, customs, and access controls

The ESPR registry is separate from the public passport endpoint. The Commission registry stores at least unique identifiers, and for products released for free circulation it stores the commodity code. After upload, the registry communicates a unique registration identifier associated with the uploaded unique identifiers; ESPR states that this communication is not proof of compliance.

Customs checks depend on this registry path. Once the registry is operational, a person placing a covered product under release for free circulation must provide or make available the unique registration identifier, and customs may release the product only after verifying at minimum that the unique registration identifier and commodity code correspond to registry data.

- Maintain a registry submission record showing product identifier, commodity code where relevant, upload timestamp, submitting entity, and returned unique registration identifier.
- Keep registry records aligned with resolver records, but do not expose registry identifiers as public proof that the passport or product complies.
- Map access rights separately for customers, dealers, importers, distributors, repairers, recyclers, market surveillance authorities, customs authorities, and other actors named in the delegated act.
- Ensure dealers and online marketplaces can expose a digital copy of the carrier or identifier when customers cannot physically access the product.
- Use the passport access matrix to decide which data is public, which data is role-restricted, and who may introduce, modify, or update each data element.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - ESPR Articles 13-15 establish the DPP registry, unique registration identifier, access for authorities and customs, and customs verification against registry data.
- [Regulation (EU) 2024/1781 (ESPR)](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - The data.europa.eu ELI source provides the canonical legislative record for the same ESPR registry and customs-control requirements.

## Link identifier design to the passport data model

Identifier design affects the data model. A model-level passport can expose shared performance, repairability, material, conformity, and circularity fields, but it cannot reliably carry item-specific events unless there is a linked record. An item-level passport can support lifecycle events, repair updates, ownership-independent maintenance, and recycling histories, but it increases data governance and resolver complexity.

Before issuing carriers at scale, define the minimum data model that the identifier must unlock: public fields, restricted fields, authority fields, update permissions, supplier references, evidence fields, and versioning behavior. The data must be based on open standards, interoperable, machine-readable where appropriate, structured, searchable, and transferable through an open interoperable data exchange network without vendor lock-in.

- Add a data-field inventory showing whether each field is model, batch, item, operator, facility, or event data.
- Link each passport view to access rights and update rights rather than duplicating the same field in uncontrolled portals.
- Plan how a new passport links to the original passport when a product changes lifecycle state or responsibility.
- Keep supplier component data linkable through resolver or data-model references without making the finished-product identifier unstable.
- Include accessibility, language, and machine-readable output tests in the release checklist for every public scan path.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - ESPR Articles 10 and 11 require open standards, interoperable formats, machine-readability where appropriate, access-right controls, update restrictions, security, privacy, and passport linking.
- [CIRPASS D3.2 DPP System Architecture](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - CIRPASS explains that resolver link types can support role-based information filtering and different data formats for circular-economy actors and authorities.

## Evidence to keep before roll-out

The evidence file should prove that the identifier and carrier design works in the real product environment, not just that a code was generated. Keep the design decision, source basis, standards choice, scan tests, resolver tests, registry mapping, access matrix, and supplier integration records together.

Avoid unsupported claims that a particular QR, NFC, RFID, DID, GS1, or proprietary implementation is legally required unless the applicable delegated act or source states that requirement. Where the product-specific rule has not fixed the standard, present the choice as an implementation option and document why it is interoperable, durable, and accessible.

- Identifier architecture record: granularity, issuing route, owner, lifecycle rules, and collision checks.
- Carrier validation record: placement, print or tag specification, durability tests, scan-device matrix, and accessibility fallback.
- Resolver test log: default public view, role-specific links, structured data endpoints, language behavior, redirects, backup route, and failure handling.
- Registry and customs record: uploaded identifiers, commodity code where relevant, returned registration identifier, and customs data handoff owner.
- Access-control matrix: public fields, restricted fields, update rights, authentication method, and evidence for each role.
- Data-model linkage: field inventory, source system, supplier dependency, version history, and original-to-new passport linking rule.

Sources for this answer:

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - ESPR provides the legal basis for evidence around carrier connection, identifier standards, access rights, registry upload, backup copy, privacy, and technical operation.
- [CIRPASS D3.2 DPP System Architecture](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - CIRPASS supports evidence testing for QR scan flows, resolver behavior, role-specific links, fallback resolver thinking, and product identifier registration concepts.
- [GS1 Digital Product Passport standards overview](https://www.gs1.org/standards/standards-emerging-regulations/DPP?ref=sorena.io) - GS1's DPP materials identify the GS1 standards stack for identification, capture, and sharing, including barcodes, EPC/RFID, GS1 Digital Link, and data sharing approaches.

## Primary sources

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Primary legal source for DPP identifier, data carrier, access, registry, web portal, backup copy, customs, and technical-design requirements.
  - Quote: "persistent unique product identifier"
- [Regulation (EU) 2024/1781 (ESPR)](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Canonical ELI record for the ESPR source used to verify registry, customs, and identifier requirements.
  - Quote: "unique registration identifier"
- [CIRPASS D3.2 DPP System Architecture](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - Technical architecture support for identifier granularity, QR/RFID carrier flows, URI transformation, resolver behavior, role-based links, and fallback resolver considerations.
  - Quote: "DPP System Architecture"
- [GS1 General Specifications](https://ref.gs1.org?ref=sorena.io) - Standards support for QR Code, NFC, RFID, GS1 Digital Link URI, indirect resolution, serial number, and human-readable data-carrier terminology.
  - Quote: "near field communication"
- [GS1 Digital Product Passport standards overview](https://www.gs1.org/standards/standards-emerging-regulations/DPP?ref=sorena.io) - GS1 overview support for the Identify, Capture, Share standards stack relevant to DPP identifiers and carriers.
  - Quote: "Identify, Capture, Share"

## Related Topic Guides

- [Annex III Data Model Planning for EU Digital Product Passports](/artifacts/eu/digital-product-passport/annex-iii-data-model-planning.md): Plan EU Digital Product Passport data fields, identifiers, access rights, update owners, registry inputs, and evidence records against ESPR Annex III and product-specific delegated acts.
- [Digital Product Passport vs Digital Twin](/artifacts/eu/digital-product-passport/dpp-vs-digital-twin.md): Compare EU Digital Product Passports with digital twins: legal access duties, identifiers, public and restricted data, evidence, governance, and reuse limits.
- [Digital Product Passport vs Paper Product Passports](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): Compare EU regulated digital product passports with paper, PDF, web, and internal product passports across access, identifiers, data carriers, restricted data, customs checks, registry, and interoperability.
- [DPP customs access review workflow for ESPR products](/artifacts/eu/digital-product-passport/customs-access-review-workflow.md): Review public, restricted, and customs access for EU Digital Product Passports, including registry handoffs, portal access rights, and release-for-free-circulation evidence.
- [DPP Data Governance RACI Template for EU Digital Product Passports](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Assign accountable owners for EU Digital Product Passport data, access rights, supplier inputs, resolver links, registry uploads, verification checks, and retained evidence.
- [DPP data-model intake workflow for EU Digital Product Passports](/artifacts/eu/digital-product-passport/dpp-data-model-intake-workflow.md): A grounded intake workflow for EU Digital Product Passport data models: product group, delegated-act status, source owner, supplier data, access class, identifiers, carrier, checks, and publication readiness.
- [DPP Governance, Verification and Audit Controls](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): Build EU Digital Product Passport governance controls for data owners, supplier evidence, access logs, validation checks, audit records, and product release gates.
- [DPP QR code vs NFC data carrier choices under EU ESPR](/artifacts/eu/digital-product-passport/faq/qr-code-vs-nfc-carrier-choices.md): How to choose QR code, NFC, or another data carrier for an EU Digital Product Passport without assuming ESPR mandates one universal carrier.
- [DPP registry and web portal integration under EU ESPR](/artifacts/eu/digital-product-passport/dpp-registry-and-web-portal-integration.md): Grounded guide to EU Digital Product Passport registry and web portal integration under ESPR, covering identifiers, data carriers, access rights, service providers, and lookup design.
- [DPP vs Battery Passport: ESPR and Battery Regulation Comparison](/artifacts/eu/digital-product-passport/dpp-vs-battery-passport.md): Compare the ESPR Digital Product Passport framework with the EU Batteries Regulation battery passport by scope, timing, data, access rights, identifiers, registry, governance, and evidence.
- [DPP vs EPREL Comparison](/artifacts/eu/digital-product-passport/dpp-vs-eprel.md): Compare the EU Digital Product Passport with EPREL: product-passport scope, energy-label database role, access model, identifiers, data carriers, and overlap limits.
- [DPP vs GS1 Digital Link: Duties vs Standard](/artifacts/eu/digital-product-passport/dpp-vs-gs1-digital-link.md): Compare EU Digital Product Passport requirements with GS1 Digital Link: legal scope, identifiers, data carriers, access rights, registry, portal, customs checks, and implementation consequences.
- [EU Digital Product Passport access: public, restricted, and customs views](/artifacts/eu/digital-product-passport/public-restricted-and-customs-access.md): How ESPR Digital Product Passport access should be split across public users, restricted actors, authorities, customs, the EU registry, and the web portal.
- [EU Digital Product Passport API and resolver architecture](/artifacts/eu/digital-product-passport/api-and-resolver-architecture.md): Grounded DPP architecture guidance for data carriers, product identifiers, resolver lookup paths, access rights, registry integration, and interoperability without premature protocol mandates.
- [EU Digital Product Passport Applicability Test](/artifacts/eu/digital-product-passport/applicability-test.md): Check whether an ESPR delegated act or battery passport rule may require a Digital Product Passport, which operator owns it, and what evidence to keep.
- [EU Digital Product Passport architecture and integration](/artifacts/eu/digital-product-passport/architecture-and-integration.md): Grounded guide to EU Digital Product Passport architecture: data carriers, identifiers, access rights, registry, portal, supplier flows, customs checks, and governance.
- [EU Digital Product Passport checklist](/artifacts/eu/digital-product-passport/checklist.md): A concrete EU Digital Product Passport readiness checklist covering product-group scope, passport fields, identifiers, data carriers, access rights, supplier evidence, registry preparation, and publication controls.
- [EU Digital Product Passport compliance: ESPR requirements](/artifacts/eu/digital-product-passport/compliance.md): Grounded EU Digital Product Passport compliance guide covering ESPR passport data, identifiers, data carriers, access rights, registry readiness, supplier validation, and evidence.
- [EU Digital Product Passport Data Carriers, Access Control, and UX](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): How to choose DPP data carriers, identifiers, access rights, and scanning UX under ESPR Articles 9-14, with QR, NFC, RFID, registry, and customs constraints.
- [EU Digital Product Passport data requirements and fields](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): How to plan Digital Product Passport data fields under ESPR: delegated-act scope, Annex III data categories, access rights, customs data, and supplier validation.
- [EU Digital Product Passport deadlines and compliance calendar](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): Grounded EU Digital Product Passport calendar for ESPR and battery passport milestones, with product-group dates flagged as dependent on delegated acts.
- [EU Digital Product Passport FAQ](/artifacts/eu/digital-product-passport/faq.md): Direct answers on EU Digital Product Passport scope, creators, product groups, registry, customs checks, access rights, identifiers, data carriers, and governance.
- [EU Digital Product Passport penalties and enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): What ESPR says about Digital Product Passport penalties, Member State fine rules, market surveillance, customs checks, and unresolved product-specific delegated acts.
- [EU Digital Product Passport Product Group Readiness](/artifacts/eu/digital-product-passport/product-group-readiness.md): Prepare product groups for EU Digital Product Passport rules by tracking ESPR delegated-act status, data fields, suppliers, identifiers, access rights, and registry handoffs.
- [EU Digital Product Passport requirements under ESPR](/artifacts/eu/digital-product-passport/requirements.md): source-linked overview of EU Digital Product Passport requirements under ESPR: product-specific delegated acts, data fields, identifiers, carriers, registry, access rights, supplier data validation, and open points.
- [EU Digital Product Passport supplier data validation controls](/artifacts/eu/digital-product-passport/supplier-data-validation.md): Build a supplier data validation file for EU Digital Product Passports: source owner, product link, access class, data model fit, evidence quality, approval record, and release gate.
- [EU DPP customs access: registry, portal, and restricted data](/artifacts/eu/digital-product-passport/faq/customs-access.md): FAQ on customs access under the EU Digital Product Passport: what customs can verify, how the registry and public portal differ, and how access rights limit DPP data.
- [EU DPP implementation playbook and vendor selection](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): Select Digital Product Passport vendors against ESPR requirements for identifiers, data carriers, access rights, decentralized storage, registry readiness, portal access, and verification evidence.
- [EU DPP Product-Group Readiness Checklist](/artifacts/eu/digital-product-passport/product-group-readiness-checklist.md): A source-grounded checklist for preparing a product group for an EU Digital Product Passport delegated act, covering data fields, suppliers, identifiers, carriers, access rights, and registry readiness.
- [EU DPP QR Code and Data Carrier Implementation Guide](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): Grounded guidance for using QR codes and other data carriers in EU Digital Product Passport programs, including unique identifiers, access, resolver testing, and evidence.
- [EU DPP supplier data validation workflow](/artifacts/eu/digital-product-passport/supplier-data-validation-workflow.md): A grounded workflow for checking supplier data before it is used in an EU Digital Product Passport, covering product linkage, evidence, owners, access class, and approval records.
- [EU DPP unique identifier requirements: product, operator and facility IDs](/artifacts/eu/digital-product-passport/faq/unique-identifier-requirements.md): FAQ on how ESPR Digital Product Passport identifiers connect products, economic operators, facilities, data carriers, resolvers and registry evidence.
- [Public vs restricted EU Digital Product Passport data](/artifacts/eu/digital-product-passport/faq/public-vs-restricted-passport-data.md): How to separate public, restricted, authority, and customs access in EU Digital Product Passport designs under ESPR and battery passport rules.
- [What is a Digital Product Passport under ESPR?](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A visitor-friendly explanation of EU Digital Product Passports under ESPR: product data, identifiers, data carriers, access rights, registry, web portal, and delegated acts.
- [What is the EU Digital Product Passport registry?](/artifacts/eu/digital-product-passport/faq/dpp-registry.md): FAQ on the ESPR Digital Product Passport registry: what it stores, who uploads data, how identifiers work, and what teams should avoid assuming.
- [Which products come first for the EU Digital Product Passport?](/artifacts/eu/digital-product-passport/faq/which-products-come-first.md): FAQ on EU Digital Product Passport product priority: batteries have a separate passport rule, while ESPR product groups depend on the working plan and delegated acts.
- [Who must create an EU Digital Product Passport?](/artifacts/eu/digital-product-passport/faq/who-must-create-a-digital-product-passport.md): DPP responsibility under the EU ESPR: how manufacturers, importers, distributors, suppliers, service providers, and delegated acts fit together.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/eu/digital-product-passport/unique-identifier-and-data-carrier-design