5.9.1

Valera now checks issuers, relying parties, and credentials against the Lists of Trusted Entities, shows every check, and asks before storing a credential that fails one. Several offered credentials can be selected and issued at once, and all of them are shown afterwards. Readers over BLE, NFC, and the DC API are now verified, and the iOS Identity Document Provider extension uses far less memory, so the system no longer terminates it.

• Update to VC-K 9.0.0-RC2
• Issuing:
  • Select the credentials of an offer with a checkbox each instead of a dropdown, showing the scheme and representation of every offered credential, and whether the issuer is not registered for it; none is selected at first, so that the user selects each one to request explicitly, and all selected ones are requested with one authorization
  • Show every credential issued at once on the result screen, with its summary card each, instead of only the first one, also when the store has not yet shown all of them, and replace the large success image with a banner above the cards; issuing from within the wallet says that the user returns to “My Data” instead of to the requesting app or website
  • Request signed issuer metadata and show the validation of the issuer before issuance, i.e. whether its access certificate is trusted, its registration information and registration certificate, and whether it is registered for the offered credential; untrusted issuers are shown as a warning, unsigned metadata as not verified
  • Validate issued credentials with VC-K's CredentialValidator before storing them, which checks their integrity as before, and trust in their issuers per credential type from the Lists of Trusted Entities
  • Ask before storing an issued credential that did not pass every check, e.g. one of an untrusted issuer, an expired one, or one whose status could not be checked, show why, and store it only if the user keeps it
  • Check that an issued credential contains every claim the metadata of its type describe as mandatory, and ask before storing one that misses some, naming the claims the issuer left out; the user may still keep it
  • Validate each received credential once as VC-K decodes it from the credential response, so that an ISO mdoc is stored with exactly the bytes the issuer signed, and reject a credential that can not be decoded as failing its parsing
  • Check the status of an issued credential with its status list fetched again, replacing a cached one, instead of a status list cached for up to its time to live, also while a recent error response of its URL would suppress fetching it
  • Use the client-attestation key for DPoP when wallet attestation is enabled
• Presentation:
  • Validate requests and their relying parties with VC-K's validation reports, and show the outcome as a warning with every check of the request, its access certificate, and its registration certificates, e.g. an untrusted, expired, revoked, or unlinked certificate, or requested data that is not registered; requests failing their integrity, e.g. their signature, are still rejected
  • Show why the WRPAC or WRPRC of a relying party is invalid, e.g. because the WRPRC could not be parsed, is revoked or suspended, its status could not be checked, or it is not linked to a valid WRPAC, and evaluate each of them even if the other one is invalid. A WRPAC or WRPRC missing from the request is shown as not provided instead of invalid
  • Warn about a request signed with a certificate that is no access certificate (WRPAC), i.e. carries no identifier of a relying party, instead of rejecting it
  • Name the failed signature as the reason for rejecting a request instead of the parsing of its access certificate, which is not checked without a valid signature
  • Resolve and display DCQL mso_mdoc_zk credential queries on the consent screens like ISO mdoc queries
  • Show a badge on the consent screens stating whether an ISO mdoc is requested as a plain mdoc or as a zero-knowledge proof (with or without plain fallback)
  • Show a loading screen while the selected credentials are sent to the relying party, and ignore repeated confirmations, which could submit a presentation twice
  • Parse and validate incoming requests, including certificate trust checks, off the UI thread for DC API, OpenID4VP, and proximity flows
  • Load the ZK circuits only for requests that ask for a zero-knowledge proof, which took several megabytes of memory for every presentation, e.g. in the iOS Identity Document Provider extension
• Proximity:
  • Verify the reader authentication of requests over BLE and NFC, reject an invalid one, and show the validation of the reader and its registration certificates like for other relying parties
  • Keep the Bluetooth connection open after sending the response until the reader closes it, for up to five seconds, so that the reader receives the response instead of failing with a closed connection
  • Verifier: Validate received documents with VC-K's CredentialValidator, which now also verifies their device signature or device MAC over the session transcript and trusts their issuers per credential type from the Lists of Trusted Entities, and show the validation of each document with every check; untrusted, expired, or revoked documents are shown with a warning, the claims of documents failing their integrity, e.g. their signature or digests, are not shown
  • Verifier: Sign the reader authentication over the session transcript itself instead of its encoding as a byte string, which holders rejected as an invalid signature
  • Verifier: Honor the “Enable L2CAP in engagement” setting for NFC engagement, which used the general L2CAP setting instead
• DC API:
  • Validate the reader authentication of ISO mdoc requests without registration certificates, reject an invalid one, and show the validation of the reader like for other relying parties; on iOS, show the trust status of the reader on the first screen of the extension as preliminary, and the full validation after continuing, refreshing missing or expired Trust Lists for up to three seconds first
  • Present a credential selected by the system on Android only for the credential query it was selected for, whose claims the system showed, instead of once for every credential query it matches, e.g. twice for a PID requested by two alternative ISO mdoc queries; the matcher reports the query with each entry of the picker
  • Match SD-JWT credentials on Android for DCQL claim paths with array indices or null wildcards, e.g. ["nationalities", null] requested by the EUDI reference verifier, which matched no credential, and update the matcher to Multipaz f7d8e684; values of a claim with a null wildcard match if any selected element matches
  • Match SD-JWT claims on Android against their original object and array structure, including whole objects such as place_of_birth, nested wildcards and indices, and exact typed values; distinguish literal claim names containing dots, numbers or null from path operations, and rebuild registrations with the updated matcher format; as OpenID4VP 1.0, 7.1.1 specifies, a claim whose path selects an element of the wrong type does not match, while other options of claim_sets without it still may
  • Keep ISO mdoc requests as received on Android and iOS, as their reader authentication failed to verify after re-encoding a request whose encoding differs from the one of VC-K, e.g. a zkRequest of the age verification verifier, which was rejected
  • Send an error to the caller and end the flow when the error screen of a failed presentation is confirmed, e.g. of a rejected request, on Android and iOS, where the Identity Document Provider extension stayed open; errors while sending a presentation are now reported to the caller as well, instead of only cancelling the request
  • Answer an issuance request as declined once the user acknowledges that loading the offer, issuing, or storing the credentials failed, which left the request without an answer
  • Open the credential selection on iOS only once after continuing, as a late second navigation could replace it while in use, and show a credential whose freshness or issuer trust can not be evaluated as not checked instead of ending the flow; log uncaught exceptions before the process terminates, and requests the system cancels
  • Do not start the periodic checks of the stored credentials and of the Trust Lists, nor load the ZK circuits ahead of time, in the iOS Identity Document Provider extension, to reduce its memory usage; its requests still refresh stale Trust Lists, and load the ZK circuits when a presentation that requests a zero-knowledge proof is finalized
• Credentials:
  • Show the validation of a stored credential in its details, i.e. its signature, the trust in its issuer, its validity period, and its status, with every check
  • Check the validity period and status of stored credentials with the validation of VC-K, which accepts a status only from status lists signed by a trusted signer, and shows other statuses as not checked
  • Offer to refresh revoked credentials, not only expired ones, as their status is now checked in the background
  • Check the status of ISO mdoc credentials with CWT status lists and identifier lists (ISO/IEC 18013-5, 12.3.6), which were requested and parsed as JWTs only and therefore reported as unknown, cache them like JWT status lists, and report an HTTP error of a status list, e.g. 406, as such instead of failing to parse the error page as a JWT
  • Cache status lists and identifier lists for at most one day, also when their time to live or expiration is later, so that they are requested again daily; a shorter time to live or an earlier expiration still applies
  • Decode the stored credentials again only if they changed, instead of on every change of any stored value, e.g. of the HTTP cache, which held a second copy of every credential, to reduce the memory usage of the iOS Identity Document Provider extension
• Trust Lists:
  • Add “Refresh trust lists” to the settings, which downloads every List of Trusted Entities
  • Trust registration certificates (WRPRC) of relying parties and issuers issued by the providers of the List of Trusted Entities of WRPRC providers, and their status lists signed by its revocation services
  • Continue a presentation with the cached lists if refreshing them fails in any way, e.g. as a request failed, was cancelled by its client or is in its failure cooldown, which could end the DC API flow on iOS; lists that can not be read establish no trust, a status list that can not be fetched is reported as unknown, and the lists are parsed off the main thread
  • Parse each persisted list once per process, one at a time, and only when it changed, instead of every list for every trust state shown and again on every change of any stored value, which exceeded the memory limit of the iOS Identity Document Provider extension, so that the system terminated it with the lists of several stages enabled
  • Download each list once if “Refresh trust lists” and the background refresh run at the same time, e.g. after enabling a stage, which downloaded every list twice, and report an HTTP error of a list, e.g. 403, as such instead of failing to parse the error page as a list
• General:
  • Use “Authenticate to continue” consistently for credential issuance, refresh, and presentation prompts on Android and iOS
  • Use VC-K’s public Ktor clients with Valera’s configured HTTP clients for issuing and presentation
  • Log only the headers of HTTP requests and responses in release builds and in the iOS Identity Document Provider extension, as logging their bodies, e.g. of the Trust Lists, took megabytes of memory
  • Write the stack trace of a logged exception to the log file at every log level, not only for errors, and keep the logged message of an error
  • Reduce the images of a successful and a failed presentation to the size they are shown in, which took about 6 MB of memory each