Define credential designs and claims

A credential design is the tenant-owned definition of one credential type: its format, the identifier wallets match on, its claims and their disclosure policy, per-locale labels, and the cards a wallet may draw. Issuer metadata and issuance templates read from it.

Complete first: Design the issuer, Build render variants.

Steps and why they come in this order

Step	Why here
1. Review existing credential designs	A vct can belong to only one credential design per tenant; a second create with the same vct is rejected with 409. Find existing designs before creating one.
2. Create or import a design	Identity (alias, format, type identifier, configuration id) is chosen at create and is what everything later references.
3. Define claims and localization	Claims and labels are body fields of the design, edited after identity exists and checked through resolve before issuance.
4. Manage versions	Issuer configurations and templates can pin a design version, so check history before and after changes.
5. Refresh imports and retire designs	Imported designs drift from their source. Refresh and cleanup come last, once the design is in use.

Formats

Format	Primary identifier	Claims
SD-JWT VC (dc+sd-jwt)	vct	JSON claim paths with a selective-disclosure policy
ISO mdoc (mso_mdoc)	docType	Namespace and element pairs such as org.iso.18013.5.1/family_name
W3C VCDM 1.1 (jwt_vc_json)	VCDM 1.1 context and types	Paths below the VCDM 1.1 credential subject
W3C VCDM 2.0 (jwt_vc_json-ld)	VCDM 2.0 context and types	Paths for the VCDM 2.0 credential

Choose the format before creating the design. A format change is a new credential contract. A design is a definition: creating one makes the type available but issues nothing.

Deeper reference

Credential designs covers the Admin Console workbench and the Postman folders 3. Tenant APIs > Credential designs and Define your own credential. Versioning explains the version model.

Next journey

Continue with Publish status lists.