A Decentralized Digital Product Passport for Textiles
In this article, we will guide you through a Digital Product Passport (DPP) showcase implementation that utilizes verifiable credentials and decentralized identifiers (DIDs) for both the product and organizations. By using DIDs for products, we ensure that access to the DPP resources and webpage is entirely built on open standards that are permissionless and can be implemented by anyone. We also show that DIDs offer equivalent capabilities as alternative protocols like the GS1 Digital Link for linking a product with a Digital Product Passport.
Aside from DPP access, we will also look at how DIDs enable the verifiability of the DPP data. Here, again, the verification mechanism is entirely based on open standards. That means that manufacturers and supply chain actors can choose between in-house implementations or SaaS offerings, such as the DPP solution offered by Spherity.
We implemented this showcase last June when our team participated in the JP Morgan Corporate Challenge, a corporate running event in Frankfurt. We designed a running T-shirt for our team, which featured a QR code containing a URL leading to its Digital Product Passport (DPP). The DPP for T-shirts is particularly relevant as textiles are among the first product categories regulated under the Ecodesign for Sustainable Products Regulation (ESPR). Since then, we have implemented additional DPP showcases, including this battery showcase, which uses the same technology described below.
According to the EU Commission, the DPP should be a tool that enables the collection and sharing of product data throughout its entire lifecycle and close the information gap. Its primary objective is to establish the sustainability, environmental impact, and recyclability attributes of the product. It must be based on a decentralized data system and harmonized, open, and interoperable standards without dependence on any commercial technology provider. It also must be accessible by scanning a data carrier, like a QR code or RFID chip.
Part I: Accessing the DPP
This section shows how a DPP access mechanism can be implemented using a QR code that links to a DID Document using a (third-party) DID resolver.
Leveraging DID Documents for Flexible and Persistent DPP Data Lookup
The DPP needs to be accessible by scanning a data carrier (e.g. QR code or RFID/NFC chip) that contains the product identifier combined with a URL that can be opened in a web browser. This is a common functionality for mobile phones and millions of other devices. However, the DPP has its particularities that need to be considered. For starters, the DPP is not only a human-readable webpage; it should also provide access to verifiable, structured data in a machine-readable format.
In addition, the DPP needs to remain accessible throughout the product’s entire lifecycle and enable the recording of use, repair, remanufacturing, and recycling event data. Product life cycles can be very long, for example for building materials. But even in the case of fashion items, like T-shirts, companies can go out of business, be acquired, or change their names before the product reaches the end of its lifecycle. A DPP solution, therefore, needs to allow the recording of events and ensure persistent access to DPP.
DIDs are well-suited to satisfy both requirements. Every DID is associated with a DID Document, a small data file in JSON format that provides useful information about the DID. This includes the public keys associated with it and service endpoints, including URLs to the DPP webpage and other resources like authentication endpoints for machine-readable data, and additional information about the product or the product manufacturer. The structure of the DID document is standardized, which ensures interoperability across all implementations.
If the DPP owner needs to be make to the service endpoint URLs it can be done without having to change the content of the data carrier. This makes such a solution more persistent and flexible during the lifecycle of a product.
The code below (Figure 2) shows the DID Document that belongs to the T-shirt showcase.
Accessing the DID Document
Now that we have established the usefulness of the DID Document for the DPP, it’s important to clarify how other parties can access it through the data carrier.
As mentioned earlier, each DID is associated with a unique DID Document. The location of the DID Document depends on the DID method being used. There exists a multitude of DID methods. Some store DID Documents on decentralized ledgers, such as Ethereum or Hyperledger Indy; others use an existing web domain. The ledger-based DID Documents offer a particularly high level of persistence since the DID document will continue to be accessible on the ledger even if the organisation goes out of business.
The DID method is specified by the DID’s prefix. In our example, we’re using the did:web DID method. Unlike other methods that store DID Documents on decentralized ledgers, the did:web method involves hosting the DID document on a pre-existing domain. This is useful when the domain and organization controlling it are already trusted by users, such as reputable institutions like government agencies or large enterprises. On the flipside, did:web doesn’t offer the same level of decentralization and persistence as other DID methods.
As a result of using different DID methods, access to the DID document, called DID document resolution, also differs. It is not necessary to delve too deep into the details of DID resolution as there exist reliable open-source libraries such as Universal Resolver that resolve all common DIDs.
In fact, if the Universal Resolver were implemented in commonly used QR code readers or mobile phone cameras, we wouldn’t have to do much else. We could simply encode DIDs into data carriers, and the Universal Resolver implemented on the mobile phone would handle the retrieval of the DID document and DPP resources. It is possible that with the wide use of DIDs this functionality will become a commodity in the future.
However, QR code and RFID readers currently only resolve common URLs, which requires us to perform DID resolution server side and include the DPP as part of a URL parameter in the QR Code.
Anyone could build such a service without too much effort, as the Universal Resolver and DID specifications are open to everyone, their usage is free of charge, and open-source implementations are available. Some companies might choose to build their own technology, in particular if metadata about DPP access shouldn’t be shared with a third-party provider.
However, smaller companies might be inclined to use a third-party offering. In our demonstration, we used the DID resolver of GoDiddy. The final URL that can be scanned by any standard QR or RFID/ NFC scanner looks like this:
With this step, we have completed the full information flow of accessing the human-readable website of the DPP shown in Figure 3via a DID embedded in a GoDiddy URL, the DID resolver on the GoDiddy server, and the DID Document.
Part II: Verifying the DPP
The second main feature of this DPP showcase is the verifiability of the data contained in the DPP. The DPP can be checked against a vocabulary that is used to describe the T-Shirt. Known textile description schemes are the Global Textile Scheme or the Circularity.ID of Circular Fashion. As those vocabularies do not yet exist as JSON-LD schemas, we have created the demo schema below (See Figure 4 or here: https://spherity.github.io/schemas/testing/breathable-t-shirt.json).
In our showcase Spherity is the manufacturer of the T-Shirt and issuer of the T-Shirt DPP. Everyone can verify who issued the DPP and if it was modified or revoked. We achieve this by signing the verifiable credential of the DPP with Spherity’s private key using a wallet. The credential includes Spherity’s company DID in the issuer field (Issuer DID) and the Product DID in the credentialSubject field (don’t be confused by the fact that the two DIDs look very similar). It also contains all the technical data about the T-shirt which is displayed on the human-readable web page. Lastly, the proofValue field contains the digital signature which was created using the private key associated with Spherity’s issuer DID.
Any third-party verifier can verify this credential. In this case, we used the open-source verifierd developed by EECC.
This credential can be verified by any third-party verifier without requiring any additional integration work. In this case, we used the open-source verifier developed by EECC.
For this process, the EECC verifier resolves the issuer DID document, in this case Spherity, with the DID did:web:20230614.dpp.spherity.com. As per the did:web specification, the DID document MUST be located at the path https://20230614.dpp.spherity.com/.well-known/did.json.
The DID document includes the public key that is required to validate the T-Shirt DPP signature. If the signature validation is successful, the EECC verifier shows a green check mark with the comment “Credential Verified” (See Figure 5). A customer, auditor, or regulator can thus be confident that the T-Shirt DPP was actually issued by the real Manufacturer (here: Spherity) and be sure that the DPP has not been modified since it was issued (in which case the signature verification would fail). One other important feature of digital signatures is non-repudiation. This means that the issuer can not deny having issued the product information.
While this is a very simple example of a DPP, this powerful concept can be scaled without adding complexity. It is also straightforward to add verifiable data about the manufacturer, such as the sustainability report, the Greenhouse Gas Emissions report, or the Child Labor report issued using the same technical concepts.
In the coming weeks, we will work with partners to extend this concept and also include credentials issued by other supply chain stakeholders and auditors…. so stay tuned!
Your Spherity DPP-Team!
