The world’s first decentralized, verifiable Battery Passport.
How to implement a Battery Passports based on SSI technology
Last update: Nov. 24th 2023
In this article, we show the first working Battery Passport whose authenticity can be proven and that links to verifiable supply chain data, such as a third party Due Diligence report. Battery Passports must be attached to each battery that is placed on the European Market starting from August 2025 with CO2 data of the battery.
You can learn about the implementation details of the Battery Passport which is using the Self-Sovereign-Identity (SSI) technology concept that is completely based on open international standards and can be used and implemented free of charge. The concept is permission-less, that means it allows any supply chain partner to participate in the DPP system.
Technically, it is interoperable with Gaia-X and any data space built on top of it and it does not require any central component. It does NOT use the Eclipse data space connector which was invented to connect two large data repositories, which is not required in the DPP use case and conflicts with wallet-2-wallet communication. It uses technologies listed in the “StandICT.eu Landscape of Standards for digital product passports” and follows the Battery Pass Content Guidance.
The Battery Passport needs to be issued by the company that places the battery on the European Market, for example, EV manufacturers but also stationary battery manufacturers. The battery passport needs to be human readable by some supply chain actors, such as recyclers or end customers. However, it also needs to be machine readable and verifiable by the usage of an API for automated compliance checks, e.g. by European Customs. This article shows both versions of the Battery Passport and all implementation details.
1. The human readable Battery Passport
The human readable Battery Passport provides an interface that allows people in the product’s life cycle to read detailed information about the battery they have in front of them. Please find our Battery Passport showcase here: https://acme.dpp.spherity.com/
The attributes you see in this passport are defined in the Battery Pass Content Guidance Documents. Battery Pass is a project which is funded by the German Ministry of Economic Affairs and Climate Action; the battery pass attributes have been developed in cooperation with major battery industry initiatives, such as the Global Battery Alliance, Catena-X, and many individual experts.
There are public and non-public attributes in the digital product passport. Public attributes can be accessed by anyone, all other attributes require an authentication of the user as the data underlies strict business confidentiality. The access control mechanism for authorised DPP users is not standardised yet. Possibilities are using common login/password mechanisms or using verifiable credentials. The login in our showcase is a mock-up as well as the data values in the passport, everything else is working technology.
2. Battery Passport Discovery
Battery passport discovery requires a globally unique identifier that is resolved on the internet. In this section, we give an overview about the battery identifier, the data carrier of the identifier (QR code), and the actual resolving of the Battery Identifier to the passport information.
2.1 The Battery Product Identifier
To discover a digital product passport on the internet it needs a globally unique identifier which is resolvable to a URL. The European Commission is asking for a decentral storage of the DPP which makes using W3C Decentralized Identifiers (DIDs) as battery identifiers a perfect fit. DIDs are globally unique identifiers by definition and have some other advantages:
- DIDs are free of charge.
- DIDs are issued and controlled by the manufacturer and not by a central organisation.
- The passport data and who has access to it stays with the manufacturer.
- As data is not uploaded to central systems, it is always up to date.
- A DID is a persistent identifier, that means it can stay the same during its entire life cycle.
- At the same time DIDs allow flexibility wrt the information that is attached to a DID, e.g. the owner of a battery, the URL to the battery passport, a service endpoint to verifiable data can change over time.
- DIDs provide a built-in security functionality to attach verifiable data (also known as: W3C Verifiable Credentials) to the battery passport, for example Due Diligence Reports.
Depending on the DID method, the DID has a different syntax and different methods to create, revoke, update, and delete (CRUD). The syntax of our Battery DID example is
did:web:acme.dpp.spherity.com:battery:7be3b99c-33a3-4d72-a747-feeb2c2ed263It consists of the DID-method (did:web) the domain and path where the did document can be found (acme.dpp.spherity.com/battery) and the unique identifier in that domain (here the UUID 7be3b99c-33a3-4d72-a747-feeb2c2ed263. In the next sections, we are explaining how to encode a DID-based product identifier in a URL, and how to resolve it. For more information about using DID as Product Identifier, please read the IEEE award winning paper “Accessing Digital Product Passports with Decentralized Identifiers (DIDs)”
2.2 Data carrier
At the moment the European Commission is asking for QR codes as the Data Carrier that leads to the Battery Passport. Other possible data carriers are RFID or NFC chips. The data carrier must contain the product identifier as a minimum. There are discussions that the data carrier should also contain some additional data attributes for use cases where no internet access is available, or retrieving data from the internet takes too long. However, those data attributes are not yet defined. A QR code type that allows for a web link plus additional attributes has been defined in DIN SPEC 91406:2019–12.
The QR code below leads to the human readable battery passport shown in Section 1. Take out your phone and try it out!
The QR code contains the Decentralised Identifier (DID) and a DID resolver link. To resolve the DID to the battery passport, it needs to be combined with a DID resolver link. In our case, we use the godiddy.com resolver kindly provided by Danube Tech. The DID resolver can be freely chosen by the manufacturer or can be built in-house. The combination of DID and resolver URL leads to the link below which is encoded in the QR code above.
https://api.godiddy.com/0.1.0/universal-resolver/identifiers/did:web:acme.dpp.spherity.com:battery:7be3b99c-33a3-4d72-a747-feeb2c2ed263?service=productA brief aside on DID resolvers:
As a DID revolver you can use the Universal Resolver, the EBSI DID-resolver, or you can build your own DID resolver by following the DID specs. This is an important aspect of the technology approach, because during the lookup of battery passports some data can be collected, such as how often a certain battery passport is queried. If this lookup and usage information is crucial, it is wise to build and host your own DID resolver, otherwise it is the most convenient to use a DID resolver service.
Scanning a QR code that leads you to a web site, is a common functionality, e.g. of mobile phones and millions of devices around the world already have this capability. What happens in the background when you call the link above is explained in the next section.
2.3 DID resolving
When calling the link the link above the DID resolver finds the DID Document that belongs to the battery DID. Every DID is associated with a DID Document. A DID Document is a small data file in JSON format that provides useful information about the DID, such as the public keys associated with it. For DPP access, the most important part of the DID Document is the service endpoint section. Here, the battery manufacturer can provide URLs to the DPP webpage and other resources like authentication endpoints for and machine-readable data.
Figure 3 shows the information flow of accessing a digital product passport.
- The DID and resolver link is scanned from the QR code, then
- the DID resolver is called and finds the DID document of the battery.
- The DID document includes the human readable Battery Passport website URL which is given back to the user who scanned the QR code.
- The user can explore the battery passport website.
The access to the API/ services endpoint works in the same way. The service endpoint gives access to the verifiable Battery Passport and its linked verifiable credentials, e.g. verifiable information about the battery manufacturer or the battery supply chain.
For more details on resolving QR codes to Product Passports, please watch the video “The Power of DIDs #5: A Deep Dive into Service Endpoints and Digital Product Passports” by Markus Sabadello or read the corresponding article “Resolving Digital Product Passports”.
2.4 The DID Document
In Figure 4 below please find the source code of the Battery’s DID Document which includes two service endpoints:
- one which indicates the public accessible, human readable Battery Passport web site https://acme.dpp.spherity.com/ and
- one that reveals the service endpoint where the verifiable battery passport can be found as well as additional verifiable information that is related to the passport, such as audit certificates.
The number of service endpoints is unlimited. The structure of the DID Document is defined in the W3C DID specification. The advantage of the DID Document concept is, if changes need to be made to the battery passport URLs or the service endpoints, or new service endpoints need to be added it can be done without having to change the content of the data carrier or the product identifier. This way product lines can be sold to other companies and information (such as battery loading cycles and repairs) can be added during the lifetime of a product.
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
],
"id": "did:web:acme.dpp.spherity.com:battery:7be3b99c-33a3-4d72-a747-feeb2c2ed263",
"verificationMethod": [
{
"id": "did:web:acme.dpp.spherity.com:battery:7be3b99c-33a3–4d72-a747-feeb2c2ed263#a7a125a110e9f6cd8a7cd4825ba840dc7600320e9d5bea19144cb64d785ad00a",
"type": "Ed25519VerificationKey2020",
"controller": "did:web:acme.dpp.spherity.com:battery:7be3b99c-33a3–4d72-a747-feeb2c2ed263",
"publicKeyMultibase": "z6MkqjcefbHmLzkJKk8cHH8P8aiWxq3MsDaRJM3tyr7RKqm3"
}
],
"authentication": [
"did:web:acme.dpp.spherity.com:battery:7be3b99c-33a3–4d72-a747-feeb2c2ed263#a7a125a110e9f6cd8a7cd4825ba840dc7600320e9d5bea19144cb64d785ad00a"
],
"assertionMethod": [
"did:web:acme.dpp.spherity.com:battery:7be3b99c-33a3–4d72-a747-feeb2c2ed263#a7a125a110e9f6cd8a7cd4825ba840dc7600320e9d5bea19144cb64d785ad00a"
],
"keyAgreement": [],
"service": [
{
"id": "did:web:acme.dpp.spherity.com:battery:7be3b99c-33a3–4d72-a747-feeb2c2ed263#product",
"type": "ProductPassport",
"serviceEndpoint": "https://acme.dpp.spherity.com/battery/7be3b99c-33a3-4d72-a747-feeb2c2ed263"
},
{
"id": "did:web:acme.dpp.spherity.com:battery:7be3b99c-33a3–4d72-a747-feeb2c2ed263#product-information",
"type": "ProductPassport",
"serviceEndpoint": "https://acme.dpp.spherity.com/battery/7be3b99c-33a3-4d72-a747-feeb2c2ed263"
}]}Figure 4: DID Document of a battery with service endpoints
2.5 The trusted ledger
According to the DID spec, the DID Document must sit on a Trusted Ledger. The Trusted Ledger of the DID Document depends on the DID method being used. A trusted ledger can be an Ethereum Network, a Hyperledger Indy Network, or a simple web domain. Therefore, the technical DID resolution differs for each DID method.
The DID method is specified by the DIDs prefix. In our example, we’re using the did:web DID method. Unlike other methods that store DID Documents on distributed ledgers, the did:web method involves hosting the DID Document at the well-known URL of a pre-existing web domain*. This is useful when the web domain and organisation controlling it is already trusted by users, such as reputable institutions like government agencies or large enterprises.
*DID-web is lacking some security features, such as traceable key rotation. Improvements are currently being designed e.g. here, and here and here.
3. The machine readable Battery Passport and its verification
The second main feature of this showcase is to verify the Battery Passport, ie. to check if the battery passport was modified, if the vocabulary is compliant, and who issued the Battery Passport.
3.1 The machine readable Battery Passport
In our showcase, Spherity is the manufacturer of the Battery and issuer of the Battery Passport. Everyone can verify who issued the DPP and if it was modified or revoked. This is achieved by signing the DPP verifiable credential with the Spherity’s private key using our DPP solution VERA. The credential includes Spherity’s company DID in the issuer field (Issuer DID) and the Product DID in the credentialSubject field. It also contains all the technical data about the Battery which is also displayed on the human readable web page shown above. Lastly, the proofValue field contains the digital signature which was created using the private key associated with Spherity’s issuer DID.
3.2 The semantics
The DPP can be checked against a vocabulary that is used to describe the Battery. This step checks if the naming of the attributes and the structure correspond to a given schema. As mentioned in Chapter 1, the used vocabulary and its semantics was defined by the Battery Pass Content Guidance Documents. As this vocabulary do not yet exist as JSON-LD schema, we have created a demo schema and are hosting it on our Spherity Website in the interim (See: https://api-rcs.susi.spherity.dev/products/v1/public-ev-battery-passport-007.jsonld). You find the link to this battery pass schema in the context section of the Battery DPP (see Figure 5). In future, this schema and a corresponding SHACL-file should be hosted and maintained by the Battery Pass Project or some other Battery Industry Consortium for Battery DPP validation.
3.3 Validation of the Battery Passport
The Battery Passport can be verified by any third-party verifier without requiring any additional integration work. In this case, we used the open-source verifier developed and kindly made available by EECC. The verifier mainly checks the signature of the Battery Passport.
For this process the verifier reaches out to the DID document of the issuer, here Spherity with the DID did:web:dpp.spherity.com. As per the did:web specification, the DID document MUST be located at the path https://dpp.spherity.com/.well-known/did.json. Any verifier service that receives the DID did:web:dpp.spherity.com will recognize it as a did:web because of its prefix and will know that the DID document can be retrieved from the domain dpp.spherity.com in the /.well-known/ path if not otherwise specified.
Spherity’s DID document includes the public key and the applied encryption method / key which is an ingredient to the cryptographic function of validating the Battery Passport signature. When the signature validation is successful, the EECC verifier shows a green check mark with the comment “Credential Verified!” (See Figure 7).
A customer, auditor or regulator can thus be confident that the Battery Passport was actually issued by the real Manufacturer (here: Spherity GmbH) and be sure that the DPP had not been modified since it was issued (otherwise the signature verification would fail). One other important service of digital signatures is non-repudiation. This means that the issuer can not deny having issued this Product Passport.
3.4 Verifiable Due Diligence reports
More verifiable credentials can be discovered about the Battery manufacturer or its suppliers such as the sustainability report, the Greenhouse Gas Emissions report or the Child Labor report. Those reports are issued as verifiable credentials by a trusted auditor using the same technical concept. The reports can be retrieved via the service endpoints in the DID Document (also called credential store) or could be referenced in the DPP credential and verified through the same method.
In our showcase, we have added a due diligence report that can be downloaded and verified in the same way as the Battery Passport itself. When verifying the “Third party supply chain assurance” report you will notice that the issuer of the report is an auditor (here: RCS Global) and that its signature was successfully verified.
With this principle all relevant supply chain data can be linked from the digital Battery Passport and technically verified. This allows battery manufacturers to show their legal compliance with legal obligations and compliance audits can thus be performed via a few API calls. The decentralised and standardised manner of the concept makes such a DPP system trusted and scalable. It allows supply chain actors to easily join the ecosystem and share data only with verified actors in predefined roles.
Special thanks go to the great technical team of Spherity, who implemented my Battery Passport vision: Ricky Thiermann, Konstantin Tsabolov, Johannes Ebert, Amine Alani, Anuja Deshpande, and Durgesh Singh (Abhi).
