Saltar al contenido principal

Standards

Security & trust

A DPP is evidence. It must be tamper-evident, signed by an identifiable party, and verifiable offline.

Threat model

  • Counterfeits cloning your QR to serve a fake DPP.
  • Man-in-the-middle rewriting DPP responses in transit.
  • Internal tampering with stored data after publication.
  • Key compromise allowing forged attestations.
  • Denial of resolution — your resolver goes offline.

Controls

  • TLS 1.3 minimum on all endpoints. HSTS preload.
  • Every DPP payload signed (JWS or JSON-LD data-integrity proofs).
  • Signatures verifiable against a DID or an X.509 chain — prefer DIDs for cross-organisation scenarios.
  • Append-only event log for writes; Merkle-anchored hash published daily.
  • Key rotation policy with revocation lists (status list 2021 or similar).
  • Redundant resolver hosting with a documented failover to a Foundation-or-industry backup in case of provider failure.

Trust lists

For cross-border acceptance, Member States are expected to maintain trust lists of authorised DPP issuers and market-surveillance callers — analogous to eIDAS trust lists. Align your issuer identity (DID or X.509) with the emerging EU trust list formats.