#0.7.0

#Features

Holder Policies for Silent Wallet Flows

Use holder policies to allow users to set granular sharing rules for credentials, ensuring consent-first data sharing during silent issuance and verification flows.

New Status Policy in Verifier Service

A flexible status policy to validate common status types like revocation or suspension, but also custom reasons based on the BitstringStatusList, StatusList2021, RevocationList2020, TokenStatusList standards.

Support for Non-Expiring Issuance Sessions

The Issuer Service API now allows for the creation of non-expiring issuance sessions. When you call ⁠POST /issuer-service-api/credentials/issue, you can set the session to remain active indefinitely by including the parameter ⁠expiresInSeconds: -1. If you prefer a session with a specific duration, you can specify the desired length in seconds using the ⁠expiresInSeconds parameter. By default, if this parameter is omitted, the session will expire after five minutes.

mDL Issuance Simplified

The mDL issuance request no longer requires the trustedRootCAs field. Also, the OpenAPI examples have been updated.

Credential Branding Extension

Issuers can now provide a secondary image for the credential branding information when setting up an issuer service. See an updated example in the SWAGGER docs.

Enterprise UI Updates

The management of service configuration in JSON format has been implemented for the following services: DID registry, KMS, Status, Credential Store, DID Store, Verifier, and Wallet.

Improved Authorization Request handling when presenting credentials via the wallet service UI.

#Fixes

SD-JWT VC Display Info Loading

When you issue an SD-JWT VC credential using the credentials/issue endpoint of the issuer service, the display information will now be correctly retrieved from the issuer service configuration. This happens if you do not provide any display information directly in your issuance request.

Wallet Service Key Enforcement

The wallet presentation flow no longer enforces that holder keys must be secp256r1. Applications can now present non‑MDOC credentials with other key types.

#Docs

OpenAPI documentation improved

Each endpoint now features clearer descriptions, and the OpenID4VCI specifications include the standardVersion as a path parameter. These updates ensure that clients generated from api.json accurately reflect the API behavior.