LESSON 2: EU DIGITAL PRODUCT PASSPORT ECOSYSTEM

Lesson Overview

This lesson provides a comprehensive analysis of the EU Digital Product Passport ecosystem architecture. Students will learn how the various components of the DPP ecosystem interact, including registries, repositories, resolvers, data carriers, and service providers. The lesson covers different ecosystem models (centralized, federated, distributed) and their architectural implications.

Learning Objectives

• Explain the EU DPP ecosystem architecture and its components
• Understand the role of registries in the DPP ecosystem
• Understand the role of repositories in the DPP ecosystem
• Understand the role of resolvers in the DPP ecosystem
• Design ecosystem architectures for different use cases
• Select appropriate ecosystem models based on requirements

Detailed Content

DPP Ecosystem Components

The EU DPP ecosystem consists of several key components that work together to enable product passport creation, storage, access, and exchange:

Product Passport: The digital record that contains information about a product throughout its lifecycle. The passport includes:

• Product identification (unique identifier)
• Product information (manufacturer, model, specifications)
• Sustainability information (material composition, environmental impact)
• Compliance information (certifications, regulatory compliance)
• Lifecycle information (manufacturing date, use history, end-of-life handling)

The product passport is the core data object in the DPP ecosystem. All other components exist to create, store, access, and exchange passport data.

Registry: A system that maintains a directory of product passports and their locations. Registries provide:

• Product Registration: Registration of products and assignment of unique identifiers
• Passport Location: Information about where passport data is stored (repository location)
• Passport Discovery: Discovery mechanisms for finding passport data based on product identifier
• Cross-Registry Query: Query capabilities across multiple registries for distributed ecosystems

Registries are critical for ecosystem interoperability. They enable different organizations to find and access passport data regardless of where it is stored.

Repository: A system that stores passport data. Repositories provide:

• Data Storage: Storage of passport data throughout the product lifecycle
• Data Access: Access mechanisms for authorized actors to retrieve passport data
• Data Integrity: Integrity mechanisms to ensure data remains uncorrupted
• Data Security: Security mechanisms to protect data from unauthorized access

Repositories can be operated by individual organizations (manufacturer repositories) or by third-party service providers (shared repositories).

Resolver: A service that translates data carrier scans into passport data access. Resolvers provide:

• Carrier Resolution: Translation of data carrier scans (QR code, NFC tag, RFID) into passport identifiers
• Passport Location: Determination of where passport data is stored based on identifier
• Access Redirection: Redirection of access requests to the appropriate repository
• Access Control: Enforcement of access control policies based on actor type

Resolvers are the bridge between physical data carriers and digital passport data. They enable consumers and other actors to access passport data by scanning data carriers affixed to products.

Data Carrier: A physical or digital mechanism for accessing DPP data. Data carriers include:

• QR Codes: Two-dimensional barcodes that can be scanned with smartphones
• NFC Tags: Near-field communication tags that can be read with NFC readers
• RFID Tags: Radio-frequency identification tags that can be read with RFID readers
• Digital Link: A standardized URL structure that resolves to passport data

Data carriers are affixed to products and provide a physical mechanism for accessing digital passport data.

Service Provider: An organization that provides DPP-related services to other organizations. Service providers include:

• Registry Operators: Organizations that operate registries
• Repository Operators: Organizations that operate repositories
• Resolver Operators: Organizations that operate resolver services
• Data Carrier Providers: Organizations that provide data carrier generation and management services

Service providers enable organizations to outsource DPP capabilities rather than building them in-house.

Ecosystem Models

The DPP ecosystem can be architected using different models, each with different trade-offs:

Centralized Ecosystem Model: In a centralized model, a single registry and repository serve the entire ecosystem. All passport data is stored in a central repository, and all access goes through the central registry.

Architecture:

• Single registry for product registration and discovery
• Single repository for passport data storage
• Single resolver for data carrier resolution
• All organizations interact with the central systems

Advantages:

• Simplicity: Single point of management and control
• Consistency: Uniform implementation across all organizations
• Cost: Lower infrastructure costs due to centralization

Disadvantages:

• Single Point of Failure: Central system failure affects entire ecosystem
• Scalability: May struggle to handle large-scale data volumes
• Sovereignty: Organizations may be reluctant to store data in a central system
• Compliance: May not meet data sovereignty requirements

Use Cases:

• Single organization with multiple products
• Small-scale implementations
• Pilot programs and proof-of-concepts

Federated Ecosystem Model: In a federated model, multiple registries and repositories operate independently but interoperate through federation protocols. Each organization can operate its own registry and repository, but they can query across the federation.

Architecture:

• Multiple registries, each operated by different organizations
• Multiple repositories, each storing data for specific organizations
• Federation protocols for cross-registry query and data exchange
• Resolver services that can query across the federation

Advantages:

• Scalability: Can handle large-scale data volumes through distribution
• Sovereignty: Organizations maintain control over their data
• Flexibility: Organizations can choose their own technology stacks
• Resilience: No single point of failure

Disadvantages:

• Complexity: More complex to implement and manage
• Consistency: Ensuring consistency across federated systems is challenging
• Cost: Higher infrastructure costs due to distribution

Use Cases:

• Multi-organization ecosystems
• Industry consortia
• Large-scale implementations

Distributed Ecosystem Model: In a distributed model, there is no central registry or repository. Passport data is stored in a distributed database (e.g., blockchain) and accessed through peer-to-peer protocols.

Architecture:

• Distributed database for passport data storage
• Peer-to-peer protocols for data access
• No central registry or repository
• Resolver services that query the distributed database

Advantages:

• Resilience: No single point of failure
• Trust: Trust is established through cryptography rather than central authorities
• Transparency: All transactions are visible to all participants

Disadvantages:

• Complexity: Most complex to implement and manage
• Performance: May have performance limitations due to distributed consensus
• Maturity: Less mature technology stack

Use Cases:

• Public infrastructure with high trust requirements
• Peer-to-peer ecosystems
• Experimental implementations

Hybrid Ecosystem Model: In a hybrid model, different components use different models. For example, a centralized registry with federated repositories, or a federated registry with distributed storage.

Architecture:

• Combination of centralized, federated, and distributed components
• Flexible architecture that can accommodate different requirements
• Gateway services that translate between different models

Advantages:

• Flexibility: Can accommodate different requirements for different components
• Optimization: Can optimize each component for its specific use case
• Migration: Can support gradual migration from one model to another

Disadvantages:

• Complexity: Most complex to implement and manage
• Integration: Requires integration between different models
• Consistency: Ensuring consistency across different models is challenging

Use Cases:

• Mixed requirements across different components
• Gradual migration from one model to another
• Complex ecosystems with diverse requirements

Registry Architecture

Registries are critical components of the DPP ecosystem. They provide product registration, passport discovery, and cross-registry query capabilities.

Registry Functions:

• Product Registration: Registration of products and assignment of unique identifiers
• Passport Registration: Registration of passport locations (which repository stores which passport)
• Passport Discovery: Discovery of passport data based on product identifier
• Cross-Registry Query: Query across multiple registries in federated ecosystems
• Registry Federation: Federation protocols for interoperability between registries

Registry Data Model:

• Product Registration: Product identifier, manufacturer, registration date, status
• Passport Registration: Product identifier, repository location, access control policies
• Registry Directory: Registry identifiers, registry locations, registry capabilities
• Federation Metadata: Federation protocols, federation status, federation policies

Registry APIs:

• Registration API: API for registering products and passports
• Discovery API: API for discovering passport locations
• Query API: API for querying registry data
• Federation API: API for cross-registry federation

Registry Architecture Patterns:

• Centralized Registry: Single registry for the entire ecosystem
• Federated Registry: Multiple registries with federation protocols
• Hierarchical Registry: Hierarchical registry structure with parent-child relationships
• Peer-to-Peer Registry: Peer-to-peer registry network with no central authority

Repository Architecture

Repositories store passport data and provide access mechanisms for authorized actors.

Repository Functions:

• Data Storage: Storage of passport data throughout the product lifecycle
• Data Access: Access mechanisms for authorized actors
• Data Integrity: Integrity mechanisms to ensure data remains uncorrupted
• Data Security: Security mechanisms to protect data from unauthorized access
• Data Archiving: Archiving of data that is no longer actively accessed

Repository Data Model:

• Passport Data: Product identifier, passport data, metadata, access control policies
• Version History: Historical versions of passport data
• Access Logs: Logs of all access events
• Audit Trail: Audit trail of all data modifications

Repository APIs:

• Storage API: API for storing passport data
• Retrieval API: API for retrieving passport data
• Query API: API for querying passport data
• Version API: API for accessing historical versions

Repository Architecture Patterns:

• Centralized Repository: Single repository for the entire ecosystem
• Federated Repository: Multiple repositories with federation protocols
• Distributed Repository: Distributed database for passport data
• Hybrid Repository: Combination of different repository patterns

Resolver Architecture

Resolvers translate data carrier scans into passport data access.

Resolver Functions:

• Carrier Resolution: Translation of data carrier scans into passport identifiers
• Passport Location: Determination of where passport data is stored
• Access Redirection: Redirection of access requests to the appropriate repository
• Access Control: Enforcement of access control policies

Resolver Data Flow:

1. Data carrier is scanned (QR code, NFC tag, RFID)
2. Resolver extracts identifier from carrier
3. Resolver queries registry to determine passport location
4. Resolver redirects access request to appropriate repository
5. Repository returns passport data
6. Resolver enforces access control policies
7. Resolver returns data to requester

Resolver Architecture Patterns:

• Centralized Resolver: Single resolver for the entire ecosystem
• Distributed Resolver: Multiple resolvers with load balancing
• Edge Resolver: Resolvers deployed at edge locations for performance
• Hybrid Resolver: Combination of different resolver patterns

Technical Concepts

• Registry: System that maintains directory of product passports and their locations
• Repository: System that stores passport data
• Resolver: Service that translates data carrier scans into passport data access
• Data Carrier: Physical or digital mechanism for accessing DPP data
• Service Provider: Organization that provides DPP-related services
• Centralized Model: Single registry and repository for entire ecosystem
• Federated Model: Multiple registries and repositories with federation protocols
• Distributed Model: No central registry or repository, peer-to-peer protocols
• Hybrid Model: Combination of different models for different components

Architecture Considerations

Ecosystem Model Selection: Select the appropriate ecosystem model based on requirements. Centralized for simplicity, federated for scalability and sovereignty, distributed for resilience and trust, hybrid for flexibility.

Registry Architecture: Design registry architecture to support product registration, passport discovery, and cross-registry query. Consider centralized, federated, hierarchical, or peer-to-peer patterns based on requirements.

Repository Architecture: Design repository architecture to support data storage, access, integrity, and security. Consider centralized, federated, distributed, or hybrid patterns based on requirements.

Resolver Architecture: Design resolver architecture to support carrier resolution, passport location determination, access redirection, and access control. Consider centralized, distributed, edge, or hybrid patterns based on requirements.

Federation Protocols: Implement federation protocols for cross-registry and cross-repository interoperability. This requires adherence to EN 18223:2026 standards.

Implementation Considerations

Registry Implementation: Implement registry with product registration, passport registration, discovery, and federation capabilities. Use standardized APIs per EN 18222:2026.

Repository Implementation: Implement repository with data storage, access, integrity, and security capabilities. Use storage technologies appropriate for long-term persistence.

Resolver Implementation: Implement resolver with carrier resolution, location determination, access redirection, and access control. Use standardized protocols per EN 18220:2026.

Federation Implementation: Implement federation protocols for cross-registry and cross-repository interoperability. Use standardized protocols per EN 18223:2026.

Service Provider Integration: Integrate with service providers for registry, repository, and resolver services. This requires integration adapters and service level agreements.

Industry Examples

Centralized Battery Passport Ecosystem: A European automotive consortium implemented a centralized Battery Passport ecosystem for EV batteries. The consortium operated a single registry and repository for all member companies. This simplified implementation but created concerns about data sovereignty and single point of failure. The architecture included a centralized registry for battery registration, a centralized repository for passport data, and a centralized resolver for data carrier resolution.

Federated Textile DPP Ecosystem: A European textile industry association implemented a federated DPP ecosystem for textile products. Each member company operated its own repository, but the association operated a centralized registry for product discovery. This balanced data sovereignty with ecosystem interoperability. The architecture included a centralized registry for product discovery, federated repositories for data storage, and distributed resolvers for data carrier resolution.

Distributed Construction Products DPP Ecosystem: A European construction industry consortium experimented with a distributed DPP ecosystem using blockchain technology. Passport data was stored in a distributed database, and access was through peer-to-peer protocols. This provided resilience and trust but introduced complexity and performance challenges. The architecture included a distributed database for passport storage, peer-to-peer protocols for data access, and decentralized resolvers for data carrier resolution.

Common Mistakes

Underestimating Ecosystem Complexity: Underestimating the complexity of ecosystem architecture, particularly the interactions between registries, repositories, and resolvers. This results in incomplete or incompatible implementations.

Choosing Wrong Ecosystem Model: Choosing an ecosystem model that doesn't match requirements. For example, choosing a centralized model for a large-scale multi-organization ecosystem. This results in scalability and sovereignty issues.

Ignoring Federation Requirements: Ignoring federation requirements in federated ecosystems. This results in systems that cannot interoperate with other DPP implementations.

Overlooking Resolver Complexity: Overlooking the complexity of resolver architecture, particularly the integration with registries and repositories. This results in incomplete or non-functional resolver implementations.

Neglecting Service Provider Integration: Neglecting integration with service providers for registry, repository, and resolver services. This results in systems that cannot leverage service provider capabilities.

Best Practices

Ecosystem Model Selection: Select the ecosystem model based on requirements, not simplicity. Consider scalability, sovereignty, resilience, and complexity trade-offs.

Registry-Repository Separation: Separate registry and repository functions to enable flexibility. This allows different organizations to operate repositories while sharing a common registry.

Standardized Protocols: Use standardized protocols for registry, repository, and resolver interoperability. This ensures compatibility with other DPP implementations.

Federation by Design: Design federation capabilities from the ground up in federated ecosystems. This ensures that systems can interoperate as the ecosystem grows.

Service Provider Integration: Integrate with service providers to leverage their capabilities and reduce implementation complexity.

Key Takeaways

• The DPP ecosystem consists of registries, repositories, resolvers, data carriers, and service providers
• Ecosystem models include centralized, federated, distributed, and hybrid patterns
• Registry architecture supports product registration, passport discovery, and cross-registry query
• Repository architecture supports data storage, access, integrity, and security
• Resolver architecture translates data carrier scans into passport data access
• Ecosystem model selection should be based on requirements, not simplicity
• Federation protocols are critical for interoperability in federated ecosystems