v0.6.0 (dev)

Upgrading

  • The callback URI for issuance changed from “/return-from-digid” to “/iss”. This will need to be updated in relevant applications, like rdo-max and DigiD.

  • The neither value for session_type_return_url in the verification server configuration is no longer supported; use same_device (the default) with a return_url_template instead.

  • The pid_issuance section of the Wallet configuration has been paired down as follows:

    • The pid_issuer_url field is now just called url.

    • The value at the digid/client_id path has been moved to client_id.

    • The object contained in digid_http_config has been removed.

  • The pid_issuer configuration has had its digid.http_config section renamed to digid.client_settings. Within this section, the base_url field has been renamed to oidc_identifier, which contains the same value.

  • The supported client identifier prefix (in the context of OpenID4VP, so a “client” here is a relying-party, a verifier) has changed from x509_san_dns to x509_hash. That means our wallet app expects x509_hash client ids. In our issuer server, the client_id field, which is part of a usecase needs to be updated (in our code that means the demo_issuer). For example:

    "client_id": "x509_hash:YYIN_SgqjFj2044q1fpvpa0rxqrXEG0U1xdm2Hw_ohM",

    The value of x509_hash is the base64url-encoded value of the SHA-256 hash of the DER-encoded X.509 certificate.

  • The attestation_settings sections of both the pid_issuer and the issuance_server have undergone significant changes. These sections have been renamed to credential_configurations an are now configured per credential format. Each individual section directly represent a Credential Configuration as presented in the Issuer Metadata. The full changes are as follows:

    • The section key now represents a Credential Configuration identifier, where before this was used as the Attestation Type.

    • The attestation_type field was added.

    • The copies_per_format field has been removed and replaced by a format field and a top-level batch_size field, that applies to all issued credentials.

    • The status_list section has had a group_name field added, in order to decouple status lists from the Attestation Type. Normally this value would be set to the same value as the Credential Configuration identifier.

  • Related to the previous change, the IssuerDocument the attestation server provides in the context of disclosure-based issuance has had the format field added.

  • The Wallet Instance Attestation (WIA) configuration has changed, reflecting a rename from WUA (Wallet Unit Attestation) and the addition of wallet metadata fields:

    • In the Wallet Provider configuration, all wua_* fields have been renamed to wia_*, and the [wua_status_lists] section has been renamed to [wia_status_list]. Additionally:

      • wua_issuer_identifier has been replaced by four wallet metadata fields: wia_wallet_name, wia_wallet_version, wia_wallet_link (optional), and wia_wallet_solution_certification_information.

      • A wia_certificate field (base64-encoded DER X.509 certificate) must now be provided. The WIA JWT is signed using a certificate chain (x5c header) instead of a bare key.

    • In the PID Issuer configuration, wua_issuer_pubkey has been replaced by wia_trust_anchors, a list of base64-encoded DER X.509 CA certificates used to validate WIA tokens.

  • The pid_issuance section of the wallet configuration has been replaced with pid_credential_offer, which contains a single string value. This string value contains a Credential Offer URI that should be used as the basis for PID issuance. Note that this URI can contain a Credential Offer either by value or by reference and must use the Authorization Code flow.

  • A type_metadata_uri is added to the CredentialConfiguration to specify a SD-JWT VC type metadata. The preview endpoint is modified to not return the type metadata but the CredentialConfigurationId instead ensuring type metadata fetching is independent of the preview.

  • A new service pacf_issuance_server has been added. It is a standalone issuance server that issues credentials using the Pre-Authorized Code Flow, and requires its own configuration file and database.

  • The demo_issuer configuration has two changes:

    • A new top-level pacf_issuance_server_url field must be added, pointing to the internal server port of the pacf_issuance_server.

    • Each entry under usecases is now either a Pre-Authorized Code Flow usecase (containing only data) or a disclosure-based usecase (containing data, client_id, and disclosed).

  • The SD-JWT VC type metadata is updated to draft 13. This means they will have to be updated as follows:

    • The lang field in DisplayMetadata and ClaimDisplayMetadata is renamed to locale.

    • ClaimMetadata now contains a mandatory field that indicates whether the claim is mandatory. This should be set to true for all claims that are listed in schema.required.

    • The schema is now dropped from the metadata.

  • A new service acf_demo_issuer has been added. It is a standalone issuer server that issues credentials using the Authorization Code Flow, and requires its own configuration file and database.

  • flutter_rust_bridge has been updated to 2.12.0, run cargo install flutter_rust_bridge_codegen --locked --version 2.12.0 to update.

  • The pid_issuer service can now serve a custom DigiD login page, where a preconfigured BSN can be selected. For this, the pid_issuer offers a digid.mock_subjects setting.

  • All issuance binaries now require the wia_trust_anchors array in their configuration file, instead of just the PID issuer.

New features

  • The Wallet Provider will now block recovery codes during PIN recovery or PID renewal when the newly disclosed recovery code does not match with stored recovery code. This is suspicious because it is already checked by the NL Wallet app as well.

  • Users can delete non-PID cards from their wallet, via the card detail screen.

  • When a card is deleted, the wallet now stores this in its history.

  • Allow incoming BLE connection through ‘Present QR’ screen. The BLE server is now started when this screen is displayed and a remote verifier can connect to trigger navigation to the disclosure flow.

  • Parse the ISO 18013-5 “close proximity” DeviceRequest and present it in the disclosure screen so the user can share the specified credentials.

  • If the RP’s DCQL request contains a Trusted Authorities Query of type Authority Key Identifier, both the verification_server and the wallet will now respect this, allowing the RP to request attestations signed by specific issuer keys.

  • The verification server will now include session_type in the hash computation of the ephemeral_id, making it impossible for any intermediary to change its value.

  • The time field will now only be included in the ephemeral_id computation for sessions that do not use a return URL. As a result, same-device sessions (and cross-device sessions that use a return URL) no longer expire, fixing a UX issue that occurred when the user took too long to enter their PIN.

  • Added an in-app FAQ, reachable from the menu’s “Need help?” entry.

  • Show a dedicated error screen instead of crashing when the app hits an invariant/unexpected fatal error.

  • Updated Flutter to 3.44.4

  • Added logic to filter duplicate PID cards using the prioritized list of PidAttestations from FlutterConfiguration. This results in no longer showing duplicate PID cards in the UI.

  • Add support for credential offer based issuance flow in wallet_app.

  • There is now support for Generic Issuance using the Authorization Code Flow. This is demonstrated by the new service acf_demo_issuer, which can issue an insurance attestation including a user consent page.

  • The wallet uses fields from the Wallet Relying Party Access Certificate when showing an organization to the user.

  • The pid_issuer service can now serve a custom styled DigiD login page, where a preconfigured BSN can be selected, or a custom BSN can be entered.

Interoperability improvements

  • The verification server now enforces HAIP 1.0 compliance for same-device flows: a redirect_uri is always returned to the wallet after a successful disclosure. See the Upgrading section for the required configuration change.

  • Sections of both the wallet and issuer code have been updated to be compliant with OpenID4VCI 1.0:

    • The issuer now provides a nonce endpoint, which replaces the c_nonce value in the TokenResponse.

    • The PID issuance flow has been changed to use the Authorization Code flow, instead of a hybrid implementation of the Authorization Code and Pre-authorized Code flow.

    • The issuer and wallet now support and use Pushed Authorization Requests (PAR) for the PID issuance flow.

    • The wallet supports retrieving a Credential Offer from a URI that is passed using the credential_offer_uri query parameter.

    • The wallet includes the correct scope value in the Authorization Request it sends in the Authorization Code flow, as retrieved from the Issuer Metadata. The Issuer issues credentials based on these particular scope values.

  • The well-known path is now derived according to spec for Credential Issuer Metadata and Oauth 2.0 Authorization Server Metadata when a subpath is involved.

  • SD-JWT VC type metadata is updated to draft 13.

  • All issuance servers can serve signed OpenID4VCI metadata with the WRPAC certificate.

  • The WIA, also known as the Wallet Attestation in OpenID4VCI, is now no longer sent as part of the CredentialRequest data structure, but along with the PAR and Token Request as defined in the [“OAuth 2.0 Attestation-Based Client Authentication” draft specification][2], in accordance with OpenID4VCI 1.0.

Bug fixes

  • The issuance server now correctly returns a 406 when it cannot match the Accept header in content negotiation.