v0.4.0 (in development)

Upgrading

  • This release changes the identifiers used by the wallet and Wallet Provider to refer to the wallet’s keys, invalidating existing keys and their identifiers. The WP’s database will therefore have to be cleared when deploying this.

  • Specifying for which attributes a relying party is authorized in a certificate has been made attestation format agnostic, meaning all existing certificates are invalid and should be regenerated to accommodate the new structure.

  • The minimum size for the ephemeral_id_secret in the configuration of the verification_server has been increased from 16 to 32 bytes.

  • The Wallet Provider no longer tracks in the database for each user if that user received a WUA. The corresponding column in the WP’s user table has been removed, so the WP’s database will therefore have to be cleared when deploying this.

  • Switched configuration of mock relying party, issuance and verification server to use DCQL (Digital Credential Query Language) for defining credential queries. (see issuance_server.example.toml)

  • The disclosed_attributes endpoint of the verifier no longer returns a JSON object keyed by the attestation type. Instead, it returns an array of attestation objects, with attestation_type added as a field in that object. This effectively removes the limitation that a particular attestation type can only appear once in disclosed attributes.

  • The WTE acronym has been replaced by WUA across the codebase, including in the Wallet Provider and PID issuer configurations, as well as their database table and column names. These configurations will need to be updated and the database migrations will need to be fresly run. In addition, a variable in the wallet configuration has been renamed, so an updated wallet configuration will need to be deployed.

New features

  • The wallet and Wallet Provider now use the SHA256 of the public keys to refer to the wallet’s keys, so that the wallet’s signing instructions to the WP are non-repudiable.

  • The wallet now supports issued attributes containing ‘null’ and array values.

  • The PID issuer now includes a new attribute called the recovery code, which is computed as the HMAC of the user’s BSN.

  • When identical attestations are issued, the wallet detects if the attestation already exists and renews the existing attestation. The only exception is that if the attestation will be valid in the future, the attestation will be treated as new.

Code improvements

  • ReaderRegistration has been made attestation format agnostic, meaning the attributes specified in the reader certificate for which the relying party is authorized to request them are specified in a manner that works for both mdoc and SD-JWT attestations.

  • The various instructions that the wallet used to send to the Wallet Provider during issuance and disclosure are now consolidated into two instructions, one for issuance and one for disclosure, that handle everything the wallet needs at once.

Wallet app improvements

  • The wallet now includes a ‘video tour’ screen, where users can watch short short video tutorials to learn about the functionalities of the app.

  • The UI has been updated to support the ‘pid renewal’ flow. Currently only available in mock builds.

  • Update to Flutter 3.35.1.

Bug fixes

CI changes

  • Configure volume mounts more naturally (and aligned with other charts) via Helm values for update-policy-server and wallet-provider.

  • Configure wallet-provider directly via Deployment instead of separate ConfigMap.

  • Capture stdout/stderr from PKCS#11 library and log lines via log library to get structured logging

  • Base CI images on Debian Trixie