Skip to content

feat(flows): use EUDI DCQL package#527

Open
Wicpar wants to merge 19 commits intoanimo:mainfrom
APTITUDE-Consortium:feat/overlay-eudi-dcql-package
Open

feat(flows): use EUDI DCQL package#527
Wicpar wants to merge 19 commits intoanimo:mainfrom
APTITUDE-Consortium:feat/overlay-eudi-dcql-package

Conversation

@Wicpar
Copy link
Copy Markdown
Contributor

@Wicpar Wicpar commented Apr 30, 2026

Based on

#521
#523
#524
#525
#526

What changed

This PR replaces the remaining wallet-side DCQL resolution path with the EUDI wallet TS12 DCQL package after the matcher and overlay screen work.

It adds a single SDK path that resolves DCQL into independent credential sets and slots, formats those slots for the shared presentation UI, and uses the selected slot credentials to create the OpenID4VP response. The previous Credo DCQL handling is no longer used for these flows.

It centralizes transaction-data behavior behind a registry. The app gets transaction-data display widgets from the registry, unsupported transaction-data types become blocking slot errors, and transaction-data response creation goes through the same registry instead of screen-local special cases.

Normal OpenID4VP flow

The normal VP review page now renders EUDI DCQL credential sets as independent groups with independent slots. Each slot can show the selected credential, open the credential selector, display a transaction-data widget for the selected credential, or show a blocking error when the slot cannot be satisfied.

Optional slots and optional credential sets can be left empty. Required unsatisfied credentials block confirmation, while transaction-data-specific failures are shown as transaction-data errors instead of generic missing-credential errors.

DC-API flow

The DC-API presentation path now consumes the same formatted submission model and selected-credential result as the normal VP flow. It no longer needs a separate transaction-data display path for credential slots.

The DC-API flow distinguishes transaction data already displayed by the Digital Credentials API from transaction data that was not displayed. If transaction data was not displayed by DC-API, the wallet adds an explicit consent step before responding. If the transaction-data type is unsupported or cannot be rendered, the flow shows an error instead of silently returning an invalid response.

Error and transaction-data UI

Transaction-data display is now handled by TransactionDataRegistry, which currently supports the Funke QES authorization transaction-data widget. The same widget can be used from normal VP review and DC-API consent screens.

Unsupported transaction-data errors now have a structured UI: user-facing title and description, transaction type, required credential, and credential query id. Development mode adds a separate debug details box with the DCQL/query/payload data, so debug output no longer pollutes the main error message.

The error model now distinguishes missing/unsatisfied credentials from credentials filtered out because they cannot satisfy linked transaction data. Unknown transaction-data types are reported as transaction-data errors tied to the affected slot.

User impact

OpenID4VP and DC-API presentation flows now use the same EUDI DCQL slot model that the one-page overlay UI displays. Credential selection, optional slots, transaction-data display, transaction-data consent, and blocking errors are centralized so behavior does not drift between in-app VP and DC-API VP flows.

Notes

The EUDI wallet functionality packages are still referenced from local tarballs in dep_packages; these should be published and switched to normal package versions before final merge.

Validation

  • pnpm types:check
  • pnpm style:check
  • git diff --check
  • Pixel dev app reload reached the wallet PIN screen after the latest changes

@socket-security
Copy link
Copy Markdown

@Wicpar Wicpar marked this pull request as ready for review April 30, 2026 18:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant