Create a presentation preset
Guidance for authors
Below is the part that’s specific to authoring: decisions only the author makes, and the common pitfalls.Choose the code carefully
Your tenant alias is automatically prepended as the author, so code: "basic-identity-request" becomes the canonical id YOUR_ALIAS:basic-identity-request. That id is what verifiers will pass as presetId for the lifetime of the preset. Presets are immutable once published, so fixing a typo later means publishing -v2 and migrating consumers.
Keep the code short, lowercase, hyphen-separated, and meaningful on its own (identity-kyc, not req1).
Decide whether it belongs in the shared catalogue (namespace)
Presentation presets carry the same namespace field as credential presets. It defaults to public, listing the preset for every tenant. Set it to private to keep a request shape to yourself. The id gains a ~ prefix (~acme:internal-check), it appears only in your own listings, and other tenants get a 404 fetching it by id.
You reference a private preset exactly as a public one: reference: "presetId:~acme:internal-check". See public and private presets for the full visibility rules.
Write the description for someone scanning a list
templateName and templateDescription are what verifiers see when browsing the preset catalogue. Be specific in the description. “Identity proof for KYC onboarding, with first name, last name, and verified flag” is far more useful than “Identity request”.
Make sure type matches what issuers issue
The templateCredentials[].type URI must exactly match the credential type that issuers put on the credentials they produce. If issuers issue https://test.didxtech.com/vct/didx/basic-identity and your preset asks for https://test.didxtech.com/vct/didx/basic-id, the request will not match, even if the contents are otherwise compatible. Coordinate with the issuers in your ecosystem.
Almost always specify trustedIssuers explicitly
Leaving trustedIssuers empty (or omitting it) accepts any issuer of this credential type, which is rarely what a real verifier wants. List the specific issuers whose credentials you trust.
Choose a name for each issuer that the end user will recognise. The wallet shows it during the consent step, so “South African Reserve Bank” is better than “sarb-prod-1”.
Updates and removals
The current API supports creating presets and reading them; it does not expose update or delete endpoints. Treat each published preset as immutable. If you need to change a shape, publish a new preset, for example bumpingcode to basic-identity-request-v2, and migrate consumers.
What consumers do with your preset
Once published, verifiers reference your preset by its canonical id (YOUR_ALIAS:basic-identity-request). They pass that id when creating a presentation request; that’s all they need to do on their side.