Pillar 2: Privacy - Wording sometimes very strong

[tlodderstedt]

In section "Privacy of Wallet Transactions" there are several instances of a "must" requirement that (in my opinion) cannot always be fulfilled.
Examples:
"i. Code providers and contributors and/or cloud operators of digital wallets must not be able to observe or track transactions undertaken by holders."
While I generally agree with the direction, absolute unobservability cannot be achieved with todays technology if, for security reasons, backend components need to be involved in a transaction. I suggest to either change the "must" to a "strongly recommended" or "must" plus exceptions. It might also be advisable to differentiate between the different data a wallet provider might "see". For example, wallet attestation requires interaction with a secure backend but does not require access to PII.

"iii. Wallet code providers and cloud operators must not be able to access the contents of digital wallet transactions log files or backups." - whether this is feasible first of all depends on the wallet architecture. Log files could be stored on the user's phone in case of a mobile app, but not in case of a web wallet. I would also encourage to shed some more light on how backup could be implemented, e.g. that a backup could be made to a place not controlled by the wallet provider (even though that might be more convenient).

[tlodderstedt]

Same in "5. Digital Wallet ecosystem providers or organizations that provide the infrastructure to which digital wallets connect to issue or verify credentials (typically called credential exchange platforms) must not be able to examine the contents, source or destination of wallet transactions."
Can you please some light on how this can be implemented? I can imagine such a platform not to read the content throught application level encryption but I'm having a hard time imagining the platform at the same time does not see the where from or to.

Wouldn't it be a more appropriate advise to recommend implementers to NOT use such platforms at all?

[andy-tobin]

Both good comments, thanks Torsten.

We did change a whole set of "must"s to be less strong, like "should" or "is not recommended". Looks like we missed some so will need to check again. Well spotted.

On the second comment about platform providers - if every issuer or relying party was going to implement their own credex platform then things would be easier. However this isn't really feasible (very expensive, time consuming) therefore one can imagine the majority of issuers/verifiers will use a platform provided by a vendor. This is also permitted in the eIDAS regulation in the shape of intermediaries or proxies.

You make a good point on such platforms not being able to examine the contents, source or destination. Such examination may be required for routing purposes, or to translate from sophisticated cryptography and execute signature checking, and provide the platform user with a simpler array of verified data down an easy API.

I think this needs to be reworded such that it says that platform providers who have to examine transactions contents for protocol translation for example, and who are able to see sources and destinations of data, must not use this information for profiling or correlation purposes. @tkuhrt could you make such a change please?

[tlodderstedt]

However this isn't really feasible (very expensive, time consuming) therefore one can imagine the majority of issuers/verifiers will use a platform provided by a vendor. This is also permitted in the eIDAS regulation in the shape of intermediaries or proxies.

The fact it is permitted does not mean we need to recommend it. I think it is important to make integration of a wallet into a verifier as easy as possible. In order to achieve this, we need simple interfaces and simple to use software (that's what OWF was started for, right?). Otherwise, the advantages of decentralized identity, especially unobservability, cannot be leveraged to the average user.