Skip to main content

​
What a preset is

A preset is a published, ready-to-use shape — either for a credential or for a verification request. It’s identified by <author>:<code>, where author is the publisher’s tenant alias (filled in by the platform) and code is a slug the publisher picks (for example, didx:basic-identity for a credential, or didx:basic-identity-request for a verification). Once published, anyone using didx:me can issue or verify against it by passing the preset id. Presets come in two flavours, and each one solves a different problem.

​
Credential presets — the schema of a credential

A credential preset defines what a credential carries and how it’s signed. Concretely:
  • The attributes the credential will hold: their names, types, whether they’re required, and which ones are always disclosed when the credential is presented.
  • The format (sd-jwt or mdoc) — which determines wallet compatibility, disclosure model, and validity rules.
  • The issuer configuration: how the credential is signed (DID vs x509 certificate) and how long it stays valid.
A credential preset is the schema and the signing recipe. Every credential issued against it shares the same shape and the same trust footprint — only the per-recipient values differ. Listed under /presets/credentials. The detailed anatomy is in SD-JWT credential preset and mDoc credential preset.

​
Presentation presets — the reusable verification request

A presentation preset defines how to query the user for information they hold. Concretely:
  • The credential types to ask for (one or more).
  • The attributes to ask back from each.
  • The trusted issuers whose credentials count as proof for each.
It’s a reusable template for the question “show me X, signed by someone I trust”. Once published, a verifier just refers to the preset id every time it wants to ask that question — no per-request setup. Listed under /presets/presentations. The detailed anatomy is in Presentation presets.

​
Uniqueness

A preset is unique in two ways, both enforced at creation:
  • The credential type, first. Each credential preset claims its type exclusively — one preset per type, platform-wide; publishing a preset whose type is already claimed is rejected. The type is what credentials carry verbatim and what verifiers match on, so this rule is what lets everyone in an ecosystem treat the preset as the definition of that kind of credential.
  • The id. Think of <author>:<code> as an alias: it’s derived from the human-readable code the author picks and the author entity itself. An author can’t publish two presets with the same code.
Presentation presets don’t claim a credential type, so only the id rule applies to them.

​
How presets are published

Presets are authored at an ecosystem level. A bank, a university, a regulator, or a national scheme publishes the shapes its community uses. DIDx publishes cross-cutting shapes. Once published, a preset is immutable — fixing a typo or evolving the shape means publishing a new version (e.g. acme:degree-certificate-v2) and migrating consumers. The <author>:<code> id is stable for the lifetime of the preset and is what every consumer references.