🧾 HTTP-URI-Architektur des EU-Passes für digitale Produkte

Der „Aufbau des DPP-Systems unter Verwendung von HTTP-URIs“ beschreibt, wie der EU Digital Product Passport (DPP) als Web-native, HTTP-URI-basiert Architektur.

Gemäß der Ecodesign for Sustainable Products Regulation (ESPR) ist jedes Produkt über standardisierte HTTP Uniform Resource Identifiers (URIs) mit digitalen Informationen verknüpft, was interoperablen Zugriff, Rückverfolgbarkeit und Lebenszyklusmanagement ermöglicht.

Dieser Artikel bietet einen Überblick über die HTTP-URI-basierte Struktur und konzentriert sich dabei auf die Kernakteure, Identifikatoren, technischen Komponenten und Governance-Mechanismen, die das DPP-System bilden. Es richtet sich an Compliance-, IT- und Produktdatenteams, die sich auf ESPR-konforme DPP-Anforderungen vorbereiten. Es behandelt die wichtigsten Identifikatoren (Produkt-UID, REO-ID, Facility-ID), die Rolle des EU-Registers und wie Resolver und dezentrale Repositories den DPP-Zugriff über HTTP-URIs ermöglichen können.

⚙️ Strukturelemente und Hauptakteure

Die HTTP-URI-Architektur verbindet physische Produkte und digitale Daten über ein Netzwerk interoperabler Elemente:

• Verantwortliche Wirtschaftsbeteiligte (REOs)
• Das EU-Register
• Validierungs- und Kontroll-Engines
• Datenträger und Scangeräte
• UID-zu-URI-Transformationsmodule und digitale Linkstandards
• Resolver, dezentrale Datenrepositorys und Archive

👥 Verantwortlicher Wirtschaftsbeteiligter (REO)

Der verantwortliche Wirtschaftsakteur ist jeder Akteur, der ein Produkt auf den Markt bringt oder in Betrieb nimmt, einschließlich Hersteller, autorisierte Vertreter, Importeure, Distributoren, Händler und Fulfillment-Dienstleister.

Innerhalb des HTTP-URI-basierten Digital Product Passport-Systems muss der REO:

• Generieren und weisen Sie den Product Unique Identifier (Produkt-UID) zu.
• Stellen Sie sicher, dass obligatorische Digital Product Passport-Daten erstellt, gepflegt und über HTTP-URIs zugänglich sind.
• Verwalten Sie Zugriffsberechtigungen für Änderungen (z. B. Reparatur-, Sanierungs- oder Wiederaufbereitungseinträge).

Lebenszyklusaspekte führen zu Komplexität:

• Neue Produkte: Das Zuweisen einer Produkt-UID und das Erstellen von DPP-Daten ist relativ einfach.
• Überholte oder wiederaufbereitete Produkte: Wenn ein Produkt nach erheblicher Verarbeitung rechtlich „neu“ wird, können sich die Verantwortlichkeiten und möglicherweise die Produkt-UID und DPP ändern.
• Gemeinsame Verantwortung: Delegierte Rechtsakte gemäß Artikel 4 ESPR werden die Übergabepunkte zwischen ersten und nachfolgenden REOs weiter klären.

Dezentrale DPP-Datenrepositorys ermöglichen es mehreren autorisierten Stakeholdern, die Informationen des Digital Product Passport zu aktualisieren und gleichzeitig Herkunft und Integrität zu wahren.

🧾 Kernbezeichner im HTTP-URI-basierten System

Bezeichner sind von zentraler Bedeutung für die Struktur des DPP-Systems, das HTTP-URIs verwendet.

🧩 REO-ID

Gemäß Artikel 11 ESPR müssen REOs, die einen digitalen Produktpass erstellen oder aktualisieren, eine eindeutige Betreiberkennung erhalten, wie zum Beispiel:

• Globale Handelsartikelnummern (GTINs)
• Globale Standortnummern (GLNs)

Dadurch wird eine zuverlässige Verknüpfung der Daten des Digitalen Produktpasses mit dem für die Einhaltung verantwortlichen Wirtschaftsakteur gewährleistet.

🏭 Einrichtungs-ID

Anhang III ESPR führt Betriebskennungen für Produktionsstandorte ein.
Sie unterstützen die Rückverfolgung des Ursprungs in komplexen Herstellungsvereinbarungen, wie z. B. Auftragsproduktion oder Mehrmarkenanlagen.

🏷️ Produkt-UID

Die Produkt-UID verknüpft jedes konkrete Produkt mit seinem digitalen Produktpass und ist der primäre Anker für die HTTP-URI-Auflösung.

Hauptmerkmale:

• Globale Einzigartigkeit: Die Produkt-UID muss global eindeutig sein oder zuverlässig in einen global eindeutigen HTTP-URI umgewandelt werden.
• Flexibles physisches Format: Aufgrund von Label-Einschränkungen kann der anfängliche Bezeichner kompakt und nicht in URI-Form sein, vorausgesetzt, er kann in einen URI umgewandelt werden, der RFC 3986 oder RFC 3987 entspricht.
• Maschinenlesbarkeit: typischerweise in einem QR-Code, Barcode oder RFID-Tag codiert, der am Produkt oder an der Verpackung angebracht ist.

Für Online-Marktplätze verlangt Artikel 9(3) ESPR die Angabe der Produkt-UID, damit DPP-Informationen aus Produktlisten ermittelt werden können.

Wenn Produkte erst zu einem späteren Zeitpunkt individualisiert werden, verweisen frühe Links möglicherweise auf DPP-Daten auf Modellebene, wobei Produkt-UIDs auf Artikelebene bei der Anpassung oder dem Endverkauf eingeführt werden.

🏛️ EU-Registrierung und SHACL Control Engine

📜 EU-Register als zentraler Identifikator-Hub

Artikel 12 Absatz 1 ESPR schreibt die Einrichtung eines EU-Registers vor, um Schlüsselidentifikatoren und zugehörige Metadaten aufzuzeichnen.

In der HTTP-URI-Architektur hat das EU-Register Folgendes:

• Enthält Produkt-UIDs, Facility-IDs, REO-IDs und eine eindeutige Registrierungsnummer.
• Kann Links zu aktuellen Resolvern oder anderen in delegierten Rechtsakten angegebenen Attributen speichern.
• Bietet standardisierte Anwendungsprogrammierschnittstellen für REOs zum Registrieren und Aktualisieren von Einträgen.
• Kann Transformationslogik hosten oder bereits generierte HTTP-URIs speichern, die von Nicht-URI-Kennungen abgeleitet sind.

Die Registry fungiert auch innerhalb einer weitgehend dezentralen Architektur als zentraler Informationsknoten und könnte sich zu einem „Resolver der Resolver“ ähnlich dem Domain Name System entwickeln.

🛡️ SHACL-basierte Validierungs- und Kontroll-Engine

Digitale Produktpässe werden mithilfe von W3C RDF 1.2 als Wissensgraphen ausgedrückt.

Eine SHACL-basierte Steuerungs-Engine validiert diese Diagramme, um Compliance und strukturelle Konsistenz sicherzustellen.

Die Steuerungsmaschine:

• Verteilt SHACL-Vorlagen („Shapes“) an REOs, um Daten vor der Übermittlung zu validieren.
• Ermöglicht Marktbehörden und Zollbehörden die automatische Überprüfung von DPP-Inhalten während der Überwachung.
• Übersetzt ausgewählte regulatorische Anforderungen aus delegierten Rechtsakten gemäß Artikel 4 ESPR in maschinenlesbare Einschränkungen.

Durch die Integration von Validierungsfunktionen in das EU-Register unterstützt das System Prüfungen vor und nach der Registrierung und hilft so allen Akteuren, konforme Datenstrukturen aufrechtzuerhalten.

📡 Vom Datenträger zum HTTP-URI

📦 Datenträger

Der Datenträger speichert physisch die Produkt-UID und bildet die Brücke zwischen dem Produkt und seinem HTTP-URI.

Zu den wichtigsten Erwartungen gehören:

• Platzierung auf dem Produkt, seiner Verpackung oder der Begleitdokumentation gemäß branchenspezifischen delegierten Rechtsakten.
• Ausreichende Haltbarkeit, Lesbarkeit und Speicherkapazität für die vorgesehene Einsatzumgebung.
• Eignung für die Produktkategorie (z. B. erfordern Textilien waschbeständige Etiketten; Elektronik bietet mehr Optionen).

Typische Technologien:

• QR-Codes und lineare Barcodes
• RFID-Tags
• Weitere maschinenlesbare Träger, angepasst an das Produktmaterial und den Lebenszyklus

Für den Online-Verkauf muss der Digital Product Passport weiterhin erreichbar sein, etwa über eine digitale Kopie des Datenträgers oder einen anklickbaren HTTP-URI.

Jeder eingebettete Link muss ein kanonischer URI gemäß RFC 6596 sein.

📷 Scangeräte und mit dem Internet verbundene Geräte

Scangeräte lesen die Produkt-UID vom Datenträger durch optische oder hochfrequente Methoden aus.

Ein mit dem Internet verbundenes Gerät (z. B. ein Smartphone, Tablet oder Industrieterminal) dann:

• Interpretiert den extrahierten Bezeichner.
• Führt die Umwandlung von UID in HTTP-URI durch oder fordert sie an.
• Sendet HTTP-Anfragen an Resolver oder Repositorys, um Digital Product Passport-Daten abzurufen.

🔗 UID-zu-HTTP-URI-Transformation und GS1 Digital Link

Viele bestehende Codes und Nummerierungssysteme sind keine direkten HTTP-URIs. Die Architektur umfasst Transformationsmodule, die solche Bezeichner in kanonische URIs umwandeln.

Zu den gängigen Ansätzen gehören:

• GS1 Digital Link: Definiert, wie GTINs in Barcodes in URIs umgewandelt werden, die auf Resolver verweisen, die DPP-Daten hosten.
• Dezentrale Identifikatoren (DIDs): Von Natur aus URI-basiert, erfordert jedoch dedizierte Auflösungsmechanismen.
• Weblink und ID-Link (IEC 61406): Erlauben Sie Identifikatoren auf Artikel- oder Chargenebene basierend auf Domänennamen, ohne dass eine zentrale Registrierungsstelle für jeden Identifikator erforderlich ist.
• Branchenspezifische Regelungen: benutzerdefinierte Nummerierungssysteme, die definierte Regeln für die sichere Umwandlung in HTTP-URIs enthalten.

Diese Mechanismen bewahren Investitionen in bestehende Codierungspraktiken und ermöglichen gleichzeitig die Teilnahme am HTTP-URI-basierten DPP-System.

🌐 Auflösung, Datenrepositorys und Archive

🧭 Resolver und REO-Resolver

Resolver sind wichtige HTTP-Komponenten, die von Produkt-UIDs abgeleitete URIs empfangen und den Client zur entsprechenden Datenquelle weiterleiten.

• REOs können ihre eigenen Resolver betreiben, diese Funktion auslagern oder an gemeinsamen sektoralen Resolverdiensten teilnehmen.
• Resolver können Antworten an die Rolle des Anforderers (Verbraucher, Dienstleister, Regulierungsbehörde, Recycler) anpassen, um Interaktionen in der Kreislaufwirtschaft zu unterstützen und gleichzeitig Datenschutz und Vertraulichkeit zu respektieren.

Standard-EU-Resolver

Wenn ein REO oder seine Resolver-Infrastruktur nicht verfügbar ist, stellt ein Standard-Resolver auf EU-Ebene die Kontinuität des Zugriffs sicher.
In Zusammenarbeit mit der EU-Registrierung ermöglicht es, dass die Daten des digitalen Produktpasses für die verbleibende Lebensdauer des Produkts abrufbar bleiben.

🛡️ Policy Decision Point (PDP)

Ein Policy Decision Point verwaltet die Autorisierung und Nutzungskontrolle für Digital Product Passport-Daten.

• Richtlinien, möglicherweise ausgedrückt in Sprachen wie der Open Digital Rights Language, legen fest, wer Daten lesen, aktualisieren oder anhängen darf.
• Diese Regeln werden in dezentralen Repositories und Resolvern konsistent durchgesetzt.

🗄️ Dezentrale DPP-Datenrepositorys und -Archive

Dezentrale DPP-Datenrepositorys sind die primäre Speicherschicht in der HTTP-URI-Architektur. Sie:

• Kann von einzelnen REOs oder Branchenkonsortien eingesetzt werden.
• Wenden Sie Linked-Data-Prinzipien für Interoperabilität und Verbund an.
• Unterstützen Sie Multi-Actor-Updates (z. B. Reparaturprotokolle, Sanierungsaufzeichnungen, End-of-Life-Behandlungen).

Archive ergänzen diese Repositories, indem sie DPP-Daten über die Betriebslebensdauer von Unternehmen oder Systemen hinaus aufbewahren.

Sie bieten einen „Service der letzten Instanz“ und stellen sicher, dass wichtige Informationen für Recycling, Due Diligence und historische Überprüfung auch bei reduzierter Leistung zur Kostenkontrolle verfügbar bleiben.

🤝 Wie ComplyMarket die HTTP-URI-basierte DPP-Implementierung unterstützt

Die Implementierung der HTTP-URI-basierten DPP-Architektur erfordert eine Koordination zwischen Compliance-, IT- und Lieferkettenteams.

ComplyMarket unterstützt Sie bei:

• Identifikatorstrategie (Produkt-UID, REO-ID, Facility-ID), abgestimmt auf GS1 Digital Link, IEC 61406 und Sektorschemata
• EU-Registerintegration (APIs) und SHACL-basierte Validierungsroutinen
• Datenträger- und Scan-Workflows und UID-zu-URI-Transformation
• Resolver, dezentrales Repository, Fallback (Standard-EU-Resolver) und Archivierungsmodelle