Credential Templates, Types, and Schemas

Credential Templates, Types, and Schemas explains how the Enterprise Stack models what kind of credential you issue (type) and in which format—while letting you define the “template” logic via your own own system.

What's included

The Enterprise Stack supports:

  • Multiple credential formats (e.g. W3C VC, SD-JWT VC, ISO mdoc/mDL).
  • Arbitrary credential types per format (e.g. DigitalDiploma, BankID, identity_credential, PhotoID).
  • Flexible data structures controlled by you (or by external schemas/standards, depending on the format).
  • Alignment with type metadata concepts (e.g. SD-JWT VC vct Type Metadata) for future schema enforcement and display definitions.

1. Credential Formats

A credential format defines how the credential is structured, serialized, and signed (for example, which fields are required and which cryptographic primitives are used).

Examples include:

  • W3C Verifiable Credential (VC)
  • SD-JWT VC (IETF)
  • mdoc

When you register a credential type in the Enterprise Stack, you always choose one of these formats so the issuer knows how to construct and sign the resulting credential.

2. Credential Types

A credential type answers: “What is this credential?” – for example:

  • DigitalDiploma, EmployeeID, BankID, eID for W3C VC.
  • identity_credential, age_over_18, residency_credential for SD-JWT VC (IETF).
  • org.iso.18013.5.1.mDL or PhotoID for mdoc/mDL-based credentials.

In the Enterprise Stack, you:

  • Register credential types together with:
    • The format (W3C VC, SD-JWT VC, mdoc, …).
    • Optional type-level metadata (e.g. branding).
  • Reference these types in issuance requests.

Once a type is registered within a particular issuer service, any issuance flow (authorization code, pre-authorized, etc.) can issue credentials “of that type” in the chosen format. The issuer does not hard-code which attributes that type must contain – unless the underlying format or external standards require it.

3. Data Structures & Schemas

Where traditional “template engines” define schema inside the issuer product, the Enterprise Stack assumes:

  • Schemas are defined and managed in your or another external systems, not hard-coded into the issuer.
  • The issuer will sign whatever payload you provide, as long as:
    • It is valid for the selected format, and
    • It respects any external schema/standard you use.

In detail:

W3C VC

  • You can define your own schemas (for example using JSON Schema) for the claims you want to include.
  • You design the structure needed for a given type (e.g. BankID: iban, bankName, holderName, riskLevel, …).
  • The Enterprise Stack checks that the credential is a valid W3C VC in JWT/SD-JWT form; it does not impose extra “template rules” on top. Optionally, you can reference an externally hosted schema, and the issuer will validate that the data in the issuance request conforms to it.

SD-JWT VC (IETF)

  • You decide which claims exist and which can be selectively disclosed.
  • The SD-JWT VC spec introduces:
    • vct (Verifiable Credential Type) – an identifier for the credential type.
    • Type Metadata – which describes which claims MUST / MAY appear and optional display properties.
  • This gives you a standards-based way to express “templates” for SD-JWT VCs that wallets and verifiers can understand.
  • Today, in the Enterprise Stack, you can freely define and use your own vct values; the Enterprise Stack does not restrict them and does not manage the associated Type Metadata. If you rely on externally hosted Type Metadata documents, your own systems are responsible for ensuring that issuance payloads conform to those definitions. We are planning a future capability that will let you define this metadata in the Enterprise Stack and optionally validate provided attributes in issuance requests against it.

ISO mdoc

  • These formats come with prescribed data elements and namespaces (e.g. org.iso.18013.5.1.mDL).
  • Some attributes are mandatory (e.g. family name, birth date); others are optional.
  • The issuer enforces the format-level rules, but does not add an additional, proprietary template layer.

At the end, you are not limited in what attributes you put into a credential, as long as they comply with the rules of the chosen format and any external schema or Type Metadata you’ve decided to follow.

“Templates” Without a Templating Engine

So how do you get template-like behavior without a “template” feature in the Enterprise Stack?

You combine three layers:

  1. Configuration level (in the Enterprise Stack)
    • Register a credential type (e.g. BankID) + format (e.g. W3C VC).
    • Optionally edit issuer metadata for labels and branding.
    • Use the registred types in your issuance requests.
  2. Application level (in your backend)
    • Maintain your own schemas or data models for each type.
    • Validate data structure and assemble the final credential payload before calling the Issuer.
    • Reuse structures and mappings across your applications (effectively your “templates”).
  3. Standards level
    • For SD-JWT VC, use vct and Type Metadata to describe schemas and display rules.
    • For mdoc / mDL, rely on ISO-defined docTypes and data element definitions.
    • For W3C VC, use JSON schemas or other schema languages your stack already uses.

Configuring Credential Types per Issuer & Tenant

Each tenant or issuer service in the Enterprise Stack can define its own:

  • Supported formats (e.g. only SD-JWT VC, or SD-JWT VC + W3C VC + mdoc).
  • Credential types per format (e.g. Tenant A: DigitalDiploma, StudentID; Tenant B: identity_credential, EmployeeID).
  • Type-specific metadata (display names, descriptions, branding).

This means:

  • One deployment can host many issuers with very different catalogs of credential types.
  • You can phase in new formats and types gradually (e.g. add SD-JWT VC identity_credential next to existing W3C VC diplomas).
  • You keep type naming and schema definitions aligned with your domain, standards, and regulatory context.

FAQs

  • Do you support credential templates? We don’t ship a built-in “template engine” where schemas are hard-coded into the issuer. Instead, we give you a flexible model of formats + types + schemas. You model “templates” in your own systems (or via open standards like SD-JWT VC Type Metadata), and the Enterprise Stack issues credentials based on those definitions.
  • What’s the difference between a credential format and a credential type? A format defines how the credential is encoded and signed (e.g. W3C VC in JWT/SD-JWT form, SD-JWT VC, mdoc). A type defines what the credential represents (e.g. DigitalDiploma, BankID, identity_credential). You usually register type/format pairs (e.g. BankID as W3C VC; identity_credential as SD-JWT VC).
  • Can I restrict which attributes are allowed for a given credential type? Yes – but this restriction lives in your schemas and rules, not in a rigid built-in template. You can:
    • Validate against your own schema before calling the Issuer.
    • Use SD-JWT VC Type Metadata (vct) to describe required/optional claims and display rules.
  • Do you limit which claims I can put into a credential? No. As long as the credential is valid for the chosen format (and any external schema/standard you use), you are free to include the claims that make sense for your use case. For mdoc/mDL, you must respect the mandatory/optional attributes defined in the ISO standards.
  • How does this compare to systems with rigid templates? In template-heavy systems, changing a credential often means editing templates inside the product. In the Enterprise Stack, the issuer stays schema-agnostic and focuses on issuance, lifecycle, and interoperability. You keep full control over schemas, “templates,” and evolution in your own domain.

Get Started

Last updated on December 15, 2025
Credential LifecycleCredential Delivery