Topic J - Wallet to Wallet interaction

[pinamiranda]

Welcome to the discussion on the Wallet to Wallet interaction, part of the ongoing development of the Architecture and Reference Framework (ARF) for the European Digital Identity (EUDI) Wallet.

This discussion is based on the document Topic J - Wallet to Wallet interaction.

Topic J is about retrieving high level requirements on how the Wallet will support wallet to wallet interactions.

CIR 2024/2982 provides the following guidance on Wallet to Wallet Interactions

Article 3 General Provisions

Regarding the protocols and interfaces referred to in Articles 4 and 5, wallet providers shall ensure that wallet units:...

(2) authenticate and validate the wallet unit attestations of other wallet units where interacting with other wallet units;...
(8) present wallet unit attestations of the wallet unit to wallet-relying parties or wallet units that request it;...

This discussion is part of a structured process to refine and complete the ARF, with your input playing a vital role. We invite you to share your comments, insights, and suggestions here. Your contributions will be carefully reviewed and considered as we work towards the next version of the ARF, which will incorporate updates on this topic.

Thank you for participating in this important conversation.

[sander]

Thank you for publishing the discussion paper and questions. In response to:

Question 3: The above use case describes a proximity-based setting. Are there any use cases for a remote presentation between user's of EUDI Wallets and if so: Should this be supported?

Yes.

A first use case that is especially relevant in the B2B and B2G context is providing evidence remotely. This is relevant for example to e-procurement and e-business reporting. Eventually it may additionally reach B2C and G2C contexts. Enabling the application of a EUDI Wallet makes such capabilities more accessible, which should be in line with the Digital Decade strategy.

For this first use case, eDelivery is the appropriate building block. The interface between the EUDIW and the eDelivery Access Point would work in a similar way as with remote QSCD management services. As with Digital Credentials API (DC API, Topic F), the eDelivery infrastructure transports OID4VC and ISO 18013-5 messages as payload.

A second use case to is consider (no surprise) qualified e-signing and e-sealing (QES). While eIDAS Art. 5a(5)(a)(vi) does not require Wallet-to-Wallet QES, it is important to be aware that several candidate protocols for Wallet-to-Wallet PID and QEAA presentation could also support QES, and to not preclude this option. In particular OID4VP and the DC API would easily support it with the current CSC standardization work.