¶ Digital Product Passport
The DPP is a set of new regulations and technical standards setup in Europe[1].
A DPP is a digital document associated with many kinds of physical products.
It can contain information about the general product specification, as well as details specific to a given unit such as serial number, warranty, ownership, etc.
The content of the DPP is dynamic, and meant to evolve alongside the lifecycle of the product.
To enable advanced DPP usage, multiple parties are involved in its design, including the NFC Forum[2].
KeeeX aims to provide the tools needed to implement a DPP Solution in ways that ensure both availability, interoperability, privacy, and adequate security properties.
¶ DPP Specification
The exact specification of the DPP is currently being developed.
However, we already have a rough outline of what it will contain.
Even though the definitive requirements are not yet defined, we can already start thinking about the different components of the DPP.
In particular, KeeeX focused on the following aspects that may be required:
- General Product Specification: Establishing a link between a physical item and information about its construction process, component details, country of origin, etc.
- Product Unit Specification: Using a unique identifier (serial number) to add manufacturing details about a specific unit, such as production date, revision number, etc.
- Product Lifecycle: Recording events and status of the unit, including but not limited to ownership, damage, repair, etc., as well as end-of-cycle events such as recycling, disassembly, disposal, etc.
- Link between physical and digital products: The DPP is linked to a physical object in a permanent manner, and this link should be maintained regardless of digital services maintaining the DPP.
It also requires methods for linking the DPP with the physical product and retrieving the DPP from the physical product. - Tamper-proof and fraud resistance: The content within the DPP, along with the connection between a physical item and its corresponding digital entry, must be tamper-proof to prevent replacing objects displaying similar unique identifiers or unauthorized editing/replacement of the DPP.
- Interoperability: Ensuring the DPP can interact seamlessly with other systems, including manufacturing, supply chain, and recycling processes
- Privacy: Minimizing data collection regarding end-users/product owners/businesses and handling such data responsibly.
¶ General architecture
Each applicable product offers a data carrier, which can be in various formats, enabling deterministic and effortless access to a service facilitating access to the DPP.
When a user employs this data carrier to access the DPP, they receive all current information concerning the product as well as specifics regarding the particular unit.
Furthermore, interactive alternatives exist for extending the content of the DPP with additional data: lifecycle events, transfer of ownership, recycling, etc.
Access to the DPP and authorization to perform multiple actions is regulated by a set of rules, thereby offering granular access to various levels of information.
Specifically, physical access to a data carrier allows every user to inquire about general product information and its current status (public data).
However, access to specific details such as ownership, lifecycle, or any particular event may be limited only to authorized users.
In keeping this structure consistent, the DPP can also be configured to permit exclusively sanctioned users to enact specific actions, like transferring its ownership, completing a repair process, and so forth.
These limitations can emanate from both local restrictions (specific to an item) or universal rules (applicable to all instances of the product).
Note: The outlined access control model is envisioned as adaptable for any future demands to avoid unnecessary changes in subsequent implementations.
As precise specifications for this aspect are currently lacking, first iterations of practical applications may not call for such elaborate configurations.
Instead, a straightforward access control scheme could initially suffice.
¶ KeeeX solution
KeeeX aims to deliver a blend of software and hardware solutions (in collaboration with trusted partners) to tackle the issues outlined earlier.
The proposed software solution offers a suite of tools to oversee the product's lifecycle, as well as an approach to inquire about the status of a product using the data-carrier for end-users, and appropriate APIs facilitating automated operations.
The hardware solution is designed to bolster security aspects and curb common drawbacks usually prevalent in traceability solutions, such as duplicated references, counterfeit items, and similar issues.
This is a general outline of the components involved to operate a DPP Solution.
A more in-depth explanation of the components is provided in the Architecture page.
¶ Data Carrier
The core function of the data carrier is to provide a link between the product and the service.
Therefore, its minimum requirement is the ability to provide a unique reference that can be used to identify the product or search for it.
Ideally, the user input process is as simple as possible, limiting the number of actions required between locating the data carrier and accessing the DPP.
In addition to this core function, advanced solutions may offer additional features that DPP Solutions can leverage to enhance the DPP, providing a superior user experience while offering an extra layer of security/trust for the solution.
For more information on KeeeX's proposition regarding the extra properties of data carrier, please refer to the Data Carrier page.
¶ Matching Service
A standard web service knowledgeable about DPP specifics can direct the user to the appropriate frontend based on the request.
Such a service can serve as a single entry point for the DPP, and also provide a centralized backend for multiple providers if needed.
A service acting as an entrypoint typically requires minimum collaboration from actual DPP Services and may be subject to heavy traffic.
This is why it is considered a separate service from the actual DPP Service.
The functionality of this service involves handling all appropriate input formats, such as standard GS1[3] urls scheme and dedicated URL schemes, and either redirecting the user (when applicable) or returning the required data based on the calling service.
Among the variable input, a matching service should consider the following factors:
- requested domain name (if applicable)
- unique identifier (either a specific sequence or the association of a product number and serial number)
- extra context information (is this a request for all details, public details, standardized details, etc.)
- the calling interface (API call expecting JSON, browser call expecting an HTML reply, etc.)
Evaluating these parameters and service settings, the matching service should be capable of returning the appropriate data.
This could range from a customized description page, a redirect to a dedicated service, or a JSON response containing suitable information.
Once this matching is achieved, the DPP tasks are then handled by the DPP service itself.
For more information on the Matching Service, visit the Matching Service page.
¶ DPP Service
Upon handling a request for a DPP from the data carrier via the matching service, the user or third party service will interface with the DPP Service.
The DPP Service consists of various tools that offer both easy user access and advanced management of intricate scenarios.
At minimum, this service maintains a simple database linking unique identifying numbers; however, it can utilize multiple technologies to deliver:
- Shared databases
- Shared ledger technologies (including SmartContracts)
- Digital signatures (with advanced key management solutions)
- etc.
For further details about KeeeX's DPP Service proposal, please refer to the DPP Service page.
¶ Technical Overview
Outlining the main aspects of each technical component without delving into their practical implementations would look as follows:
A minimal solution could do away with the load balancing, though it would compromise the availability of the service.
However, this approach might not be optimal as it may increase the risk of downtime for the service.
The DPP database can be a collection of different technologies, some proposals being outlined in the DPP Service page.
The technology choice depends on business constraints and requirements for flexibility and interoperability.
The matching service and the DPP service frontend are relatively lightweight services and are easily scalable.
The biggest constraint on the solution is the DPP backend, where most of the operations are handled.
The single-point-of-failure issue with the DPP backend should be addressed by making it highly available.