#0.17

#0.17.3

#Features

Data Retention - High Availability Support

• Added High Availability (HA) configuration for data retention purge jobs, enabling distributed locking to prevent concurrent execution across multiple instances in Kubernetes or load-balanced deployments.

#Fixes & Improvements

Data Retention

• Improved cron expression parsing and period calculation for more reliable scheduled purge operations.
• Migrated logging to use the Klogging interface for consistent, structured logging across the service.

#Breaking Changes

None

#0.17.2

#Features

Data Retention Service

• Enhanced logging with run IDs for audit trails and debugging, using lambda-based evaluation to ensure log messages are only constructed when the log level is enabled.

#Fixes & Improvements

Resolves breaking changes introduced for DocumentDB in 0.17.1.

#Breaking Changes

None

#0.17.1

Ignore due to breaking changes for DocumentDB. Use 0.17.2 instead.

#0.17.0

#Features

Issuer2 and OpenID4VCI 1.0

• Added support for OpenID4VCI 1.0 through the Issuer2 API, including support for the Authorization Code Flow and Pre-Authorized Code Flow. Learn more here
• Expanded Issuer2 capabilities with feature toggles, data retention service integration providing more flexible issuance workflows and better control over credential lifecycle.

Crypto and Key Management

• Improved crypto onboarding with Azure key-management examples and initialization to accelerate multi-cloud deployments.
• Fixed AWS SDK auth parameter naming to match the expected initialization contract, ensuring reliable key management integration with AWS KMS.
• Added support for Managed Identity authentication for key management with Azure Key Vault, improving security and ease of use. Learn more here
• Added support for Tags for both key management services, allowing you to add metadata to your keys for easier organization and retrieval.

Verifier2 Interoperability and Standards Compliance

• Strengthened verifier2 interoperability with additional W3C VC verification tests, improving conformance coverage and catching regressions earlier.
• Added support for 1EdTechJsonSchemaValidator2019 to broaden schema validation compatibility and support additional credential formats.
• Fixed tests impacted by example updates, including DCQL query correctness and issuer schema alignment, ensuring verification flows remain stable.
• Added OpenAPI examples for internationalized metadata to reduce integration guesswork and improve developer experience.

Persistence Framework and Database Support

• Introduced a new persistence framework with shared APIs and multiple backends (in-memory and MongoDB) to support scalable deployments, including a general API, data filtering, and repository-backed domain persistence used across both implementations.
• Added an in-memory implementation for credential-status storage and reorganized storage strategy/configuration to make deployments easier to reason about, improving separation of concerns and configurability.

Credential Status Storage and Publishing

• Improved credential-status storage and publishing flows with clearer separation of concerns and better configurability, enabling more flexible deployment options and easier maintenance.

#Fixes & Improvements

CI/CD and Testing

• Hardened CI and test suites with self-hosted runner support, better documentation, and more readable integration assertions.
• Improved mdoc integration test readability and assertions to reduce test maintenance overhead and improve developer productivity.
• Updated Docker instructions and fixed an alignment warning to ensure smooth deployment experiences.

Documentation

• Removed groupBy documentation from the events endpoint to match current behavior, ensuring API documentation accurately reflects implementation.

#Breaking Changes

#Using Issuer2 API

You will need to make a minor update to your deployment files to support the new Issuer2 API.

Trying to resolve the openid4vc/v1 endpoint (required for the issuance flow) will result in a 404 error. You will need to update your deployment ingress files to change all

path: /.well-known/vct/v1/

to

​path: /.well-known/

You can always find an up to date example of our deployment files here

#Azure key management behavior

• Azure key management now distinguish between SDK-based and REST-based backends. Existing deployments should review their key configuration and authentication method (SDK vs REST) before upgrading.
• Keys created with one backend (SDK vs REST) are not interchangeable with the other. If you switch backends, you may need to re-provision or migrate keys accordingly.
• Creating a key with the REST-based backend will now require a client ID, tenant ID, and client secret in the configuration, and uses keyType azure-rest-api (and no longer azure).
• Creating a key with the SDK-based backend will now require a managed identity in the configuration, and uses keyType azure (previously not available).
• All customers using Azure Keys must run migration scripts to update their keys to the new format. You can find resources to help you with breaking changes here

#AWS key management behavior

• To better align our request bodies, a new auth property has been added to the config object for the AWS key management service created with the SDK.
• If you are using the AWS key management service created with the SDK only utilising the region property, you will need to update your configuration to include the auth property. If you were previously using the Access Keys or RoleNames you will not be affected by this change.

Previously:

{
  "backend": "aws",
  "keyType": "secp256r1",
  "config": {
    "region": "eu-central-1",
  }
}

Currently:

{
  "backend": "aws",
  "keyType": "secp256r1",
  "config": {
    "auth": {
      "region": "eu-central-1",
    }
  }
}

• If you have existing keys created with the SDK, you will need to run a migration script to update your keys to the new format. You can find resources to help you with breaking changes here