Access credentials

The public part of a passport is open to anyone. The restricted parts are shown only to a reader who presents a credential: a W3C Verifiable Credential asserting the reader’s role, signed by an issuer the node trusts. Which parts each role may see is set per product group; see Access control.

Reading with a credential

A reader sends the credential in the X-DPP-Credential header to the node’s credential read route:

GET /vault/credential/dpp/{dppId}
X-DPP-Credential: <credential>

The node checks the credential’s signature, its expiry, whether its issuer is on the node’s list of trusted issuers, and, where the issuer publishes one, its revocation status list. It then serves the passport filtered to what that role may see. The filtering itself is a pure function: no network, no database.

Issuing a credential from your node

An operator can vouch for the repairers, recyclers and others in its own network:

odal credential issue did:web:repairs.example \
  --name "Example Repairs Ltd" \
  --role authorised_repairer \
  --country DE \
  --product-groups battery \
  --valid-for-days 90

Roles include authorised_repairer, recycler, remanufacturer, preparer_for_reuse and distributor, or any other label for a custom role. Omit --product-groups to cover all of them.

The node signs the credential with its own key. The credential therefore says “this operator attests that this party holds this role”, which is something an operator can reasonably say about its own network.

Two limits

• No authority roles. A node refuses to issue credentials for market surveillance, customs or notified bodies: that standing comes from a member state, not from an operator.
• No revocation. A node publishes no revocation list for credentials it issues, so once issued, a credential cannot be withdrawn. Its lifetime is the only control, and it is capped at 90 days.

Read next

• Access control: what the law says about who may see what.
• Security & cryptography: how signatures and keys work.