[WAL-896] feat(wallet): finalize authenticated OpenID4VP presentation flow

[philpotisk]

Summary

This is the WAL-896 wallet, protocol, and mobile consumer half, stacked directly on the verifier prerequisite #2055. It is based on feature/wal-896-verifier, which now sits on current main after walt-id/waltid-identity#2031.

The branch makes wallet2/mobile presentation consume authenticated Final Request Objects while preserving the stateless HTTP continuation API and the retained mobile preview flow. The coordinated Enterprise counterpart is walt-id/waltid-identity-enterprise#553.

What Changed

Authenticated wallet2 and mobile flow

• Requires strict signed Request Object resolution for wallet2/mobile presentation, including the expected audience and wallet-controlled client trust configuration.
• Re-resolves the immutable signed request URL for preview, build, response, and rejection so caller-supplied request state cannot alter the reviewed transaction.
• Keeps both continuation models: single-use retained preview state for the mobile consent flow, and stateless preview/build/send/reject operations bound to the same signed request URL.
• Preserves the wallet2 routes and request-based APIs introduced by Fix/wallet cleanup #1970; this branch wires trust and authenticated resolution through them rather than restoring caller-echoed AuthorizationRequest state.
• Exposes the negotiated response mode in the mobile presentation request model and refreshes the generated ABI/API snapshot.

DCQL and Crypto2 response handling

• Enforces DCQL Final semantics, credential-set references, complete disclosure paths, trusted-authority handling, and typed required-credential availability failures.
• Treats a missing required credential as a protocol-level preview error that can be rejected safely; malformed or unsupported matcher constraints remain fail-closed.
• Makes Crypto2 response-encryption selection deterministic and binds the selected verifier key and encryption parameters to the authenticated request.

X.509 and mobile fixtures

• Adds platform-specific X.509 certificate-chain validation needed by the wallet client-identifier path, with explicit trust-result handling and no system-trust fallback.
• Adds signed Request Object fixtures and Android/iOS mobile coverage for the signed inline URL and Request URI POST contracts.

Stack and ownership

• Immediate base: feature/wal-896-verifier / #2055 on current main.
• The native GitHub stack is #2055 → #1885 → #2091.
• Enterprise counterpart: walt-id/waltid-identity-enterprise#553, stacked on walt-id/waltid-identity-enterprise#604.
• No WAL-995 code, branch, or dependency is included.

Caveats and Follow-Ups

• The public-demo mobile checks remain enabled and are not skipped. They require the deployed verifier2 service to emit the signed inline Request Object supplied by [WAL-896] feat(verifier2): expose authenticated request objects #2055; until that deployment is available, those checks can fail before wallet processing begins.
• Recommended merge/deployment order is explicit: review and deploy the verifier changes in [WAL-896] feat(verifier2): expose authenticated request objects #2055, rerun the public Android/iOS checks against that deployment, then review and merge this wallet/mobile PR. Keeping the two logical changes stacked gives each PR a clean diff while preserving one combined delivery path.
• Request URI transport still accepts HTTP as well as HTTPS; tightening that repository-wide policy is outside this PR.
• The legacy waltid-wallet-api presentation implementation is not migrated to this wallet2/mobile Final-validation contract.
• X.509 client-identifier prefixes require the wallet to provide the intended trust anchors; no system-trust fallback is introduced.

Breaking

• Signed Request Objects are required by default for wallet2/mobile resolution.
• Successful mobile preview models now expose the negotiated response mode.
• This branch does not remove the build-vp-token or send-response route surface preserved from Fix/wallet cleanup #1970; those operations remain bound to the original signed request URL.

[linear-code]

WAL-896

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 4be930d7-4e13-489c-a4a7-83c554f533e4

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[waltkb]

The branch contains various OpenID4VP 1.0 Final violations, pre-Final (OpenID4VP Draft) protocol remnants, compilation failures, broken default Issuer2 signing configuration, conformance tooling that can report false success, etc

btw, why is there so much trailing whitespace across the files?

[szijpeter]

couple of concerns and nitpicks from a (mostly) mobile / wallet perspective. nice work otherwise

[szijpeter]

Nice improvements! 👏🏼

Most of my earlier mobile/wallet concerns are addressed. One blocking issue remains: the Android EHIC integration tests should stay enabled imo. They pass on this PR head and on main, and the public-demo tests do not cover the same POST Request Object retrieval, wallet metadata/nonce, and signed Request Object path.

I’m fine with keeping the iOS EHIC tests skipped until native PKIX/x509_hash validation is supported, but the skip rationale should accurately document that limitation and the trust-anchor follow-up.

My remaining API-compatibility and loopback-HTTPS comments are non-blocking, although I think they would be worth considering.

[waltkb]

Also, WalletPresentationHandler.kt (lines ~626-683) accepts a caller-supplied AuthorizationRequest objects for token construction and sending, and /send-response does not do wallet ownership resolution (at Wallet2RouteHandler.kt, roughly lines 758-768). This means that, theoretically, the request could be changed after the /resolve-request step (things like nonce, verifier key, and response URI) -> the fetcher would then be sent to perform an arbitrary outbound POST, and for encrypted mdocs, changing keys between steps will also breaks transcript binding

[waltkb]

In addition, the changed code at WalletPresentFunctionality2.kt (lines ~639-650) should include a call to validateAuthorizationRequest, otherwise a signed request missing nonce reaches consent and later fails through nonce!! instead of being rejected as invalid_request

[philpotisk]

Regarding #1885 (comment): agreed and contained in 04beebf4a. We removed the /present/build-vp-token and /present/send-response routes together with their caller-controlled request/result models and WalletPresentationHandler methods. A remote caller can no longer resubmit or mutate an AuthorizationRequest, response URI, nonce, response mode, verifier key, or prebuilt VP token between those steps, and the arbitrary outbound POST path is gone. The retained preview/submit flow consumes the wallet-scoped authenticated ResolvedAuthorizationRequest captured during preview. A durable manual-flow follow-up is documented to use an opaque account/wallet-scoped transaction ID, immutable authenticated state, TTL, atomic one-time consumption, and persistent multi-instance storage before an equivalent step API is exposed again.

[philpotisk]

Regarding #1885 (comment): fixed in 04beebf4a. The isolated request-resolution path now delegates to WalletPresentFunctionality2.resolveAuthorizationRequest, whose common validation rejects a missing or blank nonce. The presentation path also runs PresentationRequestValidator.validate before credential selection and returns invalid_request through a safely bound response channel. resolvedAuthorizationRequestRejectsMissingNonceBeforeCredentialSelection verifies that a pre-resolved request without nonce never reaches consent or credential selection.

my earlier concerns were addressed

[szijpeter]

fixed a couple of things from the mobile side (test fixtures mostly) and updated the branch from main. I've also refreshed the related enterprise branch and opened a PR for it: https://github.com/walt-id/waltid-identity-enterprise/pull/553

looks good to me from the mobile perspective, but would leave the final word for @waltkb

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[JakeFernandes98]

Superseded by folding the WAL-896 identity stack into #2091, which now targets main.