Credential issuance

Credential issuance builds everything a wallet needs to receive a credential. It requires the Platform foundations group: a tenant, KMS signing material and an active authorization server. The journeys run in dependency order: the issuer first, then its branding and the libraries designs are built from (assets, render variants), then credential designs and status lists, then the credential configurations that reference both by returned id, and finally issuance itself.

Every journey opens with a read of the data it is about to change.

Journeys in this group

Journey	What it covers	Complete first
1. Set up the credential issuer	Read the tenant issuer settings, update metadata and display, security, issuance behaviour and credential defaults, bind the authorization server, and check what the issuer publishes.	Configure the authorization server, Connect Azure KMS with BYOK and BYOC
2. Design the issuer	Read the issuer designs, create one bound to the issuer DID and URI, keep it current, and set the tenant brand.	Set up the credential issuer
3. Manage design assets	Read the tenant asset library, upload logos, backgrounds and templates, serve them by content hash, and delete unused assets.	Onboard a tenant
4. Build render variants	Read the render variant library, create simple cards or SVG templates per locale, attach them to designs, and maintain them.	Manage design assets
5. Define credential designs and claims	Read the tenant credential designs, create or import one per credential type, define claims and localization, manage versions, and refresh imported sources.	Design the issuer, Build render variants
6. Publish status lists	Read the tenant status lists, create one per credential profile, choose its signing key, and change and publish entries.	Connect Azure KMS with BYOK and BYOC
7. Configure credential configurations	Read the issuer credential configurations, write one per credential type linking its design, signing and status list, import from external metadata, and check effective values.	Set up the credential issuer, Define credential designs and claims, Publish status lists
8. Issue credentials	Read the issuance templates, create and track credential offers, define reusable templates, and feed attributes through pipeline sessions.	Configure credential configurations
9. Prove the credential status profiles	Run each supported credential format and status pairing independently: SD-JWT VC with JWT status, ISO mdoc with CWT status, and W3C VCDM 1.1 and 2.0 with Bitstring status.	Issue credentials
10. Configure mdoc VICAL and CWT status	Read the trust sources of the mdoc trust domain, configure and activate a VICAL source, and publish CWT status for mdoc credentials.	Publish status lists, Build trust domains and anchors

Boundaries that matter

• Creating a design does not configure an issuer, and creating a status list does not issue a credential or allocate an index. The issued credential response supplies the status URI and index.
• Issuance does not prove wallet storage or presentation. Verification is the Credential verification group.
• EDK has no API to create issuer instances. The tenant issuer comes from onboarding; these journeys configure it.

The canonical EDK Enterprise collection covers this group in 10 Issuer Configuration, 11 Credential Designs, 12 Status Lists, 13 Credential Configurations and 15 Issue SD-JWT VC and mdoc onwards. The format-specific lanes are listed in Prove the credential status profiles.