Digital Product Passport – Data Exchange Protocols (DIN EN 18216:2025 Draft)

Background & Context

• Draft European Standard: prEN 18216:2025 (DIN EN 18216:2025-07)
  • Developed by CEN/CENELEC JTC 24 “Digital Product Passport – Framework & System”; German secretariat: DIN.
  • Triggered by Commission Implementing Decision C(2024) 5423 final (31 Jul 2024) – standardisation request for the Digital Product Passport (DPP).
  • Supports Ecodesign Regulation (EU) 2024/1781 (28 Jun 2024); relationship mapped in Annex ZA.
  • Public enquiry period ends 13 Aug 2025 (comments via DIN portals, e-mail, or paper).
  • Total draft length: 37 pages; bilingual (DE/EN, with FR title).

Scope & Objectives (Clause 1)

• Defines secure & efficient:
  • Data exchange protocols (rules/procedures for communication).
  • Data formats (structure/presentation of information).
• Guarantees data that is:
  • Machine-readable, structured, searchable.
  • Transferable over open, interoperable networks (no vendor lock-in).
• Five strategic goals:
  1. Secure communication – authenticated, access-controlled.
  2. Interoperability – easy integration across sectors/legacy systems.
  3. Ease of use & integration – incl. mobile devices, user-friendly.
  4. Data integrity – trust from production to end-of-life.
  5. Documentation & discoverability – accessible to non-experts.
• Aligns with existing EU legislation & standards to lower business costs.

Key Terms & Definitions (Clause 3)

• Identifier: sequence of characters linked to entities (books, images, events).
• Data exchange: storing, accessing, transferring, archiving data.
• Identification: recognising an object as distinct within a domain.
• Authentication: verification that a claimed identity is correct.
• Data integrity: property that data is unaltered/undestroyed \Rightarrow protects against tampering during transmission.
• Secure communication: transmission mechanism ensuring confidentiality, integrity & authenticity.

Data Exchange Protocols (Clause 4)

• Mandatory:
  • RESTful APIs over HTTP (architectural style leveraging HTTP verbs, resources, statelessness).
  • HTTPS (HTTP over TLS): secure version of HTTP.
    • TLS 1.3 (RFC 8446) & successors.
    • HTTP versions: HTTP/1.1 (RFC 7230-7235), HTTP/2 (RFC 7540), HTTP/3 (RFC 9114).
• Other protocols permitted by bilateral agreement (flexibility clause).

Data Formats (Clause 5)

• Primary: JSON – lightweight, human & machine readable.
• Also allowed (message formats):
  • XML – structured markup, hierarchical.
  • JSON-LD – JSON serialisation for Linked Data (adds semantic context).
• Human-readable rendering: via HTML (must comply with W3C HTML standards; CSS & JavaScript optional). DPP need not be stored as HTML, only rendered.

Data Exchange Protocol Requirements (Clause 6)

• 6.1 General: protocols enable seamless, technology-agnostic sharing of specifications, origin, materials, compliance certificates, sustainability metrics, etc.
• 6.2 Secure data exchange: ALL server-client traffic MUST use TLS.
  • Applies especially to B2C scenarios (mobile apps, desktop, embedded systems).
  • Refers to ISO/IEC 27033 (network security) & ISO/IEC 27001 (ISMS).
• 6.3 Confidentiality & Integrity:
  • DPP data encrypted in transit.
  • Covers B2B & B2G hand-overs inside supply chains.
• 6.4 Secure transmission: only secure protocols may carry DPP.
• 6.5 Non-repudiation: sender/receiver cannot deny DPP transfer.
• 6.6 Data transfer protocols: shall at minimum satisfy Clause 5(b), 7.2 & 7.5 (cross-references ensure full security + usability).

Data Exchange – Usability & Integration (Clause 7)

• 7.1 Security & access control: encryption + integrity mandatory.
• 7.2 Ease of use:
  • Table 1 compares HTTPS & REST APIs for Consumers, SMEs, Large Enterprises.
    • Consumers: browsers auto-handle HTTPS.
    • SMEs: free certificates (Let’s Encrypt); developer-friendly frameworks.
    • Large enterprises: dedicated IT teams; existing API infrastructure.
• 7.3 Data integrity mechanisms:
  • HTTP over TLS:
    • Message Authentication Codes (MACs).
    • TLS handshake negotiates cipher suites (e.g. SHA-256).
    • Sequence numbers prevent replay attacks.
    • Certificate validation by trusted CAs.
  • RESTful APIs (usually over HTTPS):
    • Input/response validation.
    • Digital signatures inside JWT (HMAC or RSA).
    • OAuth 2.0 / OIDC token validation.
    • Use of safe & idempotent HTTP verbs (GET, PUT).

Secure Communication (Clause 8)

• 8.1 General: must ensure confidentiality, integrity, authenticity.
• 8.2 HTTPS (TLS 1.2/1.3):
  • Asymmetric PKI: public key (encrypt) vs private key (decrypt).
  • Prevents man-in-the-middle & eavesdropping.
• 8.2 RESTful APIs:
  • Rely on HTTPS.
  • Characteristics: statelessness, confidentiality, integrity, availability.
  • Must implement: rate-limiting, DDoS protection, error handling with proper HTTP status codes (e.g. 401, 403).

Identification, Authentication & Authorization (Clause 8.3)

• Use-case example: EV battery DPP – ownership chain (public) vs cell manufacturing manuals (restricted).
• 8.3.1 OAuth 2.0:
  • Token-based access; scopes enforce least-privilege.
  • Access tokens expire; refresh tokens renew access securely.
• 8.3.2 OpenID Connect (OIDC):
  • Adds ID Token (signed JWT) for user authentication.
  • Supports Single Sign-On (SSO); all token exchanges over HTTPS.
• 8.3.3 CEF eID (Connecting Europe Facility):
  • Pan-EU cross-border e-ID; leverages XML-Signatures for integrity/authenticity.
• 8.3.4 Decentralised Identifiers (DIDs):
  • Self-sovereign identities on blockchain or similar decentralised ledgers.
  • Support verifiable credentials; public-key cryptography; secure HTTPS transport.

Non-Repudiation & Audit Trail

• Ensured through:
  • Cryptographic proofs (MACs, digital signatures).
  • TLS sequence numbers & certificates.
  • Logging & rate-limit events (mentioned in REST security).

Compatible Systems (Annex A)

• AS4 Profile of OASIS ebMS 3.0 – secure document exchange via Web Services.
• Asset Administration Shell (AAS) – digital twin; interoperable over industrial protocols.
• EDI – computer-to-computer business document exchange using standardised protocols.
• Note: list is non-exhaustive; other solutions possible.

Regulatory Alignment (Annex ZA)

• Table ZA.1 maps prEN 18216 clauses to Ecodesign Regulation (EU) 2024/1781 requirements.
  • Examples:
    • 10.1(d) \rightarrow Clauses 5 & 6 for open, interoperable standards.
    • 11(a) \rightarrow Clauses 6 & 8 for data formats & integrity.
    • 11(h) \rightarrow Clauses 9.1 & 9.2 (secure HTTP + REST implementation).
    • 14, 15.1, 15.2, 15.4 \rightarrow Clauses on secure exchange, non-repudiation, confidentiality, integrability.
• Presumption of conformity valid only while standard is listed in OJEU.

Bibliography & Reference Standards

• ISO 24619 (PISA) – persistent identifiers.
• ISO 15531-43 – manufacturing data exchange.
• ISO/IEC 24760-1 – identity management.
• ISO/IEC/IEEE 8802-1AR (2020) – secure device identity.
• ISO 7498-2 – OSI security architecture.
• ISO/IEC 27033 series – network security.
• ISO/IEC 27001 – ISMS requirements.
• RFC 6749 – OAuth 2.0
• Auth0 docs – OpenID Connect protocol.
• EU Digital Building Blocks – eID.
• W3C DID Core 1.0 – Decentralised Identifiers.

Practical Implications & Take-aways

• Implementers must:
  • Use TLS 1.2/1.3 for all DPP transactions.
  • Expose/consume DPP via REST APIs with JSON/JSON-LD payloads; XML optional.
  • Provide HTML rendering for human consumption.
  • Integrate OAuth 2.0 / OIDC or equivalent for access control; consider CEF eID or DIDs for cross-border/self-sovereign contexts.
  • Record cryptographic proofs for non-repudiation.
• Organisations should align internal ISMS with ISO/IEC 27001 and network security with ISO/IEC 27033 to meet standard expectations.
• Supply chains must plan for B2B/B2G encrypted transfers & fine-grained permissions (e.g. recyclers vs public viewers).
• Regulators/Notified Bodies can use Annex ZA mapping for conformity assessments.