Credential Schemas (V2)
This page covers credential schemas using the /api/credential-schema/v2
endpoints. The v2 schema API is available now but support for using v2
schemas in issuance and verification flows is still in development.
V1 schemas remain the current standard until that work is complete, at which point v1 will be disabled. See Credential Schemas (V1) for the current implementation.
A credential schema defines the structure of a credential type: the claims it contains, the formats it will be issued in, and how it should appear in a wallet. You create a schema once and reuse it every time you issue a credential of that type. If you are issuing membership cards, you create a membership card schema; every membership card you subsequently issue is an instance of that schema.
Example
The following schema issues a credential in two formats simultaneously: SD-JWT VC and ISO mdoc. It contains three claims: a flat string claim with format-specific technical keys, a nested address object, and a flat boolean claim with no mapping.
{
"name": "Membership Card",
"organisationId": "{{YOUR-ORG-UUID}}",
"formats": [
{
"format": "MDOC",
"schemaId": "org.example.membership"
},
{
"format": "SD_JWT_VC"
}
],
"claims": [
{
"key": "Last Name",
"datatype": "STRING",
"required": true,
"mappings": [
{
"format": "MDOC",
"namespace": "org.example.membership",
"technicalKey": "family_name"
},
{
"format": "SD_JWT_VC",
"technicalKey": "surname"
}
]
},
{
"key": "Address",
"datatype": "OBJECT",
"required": true,
"mappings": [
{
"format": "MDOC",
"namespace": "org.example.membership",
"technicalKey": "address"
},
{
"format": "SD_JWT_VC",
"technicalKey": "address"
}
],
"claims": [
{
"key": "Street",
"datatype": "STRING",
"required": true,
"mappings": [
{
"format": "MDOC",
"technicalKey": "street_address"
},
{
"format": "SD_JWT_VC",
"technicalKey": "street_address"
}
]
},
{
"key": "Postal code",
"datatype": "STRING",
"required": true,
"mappings": [
{
"format": "MDOC",
"technicalKey": "postal_code"
},
{
"format": "SD_JWT_VC",
"technicalKey": "post_code"
}
]
}
]
},
{
"key": "member_status",
"datatype": "BOOLEAN",
"required": true
}
],
"allowRevocation": true,
"allowSuspension": true,
"batchSize": 10,
"layoutType": "CARD"
}
Formats
The formats array declares which credential formats this schema will be
issued in. Each entry references the name of a configured format instance
— not a format type or media type identifier. In the example above,
formats references two instances named MDOC and SD_JWT_VC; your
deployment configuration defines what each of those names actually means.
The configuration for the example might define these two instances like this:
{
"format": {
// Reference this
"SD_JWT_VC": {
"type": "SD_JWT_VC",
"params": { ... }
},
// Reference this
"MDOC": {
"type": "MDOC",
"params": { ... }
}
}
}
The value provided in formats must match one of your configured instance
names exactly. The system applies the corresponding configuration,
including any format-specific identifiers like dc+sd-jwt, automatically.
You do not set those values in the schema.
Schema ID
Optionally, provide a schemaId alongside the format name. Its effect
depends on the format:
- For mdoc, it sets the DocType.
- For SD-JWT VC, it sets the
vctclaim.
If omitted, the system generates one. For guidance on reading your configuration and identifying available format instances and their capabilities, see Reading the Configuration.
Claims
Claims define the attributes a credential contains. Each claim needs a
key, a datatype for validation, and a required flag. If required
is false, the issuer can leave that claim empty at issuance time.
If a claim's datatype is OBJECT, it nests other claims inside it via
its own claims array, as with the Address claim in the example above.
Claim mappings
By default, a claim's key is used directly as its technical
representation in every format. Add a mappings array to a claim when
you need one of the following:
-
A separate technical key per format: the
keyserves as a single, user-friendly display value for the claim across all formats, whiletechnicalKeyis the value actually written into the credential. This lets one schema definition support different technical naming per format. For example, a claim with the keySurnamemight map tolast_namein one format andsurnamein another. -
A namespace for mdoc root-level claims: the mdoc standard expects every root-level claim to belong to a namespace. If you don't provide a
namespacein a claim's mdoc mapping, the system falls back to using the schema ID as the namespace. For nested claims inside anOBJECT, the namespace is inherited from the parent and doesn't need to be repeated.
A mappings entry is never required on its own — you can omit mappings
from a claim entirely. If you do include one, format and technicalKey
are both required within that entry.
Revocation and suspension
Set allowRevocation: true to enable credential revocation. Suspension
requires revocation to be enabled; set both allowRevocation and
allowSuspension to true to allow issued credentials to be suspended.
In a multi-format schema, revocation and suspension apply per format according to what each format supports. If a format in your schema does not support a revocation or suspension feature you have enabled, that feature does not apply to credentials issued in that format, while other formats in the same schema are unaffected.
ISO mdoc supports suspension only, not revocation. Suspension of mdocs works by preventing the wallet from obtaining a new Mobile Security Object (MSO) when the current one expires. This means suspension of an mdoc credential takes effect at the next MSO refresh rather than immediately.
Translations
Schema names and individual claim names can be translated for display in wallets that support localization. See Translating Credential Schemas.
Other schema options
Batch issuance
The optional batchSize parameter sets the maximum number of credentials
that can be issued from this schema in a single batch request.
Layout
layoutType controls how the credential is rendered in the wallet.
CARD is currently the only supported value.
Transaction codes
transactionCode requires the holder to enter a code to accept the
credential. See Transaction Codes for
configuration options and use cases.
Wallet unit attestation
keyStorageSecurity and requiresWalletInstanceAttestation:
these settings require the wallet to provide attestations related to app
integrity and ability to generate certain types of keys. These settings
restrict which devices can receive credentials issued under this schema.
See
Device Limitations for Wallet Unit Attestation.
Claim datatypes
For available claim datatypes, see the datatype object of your
configuration. For configuration, see Datatypes.