Available via license: CC BY-NC-SA 4.0
Content may be subject to copyright.
Digital Product Passport Management with Decentralised
Identifiers and Verifiable Credentials - Extended Version
Ismael Ill´an Garc´ıa1,∗, Francesc D. Mu˜noz-Esco´ı1,2, Jordi Arjona Aroca1, and F. Javier
Fern´andez-Bravo Pe˜nuela1
1Instituto Tecnol´ogico de Inform´atica, Camino de Vera, s/n, 46022, Valencia, Spain
2Universitat Polit`ecnica de Val`encia, Camino de Vera, s/n, 46022, Valencia, Spain
Abstract
Digital product passports (DPP) have been proposed in the European Ecodesign for Sustainable
Products Regulation (ESPR) as a means to keep and provide product information that facilitates product
reusage, reparation, and recycling. Thus, DPPs should provide a positive effect on the environmental
impact of future manufactured products, preventing waste and promoting a circular economy (CE) model.
ESPR settles a set of requirements in collecting and administering product-related data. Decentralised
identifiers (DID) and verifiable credentials (VC) are two self-sovereign-identity-related elements that may
help in that DPP management since they introduce a decentralised administration of identity that may
enhance the overall scalability of the resulting system, improving also its reliability. This paper analyses
the ESPR requirements and describes how they may be achieved using DIDs and VCs, assessing their
performance in some scenarios.
Keywords— Digital Product Passport, Verifiable Credential, Decentralised Identifier, Circular Economy
1 Introduction
Digital product passports (DPPs) provide a verifiable collection of data about products’ composition, environmental
impact and opportunities for preventing waste [26]. Thus, the DPP should be a key element in the development of
a Circular Economy (CE) and this has led the European Commission [14] to a regulation on what DPPs shall be in
order to implement and use them in a few years.
Although CE initially referred to an economy system based on a three-action strategy, usually known as 3R
(i.e., Reduce, Reuse and Recycle), recent proposals (e.g., Potting et al. [30]) have extended it to a larger number
of complementary actions (9R): R0 Refuse (Make products redundant by abandoning their function), R1 Rethink
(Redesign to make product use more intensive), R2 Reduce (Consume fewer natural resources while the product is
manufactured or used), R3 Reuse (Other consumers may use again a product that is still in good condition), R4 Repair
(Repair a defective product instead of discarding it), R5 Refurbish (Restore an old product), R6 Remanufacture (Use
parts of discarded products in a new product with the same function), R7 Repurpose (Use parts of discarded products
in a new product with a different function), R8 Recycle (Process materials to obtain the same or lower quality) and
R9 Recover (Incineration of materials with energy recovery). There, R0 to R2 promote smarter product use and
manufacture, R3 to R7 extend the lifespan of products or their parts while R8 and R9 advise on a useful application
of materials. The information kept in a DPP assists the different agents that participate in those actions (e.g.,
suppliers, manufacturers, retailers, customers, repairers, recyclers...) to build an efficient CE ecosystem.
But the implementation of DPPs will not be trivial. There are many facets to consider: (i) their information should
be accessible by the customers, to easily choose the most adequate (in regard to environmental footprint) alternative
when any product should be bought, (ii) manufacturers should state in the respective DPP the composition of every
product they sell, but that information –in some specific manufacturing areas– may have been kept traditionally
∗Corresponding author. E-mail address: iillan@iti.es
1
arXiv:2410.15758v1 [cs.DC] 21 Oct 2024
secret and may provide some advantages to their competitors, (iii) recyclers may need multiple data from DPPs, but
not necessarily those of interest for the customers... In the end, different users of the DPP need different data from
it. How can we design, implement and manage a tool like this?
Decentralised identifiers (DIDs) [35] and verifiable credentials (VCs) [32, 33, 34] may provide a good basis to
solve those problems. DIDs are a specific kind of identifier designed for supporting self-sovereign identity (SSI) [3].
In a SSI system, each individual may generate and use its own DID(s) when needed, and associate information to
them with VCs. The novelty is that such identity-related information is now managed and presented by the identified
individual when it considers, instead of being kept and administered by external companies or services, like in previous
centralised or federated identity systems. Now, each person or company will have its own DID and complementary
data in the form of VCs, deciding at each moment which data is presented to others (through verifiable presentations,
or VPs [32, 33, 34]) when those others demand that information in a given interaction. Additionally, those third
parties will not be able to present later that data to other parties, since each action that involves identity-related
information uses a VP that should be signed by the sender and it may be easily rejected and disregarded when the
VP signer is not the subject of the VP. Therefore, with DIDs, VCs and VPs, persons and companies may easily
control which of their own information is presented to others and when and how this is done.
Additionally, DIDs may also refer to inanimate entities, like manufactured products, and in that case their
associated VCs and VPs will be handled by a given controller, specified at DID creation time. In the general case, the
controller for a given product may be its manufacturer or its current owner. Thus, when the information of a product,
that has an identifying DID, is stated in multiple VCs, each one devoted to a specific part, the DID controller may
easily choose which VC is taken for preparing the corresponding VP and deliver that VP to a given requesting party.
Following that strategy, a DPP may be implemented as a collection integrated by a DID and several VCs, with their
respective VPs that present different parts of the DPP (i.e., a concrete subset of the existing VCs) to each requesting
agent (e.g., retailers, users, repairers, recyclers...) depending on the involved product lifecycle stage, as Figure 1
shows.
Providers Manufacturer Controller Verier
Credentials for
product parts
Credential
collection (DPP)
DPP Information
Verifier
Current owner
Figure 1: Composition of DPP information from its components and the selective disclosure of specific
credentials from the owner to the verifier.
Therefore, we consider that the main contributions of this article are as follows. First, the analysis of ESPR [14],
since being an extensive legislative document, it requires considerable effort to read and process all its sections. From
this analysis, the next contribution arises: see the requirements imposed by this regulation for the implementation
of a digital product passport. Finally, it is demonstrated how this passport could be implemented based on the
decentralised identity paradigm, which we believe aligns quite accurately with the previously identified requirements.
To this end, the paper is structured as follows. Section 2 discusses the current state of the art in this research area.
Section 3 explains the requirements for identity-related management derived from ESPR. Section 4 analyses in detail
the problems that need to be solved to implement a DPP system and provides a first draft of a DID-based design
that solves each of them. Section 5 describes how those mechanisms should be implemented. Section 6 provides a
brief discussion on the quality of our proposals and an analysis of their costs. Section 7 describes several use case
scenarios and, finally, Section 8 provides the conclusions.
2 State of the Art
Three different dimensions should be considered in a review of the current state of the art on the usage of DIDs
in the future implementation of DPPs: a brief summary on self-sovereign identity (SSI) management (Section 2.1)
2
that introduces the basic terminology to be used in subsequent sections of this paper, the existing EC regulations on
DPPs (Section 2.2) and the preliminary results generated either by pilot projects or other academic research in this
field (Section 2.3).
2.1 Self-Sovereign Identity
SSI [3] refers to a decentralised identity management where each individual may control and administer what infor-
mation others have regarding its identity, as opposed to centralised or federated identity managements, where that
control belongs to a third party. The World Wide Web Consortium has published several recommendations defining
what should be understood as a DID [35] and how those identity-related data may be transferred among agents [33],
using VCs and VPs to this end.
DID subject
DID
controller
Verifiable
data registry
Stores
identifiers and
documents
controls
DID
did:method:a1b2c3
DID document
DID URL
did:method:a1b2c3/path/to /resource
refers to
contains
refers and
dereferences to
resolves to
stored on
stored on
Figure 2: Basic components of a DID architecture [35].
The main components in a SSI system based on DIDs are depicted in Figure 2. The central element is the DID.
A DID is a URI [7] composed of three parts separated by colons: (a) the scheme (invariable, it should be “did”), (b)
the method name, and (c) a method-specific identifier. A DID identifies a given entity: the DID subject. When a
DID is resolved, we obtain a DID document that stores some information on the DID subject like the cryptographic
public keys needed in different verification methods. That information kept in the DID document may be updated by
the DID controller. Usually, the DID subject and the DID controller are the same entity, but they may be different
when the DID refers to, e.g., inanimate entities, like industrial products.
Issuer
Issues verifiable
credentials
Holder
Obtains, holds and
presents verifiable
credentials
Verifier
Verifies verifiable
credentials
Verifiable data registry
Stores identifiers and schemas
Verifiable
credential
Verifiable
presentation
Verify identities and
use schemas
Register identities
and use schemas
Verify identities
and schemas
Figure 3: Roles and data flows in VC-based interactions [33].
3
In order to refer to a specific field of the DID document, we may use a DID URL that extends the DID with a
pathname that refers to that intended field. DID documents are stored on verifiable data registries (VDR) that keep
all that information persistently (e.g., using distributed ledger technology (DLT), i.e., a blockchain [4]).
Figure 4: Sequence diagram in VC-based interactions.
The information related to a given identity may be accredited or requested by other agents, as it is depicted in
Figures 3 and 4. In that case, such an information is stated in a VC and signed by an issuer A, who generates that
VC and delivers it, using a specific protocol (e.g., [24, 27]), to the VC holder B that keeps it in a digital wallet. In
the regular case, B will be the DID subject entity presented in Figure 2. Later on, B may be required to prove some
identity-related claim in order to get some service from C. To this end, C may demand B some proof about that
claim and B will present a VC stating that such claim is true. So, B takes the VC and signs it, generating thus a VP
that is delivered to C using another specific protocol (e.g., [23, 37]). Now, C behaves as a verifier and recovers B’s
public key from the VDR in order to check the VP signature. If that check is passed, then C assesses whether the
original VC signature corresponds to A, reading A’s public key from the VDR. If all those verifications are successful,
C provides the services that B requested.
2.2 Regulations on Digital Product Passports
The European Commission (EC) has been a pioneer in requiring the use of DPPs. To this end, ESPR [11] was drafted
in March 2022, supported by several funding calls (e.g., [12]) for pilot implementations in various fields. In December
2023, the European Parliament and the Council reached an agreement on that regulation [13], thus passing the next
required stage to reach its final adoption, that occurred on June 2024 [14]. Once adopted, EC should still choose and
regularly update and expand the list of products to be affected by that law, publishing subsequent delegated acts
following a working plan that shall cover a period of at least three years and be regularly updated (as stated in its
Article 18.3 [14]).
ESPR is a large document that consists of fourteen chapters, subdivided in eighty articles, and complemented
with eight annexes. Its first article may be summarised as follows [11]: “Article 1 lays down the subject matter of this
Regulation, namely a framework for setting ecodesign requirements, creating a digital product passport, and prohibiting
the destruction of unsold consumer products. It lays down the product aspects to which the eco-design requirements
relate, such as durability and reliability, reusability, upgradability, repairability, and possibility of maintenance and
refurbishment, presence of substances of concern, energy and resource efficiency, recycled content. It further sets the
scope of the Regulation...” This explicitly shows that the first goal of the ESPR is to drive the European economy
to a circular model.
Chapter III, consisting of Articles 9 to 15 is directly related to DPPs since it states their definition, requirements,
technical design and operation, what unique identifiers are, the existance and management of a product passport
registry, the existance and management of a web portal for data in DPPs, and customs controls related to the DPP,
respectively. Finally, Annex III outlines which data elements shall or may compose a DPP.
There are twelve data elements in that annex, and that list provides an orientation on the information to be
included in a DPP, but the exact contents may depend on the specific product group and on the future delegation
acts for each industrial area. The third element refers to product identification and it requires “the Global Trade
Identification Number as provided for in ... standard ISO/IEC 15459-6 [21] or equivalent of products or their parts.”
4
However, that statement does not prevent manufacturers from complementing the Global Trade Identification Number
(also known as Global Trade Item Number [16], GTIN) with a product DID. Note also that the second data element
in Annex III refers to another unique product identifier as indicated in the corresponding applicable delegated act.
Thus, those subsequent acts may extend the type of identifiers accepted for each product group. Therefore, an
analysis about the convenience of DIDs in a DPP still makes sense.
Multiple ESPR sections define what should be and do a DPP. From them, these may be of specific interest to
our paper goals:
•The three last points in Article 5.11 state that there should not be any disproportionate negative impact on
the competitiveness, nor proprietary technology imposition, nor disproportionate administrative burden on
economic actors (and among them, mainly, the manufacturers) because of the introduction and management
of DPPs.
•Article 9.2 states that there should be specific subsequent delegation acts for each product group (i.e., manu-
facturing area) that consider concrete subsets of DPP management. To this end, multiple points are presented
in that article. Let us focus on the following:
–Point (d) analyses whether the product passport should correspond to the model, batch or item level.
This means that those decisions do not correspond to the manufacturer, but they will be explicitly taken
in those subsequent laws.
–Point (f) mentions “the actors that are to have access to data in the digital product passport and to what
data they are to have access,” depending on their role: customers, end-users, manufacturers, importers,
dealers, recyclers...
–Point (g) specifies “the actors that are to create a digital product passport or update the data in a digital
product passport and what data they may introduce or update.” Thus, it will be ruled and controlled who
may create or update a DPP.
–Point (i) refers to the period for which the DPP shall remain available.
The existance of subsequent delegation acts for specifying some concrete DPP management details for each
product type has reduced the focus of academical research on DPP contents, since the product attributes and
characteristics to be handled in those DPPs will depend on those future delegation acts. In spite of this, some
relevant papers have been published in this regard [6, 22].
•Article 11.(g) requires that the DPP data authentication, reliability and integrity shall be ensured.
•Article 11.(h) demands that “digital product passports shall be designed and operated so that a high level of
security and privacy is ensured and fraud is avoided.”
Section 3 rewrites those conditions into requirements and Section 4 analyses in depth how DIDs and VCs may
be able to support and implement all those requirements, discussing their advantages when those mechanisms are
compared with other alternatives.
2.3 Solutions
Although European CE regulation proposals raised almost immediately a high interest on DPPs [1, 2, 6, 10, 22, 25,
26, 31, 36, 39], there have been few proposals that discuss the design or implementation of DPPs through DIDs. This
is because the very concept of a digital passport is recent, and there are no adopted regulations yet that govern its
structure and the necessary technologies for its development and use.
One of the initial proposals has been that of Dr. Susanne Guth-Orlowski [17, 18, 19]. She states that these
developments are feasible and offer a significant number of advantages. Her proposal does not focus exclusively on
DIDs and VCs; other technologies could be used to this end, but she does provide a primary example based on
decentralized identifiers and verifiable credentials for batteries. As described in [17], all the companies involved in the
lifecycle of a specific product (component manufacturer/supplier, product manufacturer, dealer, repairer, recycling
centre, waste disposal centre) may have their own DID for identification. Both suppliers and manufacturers use VCs
to declare the materials that make up each product component. The manufacturer aggregates these credentials to
create the first version of the passport for a specific reference. This reference has its own DID, and the credentials
may be issued by the manufacturer using the DID of that reference as their subject. On this DID, external auditors
emit certifications to be included in the digital passport. The author suggests using the same identifier for product
batches and, if the composition of the batches generated over an extended period does not change, reusing the same
5
passport for all of them. This proposal pays particular attention to the initial composition of a product and is less
focused on potential changes that may be applied during the useful life of a specific product unit (since that seldom
happens in the battery market) before it reaches the recycling stage. The same approach is applied by Berg et al.[5]
on batches of plastic products.
A problem that arises in [5, 17] is the mention that credentials will be kept in the DLT (i.e., in the verifiable data
registry, or VDR, of the corresponding DID-based system) and can be queried using the DID resolution mechanism.
However, in the World Wide Web Consortium (W3C) standard [35], such a resolution operation obtains the DID
document, which contains metadata (mainly, the public key of that identified entity), but not the credentials. Never-
theless, that DID document may maintain one or more service endpoints to access the services associated with that
identified entity. In [17], it is assumed that one of the services would be the link to the storage location of the verifiable
credentials. According to W3C [33], credentials should be kept in the digital wallets of DID owners, and their issuer
would generate them exclusively for that owner. Since products are not active agents able to initiate interactions,
what is recommended in the standard must be adapted to fit the common scenario for managing passports. To make
everything fit, subsequent articles [18, 19] mention digital twins, so it can be assumed that those twins behave as the
DID controller when managing those credentials that make up the DPP. In any case, the manufacturer could actually
manage some wallet [18] (either its own or those associated with digital twins) that maintains all these credentials.
Therefore, anyone who needs to access the DPP (e.g., a recycling centre) would interact with the wallet maintained
by the manufacturer.
In [18], the main use of the DPP is still for the user to query the initial composition of a product, but at the
end Dr. Guth-Orlowski states that further work is needed about how to add usage information to a product. In this
design the end user is not the controller of the product DID, so she can not issue a VC about certain product and
add it to the DPP. Dr. Guth-Orlowski proposes that the end user receives a delegation key with limited rights to
sign VCs to the product DID.
Moreover, the protocols to be used for interaction between wallets in a DID-based system are not specified in the
W3C recommendations. Therefore, this author mentions [19] some alternatives (DIF DIDComm Messaging V2, DIF
Presentation Exchange V2.0, OpenID Connect, OID4VC, OID4VP...). The fact that W3C has specified a metasystem
means that there are many viable approaches to managing a particular type of interaction. This should facilitate
interoperability with existing systems already in production, but it complicates the development of hypothetical
generic wallets due to the high number of protocols to consider and the diversity of configurations that each one
supports.
A second proposal has been developed by Leandro Navarro et al. [28]. In this case, it does not analyse the
management of DPPs in a general sense but focuses on a specific scope: digital devices. These devices often consist
of multiple digital components, each with its own reference and composition. Therefore, in this case, a complex
product must be managed, created by assembling a large number of parts, each with its own information about the
materials used in its manufacture. Additionally, during their lifespan, these devices may malfunction and require the
replacement of some of these components to complete their repair.
Similar to Guth-Orlowski, Navarro advocates the use of DIDs to identify these devices. However, there are
significant differences compared to Guth-Orlowski’s proposal. The first difference is that the DPP will not be a set
of verifiable credentials but another ”identifiable entity” and, therefore, will have its own DID, derived from the DID
of the digital device it provides information about. This duplicity also affects the DIDs to be managed, which will
use two different methods in their respective URIs, resulting in the following DIDs:
•did:eCHID:CHID for the products.
•did:eDPP:CHID:PHID for the passports.
Here, “chid” refers to the “chassis” identifier, which represents the original configuration of a digital device.
Typically, this identifier would consist, in a specific sequence, of the manufacturer’s identifier, the product’s reference
number within that manufacturer’s catalog, and the serial number. On the other hand, “phid” (from “product
hardware identifier”) will be a number generated by a certain benchmarking application that considers each of the
pieces that make up that device. When a component is replaced during a repair, it will result in a modification of
the “phid” that identifies the device.
Therefore, when the device is created, its manufacturer will generate its DID, as well as the initial version of its
DPP. The DID document for its DPP will contain all the relevant information about the materials that make up that
device. Perhaps this initial description includes the information present in the DPPs associated with its components,
if they exist. Every time, during its lifespan, the device undergoes a change in any of its elements, a new DPP will
be generated (as there will be a change in the final component of its DID: the “phid”), along with its associated
document, and it will be stored in the VDR.
6
As we can see, this second proposal does not manage VCs, and it is not documented that traditionally associated
public keys of a DID are used. Instead, the relevant information about materials used will be directly stored in the
DID document, but not for the product’s DID, but for the DPP’s DID. By using this architecture, there is no need for
the use of digital twins to manage credentials or private keys, as DIDs are not used for authentication or credential
management but solely to access persistent information present in DID documents.
3 Requirements
Section 2.2 has enumerated several articles in the ESPR that are somehow related to identity or to access permissions
and that could determine several requirements in the management of product identities or entity accesses. Let us
translate now those articles into specific requirements:
R-01 Product identifiers should comply with the standard ISO/IEC 15459-6. Those identifiers are also known as
global trade item numbers (GTINs). This requirement is derived from Annex III of ESPR. Therefore, DIDs, if
any, should complement GTINs, and be another data element in the DPP, instead of replacing them. Anyway,
VCs and VPs may be associated to other identifiers (e.g., GTINs), when no DIDs are used.
R-02 A DPP generic implementation may support model, batch or item granularity, but for a specific product type
such granularity will be already determined by its specific delegation act. Article 9.2.(d) of ESPR states that
rule. So, DPP granularity cannot change along time in a given type of product.
R-03 DPPs should be adequately stored and maintained along the product life cycle. Thus, at least one agent should
carry out the involved tasks, i.e., one (or, perhaps, a given subset) of the actors in a DPP system should be
responsible of keeping the DPP data along the life cycle of the products. Besides, that responsibility may
dynamically change from one actor to the next when a product makes a transition to a different stage of its
life cycle (e.g., a person sells its car to a garage, where it will be carefully revised, repaired if needed, and put
again for sale; in a scenario like this, DPP maintenance responsibilities might be temporarily assigned to the
garage). This is not a direct requirement extracted from the ESPR articles, but it conditions how to implement
some solutions to other subsequent requirements (e.g., R-04, R-05, R-06 and R-09).
R-04 DPP data shall remain available for a specific time interval. The length of that interval depends on the product
group being considered and will be determined in the corresponding delegated acts, but it should be, at least,
long enough to preserve the DPP information until the complete life cycle of all the products referred in that
DPP has been exhausted, thus making possible that the corresponding recycling centres appropriately process
those products. The chosen DPP implementation mechanisms should take this into account. In specific types
of long-lived products (e.g., buildings, cars...) the data should remain available even when the manufacturer
company has ceased to exist (e.g., because of bankruptcy). This is derived from Article 9.2.(h) in ESPR.
R-05 Only specific actors, at specific stages, may create a DPP or introduce or update any data elements in the DPP.
This is a result of Article 9.2.(g) of ESPR. The design of the DPP system should specify which of the actors
keeps the product-related data, as it has been already mentioned in R-02. Should it be a single actor or there
may be some collaborative managers? Once this issue is solved, that manager or set of managers should also
control which actors may create new DPPs or update the existing ones.
R-06 Access to different information items of the DPP should be controlled and its permission will depend on the
specific role of the requesting actor. This is a consequence of Article 9.2.(f) in ESPR. Manufacturers, dealers,
retailers, importers, customs officers, customers, end-users, repairers, recyclers may only access to subsets of
the information present in a DPP. So, some (role-based) access control mechanism is needed to handle this.
The rules to be followed will be stated in specific delegated acts for each product group.
R-07 DPP data authentication, reliability and integrity must be ensured. This is directly stated in Article 11.(g) of
ESPR. So, DPP data should be only written by the intended agents, who should certify their identity in that
DPP creation or update stages. Besides, DPP data, once written, should become immutable to ensure its
integrity.
R-08 DPPs shall be designed and operated so that a high level of security and privacy is ensured and fraud is avoided.
Again, this is directly stated in the ESPR; in this case in point (h) of its Article 11. Fake DPPs must not be
forged and accepted. Security and privacy were already partially addressed in requirements R-05, R-06 and
R-07.
7
R-09 DPP management should introduce, if any, a negligible burden to all economic actors. This is derived from
Article 5.11 of ESPR. The technologies to be used should be open and should not introduce any noticeable
costs that could endanger the competitiveness of the manufacturer or any other actors.
All these requirements can be easily met when DIDs, VCs and VPs are jointly used to manage product identities
and product certifications. That fact is analysed in detail in the subsequent section.
4 Analysis
Each of the proposals presented in Section 2.3 has made a set of design decisions, concerning decentralised identifiers
and verifiable credentials, that lead to the implementation of digital product passports. This section focuses on those
approaches, and complements them with other considerations to carefully analyse how the requirements presented in
Section 3 could lead to different DID-based (or VC-based) designs for DPP management systems.
4.1 Product Identification (R-01)
As stated in Section 2.2, ESPR currently mandates, in its Annex III, that products should use ISO-15459 identifiers,
tolerating also other complementary identifications. Therefore, DIDs could be also added to a DPP, without replacing
ISO-15459 identifiers, and such strategy does not endanger ESPR compliance. In spite of this, other research works
have tried to integrate those ISO identifiers in DIDs, creating or suggesting specific DID methods to this end.
As an example of the first approach, in [18], it is shown how DIDs could be integrated with an identifier accepted
in ISO-15459, such as a GS1’s digital link. Those links encompass a GTIN with some complementary information.
Thus, that digital link may be added to the DID document to relate both identifiers: GTIN and DID.
Similarly, another solution in this first approach could be to include the ISO-15459 identifier as an additional
attribute within the DID document, somewhat akin to the utility of the “alsoKnownAs” field defined in [35]. Assuming
a DLT network is used as a VDR, this solution would result in additional read load because finding the product’s DID
document from its ISO-15459 would require sequential reads until the correct one is found. Without a mechanism to
facilitate this process, this solution would not be viable. However, other VDR implementations are acceptable, and
they may introduce no penalty on read access time.
On the other hand, as an instance of the second alternative, Dr. Guth-Orlowski proposes to encourage the
various organizations that have standardised product identifiers (i.e., ISO/IEC and GS1) to create a DID method
that includes the identifiers generated from each standard. For instance, the DIDs to be used in DPPs might become
did:iso-15459:<iso-15459-id>. However, it is improbable that this solution will succeed because those organizations
have displayed no interest in the implementation and use of DIDs.
Finally, it is worth noting that, as an alternative approach, ISO-15459 identifiers could be the single way to
identify products, since products are the unique passive entities in this CE ecosystem, while DIDs might be used
for identifying the other entities (i.e., active agents) that intervene in the product lifecycle: manufacturers, dealers,
customers, end-users, recyclers... Indeed, GS1 proposes in a recent white paper [9] that verifiable credentials should be
used for certifying several product data with GTINs as the product identifiers in those certifications. This eliminates
the need of associating a key pair for every identified product, since no DID document should be kept for them.
However, that white paper also shows how to combine DIDs and GTINs, since VCs still use DIDs as the VC identifier
while the GTIN identifies the intended product on which some certification is made.
Therefore, from the analysis of this first requirement, these design alternatives have been generated:
D01.1 DID and ISO-15459 identifier coexistence in DPPs. VCs and VPs may refer to the DID embedded in the DPP.
All three elements of SSI management may be used in DPP management.
D01.2 ISO-15459 identifier integration in DIDs, using the resulting DIDs in DPPs. This choice preserves the func-
tionality of the D01.1 alternative and, additionally, should not worry about identification duality, since the ISO
identifiers are embedded in the DIDs. Its management should become easier than D01.1’s one.
D01.3 Only ISO-15459 identifiers are used in DPPs. Product identification is not based on DIDs in this alternative,
but VCs and VPs may still be used, referring to ISO identifiers instead of DIDs. Since passive entities, like
products, will not require many identifiers along their existence, but only a single one, no complication arises
if VCs refer to ISO/EIC identifiers (e.g., GTINs). VC-based management is still possible in this alternative.
8
4.2 Support to Multiple DPP Granularities (R-02)
Article 9.2.(d) of ESPR identifies three different granularities for managing DPPs: model, batch or item. That means
that for simple (or cheap) products that are usually discarded once they reach the end of their lifecycle, a single DPP
per product model is enough: it will provide enough information (raw materials, weight, physical dimensions...) to
deal with the product recycling and all items share the same characteristics. When some of those characteristics may
change from a batch to the next, a DPP per batch will be needed. Finally, for more complex products, composed of
multiple parts with different raw materials per part or able to be repaired in case of malfunction, a DPP per item
will be used.
In general, in all DPP types, a DID (or even none if D01.3 is chosen) per DPP is needed. Besides that, these
other aspects should be considered, leading to the following design choices:
D02.1 When the D01.3 design alternative has been chosen (i.e., no DID is used for product identification), products
with a DPP per model or per batch will store the product information in a registry (e.g., a database) whose
access might be controlled using VCs.
D02.2 In products identified with DIDs and with a DPP per model or per batch, product information should be
stored in the DID document. Although the DID document is a structure that holds certain metadata of the
entity (designed to maintain at least the public keys and access points to the corresponding service), the W3C
specification [35] allows for other information to be logically stored within it. To this end, those data that
are not directly related to the standard document attributes, may be stored separately (as mentioned in [17])
and made accessible through the service endpoints kept in the document. Therefore, it would be advisable to
establish what attributes could be included in that document regarding the product composition and the parts
that can or should be recycled and the reasons for it.
D02.3 In products with a DPP per item, the composition of each recyclable piece should be documented using VCs,
as suggested by Guth-Orlowski in her articles [17, 18, 19]. This requires the creation of specific VC schemas
that describe the structure that VCs should have.
4.3 DPP Maintenance (R-03)
It is necessary to specify who is responsible for maintaining the digital passport of a product. At the beginning of a
product’s lifecycle, the manufacturer will generate its DPP and logically, will be responsible for maintaining it. The
diversity of options arises in the subsequent stages of the product’s life. Once the product is sold for the first time,
updating the owner within the DPP, as discussed in Section 4.5, becomes necessary. With the change in product
ownership, does it make sense to transfer control of the DPP to the current user of the product? This decision again
depends on the nature of the product. If the DPP identifies a batch of products, such as plastic chairs, which are
not expected to undergo repairs but are intended to go directly for recycling once damaged, having the manufacturer
maintain the DPP would not involve any additional effort. If the information is registered in the DID document, it
would be publicly accessible to all users and agents involved in the product’s life cycle. In order to register changes
within the DPP, the manufacturer could grant limited rights cryptographic keys, through which the agents involved
in the product’s life cycle can add specific information about their activity.
However, if we consider a more complex product instead of a batch of simple ones, the scenario changes. In that
case, a credential or a group of credentials may be used to represent the DPP, and that group would need to be
accessible through a digital wallet. An example of a scenario of this kind arises when a person buys a bike, since it
is normal to expect that during the bike lifespan, it will receive maintenance and possibly repairs. So, when the bike
experiences any damage and requires, for example, the replacement of a part, the initial passport generated by the
manufacturer will no longer correspond to reality. In that case, the bike remains the same, but its composition has
changed, and this needs to be reflected in the passport. Once the manufacturer is no longer the owner of a product,
they should not have to continue managing its DPP. It is not feasible for a manufacturer to maintain the DPP for
all the products they produce. If a customer decides to change a product’s parts outside the warranty period, that
responsibility falls on them.
So, the most appropriate way to represent these product updates during its lifecycle will be through verifiable
credentials. These credentials can be issued by an authorised technician or even by the user themselves. For instance,
when a user takes their product to the relevant workshop for a repair, the workshop will issue a credential detailing
the changes made to the product. At this point, the product’s DPP will consist of a combination of the initial DPP
generated by the manufacturer and the credentials the user holds in their wallet for that product. To achieve this
resolution, two calls will be necessary. However, for a higher degree of decentralization, it’s possible to provide the
9
user with a copy of the DPP at the time of purchase to store in their digital wallet. This enables the entire resolution
process of the DPP to be completed in a single call.
Thus, the design choices that arise in the analysis of this requirement are:
D03.1 No action. When D02.1 or D02.2 choices have been adopted and the product is so simple that it should be
recycled once damaged, no specific action is required to support R-03.
D03.2 Change of DID controller in DPPs supported by DID documents. When D02.1 or D02.2 choices have been
adopted and the product may change ownership along its lifecycle, a specific mechanism should be designed
and implemented to change the DID controller entity.
D03.3 VC transfer in DPPs supported by VCs. When D02.3 has been used, a specific mechanism for transferring VCs
to a different product owner or manager may be needed.
4.4 DPP Data Availability (R-04)
In order to handle this requirement, two complementary facets should be discussed: (a) where to place the DPP
data, and (b) how to handle its persistence along time. However, note that this requirement is implicitly met, since
its solutions are directly derived from the design notes stated in R-01 to R-03.
4.4.1 DPP Data Location
DPP involves the gathering of information related to the product. The size of this collection varies depending on
the complexity of the product. For simple products that do not undergo a complex recycling process and do not
require repairs during their lifecycle, the passport will contain basic information such as the product’s identity (serial
number, model, description), manufacturer information, raw materials used in its composition, carbon footprint
in its manufacture, carbon footprint in its usage, and relevant dates (production, sale, recycling). In more complex
products, in addition to the aforementioned details, it is expected to include additional information such as warranties,
repairs, certificates issued by external auditors, as well as the ownership history of the product. A complex product,
in turn, may be composed of a combination of other complex and simple parts, and information about these should
be referenced in the final product’s DPP.
As explained, the DPP for simple products will have a shorter length. In that case, the information about their
DPPs can be recorded in the DID document itself. Alternatively, it can be presented in the form of a verifiable
credential issued by the manufacturer at the time of production, with the ISO-15459 identifier as the subject of the
credential. Normally, verifiable credentials contain two DIDs: the issuer and the subject. The W3C recommendation
allows for the possibility of omitting the subject DID in scenarios where the credential controller is irrelevant, and it
is only necessary to know who issued it and what information it contains for verification; this is known as a bearer
credential.
In the case of complex products, the situation changes. The option of using the DID document to record DPP
information implies that this document should reference the rest of the documents for the components that make it
up, potentially forming a tree with several levels of depth. This would result in as many blockchain calls as nodes in
the tree, considering the slow reads in this type of network. For example, a bicycle can be composed of around 250
pieces depending on its complexity. For this reason, this option may become impractical. On the other hand, the
option that has appeared most frequently in the analyzed solutions is the idea of forming the DPP as a collection
of verifiable credentials. These would be stored in the owner’s wallet, making the passport inquiry a single call to
their wallet. The credentials forming the DPP can be of different types, presenting different information schemes for
each scenario. Within the collection, you may find the initial product credential, credentials about possible repairs,
maintenance, or previous purchases, as well as a list with the DPP of the components that make up the product.
4.4.2 DPP Data Persistence
Simple products may keep their DPP information in their DID documents, since in the regular case that information
does not need to be updated or extended along time and may be shared by all the manufactured items with the same
model or product reference. Note that DID documents are kept in the VDR and that VDR is immutable in most
DID systems. Therefore, there will be no trouble to ensure data persistence in that case.
On the other hand, complex products may raise some difficulties, since they cannot hold their DPP data in a DID
document. At a glance, the most realistic choice is to keep those data in multiple VCs, one per kind of information.
Those VCs have been generated by the manufacturer and they will eventually be kept by the product owner, in its
10
digital wallet. If the product is sold, those VCs need to be transferred to the new owner. Similarly, at the end of
the product lifecycle, a VCs transfer or final conversion into a set of VPs to the recycling centre will be applied.
Therefore, VCs transfer should be implemented in order to manage this kind of DPPs.
4.5 DPP Creation and Updating (R-05)
Identifying products with DIDs offers certain design advantages in regard to product-associated data insertion or
updating, as the W3C DID recommendation [35] has several sections dedicated to this specific scenario. A DID
can refer to a subject but be controlled by another. In this case, a product would never control itself; there must
be an owner at all times who carries out interactions on its behalf. For this reason, the DID document supports
a ’controller’ attribute, which defines the controller of the said DID. The cryptography made public in the product
document would be generated and controlled by its owner. Initially, this would be the manufacturer. Subsequently,
when a change in ownership is needed due to the product sale, simply updating the document by overwriting the
’controller’ field with the new owner’s DID would suffice.
However, identifying products without DIDs brings about certain issues, so let us discuss what it would mean to
not use them for product identification. Without a DID, the mechanisms defined by the W3C mentioned above are
lost, so new mechanisms must be established through verifiable credentials. This alternative would involve the use
of possession credentials. At the beginning of a product’s lifecycle, the owner would implicitly be its manufacturer.
At the time of sale to a new owner, the manufacturer would issue a possession credential, which would have the new
owner’s DID as the subject of the credential and the ISO-15459 identifier of the product just acquired as an attribute
of the subject. This information will be attested to by the signature the manufacturer adds to the credential.
This design is akin to using purchase receipts in the physical world. It would simplify interactions, such as
requesting a product warranty. In this scenario, the owner would create a verifiable presentation of the credential
issued by the manufacturer at the time of sale. However, in a more realistic scenario, a product will pass through
many owners during its lifecycle. After its initial sale, a product might be gifted or designated for resale. In these
situations and others of a similar nature, the transfer of product ownership necessitates the generation of another
possession credential by the current owner for the subsequent owner. This new credential would include the previous
credential issued by the manufacturer, effectively creating a chain of easily verifiable credentials.
As we have seen, R-05 may be met reusing the tools available for supporting previous requirements. Nothing else
needs to be considered here.
4.6 DPP Access Control (R-06)
In the general case, a DPP stores different kinds of information and each kind may be only of interest to a few
agent roles. Perhaps, in some cases, some of those data should not be read by some specific agent roles. Thus, the
DPP maintainer, if any, should take care that each agent role can only access those data it is authorised to. To this
end, VCs may be provided to interested readers, stating the role they may play in the DPP system and providing
permission for some specific types of access on the interesting data.
For instance, a customer may be interested in some of the raw materials a product is composed of, e.g., in specific
allergens. DPPs may include a complete list of the product’s raw materials, since that information may be required
at the recycling stage, not being available to regular consumers, though. However, if any of those raw materials is an
allergen, then its existence in the list of materials will be readable by every role, even for customers that have not
yet purchased the product.
So, let us analyse how to manage different categories of information depending on its availability (e.g., publicly
available, available for specific roles, or only available to the owner) and which access controlling mechanisms may
be used to handle them.
Information publicly available may be kept in locations (e.g., product documentation included in the product
package, or in a website) that do not require any specific access control mechanism.
Information available to specific roles may be placed in a location that requires electronic access. Such access may
be controlled requiring that the specific role is proven using a VP that shows the ownership of a given VC stating that
such an agent belongs to that requested role. Thus, the service that controls those accesses behaves as a credential
verifier and will accept those attempts when they carry the required VP.
Therefore, the mechanisms that control product information accesses may be VCs and VPs, since they are able
to handle such management. However, nowadays, it is impossible to place any design choices or considerations in
R-06, since ESPR Article 9.2.(f) states that the security policies to be followed should be stated in future delegation
11
acts and will depend on the concrete product group being considered. Because of this, no concrete design choice may
be defined yet.
4.7 Data Authentication, Reliability and Integrity (R-07)
DID-based systems use a VDR [32, 33, 34] to keep some information, like DID documents, for instance. Blockchains
may be used for implementing VDRs. Thus, VDR immutability and integrity may be easily ensured. If DPPs are
implemented using DIDs, some invariable identity-related attributes of a DPP will be kept in the VDR (or in an
external database that synchronises the DLT contents [15], if read access time would become an issue), since they
could be stored in DID documents.
Those other parts of a DPP that could vary along time may be written and handled as VCs. VCs are not kept
persistently in the VDR, but they are delivered to the interested agents, who keep them in their digital wallets. But,
again, that information becomes immutable in its validity interval (note that VCs have an expiration time or date)
since the corresponding data structure has been digitally signed and any tampering attempt will be easily detected.
Besides data integrity, those signatures also ensure that the information has been generated by the intended party
and that the protocol that handles such information is reliable.
A third type of information that may be of interest in the DPPs of some specific product groups is that related
to traceability of relevant supply chain events. This kind of data will be implicitly stored in DPPs if the DPP of a
complex product hierarchically (i.e., recursively) includes the DPPs of all its components and each DPP stores an
ordered list of the events that have generated that item.
Thus, all aspects considered in this requirement can be successfully met with DIDs, VCs and VPs. So, no design
choices arise here.
4.8 Fraud Avoidance (R-08)
Most industrial products use GTINs as their identifiers and those GTINs can be easily seen using the appropriate
data carrier (in many cases, a barcode in their label). With GTINs, product identification becomes trivial, but,
unfortunately, its support for preventing frauds from happening is too limited: that barcode can be copied and
attached to a fake clone. Depending on the quality of that clone, it might be impossible to detect that fraud.
DPPs should be able to avoid those fraud scenarios. To this end, DIDs, VCs and VPs may be helpful. Thus, each
time a new stage is reached in the product lifecycle (mainly, in the initial ones from its manufacturing, distribution,
storage at the retailer, and sale to its first end user), that transition could be recorded generating a new VC that states
the transition date and time, with the involved parties. That VC will be presented as the input for the next stage,
where another VC will be added, generating a chain of VCs that records all those events. If all those agents identities
and public keys are maintained at a given commercial VDR (i.e., a public registry that contains the name and public
keys of all legal commercial companies, e.g., suppliers, manufacturers, distributors, retailers...), the authenticity of
those steps might be verified by the customer at purchasing time. In that way, no fake product had any opportunity
of confusing the customer, since those involved fraudulent actors would not be able to present a valid signature in
their claimed VCs.
In that scenario, a key element is to compel every agent to create and sign a new VC that includes all the existing
path of previous stages/VCs. Thus, if a fraudulent retailer FR tries to impersonate a legal one LR, FR will not be
able to do so, since it does not know LR’s private key for signing that final VC. Moreover, if FR signs that VC with
its own FR (private) key, that fact will be also detected by customers:
•FR’s identity and key will not be in the commercial VDR previously mentioned. Thus, the VP to be presented
to the customer will not have any verifiable signature since FR does not know LR’s private key. Therefore, FR
uses its own private key for signing the VP and its corresponding public key will not be in that public registry.
•In the previous product lifecycle stage, the generated VC had a given subject that would not match FR’s
identity, but LR’s one.
A system that follows a similar approach (in the sense of using a chain of related VCs) has been designed and
presented (although it is still a work in progress) by the W3C [29]. In its Appendix B.2, that working draft explains a
use case where VCs provide claims about companies and products identified with GS1 keys (e.g., product identification
is managed with GTINs). Since every VC may be identified using a DID, the next VC refers to the previous one
using its DID. In that way, a chain of related VCs may be easily implemented.
Thus, to appropriately handle R-08 a new design note should be provided:
D08.1 A chain of related VCs is needed. Each element in that chain certifies who and when generated a transition in
the product life cycle.
12
4.9 Negligible Burden to Actors (R-09)
Article 5.5 of the ESPR mentions that all DPP management should have no negative impact on the competitiveness
of the involved actors (mainly, manufacturers, dealers and retailers), nor impose any proprietary technology, nor
introduce any administrative burden for those actors.
Although DID-based identity management is a new technology that has not yet had a wide adoption, it may
help in this regard. To begin with, the recommendations published by W3C about DIDs, VCs and VPs [32, 34]
admit and promote open implementations. Indeed, there are several libraries and tools available that facilitate those
implementations with no licence fees. Once accepted and adopted by the general public, there will be personal digital
wallets that will make VC- and VP-based interactions very easy. Besides, the involved product-lifecycle-related
companies already handle all the information that should be present in DPPs. So, storing also that information in
the required resources for implementing that DID-based system will not become expensive nor time-consuming.
No additional design consideration is needed to handle R-09.
5 Proposals
Let us briefly discuss how to implement each one of the design alternatives identified in Section 4. If any of them
requires a thorough discussion, that explanation is given in a subsequent part.
The three design alternatives (D01.1, D01.2 and D01.3) related to product identification (R-01) have already been
described in detail in Section 4.1 and do not require specific mechanisms to implement them. Implementations of
D01.1 and D01.2 have already been given in related papers [18, 28], while the convenience of D01.3 has also been
thoroughly explained in [38]. Similarly, the design choices outlined in Section 4.2 in regard to DPP granularity
(R-02) have implementations in other papers such as [20] (since it describes how to use VCs to control the access to
a system, as required in D02.1), [28] (for D02.2) and [18, 19] (for D02.3). Similarly, option D03.2 (change of a DID
controller) is an issue that has already been discussed in Section B.12 of the DID recommendations [35], while D03.3
(VC transfers in DPP) becomes a subcase of D03.2 when a DPP supports jointly DID and ISO-15459 identifiers, as
suggested in D01.1, since in that case each product will have its own DID and the current product owner will be
the DID controller. In case of assuming D01.3 (i.e., no DID per product), then D03.3 could be implemented using a
non-fungible token (NFT) per product, modelling product ownership with the NFT ownership. DPP data availability
(R-04), DPP creation and updating (R-05), DPP access control (R-06), data authentication, reliability and integrity
(R-07) and negligible burden to actors (R-09) are intrinsically handled in a correct way when VCs and VPs are used.
Therefore, they do not need any specific proposal for their management.
So, only the mechanisms discussed in Section 4.8 (R-08) demand specific proposals to be described subsequently.
Those descriptions will also analyse which combinations of solutions to the other requirements make sense.
5.1 Management of Verifiable Credential Collections
A DPP will contain relevant information about the product, such as the raw materials it is made from, data obtained
during manufacturing such as CO2produced, or certificates issued by other organizations. In a system based on
decentralised identity, all this information must be contained in the form of verifiable credentials, so the DPP will
not be a simple document but a collection of these credentials. We will refer to this collection generated by the
manufacturer as the original DPP, as it represents the state of a product that has just begun its life cycle and has
not yet received updates.
In the case of simple products or batches of complex products with the same manufacturing process, the DPP will
be identified by the GTIN as a class or product identifier. The original DPP with only the GTIN will be sufficient for
simple products that will only be used to form part of other more complex products or for ob jects that, once broken,
will go directly to recycling without receiving repairs. For complex products like bicycles or cars, it is expected that
they will receive updates such as part replacements or inspections during their life cycle. This makes it necessary
for the DPP to be extensible and for mechanisms to be defined that allow different agents to add information about
a product during the different stages of its life cycle. From the moment of manufacture, the credentials generated
to extend a product’s original DPP will refer to an instance of that product, so in addition to the GTIN, its serial
number must be included.
Using vehicles as an example of complex products, it is expected that the agents responsible for issuing information
about the vehicle after its manufacture will mostly be the workshops that the owner hires for maintenance. When
a workshop performs work, it must issue a new credential to the owner, containing information about the task
performed or the changes made concerning the original DPP. This credential must contain both the product’s serial
13
number and the GTIN to be related to its DPP, becoming part of the collection. Although we refer to all credentials
as a collection, they are not stored together. The original DPP is stored by the manufacturer, and the owner keeps
updates about an instance of the DPP.
The issuance of this credential will have been done privately between the owner and the workshop, but this
extension of the DPP must be published in some verifiable data registry to achieve product traceability. This is
necessary because the newly generated credential will be stored in the owner’s digital wallet, but the owner might
decide not to share this information with other workshops or potential buyers.
The process of resolving a DPP based on credentials and DIDs is well defined in Dr. Guth-Orlowski’s proposal.
In this proposal, from the DID of a product, one could query its document, which must have an address to the
manufacturer’s digital wallet to request the DPP. This solution is sufficient to obtain the DPP of simple or complex
products that have not received updates.
As explained earlier, the original DPP will be generated by the manufacturer and stored and made available for
possible queries by other agents. Although, at the time of purchase, the new owner could store a copy of that original
DPP in their digital wallet, it is not necessarily mandatory as it would duplicate the information.
To perform the process of querying the current state of a certain product’s DPP, one would need to obtain the
original DPP identified by the GTIN, either from the manufacturer or the current owner, and apply in order the
updates that the owner might have in their digital wallet in the form of verifiable credentials. All credentials must
refer to the same serial number.
5.1.1 P08.1: VCs and DID per Product
Working only with credentials results in a lack of traceability, as they are issued and stored privately between the
two interacting agents. To address this, mechanisms are needed to identify both the agents and the product and to
register the events that occur during their interaction. A product, in addition to having a collection of credentials
as its DPP, should also have an associated DID. This new identifier is not intended to replace the current product
identification system (GTIN + SN) but to complement it by enabling a digital twin for each product. The product
will be identified in the corresponding DID document, thus allowing the relationship between the DID, GTIN, and
serial number. By extending the functionalities of DID documents, it could be defined that the controller of the
document corresponds to the current owner of the product. Design options chosen for this proposal are represented
in Figure 5.
Unlike credentials, DID documents will indeed be registered in some public registry. To check who the owner of
a product is at a certain time, it will only be necessary to read the controller attribute of the document. Identifying
the owner publicly would pose a security and privacy issue if personal data such as a national ID or Social Security
number were used. For this reason, the owner should be represented in the document by an anonymous DID that
they should only use for their relationship with that product. The fewer DIDs are reused for different use cases, the
harder it will be to discover the identities of the subjects of those identifiers through DID correlation.
D01.1
D01.2
D01.3
D02.1
D02.2
D02.3
D03.1
D03.2
D03.3
Figure 5: Design options in P08.1.
When the product is sold to another agent and the ownership change needs to be registered, the current owner
(Pn) only needs to replace the controller field of the document with the DID of the new owner (Pn+1), as shown in
Figure 6. With this change, Pnwill no longer have control over the document and will not be able to modify it.
Pn+1 will need to update it to add their own public keys. In most cases, the DID document will be registered on a
DLT-type network, so in addition to being able to consult the current controller, it will also be possible to access the
entire history of owners that the product has had.
14
In the example of DPP extensibility, the need to publish the process in a registry to achieve the traceability
of products and their passports throughout their lifecycle was mentioned. To implement these mechanisms, the
functionalities of DID documents can be employed. Initially, the controller of the product will be the only one able
to make updates to the document, but the DID specification defines the use of delegation keys. These keys would
allow another agent to update the document.
Returning to the example of the vehicle workshop, once the repair is done, the workshop will issue a credential
with the information to the owner. Additionally, the owner must grant permission to the workshop to update the
document and register this event using a hash of the credential. This will allow maintaining the traceability of a
product while keeping the information in the credentials private. Furthermore, registering the credential’s hash in
the document will serve to verify that the owner is not attempting to hide information related to the product in
situations where this information is relevant.
DID update:
authorization
DID update
DID
GTIN
Controller
----
DPP
information
Controller:
NDID update:
credential hash
DPP Creation Owner Change DPP Extension
Controller:
N + 1
Manufacturer Product Consumer WorkshopRepairVC
Figure 6: DPP lifecycle representing the events when the DID information is updated and when a VC is
used, in three different scenarios: product creation, transfer, and information extension.
5.1.2 P08.2: VCs per Product
The previous proposal was based on the use of verifiable credentials to register product updates and DIDs to identify
both the agents performing these updates and the products receiving them. The alternative presented in this section
aims to address the same issue but using only verifiable credentials in all possible aspects, thereby eliminating the
need to identify the product with a DID or to use the functionalities of the DID document.
W3C establishes that the subject of a verifiable credential does not necessarily need to be a DID, as long as it can
be universally identified through the rest of the data. Based on this, a product’s credentials do not need to refer to
its DID, but to its GTIN and serial number. This way, the need to generate an additional identifier for each product
instance is eliminated. However, this does not imply the complete elimination of DIDs, as they are still necessary to
identify the other agents in the chain.
By dispensing with a DID, access to the associated document that specifies the controller’s DID is lost. Therefore,
an alternative that allows the owner to prove possession of the product must be considered. A viable solution would
be to implement a “transfer credential”, a verifiable credential that functions similarly to a physical purchase receipt.
This credential would be issued by the seller to the new owner and stored in their digital wallet.
In the event of a future resale, the current owner would issue a new transfer credential that includes the original
receipt credential obtained from the seller and the current transaction information, such as the date of the sale, the
price, and the new owner. This new transfer credential would be given to the new owner, who would store it in their
digital wallet. In this way, a chain of transfer credentials would be created, tracing back from the current owner to
the manufacturer, including all previous owners and the store where the product was originally sold. This chain of
credentials would serve as proof of possession and allow tracking the product’s ownership history.
15
D01.1
D01.2
D01.3
D02.1
D02.2
D02.3
D03.1
D03.2
D03.3
Figure 7: Design options in P08.2.
As in the previous proposal, it is crucial to ensure that the change of ownership is securely recorded. Since the
issuance of the transfer credential is a private communication, the previous owner could still present their previous
credential, which could be successfully verified. For this reason, during the issuance process, it must be ensured that
the seller revokes their current transfer credential so that the only valid one is the buyer’s. Figure 8 illustrates the
steps in this process.
2. Transfer chain
N - 1 N N + 1
1. Revoke credential N
VDR Revocked VC Valid VC Consumer
Figure 8: Steps for the transfer of control of a DPP through a chain of verifiable credentials, where the last
one represents the current owner.
An alternative to revocation by the owner would be to request that the manufacturer revoke the current credential
and issue a new one for the new owner, acting as a trusted provider. While this option is simpler, it presents
some disadvantages: manufacturers do not have an inherent interest in maintaining a long-term relationship with
the owners, as their interest ends once the product is sold. To address this, incentives could be established for
manufacturers to maintain the service, but they could not be forced. Additionally, the main problem lies in the
dependence on the manufacturer as a trusted provider, which contradicts one of the primary goals of using DIDs and
verifiable credentials: eliminating intermediaries.
Proposal P08.1 explains why it is necessary to register credentials in the DID document. In P08.1.2, since the
product is not identified with a DID, there is no document available for this registration. Therefore, the implemented
data registry must be used to register the hash of the credentials. In the case of a DLT, this would be done through
a transaction that includes the product identifier and the hash of the issued credential.
6 Discussion
This section discusses the advantages and disadvantages of the two previous proposals. A preliminary analysis of the
implications and the feasibility of each proposal presented in the previous section will be conducted.
16
6.1 Pricing
One of the most important factors when evaluating the proposals will be the cost for the users of the system. This
cost will primarily depend on the DLT network chosen for implementation. Public networks like Bitcoin or Ethereum
have transaction costs ranging between two and seven euros, whereas other layer 2 solutions can significantly reduce
this cost to just a few cents.
Beyond the choice of the network, the cost will also vary depending on the specific proposal implemented. This
is because each approach has different operational needs within the DLT network. On the same network, the cost of
these operations can be up to 20 times higher depending on the selected proposal.
For this comparison, we have chosen the Cheqd network as an example. Cheqd [8] is a DLT specifically designed
to support decentralised identity and, at the same time, has significantly lower costs than some of its alternatives. A
clear example is the deactivation of a DID: on the Sovrin main network, this process costs 10 euros, while on Cheqd
it only costs 0.40 euros. On Cheqd, the prices of operations are tied to the price of the network’s cryptocurrency, so
the cost will be approximate and could vary.
The choice of the DLT network and the specific proposal will have a significant impact on the operational costs
for the system’s users. Therefore, it is crucial to conduct a detailed analysis of these aspects during the proposal
evaluation phase. Finally, the cost analysis of the proposals will be calculated from the perspective of the product
owners, as they will bear most of the system’s costs.
In proposal P08.1.1, each product will need to have its own DID. This DID will be defined at the beginning of
the product’s lifecycle. Therefore, the manufacturer will have to assume its cost as an additional manufacturing cost.
On Cheqd, the cost to register a DID is approximately 50 tokens of the network, and during the DID registration
process, Cheqd allows the use of a custom DID document, so there would be no need to update the document after
the DID is registered. On the other hand, to be able to control the identifiers being generated, the manufacturer will
need their own DID. Subsequently, once the product leaves the factory and is sold to another agent, the manufacturer
will need to update the document to transfer its control to the new owner, which would cost 25 tokens. Therefore,
the cost for the manufacturer would be the following equation where xis the number of products and tis the value
of the tokens:
50t+ 75xt (1)
The equation represents the cost of the system for the manufacturer, as they will first need a DID, and from that
point on, it will be 50 tokens for the product’s DID, plus another 25 tokens when the product is transferred.
At the time of writing this article (i.e., June 2024), Cheqd tokens are priced at 0.04 euros, so apart from the
company’s own DID, which would cost 2 euros, each product would have an additional cost of 3 euros. After the
manufacturer transfers the product, subsequent owners would only have to pay 25 tokens, equivalent to 1 euro,
for each DID document update. This would occur whenever the product undergoes an event, such as repairs or
inspections, or in the case of a change of ownership.
With proposal P08.1.2, products would not need a DID, and therefore owners would not have to pay the cost
of updating the DID document. In this system, based primarily on credentials, the cost is significantly reduced, as
both the price of creating a status list for the credentials and updating the list to indicate their revocation is only
2.5 tokens (0.1 euros). The following equation represents the cost for manufacturers, including the cost of an initial
DID, the issuance of the passport, and the issuance of the possession credential.
50t+ 5xt (2)
We say “based primarily on credentials” because both the manufacturer and the other agents participating in the
product’s lifecycle will still need at least one DID. Although the cost of DIDs is present in both proposals and one
could argue that it is not necessary to mention it, it must still be included, as it is an additional cost associated with
using DIDs and verifiable credentials.
6.2 Traceability
Proposal P08.1.1, based on DIDs, offers superior traceability by identifying products with a DID and recording their
events in the associated DID document. This allows any agent with the product’s identifier to verify its ownership
history and received events. Publishing the ownership history and events in the DID document might seem like a
loss of data privacy, but it is important to consider that the owners are not identified with personal information but
with an anonymous identifier, which, for greater privacy, will only be used in relation to the product, thus preventing
correlation.
17
Detailed information about the events is stored as verifiable credentials in the current owner’s digital wallet,
protecting privacy and preventing unauthorised access. Unlike verifiable credentials, which require each issuance
to be recorded on the blockchain, the DID document allows for a more seamless and straightforward query of the
product’s history. This is due to the centralization of information in one place. To achieve similar traceability in
proposal P08.1.2, each issuance would need to be recorded on the blockchain, which is more complex. Moreover,
querying the complete history would require retrieving and verifying each transaction individually, making the process
slower and less practical.
Proposal P08.1.1 offers significant advantages in terms of product traceability, providing a transparent history,
data protection, and efficient queries. While verifiable credentials offer greater privacy, their use for traceability is
less efficient and scalable.
6.3 Chosen Proposal
After analyzing both proposals in detail, it is time to evaluate which one is more suitable for implementation.
One of the main requirements of the DPP is that the implemented system should not impose excessive costs on
manufacturers, as this could jeopardise their competitiveness in the market and lead them to avoid its implementation.
Section 6.1 has discussed the cost of each proposal, and it has found that the difference is considerable, with
P08.1.1 potentially costing around 15 times more than its alternative. Despite this significant difference, if the
network for implementing the system is carefully chosen, this difference will amount to only a few cents or a couple
of euros.
Considering these costs for complex products like a bicycle, whose average price is around 1,200 euros, an addi-
tional couple of euros for enabling the DPP can be considered negligible. However, for simpler products with much
lower prices, such as a light bulb, a couple of euros could represent a 50% increase in its price. This would be the case
if light bulbs required a DID for each product instance, but this is not the case, as simple products are recognised
because they will not receive updates such as repairs; if a light bulb stops working, it is not taken to a workshop, it
is simply recycled. Therefore, for simple products, the cost would be even lower, as only one DID per product type
would be needed.
Subsequently, in Section 6.2, the advantages of traceability and information availability offered by proposal P08.1.1
compared to P08.1.2 were presented. After analysis, we consider that these advantages outweigh the cost difference
between the proposals.
7 Use Cases
To better visualize the use of the digital product passport along with verifiable credentials and decentralized identifiers,
we present two different scenarios. The first scenario considers a simple product that is not intended to receive repairs,
as it is better to recycle it and purchase a new one once it breaks. The second scenario presents a complex product
that contains certain electronic components which, in case of failure, could be replaced to restore the product’s
functionality.
7.1 Simple product
For the first product, we have chosen cycling glasses. These consist of two components: a lens, which is a single piece,
and the frame. Unlike the lens, the frame is not a single piece as it is composed of four other parts. The frame of
the glasses is formed by joining the temples, the temple tips, the lens frame, and the nose bridge pads. If the lens
of the glasses breaks, it would not make sense to buy another lens to replace it, as the price would be very close to
buying new glasses. For this reason, this type of simple product that is not expected to receive updates does not
need a digital passport per product instance, but rather per reference.
As mentioned, cycling glasses consist of two distinct parts: the frame and the lenses. It is easy to assume that
both parts will be manufactured in different factories and then assembled together at another location. At the time
of their manufacture and departure from the factory, each part must have its own digital product passport (DPP).
For the frame, since it consists of a simple product and in case any part of the frame breaks, the easiest solution
would be to buy a new frame or new glasses altogether, the DPP could follow the design option D02.2. With this,
all the information about the frame’s parts will be available in the document of the DID that identifies that model
of frame. In the case of the lenses, the DPP will be a DID document containing their information, such as the type
of lens used (i.e., its material composition), its UV filter grade, and the ISO standards it meets.
18
7.2 Simple electronic product
In the second case, we have selected a computer mouse. This device, although it may seem simple at first, contains
a series of fairly complex electronic components that lend themselves to repair in case of failure. This scenario will
not apply to all mice, as a wired mouse purchased for 10 euros, no matter how simple the repair, would exceed the
purchase price. This is not the case with more modern and complex devices, such as some models that exceed 100
euros and, besides containing more electronics and components, also include batteries in the case of wireless models.
Despite containing many electronic components inside, a mouse can be divided into two groups of parts: the
casing and the motherboard. The casing, in most cases, will be made of some type of plastic or rubber and will
consist of the various buttons that the mouse contains and the larger parts that connect them. However, similar to
the frame of glasses, it will be a very simple product passport whose information will mainly serve to indicate what
type of plastic has been used and how to recycle it. For this reason, its DPP will be the same as that of the frame
of the glasses.
In contrast, the motherboard will be a collection of the passports of many electronic components such as sensors,
LED lights, microchips, and even batteries, which already contain a greater variety of materials in their composition
such as metals and silicones, requiring more specific handling for their subsequent recycling. In total, the motherboard
may have more than 10 different components that may be subject to repair in case of failure, so each of these may
have its own passport. Here, the design option D02.3 may be the most appropriate, since in case the battery fails,
its credential within the passport will be replaced by the credential of the new battery.
7.3 Complex product
The use cases that have been analyzed correspond to a fairly simple product that is not expected to receive any
repairs, and another product of reduced complexity but already featuring electrical components that will require
more customized recycling and that, in certain cases, could indeed be subject to repairs. Finally, to better visualize
the needs and limitations of the digital passport, we will present another use case, one that represents more complex
products due to their number of components and the amounts of repairs and maintenance they will receive throughout
their lifecycle. A car is a product that fits perfectly with the needs we have described.
In detail, a car can have between 70,000 and 90,000 different parts. If we only used credentials to store the
information of all the components, the collection of credentials that will form the product’s digital passport and that
the owner will need to keep in their wallet could take up from 300 megabytes to nearly half a gigabyte of storage.
This represents a considerable burden for the user, and the implementation of the passport should be as transparent
as possible for both users and companies. Due to this, another implementation needs to be considered for these
highly complex products. To attempt to reduce the size, the use of credentials could be minimized. In the case of
cars, instead of being a collection of credentials, the passport could be a DID document, which references its most
direct components, whose passports would point to their own components, and so on, down to the simplest parts.
This type of passport could be generated by car models or batches. Then, the information on repairs for a specific car
instance would be recorded in verifiable credentials in the owner’s wallet. With this model, the owner would handle
a significantly reduced number of credentials compared to the first option we presented for the car’s DPP.
8 Conclusion
This article presents an in-depth analysis of the European Commission’s Digital Product Passport (DPP) proposal,
a critical initiative for advancing the circular economy in the region. The DPP emerges as a key element in driving
transparency, traceability, and sustainability across supply chains, promoting more efficient resource utilisation and
waste reduction. The primary objective of this article is to demonstrate the viability of using decentralised identity
(DID) for implementing the Digital Product Passport. To achieve this, existing SSI-based solutions are thoroughly
examined, exploring their potential application within the DPP context. While these existing solutions present valid
proposals and showcase the ability of DID and verifiable credentials to support specific passport scenarios, limitations
in their scope to encompass all stages of the product lifecycle are identified. Instead, the proposal presented in this
article defines mechanisms to accompany the product throughout its useful life, supporting scenarios of ownership
transfer and the extension of DPP information for complex products.
Drawing upon the specific requirements outlined in the European Regulation for Ecodesign of Sustainable Prod-
ucts (ESPR), a comprehensive analysis of each functional requirement of the Digital Product Passport is conducted.
In this analysis, various system elements that could support the DPP are proposed, and implementation alternatives
are explored, considering the technological ambiguity present in these European regulations.
19
Section 5 clusters the diverse design options into two viable proposals for the DPP: one based on DID and the
other on verifiable credentials. After presenting both alternatives, a detailed comparison is conducted to determine
which one is more suitable for implementation. The selection of the most appropriate proposal will depend on various
factors, including technical, economic, legal, and acceptance aspects from different stakeholders. The final decision
must carefully consider the advantages and disadvantages of each proposal in relation to the specific requirements of
the Digital Product Passport and the overall goals of the circular economy in the European Union.
Ultimately, this article offers a comprehensive and well-founded perspective on the potential of decentralised
identity for implementing the Digital Product Passport, laying the groundwork for future research and discussions
on applying innovative technologies towards a more sustainable and circular economy.
References
[1] Thomas Adisorn, Lena Tholen, and Thomas G¨otz. Towards a digital product passport fit for contributing to a
circular economy. Energies, 14(8), 2021.
[2] Shafin Afrid and Arafat Saleheen. Potential of decentralised blockchains for the digital product passport - Need
for traceability and transparency in textile industries, July 2023. M.Sc. Thesis on Textile Management, The
Swedish School of Textiles, University of Boras, Sweden.
[3] Christopher Allen. The path to self-sovereign identity. Life with Alacrity blog, April 2016. Available at:
http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html. Accessed on February 2024.
[4] Antonio Fern´andez Anta, Chryssis Georgiou, Maurice Herlihy, and Maria Potop-Butucaru. Principles of
Blockchain Systems. Synthesis Lectures on Computer Science. Morgan & Claypool Publishers, 2021.
[5] Holger Berg, Raik Kulinna, Carsten St¨ocker, Susanne Guth-Orlowski, Ricky Thiermann, and Natalie Porepp.
Overcoming information asymmetry in the plastics value chain with digital product passports: how decen-
tralised identifiers and verifiable credentials can enable a circular economy for plastics. Working paper 197,
Wuppertal Institut f¨ur Klima, Umwelt, Energie, Wuppertal, Germany, April 2022. Available at: https://nbn-
resolving.org/urn:nbn:de:bsz:wup4-opus-79405. Accessed on March 2024.
[6] Katharina Berger, Josef-Peter Schoeggl, and Rupert J. Baumgartner. Digital battery passports to enable circular
and sustainable value chains: Conceptualization and use cases. Journal of Cleaner Production, 353:131492, 2022.
[7] Tim Berners-Lee, Roy T. Fielding, and Larry M. Masinter. Uniform Resource Identifier (URI): Generic Syntax.
Internet Engineering Task Force (IETF) RFC 3986, January 2005.
[8] cheqd. Infrastructure for trusted data markets. Web page, 2024. Available at: https://cheqd.io. Accessed on
June 2024.
[9] Kevin Dean. GS1 verifiable credentials - white paper on data model and validations. GS1 AISBL, Avenue Louise
326, box 10, 1050 Brussels, Belgium, May 2023. Available at: https://ref.gs1.org/gs1/vc/data-model/. Accessed
on April 2024.
[10] Antoine Durand, Thomas Goetz, Tim Hettesheimer, Lena Tholen, Simon Hirzel, and Thomas Adisorn. Enhanc-
ing evaluations of future energy-related product policies with the digital product passport. In Energy Evalua-
tion Europe 2022 Conference, Lab. Paris-Saclais, B. Gaspar Monge, 91120 Palaiseau, France, September 2022.
EDF. Available at: https://publica.fraunhofer.de/bitstreams/144964c7-b5df-49c4-96fc-ed558e3076f1/download.
Accessed on March 2024.
[11] European Commission. Proposal for a regulation of the European Parliament and of the Coun-
cil establishing a framework for setting ecodesign requirements for sustainable products and repeal-
ing Directive 2009/125/EC. EUR-Lex, March 2022. Available at https://eur-lex.europa.eu/legal-
content/ES/TXT/HTML/?uri=CELEX:52022PC0142. Accessed on February 2024.
[12] European Commission. Call for proposals on Digital Product Passport. European Health and Digital Exec-
utive Agency (HaDEA), May 2023. Available at: https://hadea.ec.europa.eu/calls-proposals/digital-product-
passport en. Accessed on February 2024.
[13] European Commission. Commission welcomes provisional agreement for more sustainable, repairable
and circular products. European Commission Press Release, December 2023. Available at:
https://ec.europa.eu/commission/presscorner/detail/en/ip 23 6257. Accessed on February 2024.
20
[14] European Commission. Regulation (EU) 2024/1781 of the European Parliament and of the Council establishing
a framework for setting ecodesign requirements for sustainable products amending Directive (EU) 2020/1828
and Regulation (EU) 2023/1542 and repealing Directive 2009/125/EC. Official Journal of the European Union,
June 2024. Available at http://data.europa.eu/eli/reg/2024/1781/oj. Accessed on August 2024.
[15] F. Javier Gonz´alez-Bravo Pe˜nuela, Jordi Arjona Aroca, Francesc D. Mu˜noz-Esco´ı, Yuriy Yatsyk Gravrylyak,
Ismael Ill´an Garc´ıa, and Jos´e M. Bernab´eu-Aub´an. DELTA: DLT-database synchronization. In 5th IEEE
International Conference on Blockchain and Cryptocurrency (ICBC), Dubai, United Arab Emirates, May 2023.
IEEE-CS Press.
[16] GS1. Global Trade Item Number (GTIN). GS1 Web Site, January 2024. Available at:
https://www.gs1.org/standards/id-keys/gtin. Accessed on February 2024.
[17] Susanne Guth-Orlowski. The digital product passport and its technical implementation. Medium blog,
October 2021. Available at: https://medium.com/@susi.guth/the-digital-product-passport-and-its-technical-
implementation-efdd09a4ed75. Accessed on February 2024.
[18] Susanne Guth-Orlowski. Accessing digital product passports with decentralized identifiers (DIDs). Medium
blog, February 2022. Available at: https://medium.com/spherity/accessing-digital-product-passports-with-
decentralized-identifiers-dids-175ca455cee3. Accessed on February 2024.
[19] Susanne Guth-Orlowski, Johannes Evert, and Ricky Thiermann. Implementing digital prod-
uct passports using decentralized identity standards. Medium blog, April 2023. Available at:
https://medium.com/spherity/implementing-digital-product-passports-using-decentralized-identity-standards-
f1102c452020. Accessed on February 2024.
[20] Felix Hoops and Florian Matthes. A universal system for OpenID Connect sign-ins with verifiable credentials
and cross-device flow. CoRR, abs/2401.09488, 2024.
[21] International Organization for Standardization. ISO/IEC 15459-6:2014. Information technology - Automatic
identification and data capture techniques - Unique identification - Part 6: Groupings. ISO/IEC Standard,
November 2014. Available at: https://www.iso.org/standard/54786.html. Accessed on February 2024.
[22] Steffen Foldager Jensen, Jesper Hemdrup Kristensen, Sofie Adamsen, Andreas Christensen, and Brian Vejrum
Waehrens. Digital product passports for a circular economy: Data needs for product life cycle decision-making.
Sustainable Production and Consumption, 37:242–255, 2023.
[23] Nikita Khateev and Stephen Curran. Aries RFC 0454: Present proof protocol 2.0. Hyperledger Aries Request
for Comments, April 2021. Available at: https://github.com/hyperledger/aries- rfcs/blob/main/features/
0454-present-proof-v2/README.md. Accessed on March 2024.
[24] Nikita Khateev, Stephen Klump, and Stephen Curran. Aries RFC 0453: Issue credential protocol 2.0. Hyper-
ledger Aries Request for Comments, April 2021. Available at: https://github.com/hyperledger/aries-rfcs/
blob/main/features/0453-issue-credential-v2/README.md. Accessed on March 2024.
[25] Melanie R.N. King, Paul D. Timms, and Sara Mountney. A proposed universal definition of a digital product
passport ecosystem (DPPE): Worldviews, discrete capabilities, stakeholder requirements and concerns. Journal
of Cleaner Production, 384:135538, 2023.
[26] David J. Langley, Eugenia Rosca, Marios Angelopoulos, Oscar Kamminga, and Christa Hooijer. Orchestrating a
smart circular economy: Guiding principles for digital product passports. Journal of Business Research, 169(C),
December 2023.
[27] Torsten Lodderstedt, Kristina Yasuda, and Tobias Looker. OpenID for verifiable credential issuance.
OpenID Foundation Editor’s Draft, February 2024. Available at: https://openid.github.io/OpenID4VCI/
openid-4-verifiable-credential- issuance-wg-draft.html. Accessed on March 2024.
[28] Leandro Navarro, Javier Cano Esteban, Marc Font Miralles, and David Franquesa Griso. Digital transformation
of the circular economy: digital product passports for transparency, verifiability, accountability. In XXVIII Jor-
nadas de Concurrencia y Sistemas Distribuidos (JCSD), Las Navas del Marqu´es, ´
Avila, Spain, June 2022. Avail-
able at: https://jcsd2022.networks.imdea.org/wp-content/uploads/sites/20/2022/06/14-digital-transformation-
of-the-circular-economy-digital-product-passports-for-transparency-verifiability-accountability.pdf. Accessed on
February 2024.
[29] Nate Otto, Sunny Lee, Brian Sletten, Daniel Burnett, Manu Sporny, and Ken Ebert. Verifiable credentials use
cases. W3C Editor’s Draft, February 2024. Available at: https://w3c.github.io/vc-use-cases/. Accessed on April
2024.
21
[30] Jos´e Potting, Marko Hekkert, Ernst Worrell, and Aldert Hanemaaijer. Circular economy: Measuring innovation
in the product chain. PBL Netherlands Environmental Assessment Agency, publication number 2544, The
Hague, Netherlands, January 2017. Available at: https://www.pbl.nl/sites/default/files/downloads/pbl-2016-
circular-economy-measuring-innovation-in-product-chains-2544.pdf. Accessed on February 2024.
[31] Foivos Psarommatis and G¨okan May. Digital product passport: A pathway to circularity and sustainability in
modern manufacturing. Sustainability, 16(1), January 2024.
[32] Manu Sporny, Dave Longley, and David Chadwick. Verifiable credentials data model 1.0. Expressing verifiable
information on the Web. World Wide Web Consortium Recommendation, November 2019. Available at: https:
//www.w3.org/TR/2019/REC-vc-data-model- 20191119/. Accessed on February 2024.
[33] Manu Sporny, Dave Longley, and David Chadwick. Verifiable credentials data model v1.1. World
Wide Web Consortium Recommendation, March 2022. Available at: https://www.w3.org/TR/2022/
REC-vc-data-model- 20220303/. Accessed on February 2024.
[34] Manu Sporny, Dave Longley, David Chadwick, and Orie Steele. Verifiable credentials data model v2.0. World
Wide Web Consortium Working Draft, March 2024. Available at: https://www.w3.org/TR/vc-data-model-2.
0/. Accessed on March 2024.
[35] Manu Sporny, Dave Longley, Markus Sabadello, Drummond Reed, Orie Steele, and Christopher Allen. Decentral-
ized identifiers (DIDs) v1.0. Core architecture, data model, and representations. World Wide Web Consortium
Recommendation, July 2022. Available at: https://www.w3.org/TR/did-core/. Accessed on February 2024.
[36] Lukas Stratmann, Gerrit Hoeborn, Christoph Pahl, and G¨unther Schuh. Classification of product data for a
digital product passport in the manufacturing industry. In 4th Conference on Production Systems and Logistics
(CPSL), pages 448–458, Santiago de Queretaro, Mexico, March 2023.
[37] Oliver Terbu, Torsten Lodderstedt, Kristina Yasuda, and Tobias Looker. OpenID for verifiable presentations.
OpenID Foundation Editor’s Draft, February 2024. Available at: https://openid.github.io/OpenID4VP/
openid-4-verifiable-presentations- wg-draft.html. Accessed on March 2024.
[38] United Nations Economical Commission for Europe. eDATA verifiable credentials for cross-border
trade. UNECE White Paper, September 2022. Available at: https://unece.org/sites/default/files/2023-
08/WhitePaper VerifiableCredentials-CrossBorderTrade September2022.pdf. Accessed on May 2024.
[39] Joerg Walden, Angelika Steinbrecher, and Maroye Marinkovic. Digital product passports as enabler of the
circular economy. Chemie Ingenieur Technik, 93(11):1717–1727, 2021.
22