Currently, the web-platform-tests for the Digital Credentials (DC) API are limited to testing various error conditions, such as malformed requests or multiple concurrent requests. This leaves significant gaps in our testing capabilities.

For example,, we are unable to test:

1. The end-to-end successful flow (the "happy path") of a user being issued and presenting a credential.
2. User interactions with the selector UI, such as aborting the operation while the dialog is active.

To address this, we need a testing mechanism that can simulate a complete wallet interaction.

I would like to propose two potential alternatives for discussion:

Alternative 1: Extend WebDriver with Virtual Wallets
We could follow a similar approach to the WebAuthn specification, which introduced the virtual_authenticator interface to WebDriver. This approach would involve creating a virtual wallet testing API.

The virtual wallet would be configurable through WebDriver to operate under a specific issuance and presentation protocol (e.g. openid4vp). It would need to fully support get() and create() methods, allowing tests to simulate the entire credential lifecycle.

Pros:

• Provides a powerful and reusable test API that web developers could also leverage for their own application testing.
• Aligns with existing testing patterns on the web platform. And hence we won't have to implement things from scratch

Cons:

• The implementation could be complex, particularly regarding the correct handling of cryptographic protocols required to encrypt and format responses.

Alternative 2: Introduce an Action-Based Testing Protocol
A lighter-weight alternative would be to introduce a simple, action-based protocol specifically for testing the API's interaction with the wallet selector UI. This could be similar to geolocation setting testing APIs.

This protocol would allow tests to issue commands to the wallet UI to simulate user behavior. Example commands could include:

• accept_next_request(credential_data): Instructs the wallet to accept the next API call and respond with the specified credential.
• reject_next_request(error_reason): Rejects the next API call.
• hold_next_request(): Keeps the UI open without responding, allowing for testing of timeout logic.
• abort_after(timeout): Simulates the user closing the UI after a specified duration.

Pros:

• Simpler to implement as it focuses on behavior rather than complex cryptographic protocols.
• Directly addresses the need to test UI interactions and different user choices.

Cons:

• May be less realistic than a full virtual wallet implementation.
• Might not be as useful for web developers' own testing needs.