Skip to main content
A credential preset is a published, ready-to-use credential shape: its format, attributes, and disclosure rules. Once published, anyone issuing the credential refers to it by its identifier (something like acme:degree-certificate or didx:basic-identity). To issue a credential, you pick a preset and supply the per-recipient values for the attributes it declares. Think of the preset as a blank form: the fields, types, required markers, and disclosure rules are all baked in. Issuance is filling that form in for a specific person, and the platform stamping it with a cryptographic signature. The signed, filled-in form is the credential the user holds in their wallet.

​
Identifier and metadata

The metadata that identifies a preset is the same regardless of credential format:

​
Uniqueness

A preset is unique in two ways, both enforced at creation:
  • The id. <author>:<code> is the human-readable preset identifier. The platform interpolates author from your tenant alias; you supply code, a lowercase hyphen-separated slug, in the create request.
  • The credential type. Each preset claims the credential type its credentials carry (templateType: the VCT for SD-JWT, the DocType for mDoc), and the claim is exclusive across the whole catalogue. Creating a preset whose credential type is already defined by another preset, yours or anyone else’s, is rejected with a 409. A preset is the ecosystem-wide schema for its type: two presets must never share a type with diverging definitions.

​
Immutability

Once published, a preset is immutable: the API supports creating and reading presets, and does not expose update or delete endpoints. Removal is deliberately not permitted:
  • Credentials may already have been issued against the preset. They stay in wallets and keep verifying long after issuance, and the preset is the published definition of what they mean.
  • Removal would free up the preset’s credential type, allowing it to be re-created with a different schema or semantics. Verifiers matching on that type would then face two generations of incompatible credentials under one identifier.
If a preset no longer fits, publish a new one (e.g. acme:degree-certificate-v2) and migrate issuers to it. The identifier you choose at creation lives forever, so choose the slug carefully.

​
Two formats, two shapes

The rest of the preset’s body — templateAttributes, templateType, issuerConfig, validUntil — differs significantly between SD-JWT and mDoc. The two formats use different attribute structures, different signer options, and different validity rules.

SD-JWT credential preset

The default for most credentials. Selective disclosure built in, wide wallet support.

mDoc credential preset

For ISO 18013-5 credentials such as mobile driving licences and government-issued ID.

​
Three paths

Browse a credential preset

Find a preset already published by DIDx or another publisher and issue against it. No setup, no design work.

Create an SD-JWT preset

Publish your own SD-JWT credential shape so it can be issued by name.

Create an mDoc preset

Publish your own mDoc credential shape so it can be issued by name.

​
When a preset isn’t enough

If no preset matches your use case, you can define a one-off custom credential template instead. This is the exception, not the rule; most integrations don’t need it.