Changelog

​

External credential types for SD-JWT

• Supply the VCT verbatim with type. SD-JWT credential presets accept an optional type carrying the credential type as-is: a urn: URI (e.g. urn:eu.europa.ec.eudi:pid:1) or your own platform VCT URL. Every credential issued against the preset carries it in its vct claim. Previously the VCT was always projected from code. See Create an SD-JWT credential preset.
• code keeps two roles. It remains the preset id component (<author>:<code>), and, when type is omitted, the shortcut that projects to a platform-hosted VCT URL.
• Custom credential templates accept type too. For the advanced custom template path, the same type field carries the credential type verbatim; sending both code and type there is rejected with a 400.
• Type metadata for external types. The platform hosts type metadata only for platform VCT URLs. For external types, GET /templates/credentials/sd-jwt/:id/type-metadata returns the generated document for the author to publish per their ecosystem’s resolution policy.
• One preset per credential type. Creating a preset whose credential type is already claimed by another preset is rejected with a 409.

​

Validation changes

• mDoc type is format-validated. DocTypes on templates and presets must be dot-separated reverse-DNS-style segments, at most 200 characters; URL-shaped or whitespace-containing values are rejected with a 400.
• mDoc templates reject code. Previously it was silently ignored; it has never meant anything on mDoc templates.
• Malformed SD-JWT type values fail schema validation. The 400 error code for these changed from BAD_REQUEST to VALIDATION_ERROR, consistent with other schema validation failures.

​

API surface

• /api/v1/ versioning. All existing endpoints are now mirrored under /api/v1/ with a versioned prefix. Unversioned /api/ routes continue to work, so there are no breaking changes for existing integrations.
• Issuances and credentials are separate resources. Under /api/v1/, the previously conflated /credentials resource is split:
  • /api/v1/issuances: issuance sessions (offer / exchange flow).
  • /api/v1/credentials: flat issued credentials and revocation.
  Each resource now has consistent {id} semantics. See the Credentials API reference for the new shapes.

​

Preset-driven workflows

• Issue a credential by preset. POST /credentials/issuance accepts presetId instead of credentialTemplateId. The first issuance per (preset, tenant) materialises the underlying template behind the scenes; subsequent calls reuse it. See Issue a credential.
• Create a presentation request by preset. POST /presentations/request accepts presetId, mirroring the credential flow. See Create a presentation request.
• Tenant-portable trusted issuers on presentation presets. Presets now declare trusted issuers as real-world identifiers (public DIDs or x509 certificates) instead of tenant-scoped record ids. When a tenant uses the preset, each issuer is auto-resolved against that tenant’s own trusted entities (reused or created). The response surfaces a meta.trustResolution block describing what mapped where. See Presentation presets.

​

Wallet & verifier behaviour

• Org-pushed presentation requests no longer fail when the user has no matching credential yet. Push always succeeds for a valid request URI. As long as the request hasn’t expired, the user can come back and respond to it whenever they actually obtain credentials that satisfy it.
• Verification error details propagated. Errors from underlying verification surface as a list in the API response, instead of being collapsed to a single message. Easier to diagnose why a presentation failed.