Skip to main content

Credential Types

A Credential Type is a reusable definition of what a credential is: its data schema, its technical format, its icon, and how its fields are laid out when displayed. A wallet's issuer configuration (see Identity Templates) always points at one Credential Type — the type is the "what," the issuer definition is the "who issues it and how."

Finding Credential Types​

Go to Building Blocks → Credential Types tab. The list shows each type's icon, Name, Format, Description, and actions:

IconAction
✏Edit
⬇Export — downloads the type as JSON
🗑Delete (with confirmation)

Two buttons above the list: Import and Create from scratch.

Creating a credential type​

Click Create from scratch. You'll go through a 4-step wizard.

Step 1 — Identity & Configuration​

  • Name (required) — the display name, e.g. "University Degree."

  • Description (optional)

  • Credential Types (required) — a space-separated list of VC type strings, e.g. VerifiableCredential UniversityDegreeCredential. This is the technical type/vct value(s) embedded in every credential of this kind.

  • Format (required):

    • SD-JWT VC — selective-disclosure JSON format; the default choice for most EUDI-style use cases.
    • JWT VC (VCDM) — W3C Verifiable Credentials Data Model as a signed JWT; requires a Schema URL (shown only for this format) pointing to the credential's JSON Schema. Common for EBSI-based credentials.
    • MSO Mdoc — ISO 18013-5 mobile-document format (CBOR-encoded), used for mobile-driving-licence-style credentials.

    See Introduction & Core Concepts for more on choosing between these.

  • Icon — a MUI icon name (e.g. School, Badge, Verified) with a live preview; this icon appears wherever the credential type is shown in lists.

  • Has PDF twin (checkbox) — when enabled, a signed PDF representation is generated alongside every credential of this type, downloadable from the credential's detail view. Useful for credentials people expect to print or attach to an email (e.g. certificates, invoices).

Step 2 — Subject Definition​

Define the credential's data schema using the structured field editor. Organize fields into groups; for each field specify its key, display name, data format (text, number, boolean, date, etc.), and whether it's required. This schema drives both the data-entry form shown during issuance and the validation applied to drafts.

Step 3 — Display Layout​

Design how the credential renders once issued. Drag fields from the pool defined in Step 2 into display groups/columns — this controls the layout shown in the credential detail view (as opposed to a raw key/value fallback, which is what's shown for any type without a display layout).

Step 4 — Review​

A read-only summary of everything you've entered across the previous three steps. Click Create to save the credential type, or step back to make changes.

Editing a credential type​

Click the ✏ icon on any row to open the same 4-step form, pre-filled, ending in a Save action instead of Create.

Importing a credential type​

Click Import to open the Import Credential Type dialog and paste/upload a previously exported type.

Exporting a credential type​

Click the ⬇ icon on any row to download it as JSON.

Deleting a credential type​

Click the 🗑 icon and confirm. Note that deleting a type that's still referenced by a wallet's issuer configuration will leave that issuer definition pointing at a missing type — remove or update the reference in the relevant Identity Template or wallet's Interactions configuration first.

How this connects to a wallet​

A Credential Type on its own doesn't issue or verify anything — it only becomes active once:

  1. it's referenced by a Credential Issuer definition inside an Identity Template or directly on a wallet, which is what lets that wallet actually issue credentials of this type; or
  2. it's referenced by a Credential Verifier definition, which is what lets a wallet request a presentation of it.

Per-wallet issuer/verifier role assignments (which credential type a specific wallet issues under which role) are managed through the wallet's Configure interactions screen — see Managing Identities.

Continue to Managing Identities.