Topic E - Pseudonyms, including User authentication mechanism

[phin10]

Welcome to the discussion on the Topic E - Pseudonyms, including User authentication mechanism, 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 Topic E - Pseudonyms, including User authentication mechanism paper.

There are two main requirements in [eIDAS 2.0] about Pseudonyms in relation to Wallet Units:

1. Wallet Units must be able to generate pseudonyms and store them encrypted.
2. Relying Parties must accept identification via pseudonyms when there are no legal requirements for identification.

In the referenced discussion paper we elaborate on the use cases inferred from the above legal requirements. The distinction between the two use cases follows from Article 14 2. [CIR.2014.2979]. Both use cases are described in an online non-proximity-based setting where the pseudonyms are presented towards services over the internet.

• Use case A - Pseudonymous Authentication: Pseudonyms can be used to authenticate a user when it is not necessary for a Relying Party to learn the identity of a user.
• Use case B - Presentation of Attributes with Subsequent Authentication using Pseudonyms: Similarly to the use case A, a user wishes to create an account with an associated pseudonym that can be used for subsequent authentication at later sessions. However, in this scenario the user would like to register verifiable attributes in the form of either Person Identification Data (PID), Qualified Electronic Attestation of Attributes (QEAAs), or Electronic Attestation of Attributes (EAAs) while registering.

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.

[timcappalli]

Some feedback on the WebAuthn-related text:

---

Across all sections

The short name for the Web Authentication API is "WebAuthn" (not "WebAuthN").

---

Section 4

The technology underlying [WebAuthN] is commonly refereed to as passkeys.

A passkey is a type of credential, not a general technology or protocol.

Alternate text: "Passkeys are a widely used type of credential which are created and asserted using the [WebAuthn] API."

---

Section 4.1

the service will send them a challenge consisting of a random number.

s/"random number"/"random value" (not always a number)

If the signature verifies as expected, the user is considered authenticated and thereby granted access to the service.

"If the signature verifies and the origin matches as expected..."

---

Section 4.2

[WebAuthN] defines an API for the creation and use of passkeys.

"WebAuthn defines an API for the creation and use of passkeys (among other WebAuthn credentials)."

Client: The client that the user uses to interact with the Relying Party's server.

"The client that the user uses to interact with the Relying Party's server and their authenticator."

The interface is referred to as the WebAuthnAPI.

Why is this collapsed together vs "WebAuthn API"?

However, [WebAuthN] does not specify how the Authenticator and the Client must communicate. We briefly discuss the relation to Topic F in Chapter 5.

This is specified in the FIDO Client to Authenticator Protocol, which is a sister specification to WebAuthn.

User ID: An identifier unique to each user that is assigned by the Relying Party. This will be provided to the Authenticator when registering a new passkey and subsequently provided by the Relying Party to indicate to the Authenticator which passkeys are requested. The Authenticator will keep track of which passkeys are available for which User IDs and Relying Party IDs. The Relying Party keeps track of a User Name for each User ID.

The user ID (aka user handle) is not provided by an RP during authentication ceremonies. It is provided in the assertion from the authenticator for the RP to link to a user account.

User Display Name: An alias that may be chosen by the user or the Relying Party and assigned to a specific passkey on the Authenticator. This allows the user to easily distinguish and select which passkey they want to authenticate with if several are present.

Display name is not used by most clients and is likely to be deprecated in a future version of the spec. user.name is required, and I assume that is what you're referring to. Recommend changing this to "User Name".

---

Section 4.2.2

The Client checks that the Relying Party ID is consistent with the caller's domain..

"...with the caller's origin..."

For this step the User Display Name can be presented to the user.

"... the User Name can be ..."

---

4.3

The information about the Relying Party is verified only by the Client and not by the Authenticator itself.

There is nothing stopping the authenticator from also validating the RP's origin.

[EricVerheul]

The context of Question 4.4 is a user presenting a wallet generated pseudonym together with (parts of) the Personal identification data (PID) and/or attestations. Question 4.4 asks whether:

1. the user pseudonym should be cryptographically bound to the user person identification data/ electronic attribute attestation (security) AND
2. the user pseudonym should not provide for information allowing any party to link them to the wallet/user (unlinkability).

I think that the answer to Question 4.4 should be a firm ‘Yes’ as I consider this combination of security and unlinkability fundamental for public trust in the wallet. However, Topic E does not provide a technique meeting both properties, i.e. security and unlinkability. However, the Self Generated Verifiable Pseudonyms (SGVP) from the Proof of Association paper (https://eprint.iacr.org/2024/1444) do meet both properties. I therefore suggest that the SGVP concept is included in Topic E as a possible solution.

My full reaction is in the attached PDF
Comments&Recommendations Topic E.pdf

Kind regards, Eric Verheul

[joelposti]

Thank you @EricVerheul for your comments! I read the Dutch non-paper regarding pseudonyms last summer. Reading that I wondered whether it was intended to be read as if there is a pseudonym provider or not. And if not, how does the relying party trust the pseudonym? Your comments reminded me of this question. In your comment you said:

b) wallets include a functionality to generate user-chosen and managed pseudonyms, to authenticate when accessing online services. That is, there is no central “pseudonym provider” as we do not want a party knowledgeable for which relying parties a user has pseudonyms let alone that a central party knows when the user authenticates with the pseudonym towards a relying party

Could you explain how the relying party can trust a pseudonym generated by the wallet? With a Proof of Association?

It is demonstrated that, unlike WebAuthN, SVGP can provide both security AND unlinkability. So, for instance, SGVP allows to cryptographically bind the SGVP pseudonym to the facial image of the mobile driving license and to the resident address in the PID, allowing to only present those three to a relying party and without any party being able to link this to the user.

Aren't user's facial image and resident address intrinsically linkable/correlatable data? Or is there something I do not understand about the presentation of the three pieces of data to the RP?

[EricVerheul]

Could you explain how the relying party can trust a pseudonym generated by the wallet?
With a Proof of Association?
The PID holds an ‘encrypted pseudonym secret’ (see Annex H of the PoA paper). Instead of the PID one could introduce a dedicated attestation holding the ‘encrypted pseudonym secret’; for simplicity (as in Annex H) I assume the PID holds this ‘encrypted pseudonym secret’. Typically, the ‘encrypted pseudonym secret’ is presented in isolation (selective disclosure).
Other attestations are provably bound to the PID and thus to the ‘encrypted pseudonym secret’ using the Proof-of-Association.
The wallet/user can a generate/derive a pseudonym, P, using the ‘pseudonym secret’ whereas the SGVP concept allows the wallet/user to prove that these pseudonyms are correctly formed using the ‘encrypted pseudonym secret’. So the pseudonym trust chain for relying party is P --> ‘encrypted pseudonym secret’ --> PID --> other attestations (PoA)

Aren't user's facial image and resident address intrinsically linkable/correlatable data?
Or is there something I do not understand about the presentation of the three pieces of data to the RP?
With unlinkability I mean (roughly formulated) that there is not more linkability than by the attributes presented introduce themselves; that is the best one can achieve. As the resident address more or less directly identifies the user, so perhaps it would have been better to resident municipality, i.e. the city one lives.

[joelposti]

Could you explain how the relying party can trust a pseudonym generated by the wallet? With a Proof of Association? The PID holds an ‘encrypted pseudonym secret’ (see Annex H of the PoA paper). Instead of the PID one could introduce a dedicated attestation holding the ‘encrypted pseudonym secret’; for simplicity (as in Annex H) I assume the PID holds this ‘encrypted pseudonym secret’. Typically, the ‘encrypted pseudonym secret’ is presented in isolation (selective disclosure). Other attestations are provably bound to the PID and thus to the ‘encrypted pseudonym secret’ using the Proof-of-Association. The wallet/user can a generate/derive a pseudonym, P, using the ‘pseudonym secret’ whereas the SGVP concept allows the wallet/user to prove that these pseudonyms are correctly formed using the ‘encrypted pseudonym secret’. So the pseudonym trust chain for relying party is P --> ‘encrypted pseudonym secret’ --> PID --> other attestations (PoA)

Does the presentation/disclosure of the ‘encrypted pseudonym secret’ from a PID come with the PID's metadata (issuer's seal, PID's public key, issuance and expiry timestamps, etc)? If so, the RP can deduce from the metadata all sorts of things such as likely nationality of the user. Of course, presenting a pseudonym attestation issued by a national pseudonym provider also reveals that. I am just trying to figure out what level of information disclosure is necessary to establish trust in the pseudonym.

Aren't user's facial image and resident address intrinsically linkable/correlatable data? Or is there something I do not understand about the presentation of the three pieces of data to the RP? With unlinkability I mean (roughly formulated) that there is not more linkability than by the attributes presented introduce themselves; that is the best one can achieve. As the resident address more or less directly identifies the user, so perhaps it would have been better to resident municipality, i.e. the city one lives.

Thank you for the explanation. I understand now.

[EricVerheul]

The ‘encrypted pseudonym secret’ is just an attribute technically comprising of two points on an elliptic curve. It can be placed in the PID like I did for simplicity, or in any (dedicated) attestation. When placed in the PID, you see the PID issuer and from there probably the nationality of the user. If that is something you want to avoid, you would need an attestation provider that issues ‘encrypted pseudonym secret’ attestation to any EU citizen and associated to his/her PID.

BTW The ‘encrypted pseudonym secret’ is randomizable which means that each PID/attestation holds a randomized ‘encrypted pseudonym secret’ that are not interlinkable although they contain the same secret. That is, the PID/attestation is not a linking factor of its own. The security of that mechanism is based on the hardness of the so-called Diffie-Hellman decission problem.

Maybe it all sounds complex, but it can be supported by all existing cryptographic hardware. We need to think on backup & recovery of the 'pseudonym secret' which effectively is a DH private key if we want pseudonym compatibility of all the wallets of the user.

[AEPDmbeltran]

On behalf of the Spanish Data Protection Authority (AEPD)

The attached document contains our comments on this topic.

topicE 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 E. Please find below the response of the @eu-digital-identity-wallet/arf-writers:

We thank you for the feedback. Below we address the (more) technical points of your response, as in our scope.

Based on your suggestions we have introduced a new requirement (Requirement 7a) stating that “A Wallet Unit SHOULD allow the User to manage pseudonyms within the EUDI Wallet in a user-friendly and transparent manner. Users SHOULD be informed about when and to whom their pseudonyms are used and be able to view a complete transaction log (including canceled or unsuccessful transactions).”

Further, we believe that some of your comments are addressed in the proposed HLRs:

• Requirement 4 states that users should be able to use multiple pseudonyms for a single RP.
• Requirement 14 states that “It SHALL NOT be possible to correlate Pseudonyms based on their values nor on other data sent by the Wallet Unit during registration and authentication, meaning that colluding Relying Parties SHALL NOT be able to conclude that different Pseudonyms belong to the same User.”

[jtalir]

Discussion paper mentions WebAuthn as the only solution for the problem. If I'm not wrong SOIPv2 https://openid.github.io/SIOPv2/openid-connect-self-issued-v2-wg-draft.html could serve well for the same purpose. Would it be possible to mention in this document which alternatives to WebAuthn were evaluated and why these alternatives were refused?

[OBIvision]

Critical problem - CTAPI2 is locking the pseudonym to persistent identity in the TEE

This entire section fail to address the core problem that the BigTech community has a built-in tracking backdoor in FIDO2 CTAPI2 which essentially reduce a roaming authenticator to a slave of the TEE which use persistent keys and thus enforce linkability.