While the rest of the solution up to the matching service remains static, the DPP service is dynamic in nature.
In addition to serving static data, such as user guides and general manufacturing details, it can provide actual details about specific units, including a series of events that affect the product.
These dynamic DPP capabilities are constrained by a set of rules regarding content, accessibility, and modifiability.
The KeeeX proposal is based on outcomes from multiple previous projects related to traceability, discussions in various fields of application, and other relevant experiences.
Static components of a DPP, linked to either a product series or a specific unit, are handled through basic linking between product identifiers and static data sets.
Dynamic components of the DPP involve a series of events whose content indicates all considered life-cycle events surrounding a physical unit.
These event formats are designed to accommodate various future extensions to their content and to handle the addition of new types of events.
This event view enables both the creation of a trail of life-cycle events and changes to the 'passport' parts of the DPP, providing a set of properties that can be updated or created as needed.
These properties (static content and events) are associated with different access levels, offering a public view of a given DPP and a private view of the same DPP with additional information depending on the user's permissions.
Access control depends on the authenticated user and may include delegation of permissions to third parties, such as qualified repair services, to closely follow the 'live' state of a unit.
The concept of a keeexed file refers to a regular file that has been processed to embed metadata within it, rather than creating a separate entity.
This embedded metadata includes:
In addition to embedding this metadata, keeexed files remain fully usable in their original format.
A keeexed PDF file remains readable with standard PDF readers; a keeexed image can be viewed in standard image viewers, and so on.
keeexed files also possess verifiable properties, allowing for independent auditing, and they carry proof of authenticity that is transported when the file is extracted from the solution.
This means that a keeexed file downloaded from the DPP service can still be confirmed as authentic and unedited by any future recipient of that single file.
The DPP is structured to formalize its content, ensuring ease of use and indexing, while also allowing for future extensions and additions without compromising the solution's core.
A given DPP, focused on a single unit, consists of two main components: static data and events.
The static data comprises files in various formats, which are processed using KeeeX technologies to ensure their verifiability and authenticity among relevant stakeholders (manufacturers, distributors, etc.).
The events are comprised as a series of JSON objects that adhere to a simple top-level format with generic properties.
This structure enables the addition of custom content for specific events as needed.
The combination of static files, 'life cycle' events, and 'data update' events provides a comprehensive view of the DPP associated with a unit at any given time.
A set of static data can be associated with any given DPP.
Furthermore, it's also possible to reference the same data from multiple DPPs, which is often the case for a product series.
These static data are expected to be keeexed, a process that preserves the file's immutability and allows for proof of its authenticity.
The resulting keeexed files behave as they normally would (e.g., a keeexed PDF file can still be opened by a PDF viewer), and they remain autonomously verifiable even after extraction from the DPP solution.
Static files are expected to be digitally signed by recognized authors, such as manufacturers, etc.
The events associated with a DPP are built as a string of events, linked by cryptographically secure elements.
This forces the order of the events in a way that cannot be reordered, and in which events cannot be inserted or removed without breaking the chain of events.
The solution considers two types of events:
Some events may fit both categories (for example, a change of ownership is a lifecycle event that also triggers a change in the identification of the unit's owner).
The JSON format is similar to the following (pending definitive implementations):
{
"version": "1a",
"propertyUpdate": {
"dpp.owner": "new owner public key"
}
"type": "kx.dpp.ownerChange",
"data": {
"reason": "Item gifted"
}
}
A set of formalized properties, namespaced with dpp. is used as the common base for interoperability.
The type of event is also a scoped string, allowing known behaviors and compatibility with future unexpected behaviors without risk of conflicts.
The data part depends on the type of event.
The propertyUpdate field is a map of properties that have changed.
If it's present, the event is considered to be a "data update" one.
These events, as are the static data, are keeexed, providing additional metadata related to timestamping, authenticity, digital signatures, and reference to previous entries.
In addition to the events, an efficient mechanism for attaching files allows embedding references to other files as needed (pictures, PDF files, etc.)
These attachments are also expected to be keeexed to bring proof of their authenticity.
Both attachments and events, as well as other keeexed files, allow independent verification and validation of their content outside of the provided DPP solution.
A full list of expected core properties is yet to be defined.
The presence of a version indicator allows for potential evolution of even the core identifier when/if needed in the future, to conform with as-yet unknown standards and evolutions.
The base DPP Service would operate as the minimum common denominator against multiple users, meaning it should operate at least with regular user accounts (most likely tied to email addresses).
KeeeX considers critical to embed digital signatures from every actor in a solution.
To this end, each user is associated with a cryptographically secure key pair, which acts as proof of identity for the user's actions.
This secure key pair initially behaves as a custodial key, but remains inaccessible to the service, ensuring the user's control over their authenticated actions.
KeeeX's solutions are also able to integrate with more advanced or involved key management schemes if needed.
In addition to users' digital identities, each actor (manufacturers, etc.) should be known and have its own dictionary of associated identities.
While KeeeX provides a basic directory service that can be used as such, KeeeX's core technology only cares about producing and embedding digital signatures, remaining compatible with a large set of tools for identity management that operate above the core handling of files and signatures.
A third type of actor is considered in our proposed solution.
Advanced NFC tags allow the registration of a unique tag as a digital signatory associated with a product.
By using KeeeX technology, based on (possibly public) ledgers and bi-directional cryptographic references, a physical product can itself be registered as part of the DPP solution, requiring proximity to the physical object to perform a selection of operations.
This also provides a mechanism to ensure that a unit's references are not copied or transferred to another unit, proving its authenticity.
This is rendered possible by the initial registering of the unique tag's cryptographic key with its associated DPP.
The core implementation is based on a regular DBMS and keeexed files.
The keeexed files are the first source of trust; the database is essentially responsible for user management and performance improvement.
The service is designed to work with a PostgreSQL server as its DBMS.
Storage is done through an S3 interface (AWS S3, OVH S3, etc.).
However, multiple future developments are envisioned, including:
However, these approaches are not all compatible with all the requirements of large-scale solutions, have performance impacts, and need to be examined carefully.
The core of the DPP Service is the management of events, through a permission matrix and a set of rules.
To provide end-users with visibility on the DPP, the service exposes an API to retrieve events, and the associated data.
It also provides a SPA that can interact with that API, and provides user-side services that can handle cryptographic operations for authentication and digital signatures.
The details of the split for the DPP service are presented in the architecture page.