Credential Designs: Credential designs
Catalog id: resource.credentialDesigns.credential-designs
A credential design is the tenant-owned definition of one credential type: the wire format it uses, the identifier wallets and issuers match on, the claims it carries, how those claims are labelled per locale, and which cards a wallet may render for it. Issuer metadata, issuance templates and wallet display all read from it, so it is the single place a credential type is described.
A design is not an issued credential. Creating one makes the type available; it does not put anything in a wallet.
Audience: tenant administrator.
Guide: Credential designs.
Identity is chosen at create, the rest is edited after
Creating a design registers its identity and little else. The alias is the short handle operators
and automation use inside the tenant, so keep it stable. The format decides which primary identifier
applies: SD-JWT VC uses vct, W3C uses type, and mdoc uses docType. That identifier is what
wallets and issuer metadata match on, which makes it the one value you cannot casually revise once
credentials referencing it exist.
credentialConfigurationId is the id advertised in OID4VCI issuer metadata. It is optional at create
but required before that configuration can issue anything, so a design without one is a definition
that no wallet can request yet.
hostingMode says whether the tenant hosts the type document itself or caches an external one. With
vctHostingMode set to HOSTED, the platform serves the VCT document at the tenant's own URI, which
is what lets a wallet resolve the type without reaching a third party.
Everything else is finished in the workbench after create, and the console opens it for you: claims and their selective-disclosure policy, per-locale labels, attached render variants, the raw source document, and a resolved preview showing what a given locale actually gets after inheritance.
Working with designs
- Admin Console
- Request
- Response
- Try it
Resources > Credential Designs > Credential designs is the library. Each row is one type, with its alias, hosting mode and a summary of its primary binding. An empty list is normal on a clean tenant that was registered without sample data.
- Admin Console
- Request
- Response
- Try it
The create dialog asks only for identity, then hands you the workbench. This example registers an
SD-JWT VC design: the binding carries vct, vctHostingMode, the credentialConfigurationId and
the issuer it belongs to, while alias and hostingMode sit on the design itself.
Read the response rather than assuming: it returns the design id, its version and content hash, and those are what later calls and issuer configuration should use. A design being visible in the library does not mean it can issue; its binding, claims, signing selector and status profile all have to validate together first.
Full schema: Credential design API.
The workbench tabs
Overview holds the alias, format and the format-specific binding identifiers. Claims is the claim tree: paths, value kinds, widget hints and which claims may be selectively disclosed. Localization carries per-locale display strings and claim labels. Render attaches variants and sets per-locale preferences, though variant content itself is edited under Render variants. Source JSON exposes the raw document for import and export style edits, and Resolved preview shows the effective design for one locale after inheritance is applied, which is the tab to check when a label is not appearing where you expect.