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).

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.

  • Updated Flutter to 3.44.1

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 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.