A Digital Product Passport must be readable in two ways: by a human (PDF, web page) and by a machine (structured, authentic data). Article 77(5) of the Battery Regulation explicitly requires a machine-readable, signed form as well. The de facto solution for this is W3C Verifiable Credentials (VC).
What are Verifiable Credentials?
The W3C Verifiable Credentials Data Model 2.0 (an official W3C Recommendation since 2025) is a standard data model for expressing verifiable claims. It was originally designed for digital identity (for example, a diploma or a driving licence), but it fits product data perfectly: the issuer makes a signed claim about a subject (the product).
How is a DPP built as a VC?
In simplified terms, a DPP expressed as a Verifiable Credential brings together a few key elements:
@context— the credential vocabulary references (for example,https://www.w3.org/ns/credentials/v2).type— the credential types, for exampleVerifiableCredentialandBatteryPassport.issuer— who issued it, expressed as a DID (for example,did:web:demo.readypass.eu).credentialSubject— the product data itself, i.e. the DPP fields (such asgtin,chemistryType,carbonFootprintTotal).proof— the embedded digital signature (aDataIntegrityProof, for example with theeddsa-rdfc-2022cryptosuite) that makes the record tamper-evident.
In other words, credentialSubject holds the product data, issuer identifies who issued it, and proof carries the cryptographic signature that protects it.
Why VC in particular?
1. Verifiable: anyone who receives the VC can verify the signature — without asking the issuer. 2. Interoperable: a standard, open format; not tied to a single vendor. 3. Selective disclosure: it allows only certain fields to be revealed (for example, for the consumer vs. the authority view) — which aligns with the access groups. 4. eIDAS-compatible: the VC signature can be mapped onto an eIDAS seal/signature.
VC vs. plain JSON
Plain JSON is neat and structured — but anyone can modify it, and it carries no proof of origin. A VC adds cryptographic integrity and verifiable origin on top. That is the difference between "product data" and "authentic product data".
Data Integrity and key management
The most common signing suite is a Data Integrity proof with an Ed25519 key (the eddsa-rdfc-2022 cryptosuite). The issuer's public key can be verified from a did:web document or a trust list — the digital analogue of the eIDAS Trusted List. The verifier indicates validity with a green/red tick.
How does this relate to prEN 18246?
prEN 18246 (DPP data authentication, reliability and integrity) sets out three principles: integrity, authenticity and verifiability. A W3C VC plus a Data Integrity proof implements exactly this in practice.
Frequently asked questions
Do we give the consumer a VC too?
The consumer sees the HTML view; the VC is the machine-verifiable form (for the certifier, the EU platform, integrations).
Does it require a blockchain?
No. A VC is signed and verifiable on its own; it works without a blockchain.
How do I handle selective disclosure?
SD-JWT VC or BBS+ techniques enable field-level disclosure — aligned with the personas.
The format of authentic data matters. ReadyPass issues the DPP with a W3C VC 2.0 + Data Integrity signature — verifiably and interoperably.
Sources: W3C Verifiable Credentials Data Model 2.0; W3C Data Integrity (eddsa-rdfc-2022); prEN 18246; eIDAS 910/2014.
