Skip to main content
This page covers authoring an SD-JWT credential preset: the request body, the decisions that only the author makes, and the common pitfalls. For the field-by-field shape walkthrough, see SD-JWT credential preset. For mDoc credentials, see Create an mDoc credential preset.

​
Request

​
Authoring guidance

​
Choose the preset identifier (code)

Your tenant alias is automatically prepended as the author, so code: "basic-identity" becomes the canonical preset id <your-alias>:basic-identity. That id is what issuers will pass as presetId for the lifetime of the preset. Presets are immutable once published. Keep the code short, lowercase, hyphen-separated, and meaningful on its own (degree-certificate, not cred1).

​
Choose the credential type (type)

type is the credential type (the VCT) carried by every credential issued against the preset. It is unique platform-wide: one preset per credential type, and creating a preset whose type is already claimed by another is rejected with a 409. Supply it verbatim in the optional type field, for example when the type is dictated by an external ecosystem such as EUDI:
If type is omitted, the platform infers it from the preset identifier: the preset acme:identity-1-0 projects to https://didx.co.za/vct/acme/identity-1-0. Accepted shapes: a urn: URI, or your own platform VCT URL (https://didx.co.za/vct/<your-alias>/...). Other http(s) URLs are rejected: every URL-shaped VCT issued by the platform is platform-hosted and resolvable.

​
Write the description for someone scanning a list

templateName and templateDescription are what issuers see when browsing the catalogue. Be specific in the description. “Basic identity credential carrying first name and last name” is far more useful than “Identity credential”.

​
Use alwaysDisclosed: true sparingly

For SD-JWT credentials, the holder normally controls what’s shared on a per-presentation basis. alwaysDisclosed: true removes that choice for a given attribute. Set it true only for fields whose presence is meaningful in itself, typically trust signals like a verified flag, where the credential carries no useful meaning without it. For ordinary personal data (name, date of birth, etc.), leave it false and let the holder decide.

​
Pick issuerConfig.signer deliberately

did:web is the default — credentials are signed using the tenant’s did:web DID, and verifiers fetch the DID document to validate. Choose certificate only when you need x509-based signing (rarer for SD-JWT; common in regulated environments). The certificate option also caps the validity window at 365 days.