Standards

APIs

Every DPP service exposes at least four capabilities: resolve an identifier to a DPP, read the DPP, discover which attestations compose it, and (optionally) update fields. Nothing here is exotic — use boring, stable HTTP patterns.

Resolve & read

GET /01/<gtin> — returns the DPP as JSON-LD (or HTML via content negotiation).
GET /01/<gtin>/10/<lot> — batch-level resolution.
GET /01/<gtin>/21/<serial> — instance-level resolution.
Responses include an ETag and a Last-Modified header.

Discovery

A DPP references the attestations (VCs) that make it up. Clients need a cheap way to list them:

GET /01/<gtin>/attestations returns a list of VC IDs with issuer and subject claims.
GET /vc/<id> returns the signed credential for independent verification.

Write

Writes update in-life fields (e.g., state of health, ownership transfer) or append a new VC. Typical pattern:

POST /01/<gtin>/events — append a signed event.
PATCH /01/<gtin>/fields/<path> — mutate a specific field, creating a new DPP version.

Authentication

Public layer: unauthenticated, rate-limited.
Professional layer: OAuth 2.0 client-credentials with a claim that the caller has a verified role (repairer, refurbisher, recycler).
Authority layer: mutual TLS or OAuth with a claim attesting the caller is an authorised market-surveillance authority.
Writes always require a signed request or VC presentation from a key authorised by the DPP issuer.