#Credential Templates, Types, and Schemas

Credential Templates, Types, and Schemas explains how the Community 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 Community 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 / mDL (ISO 18013-5)

When you issue a credential via the Community Stack API, you 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 Community Stack, you:

• Define credential types in the issuer metadata configuration 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 configured, any issuance flow 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 Community Stack assumes:

• Schemas are defined and managed in your own 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 Community Stack checks that the credential is a valid W3C VC in JWT/SD-JWT form; it does not impose extra "template rules" on top.

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.
• In the Community Stack, you can freely define and use your own vct values. If you rely on externally hosted Type Metadata documents, your own systems are responsible for ensuring that issuance payloads conform to those definitions.

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 Community Stack?

You combine three layers:

1. Configuration level (in the Community Stack)
   • Define credential types + formats in your issuer metadata configuration.
   • Optionally configure display metadata for labels and branding.
   • Reference these 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 API.
   • 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.

#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 Community 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 define type/format pairs in your issuer metadata.
• 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 API.
  • 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.

#Get Started

• Configure issuer metadata – Learn how to define credential types and formats in the issuer metadata configuration file.
• Issue your first credential – Step-by-step guide showing how to issue credentials using your configured types.