Implementing Digital Product Passports using decentralized identity standards
- Dr. Susanne Guth-Orlowski
- Apr 27, 2023
- 10 min read
Or how to use the “StandICT.eu Landscape of Standards for digital product passports”
Authors: Dr. Susanne Guth-Orlowski, Johannes Ebert, Ricky Thiermann
Introduction
This article is showing how to implement the digital product passport (DPP) with some standards mentioned in the StandICT.eu ‚A Landscape of Standards for digital product passports‘ [1]. Whereas the architecture diagram from the report is technology agnostic (see Figure 1), in this article we are concentrating on using decentralized technologies, such as W3C decentralized identifiers [2] and W3C verifiable credentials [3] to implement the digital product passport. It shows how those technologies, file formats, and protocols can be used to exchange supply chain data among industry players, authorities and end customers.
In the following chapters we will describe what standards are needed for the decentralised approach and how they work. We show how W3C decentralized identifiers are created for all involved supply chain parties and products, how product and company information is issued as W3C verifiable credential, and how digital product passports can be found and verified from its users.
Setting up Decentralized Identifiers for Companies and Products
For a trusted digital environment it is essential to create globally unique identifiers for all involved parties and “things” (here: products). In the world of decentralized identifiers (short DIDs), DIDs are created by a wallet. A wallet is a piece of software that implements a large number of standards around decentralized identifiers, including communication protocols, trusted ledger access, etc. When creating a DID, the wallet follows the rules defined by the W3C decentralized identifiers standard [2].
Every party, for example a supplier, creates its own company DID, which also includes the creation of a public-private key pair. Whereas the private key always stays with the supplier, the public key is published on a trusted ledger in a DID document. The public key needs to be accessible to the ecosystem to verify signatures from the supplier. Economic operators can also create DIDs as globally unique identifier for their products.
DID documents are registered [4] on a trusted ledger where they cannot be modified or tampered with. The trusted ledger can be chosen depending on the use case, the security requirements, and the required level of trust. Often used trusted ledgers are:
The DID document optionally also includes service endpoints, which lead to further information / claims about the supplier, e.g. the supplier’s company registration, its company identity verification in form of a vLEI [12], its ISO certification, or its GHG emissions report. Claims about the supplier can be made by the supplier himself (self attestations) or by third parties (e.g. an auditor). In the world of decentralized identifiers, such claims are implemented as ‘verifiable credentials’, which is described in the next section.
Provision of Data and Digital Product Passport creation
Before creating a digital product passport, the data it contains must be made available in a verifiable manner. Third parties and suppliers provision this information in the form of W3C Verifiable Credentials [3]. In Figure 3 below the third party issues the ESG credential to the supplier, the GHG emissions report, as well as the battery test report to the economic operator (flow 1.a).
Technically speaking the third party’s wallet initiates a secure connection with the supplier wallet using the standardised DIDComm [13] protocol. It then issues the ESG credential which is encoded in JSON-LD [15] or VC-JSON [16] and signs it with the third party’s private key. In the same way the economic operator receives the GHG emissions report and the battery test report. The supplier issues the product information about his pre-product also as a verifiable credential to his own wallet signed by his private key (also called: self attestation, (see flow 1b)).
Now the economic operator who places the battery on the market can verify the product information and ESG compliance of his supplier (flow 2) and reference the respective credentials in the battery passport which he creates (flow 3). The battery passport is a self attestation, a verifiable credential issued and signed by the economic operator. In the battery passport he also references his own credentials that concern the battery (Battery Test and GHG emissions) and adds all additional required attributes to be compliant to the regulation. For batteries those attributes are defined in the Battery Passport Content Guidance [17] . For other products and product components vocabularies often already exist, which might need to be enhanced to comply to the Ecodesign for Sustainable Products Regulation [18]. Examples are the Safety Data Sheet for chemical products [19], RMS for recycled plastic [20], the Asset Administration Shell Submodels for Industry 4.0 information, the Circularity.ID for textiles, or the PCDS [21] for general circularity attributes.
Finally, the product identifier, the product DID, is encoded in a suitable way to fit to the data carrier. In our example it is encoded into a QR code (flow 4). An alternative to creating a DID per product is to use an already established product identifier in the DPP (see [22]).
Find and verify the digital product passport data
Once the DPP is created, its identifier is put on a QR code and glued on top of a battery. The DPP user now needs to find the DPP data and verify it. How to find digital product passports of products that use a DID as a unique global identifier, has been described in the IEEE award winning paper “Accessing Digital Product Passports with Decentralized Identifiers” [23]. No central component is required to register and find digital product passports, as the Universal Resolver [24] naturally takes over this part.
In short, to find the DPP, one has to decode the QR code and retrieve the product DID (step 1). As a response to resolving the DID with the universal resolver [25] (step 2), the user application (a wallet) receives the DID document (step 3) which includes the service endpoints for fetching the digital product passport. The DPP is securely kept in the credential store of the economic operator. If no access control is applied, the DPP can be shared and validated immediately by checking its signature with the public key of the economic operator on the trusted ledger. However, the DPP and supply chain data underlie high business confidentiality requirements. Therefore, the credential store and the issuer’s wallet are managing the access control for the DPP which is described in the more technical sections below.
To fetch the DPP from the economic operator, the user needs to talk to the wallet of the economic operator. Wallets often implement protocols, such as DIDComm [13] which are designed for a secure message exchange between wallets. Protocols on top of DIDComm, such as Aries [25] or DIF Presentation exchange [26] allow handshakes between wallets, with which they can ask for and receive verifiable credentials. Alternatively, OpenIDConnect [27] with OID4VC [14] and OID4VP [24] or other emerging protocols can be used. On this level access control mechanisms can be implemented, as verifiable credentials, here the DPP, are only shared on request. Examples for access control mechanisms are:
A wallet can be configured to automatically share all credentials with everyone.
A wallet can implement a role based access control mechanism, where access rights to verifiable credentials can be expressed and enforced based on a rights expression language, such as ODRL [29]. For example, access is given if the requester can show an identity credential that proves his auditor role.
A wallet can be configured to share no concrete data but only proofs of the data (Selective Disclosure, Zero Knowledge Proofs).
The eclipse data space connector [30] defines another way to express, negotiate, and document the rules under which data is shared, and also with whom. However, it replaces the basic way wallets communicate with each other, is only used in certain industry consortia (such as Catena-X), and thus is not suitable for a broad, cross-industry data exchange. The best solution for credential exchange and access control is the one closest to the industry requirements, its common practice, and that adheres to general security standards [31, 32].
Each industry or product segment needs to determine the above mentioned wallet exchange protocols to allow the highest level of interoperability which usually manifests in a trust framework. A trust framework defines some technical but also non-technical rules to establish trust for a certain use case or industry. A general trust framework approach is shown in Trust over IP [33], and specific examples are OCI [34] and Gaia-X [35].
Benefits
Benefits of the decentralized approach are:
Product information stays with its owner.
The owner of the data has full control over who can access his data.
Because product and company data is not uploaded to central platforms and not shared multiple times, the data is always up to date.
Decentralised technology is inclusive. Everyone with a wallet can technically participate in the ecosystem.
Entry barriers are low, as open source wallets and reference implementations are available.
Companies have a high need to insert trusted data into their internal systems. Data in the form of verifiable credentials can meet this need and provide end-to-end verifiability.
A decentralised approach allows an ad-hoc trusted data exchange without a bilateral integration, also referred to as ‘decentralised integration’. In other words you can exchange data with and trust data of a company you have never dealt with before.
A decentralised approach makes central components obsolete, which saves development, deployment, management and other ongoing costs which come with central components.
A DPP solution that follows the approach above is the Spherity Digital Product Passport.
This article is subject to change and will be further improved.
Sources
The sources in bold are standards mentioned in the StandICT report
[1] StandICT.eu Technical Working Group Digital Product Passport. (2023, March 21). A Landscape of Standards for the Digital Product Passport (EUOS TWG) (J. Gayko & B. Helfritz, Eds.). StandICT.eu. Retrieved April 26, 2023, from https://www.standict.eu/digital-product-passport-standards-report
[2] Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele, O., & Allen, C. (2022, July 22). Decentralized Identifiers (DIDs) v1.0 (M. Sporny, A. Guy, M. Sabadello, & D. Reed, Eds.). W3C. Retrieved April 26, 2023, from https://www.w3.org/TR/did-core/
[3] Sporny, M., Longley, D., & Chadwick, D. (2022, March 22). Verifiable Credentials Data Model v1.1 (M. Sporny, G. Noble, D. Longley, D. C. Burnett, B. Zundel, & K. Den Hartog, Eds.). W3C. Retrieved April 26, 2023, from https://www.w3.org/TR/vc-data-model/
[4] Sabadello, M., & Saglam, C. (n.d.). DID Registration (Pre-Draft). DIF. Retrieved April 26, 2023, from https://identity.foundation/did-registration/
[5] Buchner, D., Steele, O., & Looker, T. (n.d.). Well Known DID Configuration. DIF Approved Deliverable. Retrieved April 26, 2023, from https://identity.foundation/specs/did-configuration/
[6] Gribneau, C., Prorock, M., Steele, O., & Terbu, O. (2023, March 18). did:web Method Specification (M. Prorock, O. Steele, & O. Terbu, Eds.). W3C. Retrieved April 26, 2023, from https://w3c-ccg.github.io/did-method-web/
[7] Hyperledger Foundation. (n.d.). Hyperledger Indy. Retrieved April 26, 2023, from https://wiki.hyperledger.org/display/Indy
[8] Curran, S., Bastian, P., Hardman, D., Howland, C., & Bormann, C. (2023, February 23). Indy DID Method Specification. Hyperledger Foundation. Retrieved April 26, 2023, from https://hyperledger.github.io/indy-did-method/
[9] IDunion. (n.d.). IDunion — Ermöglicht selbstbestimmte Identitäten. Retrieved April 27, 2023, from https://idunion.org/?lang=en
[10] Veramo Core Team. (2022, November 7). ETHR DID Method Specification. DIF. Retrieved April 26, 2023, from https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md
[11] EBSI. (2023, April 11). European Blockchain Services Infrastructure. Retrieved April 27, 2023, from https://ec.europa.eu/digital-building-blocks/wikis/display/EBSI/Home
[12] GLEIF. (n.d.). Introducing the verifiable LEI (vLEI). Retrieved April 26, 2023, from https://www.gleif.org/en/vlei/introducing-the-verifiable-lei-vle
[13] Curren, S., Looker, T., Terbu, O., Den Hartog, K., & Shaaban, B. (n.d.). DIDComm Messaging v2.0 (S. Curren, T. Looker, & O. Terbu, Eds.). DIF. Retrieved April 26, 2023, from https://identity.foundation/didcomm-messaging/spec/v2.0/
[14] Lodderstedt, T., Yasuda, K., & Looker, T. (2023, February 3). OpenID for Verifiable Credential Issuance. OpenID Foundation. Retrieved April 26, 2023, from https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html
[15] Sporny, M., Longley, D., Kellogg, G., Langthaler, M., Champin, P.-A., & Longley, D. (2020, July 16). JSON-LD 1.1 (G. Kellogg, Ed.; W3C Recommendation). W3C. Retrieved April 26, 2023, from https://www.w3.org/TR/json-ld11/
[16] Cohen, G., & Steele, O. (2023, April 5). Verifiable Credentials JSON Schema 2022 (Final Community Group Report). W3C. Retrieved April 26, 2023, from https://w3c.github.io/vc-json-schema/
[17] Battery Pass. (2023, April). Battery Passport Content Guidance. Retrieved April 26, 2023, from https://thebatterypass.eu/assets/images/content-guidance/pdf/2023_Battery_Passport_Content_Guidance.pdf
[18] European Commission. (n.d.). Ecodesign for sustainable products. Retrieved April 26, 2023, from https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products_en
[19] European Chemicals Agency. (2020, December). Guidance on the compilation of safety data sheets. Retrieved April 26, 2023, from https://echa.europa.eu/documents/10162/2324906/sds_en.pdf/01c29e23-2cbe-49c0-aca7-72f22e101e20
[20] GreenBlue. (2021, May 6). The Recycled Material Standard Framework. RMS. Retrieved April 26, 2023, from https://www.rmscertified.com/wp-content/uploads/2021/05/Framework-052021_1159.pdf
[21] PCDS. (2020, February 14). Product Circularity Data Sheet (PCDS) v3.2s. Retrieved April 26, 2023, from https://pcds.lu/wp-content/uploads/2020/11/20200214_Light_PCDS_v3.2s_FORM.pdf
[22 ] EECC, GS1 Germany GmbH, Robert Bosch GmbH, SBB, Siemens AG, & Spherity GmbH. (2023, March 27). Empowering Sustainable Products and Consumer Confidence through Verifiable Credentials v1.01. IDUnion. Retrieved April 26, 2023, from https://www.google.com/url?q=https://drive.google.com/file/d/1-JPm-TDpqWoXyghX_8o8_F-FSuZatILF/view?usp%3Dshare_link&sa=D&source=docs&ust=1682580329996953&usg=AOvVaw2Nvinal4PXtZEXPXhGxh_a
[23] Guth-Orlowski, S. (2022, February 21). Accessing Digital Product Passports with Decentralized Identifiers (DIDs). Retrieved April 26, 2023, from https://medium.com/spherity/accessing-digital-product-passports-with-decentralized-identifiers-dids-175ca455cee3
[24] Sabadello, M., & Zagidulin, D. (2023, January 18). Decentralized Identifier Resolution (DID Resolution) v0.3 (M. Sabadello & D. Zagidulin, Eds.; Draft Community Report). W3C. Retrieved April 26, 2023, from https://w3c-ccg.github.io/did-resolution/
[25] Huseby, D., & Bohan, S. W. (2022, July 08). Hyperledger Aries. Hyperledger Foundation. Retrieved April 26, 2023, from https://wiki.hyperledger.org/display/ARIES
[26] McGrogan, D., Cohen, G., Steele, O., & Chang, W. (n.d.). Presentation Exchange 2.0.0 (D. Buchner, B. Zundel, M. Riedel, & K. Hamilton Duffy, Eds.; DIF Ratified Specification). DIF. Retrieved April 26, 2023, from https://identity.foundation/presentation-exchange/spec/v2.0.0/
[27] Sakimura, N., NRI, Bradley, J., & Ping Identity. (2014, November 8). OpenID Foundation. Retrieved April 26, 2023, from https://openid.net/connect/
[28] Terbu, O., Lodderstedt, T., Yasuda, K., Lemmon, A., & Looker, T. (2021, December 17). OpenID Connect for Verifiable Presentations. OpenID Foundation. Retrieved April 26, 2023, from https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0-07.html
[29] Iannella, R., & Villata, S. (2018, February 15). Open Digital Rights Language (ODRL) Version 1.1 (W3C Recommendation). W3C. Retrieved April 26, 2023, from https://www.w3.org/TR/odrl-model/
[30] Eclipse Foundation. (n.d.). Eclipse Dataspace Components. Retrieved April 26, 2023, from https://projects.eclipse.org/projects/technology.edc
[31] ISO/IEC JTC 1/SC 27. (n.d.). Information security, cybersecurity and privacy protection. ISO. Retrieved April 26, 2023, from https://www.iso.org/committee/45306.html
[32] Barreira, I., Izenpe, Gustavsson, T., Primekey, Wiesmaier, A., AGT International, & Manso, C. G. (2013, December 20). Guidelines for trust service providers — Part 1: Security framework. ENISA. Retrieved April 26, 2023, from https://www.enisa.europa.eu/publications/tsp1-framework
[33] Trust Over IP Foundation. (n.d.). The ToIP Model. Retrieved April 27, 2023, from https://trustoverip.org/toip-model/
[34] Wirrig, C., Colgan, A., Payson, B., & Waldorf, E. (n.d.). OCI DSCSA Interoperability Profile v3.0.0. OCI. Retrieved April 26, 2023, from https://www.oc-i.org/resources-portfolio/oci-interop-v3-0-0
[35] Gronlier, P. (n.d.). Gaia-X Trust Framework. Retrieved April 27, 2023, from https://gaia-x.gitlab.io/policy-rules-committee/trust-framework/gaia-x_trust_framework/
Stay sphered by joining Spherity’s Newsletter list and following us on LinkedIn and Twitter. For press relations, contact communication@spherity.com.
Also tune into our Product Passport Pioneers Podcast with DPP policy makers, Governments, car manufacturers, and other industry experts on Spotify, Apple Podcast, Buzzsprout, Google Podcast, and YouTube!
