Every Terrave DPP is cryptographically signed with ECDSA P-256, archived to IPFS with a content-addressed CID, and identified with a GS1 Digital Link. Falsification is verifiable by any party with a standard ECDSA library.
Verification endpoint
The public verification endpoint checks the cryptographic integrity of the DPP payload and returns a structured result. No authentication required.
GET /api/dpp/04012345678901/verify
{
"upi": "04012345678901",
"verified": true,
"signature": {
"algorithm": "EC-P256-SHA256",
"keyId": "terrave-hsm-2026-01",
"signedAt": "2026-01-15T09:00:00Z",
"ipfsCid": "bafybei...",
"canonicalDigest": "sha256:a3f2..."
},
"payload": {
"version": "2026-01-15",
"productName": "TerraCem Low Carbon CEM III/B 32.5 N",
"gwpA1A3": 380,
"gwpUnit": "kg CO2e/tonne"
}
}How it works
The full DPP data payload — all 13 EN 15804+A2 indicators, lifecycle modules, product identity, PCR reference, and verification metadata — is serialized as canonical JSON-LD. Field order is deterministic. Unicode normalization NFC is applied.
A SHA-256 digest of the canonical JSON-LD is computed. This is the message that will be signed. Any modification to any field in the payload — including whitespace — changes the digest.
The digest is signed with ECDSA P-256 using the issuing organization's private key, held in a hardware security module (HSM). The signature, public key fingerprint, and key identifier are embedded in the DPP manifest.
The signed manifest is pinned to IPFS. The content-addressed CID is deterministic — the same data always produces the same CID. The CID is embedded in the public DPP record and cannot be changed without invalidating the signature.
The product's GTIN is registered in the GS1 Digital Link registry, resolving to the Terrave DPP page. QR codes on physical products encode the GS1 Digital Link URL per ISO/IEC 18975.
Signature manifest
The signature manifest is included in the DPP JSON-LD under the terrave:signature key. It contains everything needed for independent verification.
Lifetime persistence
ESPR Article 10 requires DPPs to remain accessible throughout the product's expected service life plus 10 years. Terrave implements a three-layer persistence guarantee.
Signed manifests are pinned to IPFS via Pinata and a second independent pinning service. Content-addressed CIDs are deterministic and retrievable from the IPFS network independently of Terrave's infrastructure.
Terrave maintains a data escrow arrangement with a designated EU archive operator. In the event of Terrave's operational discontinuity, the escrow operator receives the full DPP dataset and continues serving the verification API.
GS1 maintains the Digital Link registry independently of Terrave. Even if a DPP's hosting URL changes, the GS1 registry record can be updated to point to the new location — without changing the GTIN or QR code on the physical product.
FAQ
Terrave's signing scheme implements the DPP integrity mechanism defined in prEN 18246, the draft European standard for Digital Product Passport data elements and exchange formats. The scheme uses ECDSA P-256 (also known as ES256 in JWA notation), which is the mandatory algorithm in prEN 18246.
Yes. The public verification endpoint at /api/dpp/[upi]/verify returns the signature, public key, and canonical digest in a format compatible with standard ECDSA libraries. The signing public key is also published in the Terrave Trust Registry at /api/trust/keys. Any ECDSA P-256 implementation can verify the signature independently.
IPFS archival means the signed manifest is content-addressed and retrievable from the IPFS network independently of Terrave's infrastructure. The IPFS CID is embedded in the public DPP record. In addition, Terrave maintains an ESPR-compliant data escrow arrangement with a designated EU archive operator for lifetime plus 10 years persistence per ESPR Article 10.
Call the verification endpoint at /api/dpp/[upi]/verify. It returns `verified: true` if the current data matches the signature, and `verified: false` with a `reason` field if the signature fails to verify — indicating the data has been modified after signing. The IPFS CID provides a secondary check: the CID from the public record must match the CID of the retrieved manifest.
ESPR Article 10 requires DPPs to remain accessible for the product's expected lifetime plus 10 years. For construction products with a 50-year reference service life, this means 60 years minimum. Terrave's IPFS archival and escrow arrangements are designed for this requirement. The Terrave DPP hosting commitment is published at /legal/dpp-persistence.
Yes, but each update creates a new version with a new signature and IPFS CID. The version chain is immutable — prior versions remain retrievable. The DPP record shows the current version as the active record. Verifiers and regulators can retrieve any prior version. Version history is accessible at /api/dpp/[upi]/history.
The GS1 Digital Link QR code encodes the UPI (GTIN-based unique product identifier), not a version-specific URL. The resolver at terrave.ai/01/[gtin] always redirects to the current active version of the DPP. The physical QR code does not need to change when the DPP is updated.
GS1 Digital Link URLs follow the pattern terrave.ai/01/{gtin}. For example, a product with GTIN 04012345678901 resolves via terrave.ai/01/04012345678901. The resolver validates the GTIN check digit (ISO/IEC 7812 mod-10 algorithm) and redirects to the active DPP at terrave.ai/dpp/{upi}. The URL structure conforms to GS1 Digital Link Standard v1.1.1.
Ready to verify
The Terrave demo DPP for TerraCem Low Carbon CEM III/B 32.5 N is publicly accessible. Call the verification endpoint or scan the GS1 QR code.