DPP Certification and Trust Chain

Imagine you buy a luxury watch on a second-hand marketplace. The seller swears it is authentic. How do you check, without trusting the seller — and without trusting the original brand's website either, in case it disappears one day?

This page explains how Keyban's certification model answers that question. We start with the everyday picture, then dive into the cryptographic details for developers who need to integrate or audit.

Paper certificate vs DPP

A traditional product certificate (paper, hologram, scratch-off code) has three weaknesses. A DPP fixes all of them:

1. Paper certificate

   Traditional model

   • A skilled counterfeiter copies the visual artifact
   • Verification depends on the brand's servers staying online
   • You have to trust whoever shows you the certificate
   • No audit trail when data is corrected or enriched
2. Digital Product Passport

   Keyban model

   • Cryptographically signed — forgery breaks the signature
   • Anchored on a public blockchain that outlives any single brand
   • Anyone can verify, without sign-in and without contacting the brand
   • Every certification is a permanent on-chain receipt

Side-by-side comparison: paper certificates can be forged, depend on the brand existing, and require trusting the seller. DPPs are cryptographically signed, anchored on a public ledger, and verifiable without trusting any single party.

The trust chain at a glance

Three roles share the work, and four building blocks support them:

1. BrandCreates the passport, decides which fields to certify.
2. Blockchain receiptA tamper-proof event on Starknet linking the product to its signed payload.
3. Certifier registryAn on-chain directory listing which signing keys are currently trusted.
4. Signed passportThe product data plus a cryptographic proof, packaged together.
5. CertifierHolds the signing key, stamps the passport like a digital notary.
6. IPFS storageA worldwide library where the signed passport lives, addressed by its content hash.
7. BuyerAnyone, anywhere, with a QR code or link — no account required.

A hub showing the signed passport at the centre, surrounded by the brand who creates the data, the certifier who signs it, the blockchain receipt, the IPFS storage, the on-chain registry of certifiers, and the buyer who verifies.

The headline insight: the buyer never contacts the brand's servers. The blockchain plays the role of an indestructible public ledger; the IPFS network plays the role of a worldwide library where the signed passport is stored. Both are designed to outlive any single company.

The four-step lifecycle

1. 1

   Step 1: Brand

   Creates a DPP passport with the product information.

3. 2

   Step 2: Sign & anchor

   Certifier signs it, then writes a tamper-proof receipt on the blockchain.

5. 3

   Step 3: Buyer scans

   Scans a QR or follows a link — no account, no password.

7. 4

   Step 4: Verify

   App checks the signature against the receipt — no backend in the loop.

Four-step flow showing the brand signs and anchors a DPP on-chain, then any secondary buyer can query the chain and verify the signature trustlessly.

How a passport gets certified

When the brand decides a passport is ready to publish, two things happen automatically:

1. The data is sealed. Keyban takes the fields the brand wants to certify (name, vintage, serial number, etc.) and computes a unique fingerprint of them — a content hash. Like a digital wax seal: any change to the data, even a single character, produces a completely different fingerprint.
2. A receipt goes on-chain. Keyban writes that fingerprint on the Starknet blockchain along with a pointer to the full signed passport (stored on IPFS). This receipt is permanent and visible to everyone.

From that moment on, the passport is anchored. The brand cannot quietly edit it later; any modification would produce a new fingerprint that does not match the on-chain receipt.

How verification works

When you scan a QR code or open a verify-dpp link, the app silently does four things:

1. Asks the blockchain for the receipts attached to this product. It receives a list (one per certification — there can be several over time if the brand updates the data).
2. Fetches the signed passport from IPFS using the pointer in the receipt.
3. Recomputes the fingerprint locally from the data it just downloaded, and checks it matches the receipt on-chain.
4. Verifies the certifier's signature using the certifier's public key (which is also published on-chain, in a registry).

If all four checks pass, you see a green checkmark. If any of them fails, the app warns you. No server in the middle, no trust in the seller required.

What if the certifier's key is compromised?

Keys do not last forever. If a brand suspects their certification key has leaked, or simply wants to refresh it as a precaution, they can rotate to a new key:

1. 1

   Step 1: New key created

   Status: pending. The old key keeps signing in the meantime.

3. 2

   Step 2: On-chain rotation

   rotate_certifier(old, new) is published to the registry.

5. 3

   Step 3: New key active

   Old key transitions to rotated. New passports use the new key.

7. 4

   Step 4: Old passports still verify

   The registry remembers both keys, so historical certificates remain valid.

Four-step rotation: a new key is created in pending state, registered on-chain, the old key transitions to rotated, and old signed passports remain verifiable through the registry.

If a key is explicitly revoked (because it was actually compromised), older signatures from after the suspected breach should not be trusted. The verify-dpp app warns the buyer accordingly.

What if a field is sensitive?

Some passport fields contain information that should not be public (a serial number tied to insurance, an IBAN, personal data). The brand can pre-encrypt those fields before submitting the passport to Keyban, using the convention encrypted:<algorithm>:<payload> per field. The signed passport then carries the encrypted form on IPFS, exactly as if it were any other string — Keyban itself does not introspect the value.

When the verify-dpp app encounters such a field, it shows a placeholder and asks the buyer to provide the decryption key. The decryption happens entirely in the browser. Brands typically distribute the key separately (a printed card inside the box, an SMS, a follow-up email) so the buyer can unlock the sensitive parts without exposing them on the public ledger.

Recap

Question	Short answer
Can the brand fake a certificate?	No — the on-chain receipt is the source of truth, not the brand's website.
Can a re-seller modify the passport?	No — any change breaks the fingerprint, and the app will refuse to verify.
What if the brand goes out of business?	The blockchain and IPFS keep working, so verification still succeeds.
Do I need an account to verify?	No — verify-dpp works without sign-in.

---

For developers

The sections above describe the user-facing model. Below are the technical details, in case you need to integrate with Keyban or audit the system end-to-end.

Cryptographic primitives

Concern	Choice	Why
Signature algorithm	ECDSA P-256 (NIST curve)	Widely supported, hardware-accelerated, FIPS-friendly.
Hash function	SHA-256	Standard, fast, collision-resistant.
Canonical form	JCS (RFC 8785)	Deterministic JSON serialisation; ensures the same data always produces the same hash.
Content envelope	W3C Verifiable Credential v2	Open standard, interoperable with non-Keyban verifiers.
Proof format	DataIntegrityProof, ecdsa-jcs-2019	Modern VC proof suite, no JWS overhead.

W3C Verifiable Credential structure

The "signed passport" we have been calling a passport throughout this page is, technically, a W3C Verifiable Credential (VC) — an open standard for cryptographically attested data, defined by the W3C VC Data Model 2.0. Using the standard means any third-party verifier (not just verify-dpp) can validate the signature with off-the-shelf libraries.

When a passport is published, Keyban builds a VC like this:

{
  "@context": "https://www.w3.org/ns/credentials/v2",
  "type": ["VerifiableCredential", "PassportCredential"],
  "issuer": "did:key:z...",
  "credentialSubject": {
    "productName": "Wine Bottle 2020",
    "vintage": "2020",
    "alcohol": "14%"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-jcs-2019",
    "proofValue": "..."
  }
}

The type array carries the generic VerifiableCredential type plus a Keyban-specific PassportCredential marker, so an external verifier can distinguish a DPP credential from another VC variant.

The issuer field is a did:key DID — the certifier's public key encoded directly in the identifier. A verifier extracts the public key from the DID, then checks the signature against the canonicalised credentialSubject.

On-chain event

After signing, the VC is uploaded to IPFS (returns a CID) and the KeybanDppCertifier Cairo contract emits:

pub struct KeybanPassportCertified {
    #[key] pub id: ByteArray,         // Product UUID
    #[key] pub ipfs_cid: ByteArray,   // IPFS pointer to the signed VC
    #[key] pub content_hash: felt252, // SHA-256 of the canonical credentialSubject
}

Source: blockchain/starknet/contracts/src/dpp_certifier.cairo.

The content hash is masked to fit in felt252 (Starknet's native field element). Concretely, the top 5 bits of the SHA-256 output are zeroed out: collision resistance drops from 2²⁵⁶ to ~2²⁵¹, still astronomically safe. The hash is stored as a 0x-prefixed 64-char lowercase hex string for byte-for-byte equality across frontend/backend/indexer.

All three event fields are indexed, so verifiers can look up an event by product ID or by content hash alone — useful when a buyer has the certificate file but not the product UUID.

Certification key lifecycle

Each organization owns a P-256 key pair. The states are:

State	Meaning
active	Used to sign new VCs.
pending	New key created during a rotation, waiting for the on-chain rotate_certifier call to confirm.
rotated	Replaced by a newer key. Old VCs signed with it remain verifiable.
revoked	Explicitly invalidated. Verifiers should refuse VCs signed with it.

The Starknet KeybanCertifierRegistry contract stores the mapping pubkey → (name, isValid). During rotation, both the old and new keys are present in the registry, so there is no window where verification breaks. Each rotation is published per-network (mainnet, sepolia, devnet) and Keyban tracks completion individually for each network to avoid "key not found" errors.

Verification sequence

1. Buyerprimary
2. verify-dpp appsystem
3. Starknet RPCsystem
4. IPFS gatewaysystem
5. Certifier registrysystem

1. 1Scan QR or paste URL with ?productId=...
2. 2getEvents(KeybanPassportCertified, id: productId)
3. 3[event1, event2, ...]
4. 4GET /ipfs/{event1.ipfs_cid}
5. 5Signed VC JSON
6. 6getCertifier(vc.issuer.pubkey)
7. 7{ name, isValid }
8. 8Verify ECDSA-P256 signature, recompute content_hash (entirely client-side)
9. 9Show verified attributes, certifier name, signature status

Buyer provides URL/QR, app queries blockchain, fetches IPFS, verifies signature.

Trust assumptions

A buyer trusts:

• The certifier registry contract to honestly report which public keys are valid.
• The blockchain itself — that no one can rewrite history.
• The IPFS gateway they query, but only for availability; the content is hash-addressed so any tampering is detected immediately.

A buyer does not need to trust:

• The brand's website or backend.
• The seller of the product.
• Keyban's own servers.

This is the structural property the architecture buys: portability of trust over time and across operators.