Topic P - Secure Cryptographic Interface between the Wallet Instance and the WSCA

[phin10]

Description
The need for harmonization of this interface needs to be discussed. If the WSCA is delivered by the Wallet Provider, the situation is different than when the WSCA is delivered by the WSCD provider.

Planned publication discussion paper
3 September 2025

Link to discussion paper
Link

Discussion close
Three weeks later.

[OBIvision]

CTAP2 is an example of how the ARF Wallet is failing. It does not support the by far most important aspect of QUALIFIED UNLINKABLE Signatures but feed control to BigTech side-channels intra-phone through lock-in to the smartphone Tee which again feed linkability to the backend FIDO2 servers.

[sander]

Re: Question 2. For interacting with remote HSMs, also consider:

• CSC API v2, if the WSCA only needs to provide digital signatures and no shared secrets;
• User Authentication API v0, designed for easy use in EUDIW over the interfaces in the reference code.

Both are based on OAuth v2, which enables abstraction over authentication and approval mechanisms.

The ARF should provide reference controls and application profiles for such standards, to facilitate cross-border agreement on proper WSCA/WSCD application for LoA High authentication.

[OBIvision]

This discussion is omitting some key elements.

1. The binding of a secure element to the actual body with biometrics is essential as the secure element can otherwise be managed by another person than the keys are issues to. One obvious solution to this problem is a QSCD with on-card biometrics.

2. The ability to conform use of a secure private key in a cryptographic element should be closely tied with the user interface in order to avoid man-in-the-middle. One obvious solution to this problem is a QSCD with on-card UI, i.e. both display and confirmation linked to the on-card biometric fingerprint.

Without these, you would not be able to claim high assurance. Neither of the two above can be sufficiently provided by a smartphone TEE.

In order to adhere to article 5a.16, the creation and use of new contextual keys should occur in such a way that no entity end-to-end can collect material to link said key to said device. Here smartphones have a real problem as they are loaded with provider-controlled side-channel attacks designed to track users and feed such data to server databases.
.

[OBIvision]

A critical issue in this connection is the addition of Unlinkable PKI where the remote HSM act as a local witness certifying new unlinkable asymmetric keys on behalf of the CA.

With this many of the zero-knowledge properties can be achieved within simple atomic credentials, i.e. pure standard PKI already standardized. Described e.g. here
https://www.edps.europa.eu/system/files/2022-07/03_-_stephan_engberg_-_edps_trustworthy_pki_engberg_20220622_en_0.pdf

[AEPDmbeltran]

On behalf of the Spanish Data Protection Authority (AEPD)

The attached document contains our comments on this topic.

topicP AEPD response.pdf

Thank you very much for this opportunity to contribute to this important discussion.