Configure credential configurations
A credential configuration is what the issuer advertises and a wallet requests, addressed by its credential_configuration_id. Writing its settings links a credential design, a signing key and a status list to the issuer. This journey comes after designs and status lists because it references both by returned id.
Complete first: Set up the credential issuer, Define credential designs and claims, Publish status lists.
Steps and why they come in this order
| Step | Why here |
|---|---|
| 1. Review configurations and effective values | Seeded or earlier configurations may already advertise the type. Read stored and effective values before writing. |
| 2. Write a configuration | Writing settings both stores them and registers the id in the issuer index, which is what makes the issuer advertise it. |
| 3. Import configurations from issuer metadata | When a configuration already exists in another issuer metadata document, import it instead of retyping it. |
| 4. Check the effective configuration | Inheritance is live. Confirm the resolved values, operator form and authorization server before creating offers. |
Design versus configuration
The credential design owns identity and presentation: per-locale display, claim policy and rendering. The configuration settings own everything else: OAuth scope, format identity, binding and signing algorithms, proof types, signing key, validity and status binding. Writing settings never touches design-authored display, and editing a design never overwrites settings.
The routes below are tenant-scoped. The same paths exist under .../oid4vci/issuer/instances/{instanceId}/...
when a tenant runs more than one issuer instance and a configuration must differ per instance.
Deeper reference
Credential Issuer: Credentials
explains every setting and the 13 Credential Configurations Postman folder.
Issuer configuration shows a complete effective example.
Next journey
Continue with Issue credentials.