Implications of CADA on the W3C DC API

[Sebastian-Elfors-IDnow]

I’ve researched the Cloud and AI Development Act (CADA) draft and its potential implications on the W3C DC API. At the moment, Apple and Google are using their own (US based) cloud-services as backend to their wallets with W3C DC API, but those are proprietary deployments. If an EUDIW Provider would implement the W3C DC API under CADA, the EUDIW Provider would need to host the DC API backend in an EU-based self-hosted cloud-service, since the EUDIW Provider will most likely fall under CADA Level 4. So potentially the DC API could result in additional complexity for the EUDIW Providers who will implement it.

[Saramandus]

Thank you @Sebastian-Elfors-IDnow

Since CADA and the specific hosting/sovereignty requirements under the EBW regulation are still draft proposals, we cannot introduce infrastructure hosting mandates as normative requirements in WBCS CS-07 (which focuses strictly on technical interface interoperability for the ITB).

However, this is highly valuable feedback. To ensure it is preserved for the future roadmap and our reports to the Commission, I would suggest flagged this as a strategic deployment risk in the Pilot Design (D3.1) Chapter 7 (@ardvanderheijden - do you have notes on this already?).

We could add an informative (non-normative) note in CS-07 Section 8 highlighting the cloud-hosting and CADA Level 4 sovereignty challenges for EUDIW Providers leveraging proprietary DC API backends, but with CS focusing on implementation I am not convinced that it is the right place.

Once we know this has been documented as feedback for future production environments, we could close this issue.

[ardvanderheijden]

D3.1 is already final and at the desk of the commission, so it is not possible to include it there. But it seems to me that we can see if we can include it in D3.2 (the report on the pilot infrastructure). There we will describe what we have built, and have not built for piloting (which include topics to address after the project).
We could flag this - as Sarah suggests - in the CS-07 item and mark it as 'possible item for D3.2'. When producing D3.2 we can then search in GitHub on 'D3.2' and find relevant items to process during production.
How does that sound?