Cryptographic Signing

Every DPP is a signed, verifiable credential

Digital Product Passports are only useful if they can be trusted. The platform signs every DPP document using the W3C Data Integrity standard (eddsa-jcs-2022) with Ed25519 elliptic curve signatures. The result is a tamper-evident credential that any verifier can authenticate independently — no central authority, no proprietary validation service.

If a single byte of the DPP changes after signing, the signature breaks. That is the point.

How signing works

The DPP document is canonicalised using JSON Canonicalization Scheme (RFC 8785) to produce a deterministic byte representation. Proof options — type, cryptosuite, timestamp, verification method, and purpose — are separately canonicalised. Both are SHA-256 hashed and concatenated. The combined hash is signed with the Ed25519 private key. The signature is encoded as multibase base58btc and attached as a proof object on the credential.

Decentralised identity with DID:web

Each deployment has a did:web identifier that matches the resolver domain. A public DID document is served at /.well-known/did.json containing the Ed25519 public key. The DPP issuer field identifies the brand — for example, did:web:yourbrand.com — while the verification method points to the resolver where the key is hosted. Any verifier fetches the public key from the DID document and checks the signature. No API key. No account. No trust relationship. Just cryptography.

W3C Verifiable Credentials format

The signed DPP follows the W3C Verifiable Credentials v2 specification, with contexts from GS1 and the UN Trade and Transport vocabulary (UNTP). It carries the type VerifiableCredential and gs1:DigitalProductPassport. This is not a proprietary format. It is the open standard that the CEN/CENELEC technical standards (prEN 18239) reference for DPP access rights and interoperability. When the EU central registry arrives, your credentials are already in the right format.

Why do Digital Product Passports need cryptographic signing?

The EU Digital Product Passport is a regulatory document. Market surveillance authorities, customs officials, and consumers need to trust that the data has not been altered since the brand published it. Without cryptographic signing, there is no way to distinguish a legitimate DPP from a tampered or fabricated one.

The ESPR 2024/1781 regulation requires that DPPs are verifiable and tamper-evident. The CEN/CENELEC technical standards series (prEN 18239 for access rights, prEN 18223 for interoperability) references W3C Verifiable Credentials as the mechanism for achieving this. Cryptographic signing is not an optional security layer. It is a regulatory requirement that will be enforced as delegated acts come into force.

A signed DPP gives you three things:

1. Tamper evidence — If any data in the DPP changes after signing, the signature becomes invalid. This protects against both accidental corruption and deliberate falsification.
2. Issuer authentication — The signature proves which organisation issued the DPP. Verifiers can confirm the issuer’s identity through the DID document without contacting the issuer directly.
3. Decentralised verification — Anyone can verify the signature using the publicly available key. No API key, no account, no trust relationship with the platform. Just cryptography and an HTTP request.

How does DID:web verification work in practice?

When a verifier (market surveillance authority, customs official, or consumer app) receives a signed DPP, the verification process is:

1. Read the verificationMethod field from the proof object (e.g., did:web:yourbrand.aura.trackvision.ai#key-1)
2. Resolve the DID by fetching https://yourbrand.aura.trackvision.ai/.well-known/did.json
3. Extract the Ed25519 public key from the DID document
4. Verify the signature against the DPP document using the public key

If the signature is valid, the verifier knows two things: the DPP was issued by the entity that controls that domain, and the document has not been modified since signing. The entire process requires a single HTTP GET request and a standard cryptographic verification. No proprietary SDK. No platform dependency.

The did:web method was chosen because it maps directly to DNS, the existing trust infrastructure of the internet. If you control your domain, you control your DID. This aligns with the CEN/CENELEC prEN 18239 standard, which specifies DIDs and OAuth 2.0 for DPP access rights management.

What standards does the signing implementation follow?

The cryptographic signing implementation is built on open, well-documented standards:

• W3C Data Integrity 1.0 — The overarching specification for attaching cryptographic proofs to linked data documents
• eddsa-jcs-2022 cryptosuite — The specific combination of Ed25519 signatures with JSON Canonicalization Scheme, defined as a W3C specification
• RFC 8785 (JCS) — JSON Canonicalization Scheme, which produces a deterministic byte representation of any JSON document regardless of key ordering or whitespace
• Ed25519 — An elliptic curve digital signature algorithm, chosen for its speed, small key size (32 bytes), and resistance to side-channel attacks
• Multibase base58btc — The encoding format for the signature value, as specified by the W3C

These are not proprietary choices. They are the standards that the GS1 Digital Link ecosystem and CEN/CENELEC technical standards reference for DPP interoperability. A DPP signed by Aura can be verified by any system that implements the same standards, including other DPP platforms, EU customs systems, and open-source verification tools.

How does signing relate to the GS1 Digital Link resolver?

The GS1 Digital Link resolver serves as the public endpoint where signed DPPs are accessed. When a verifier or system requests the machine-readable DPP (via Accept: application/ld+json or ?linkType=gs1:dpp), the resolver returns the full JSON-LD document including the cryptographic proof.

The resolver also hosts the DID document at /.well-known/did.json, making it the single endpoint for both DPP retrieval and issuer verification. When a consumer scans a QR code on a product, the resolver handles content negotiation: human consumers are redirected to the branded DPP landing page, while machine consumers receive the signed credential.

Each brand deployment gets its own resolver domain and its own Ed25519 key pair managed through GCP Secret Manager. Keys are isolated per tenant with no cross-tenant access.

How Aura helps

Cryptographic signing is technically demanding to implement correctly. Canonicalisation, key management, DID document hosting, and proof generation each require specialist knowledge. Aura handles all of this automatically. When a DPP is generated from your product and supplier data, it is signed with your brand’s Ed25519 key, the proof is attached, and the credential is served through your GS1 resolver with the DID document in place. You do not need to manage cryptographic keys, configure DID endpoints, or understand JCS canonicalisation.

Your DPPs are verifiable from the moment they are published. When the EU central registry becomes operational and begins accepting signed credentials, your DPPs will be ready for submission without modification.

Frequently asked questions

Can market surveillance authorities verify our DPPs independently?

Yes. That is the purpose of decentralised verification. Any authority can fetch the DID document from your resolver domain, extract the public key, and verify the signature. No API key, no account, no commercial relationship with Aura is required. The verification process uses open W3C standards that any system can implement.

What happens if we need to update a DPP after it has been signed?

When a DPP is updated (for example, after receiving new supplier data), the document is re-signed with a new timestamp. The previous signature becomes invalid for the updated document, which is the intended behaviour. The new signed version replaces the old one at the resolver endpoint. If you need to maintain a history of signed versions, the platform retains all provenance data for the 10-year regulatory retention period.

Are the cryptographic keys managed by Aura or by the brand?

Keys are managed by Aura on the brand’s behalf, stored securely in GCP Secret Manager with per-tenant isolation. Each brand deployment has its own Ed25519 key pair. No other tenant can access your keys. The public key is published in the DID document at your resolver domain for anyone to use in verification.

Is the W3C Verifiable Credentials format compatible with the future EU central registry?

The CEN/CENELEC technical standards (prEN 18239, prEN 18223) reference W3C Verifiable Credentials and Decentralised Identifiers as core components of the DPP interoperability framework. While the registry’s API contracts are still being finalised, the credential format Aura uses aligns with the published standards drafts. When the registry becomes operational, Aura will implement the connection automatically.