Define your credential structure
Before issuing, you need to define what data the credential will contain and how it maps from your source systems. This page covers the credential configuration template, how to map your data, and where claim data can come from.
Define your credential structure
Before issuing, you need to define what data the credential will contain and how it maps from your source systems.
Credential configuration
A credential configuration is the template that defines:
- Credential type and format: mDocs (ISO/IEC 18013-5) or CWT.
- Claim mappings: How source data maps to credential attributes, organized by namespace.
- Validity rules:
validFrom,validUntil, or relative expiry (expiresIn). - Revocation: Whether to include status list references.
- Branding: Display metadata for wallet rendering (name, logo, colors).
Credential data mapping
Map your existing data models (e.g., from legacy digital credentials or other data sources) to the relevant ISO/IEC 18013-5 (or equivalent) schema. All claim mapping logic, including translation of custom or legacy fields, should occur in your claims source or be handled before passing data to the credential configuration.
Claim data sources
Claims can come from multiple sources depending on your workflow:
| Source | Available in | Description |
|---|---|---|
| Authentication provider (ID token) | Authorization Code | Claims from the user's OIDC authentication |
| Interaction hook response | Authorization Code | Claims returned by your custom interaction step |
| Credential offer payload | Pre-authorized Code | Claims supplied directly when creating the offer |
| Claims source | Both flows | External API call to fetch additional data |
Next steps
With your credential structure defined, deliver credential offers to holders.
How would you rate this page?
Last updated on