Topic C: Wallet Unit Attestation (WUA) and Key Attestation

[phin10]

Welcome to the discussion on the Digital Credentials API, 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 C - Wallet Unit Attestation (WUA) and Key Attestation.

The goal is to define high-level requirements for WUA as defined in the IAs of article 5a, and for the key attestation. The legal requirements in Chapter 2 of the document addresses different aspects related to Wallet Unit Attestation. The aspects cover interaction with the user (i.e. requirements in relation to the user interface), interaction with other parties (i.e. what WUA should be used for) and the WUA itself (i.e. essential information that should be contained in the WUA). This document will not go into requirements on the user interface, etc., but will focus on how WUA may be used in connection with other parties.

Furthermore, the document is ONLY intended to clarify the high level requirements related to WUA. The technical specifications related to WUA is to be developed by the Commission at a later point in time.

The legal requirements in relation to the functional requirements of WUA can be summarized as the following functionality:

1. WUA information must allow relying parties, PID and attestation providers and other Wallet Units to validate the authenticity and revocation status of a Wallet Unit.
2. Wallet Providers must be able to revoke a Wallet Unit.
3. Only the Wallet Providers of a Wallet Unit must be able to revoke that Wallet Unit.
4. It is the Wallets Providers responsibility to create the WUA.
5. PID issuers must be able to ensure their data is cryptographically bound to the wallet unit during issuance.

Based on the functional requirement, the following requirements with regard to the WUA itself can derived:

1. The WUA must contain a public key, where the corresponding private key is protected by a WSCD.
2. The WUA must contain information, allowing parties to check if a Wallet Unit has been revoked.
3. The WUA must contain information, allowing parties to verify the validity of the Wallet Unit, i.e. the WUA must contain a signature from the Wallet Provider.

All of this can be achieved as a (revocable) attestation on a public key, issues by the Wallet Provider. Additionally the WUA should contain relevant information on the Wallet Unit capabilities, such as the WSCD/WSCA. These must also be attested by the Wallet Provider and may be used to provide additional trust in the Wallet Unit.

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.

[EricVerheul]

Topic C formulates requirements for the Wallet Unit Attestation (WUA) based on the eIDAS regulation and three November 24 2024 eIDAS implementation regulations and is asking public feedback on three questions. In this comment I only give my answers to the first two questions which I think are fundamental for wallet security.

Topic C starts with a summary of the WUA requirements based on the legal texts and from this interprets what this means from a cybersecurity perspective. I think this is confusing and not working for me, also as it seems to assume that the legal people that wrote the texts are cybersecurity experts having done a thorough cybersecurity risk assessment.

In my view one should start the WUA discussion from a cybersecurity/privacy standpoint avoiding technical details as much as possible and from thereon compare the legal texts on what is missing. Then fix/amend that in the wallet Architecture Reference Framework (ARF) in a way the legal people can use it in upcoming eIDAS implementation regulations. I think the WUA cybersecurity discussion boils down to three questions which are not yet fully satisfactorily answered in Topic C. These questions are:
A. What is the WUA?
B. What wallet security functionality should the WUA facilitate?
C. How do we guarantee that the WUA is not a supercookie?

My full reaction to Topic C and my answers to A-C can be read in Comments&RecommendationsTopicC.pdf. Here I also refer to the paper specifying Proof-of-Association (PoA) techniques I posted earlier.

Topic C Question 1: Are there any missing requirements?
Answer: Yes. Apart that the present requirements in Topic C could be made more precise, Topic C is lacking requirements on the security functionality the WUA should provide:

• ­ related to the issuance of attestations; only WUA security functionality related to PID issuance is formulated which I think is not enough
• related to the privacy friendly presentation of (selectively disclosed parts of) PID and attestations, also in their reliable combination, cf. eIDAS regulation Clauses 5(a) and 4(a) of Article 5a.

Topic C Question 2: Do we prevent PID and Attestation providers from achieving "cryptographically bound" (such as by proof of association), by limiting the WUA to contain only a signed public key and a set of supported capabilities/operations?
Answer: No, when the set of supported capabilities/operations include rudimentary key-attestation and a proof-of-association technique described in the PoA paper. Note that in Question 2 the fundamental role of achieving "cryptographically bound" for relying parties is also lacking. This is more than assurance that attestation private keys are hardware bound, but should also include that they are bound to the same hardware as the WUA private key is and under the same user control. See my detailed comments in Comments&RecommendationsTopicC.pdf

[AEPDmbeltran]

On behalf of the Spanish Data Protection Authority (AEPD)

The attached document contains our comments on this topic.

topicC AEPD response.pdf

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

[phin10]

@AEPDmbeltran, thank you for your input to the discussion on topic C. Please find below the response of the @eu-digital-identity-wallet/arf-writers:

We note that the comments were written before the final version of the discussion paper was published. Several of the comments have been debated and addressed since then. In particular, the different needs and requirements related to the WUA functionality related to Relying Parties and PID Providers and Attestation Providers have received much attention and should now be clearer.

As you point out, revocation, and the use of WUA in general, may create privacy risks. In that regard, WUA may be treated as a “regular” attestation and utilize the requirements, techniques and discussions put forth in Topic A on privacy. Please note that the HLRs established in Topic A are phrased such they explicitly also apply for the WUA functionality. This includes batch issuance of single-use WUAs as a privacy mechanism.

The technical details of the WUA functionality are intentionally left out of the discussion paper but will be further detailed in a forthcoming technical specification.

Regarding the concern on automatic presentation of the WUA, without interaction with the user, we have created HLR WUA_24e: “The WUA SHALL only be presented as part of either the issuance or presentation of PID or Attestations.”. The purpose of this requirement is to ensure that the user gives an implicit consent to present WUA as part of another interaction, e.g. the user must consent to presenting PID to a Relying Party, before the WUA is presented along with the PID.

[AEPDmbeltran]

@phin10 , thank you for your response. We have reviewed the latest version of the discussion paper and have seen that some of our concerns/doubts have been addressed, while others haven't. We look forward to future technical specification to continue the discussion. Thanks again.

[ad-Orange]

• We think that if the proper protocol is used (typically a ZKP based / Topic G related protocol) for all presentations, then the strategy of using the WUA as “any other attestation” would actually be a good thing as any use of it in presentation would not break any privacy but would only disclose what is strictly necessary for the intended use. In this case the protocol must not only support selective disclosure but also minimization techniques like range proofs and set membership proofs

• The discussion about short or long validity terms is linked to 2 different features
  o The ability to do privacy preserving non revocation proofs -> this can (and shall) be solved with accumulators
  o There is structurally no solution to implement fully secure full offline transaction -> From our understanding, full offline transactions could not be high or could be forced to a short validity period (as short has the biggest impact of an offline transaction – e.g. opening a door or accessing a ward – could be). To us, the second option does not make any sense and it shall be accepted that full offline transactions cannot be high and for substantial transactions, RPs shall decide whether they allow them or not. We believe that this statement shall be clear in the ARF.

• We agree that using WUA with the envisioned properties with the envisioned protocols could only lead to a major data protection meltdown. However (and unfortunately) single use WUA would not solve it from a privacy point of view (issuer – verifier linking -> the wallet provider could know all user transaction -> no “unlinkability by design”) and batch issuance will not change anything to that

• Furthermore, the description in chapter 3.1 explaining that “the PID providers must keep track of all Wallet Units (i.e. the WUAs) to which PID has been issued and periodically (e.g. daily) monitor this list to check if a WUA has been revoked” is detrimental from a security and privacy point of view:
  o Security: This asynchronous process places a structural minimum limit on the target revocation time of 1 day, which could be unacceptable (and shall be deemed unacceptable according to us).
  o Privacy: this forces wallet and PID providers to bidirectionally coordinate their knowledge of users through a common identifier, which is bad. Wallet providers have no business keeping track of what PID issuers are doing with the wallet instances they have issued.

• We agree with the AEPD that "The Wallet Unit must handle the presentation of the WUA automatically, without the involvement of the User" violates basic security and data protection principles, particularly the transparency principle.

There are alternative processes that can be implemented TODAY today and that are much more data protection respecting and secure.

• For a revocation that is both secure (synchronous), efficient (only one WSCD side calculation is necessary) and privacy preserving, accumulators can be used in combination with BBS#
  o Synchronous: as soon as the issuer has updated their revocation accumulator, all transaction must take it into account
  o Efficient: the WUA does never need to be sent for a presentation. Furthermore, even if it needed to be sent, with BBS#, whatever the number of VCs to be combined / use as part of a transaction, only one WSCD call / calculation is necessary.
  o Privacy preserving: accumulators don’t leak anything except the timing of the witness update with the issuer IFif this is the used method and IF if this method is performed synchronously
• Leveraging this method, we would advise the following efficient and privacy preserving trust model to be implemented:
  o The following data model is used:
• The WUA serial number is included in the PID VC and the PID issuer knows this serial number and the identity of the wallet provider
• The WUA serial number (and optionally, depending the business needs, the PID serial number also) is included in each of the user’s VC but it is blindly signed so that the issuer does not know it

o For each and every transaction, the WUA serial number (part of each VC) is obfuscated (through a committment for those cryptography inclined) and:

• An accumulator based ZKP is performed by the wallet that the WUA serial number has not been revoked. The user cannot lie because this serial number has been signed by the issuer as part of the VC. If the issuance process of the issuer is trusted, then the WUA does not need to be send for each transaction.
• Any other needed non revocation proof can be performed

o For the revocation process:

• If the user revokes through its wallet provider, the corresponding WUA serial number is revoked and this immediately takes effect for all VCs of the wallet which all suddenly become unusable.

• If the user revokes through its PID provider, the PID provider revokes the PID VC and informs the wallet provider that the corresponding WUA serial number shall also be revoked. This immediately makes all wallet VCs and VCs depending on this PID unusable.

• This same process can be used for non-revocation checks of the WSCD which would be particularly useful in case of HSM use: in a single accumulator update, all VCs depending on a particular HSM would instantly be made unusable.

All these principles can be implemented with the BBS# proposal we have made and are illustrated in the following github flows proposed for presentation.

Finally, we think that the WUA MUST be managed through a ZPK enabled scheme (cf topic G), otherwise the transactions that absolutely required full privacy / unlinkability will be at least linkable by the issuer, which is not acceptable. And contrary to this sentence “To mitigate the privacy risk of the long validity period of the WUA, the WUA should be a once-only attestation as specified in [Topic A].“, this will not mitigate anything in this case.

Generally, the topic remains very confusing and we do not see at this stage a clear setup taking into account at the same type time the security, privacy and scaling issues:

• Should the expiration time of the WUA be long or short ?
• Should the WUA be reissued for each transaction or not ?
• How will the proof of binding between WUAs and attestation be done ?
• How will the current WUA setup manage unlinkability requirements ?
• Should the PID providers monitor what’s going on in the revocation lists of wallet issuers or should the WUA be sent each time and thus the attestations become invalid as soon as the WUA is revoked ?

As long as these questions are not answered very precisely, we will remain unconvinced that an industrially deployable solution is on the way and will remain on the contrary convinced that deploying a first version of the ARF without ZKP is bound to failure and just delaying the inevitable and obvious.

[david-bakker]

There is structurally no solution to implement fully secure full offline transaction -> From our understanding, full offline transactions could not be high or could be forced to a short validity period (as short has the biggest impact of an offline transaction – e.g. opening a door or accessing a ward – could be). To us, the second option does not make any sense and it shall be accepted that full offline transactions cannot be high and for substantial transactions, RPs shall decide whether they allow them or not. We believe that this statement shall be clear in the ARF.

Hi @ad-Orange, sorry to pick only one sentence out of your long post, but most of the other things are actively being discussed already and I like to understand this objection better. On the face of it, it seems strange to me to say that offline (i.e., proximity) transactions cannot be on LoA High or that attestations used offline must have a short validity period for them to be LoA High. That is because the CIR 2015/1502, which specifies the LoAs, was written in the context of very long-lived, offline electronic identification means such as electronic passports and identity cards. Yet, of course, it allows LoA High to be reached for such identification means.

Also, in the context of the ARF, if a proximity transaction flow is used, this only means that the Wallet Unit and the Relying Party are not communicating over the internet. It does not mean that the RP must be fully offline. Moreover, even if the RP is offline at the moment of the transaction, it may be online often enough to allow it to retrieve a fresh attestation status list or identifier list every 24 hours (or more often). For those reasons, I don't believe that it's impossible for proximity transactions to be LoA High. But please continue the discussion if you disagree.,

[ad-Orange]

Hello @david-bakker,

To cut a long story short: what we meant here is FULL offline. Meaning neither the holder nor the relying party is online. In any sort of way. In this situation there is no physical way to get a hold on the revocation status. Given how sometimes the management of fugitives or criminal wire transfers can be a matter of minutes (or even seconds) rather than hours, it does not seem to us that it makes any sense for revocation not to be managed in a synchronous (or almost synchronous) way and 24h seems way too long, especially for what is deemed « level high ».
That being said, we certainly don’t confuse offline and proximity and we don’t see any good reason why a proximity transaction could not be high if at least one of the parties of the transactions (ideally the relying party) is online. And there exists lots of different ways (existing or to be defined) to get the revocation status as long as at least one of the 2 parties is online.

Does it clarify things or do you still disagree with at least part of the reasoning ?

[david-bakker]

Hi @ad-Orange, yes, that clarifies, thanks. I agree with you. The reason I asked is that often 'offline' is used as a kind of shorthand for 'in proximity'. Also, 'full offline transactions' are not recognized as a category in the ARF and therefore do not seem to be very relevant to me. But that's probably my particular way of looking at the world :-).