Topic E - Pseudonyms, including User authentication mechanism #375
Replies: 7 comments 14 replies
-
|
Some feedback on the WebAuthn-related text:
The short name for the Web Authentication API is "WebAuthn" (not "WebAuthN").
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."
s/"random number"/"random value" (not always a number)
"If the signature verifies and the origin matches as expected..."
"WebAuthn defines an API for the creation and use of passkeys (among other WebAuthn credentials)."
"The client that the user uses to interact with the Relying Party's server and their authenticator."
Why is this collapsed together vs "WebAuthn API"?
This is specified in the FIDO Client to Authenticator Protocol, which is a sister specification to WebAuthn.
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.
Display name is not used by most clients and is likely to be deprecated in a future version of the spec.
"...with the caller's origin..."
"... the User Name can be ..."
There is nothing stopping the authenticator from also validating the RP's origin. |
Beta Was this translation helpful? Give feedback.
-
|
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:
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 Kind regards, Eric Verheul |
Beta Was this translation helpful? Give feedback.
-
|
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:
Could you explain how the relying party can trust a pseudonym generated by the wallet? With a Proof of Association?
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? |
Beta Was this translation helpful? Give feedback.
-
|
Could you explain how the relying party can trust a pseudonym generated by the wallet? Aren't user's facial image and resident address intrinsically linkable/correlatable data? |
Beta Was this translation helpful? Give feedback.
-
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.
Thank you for the explanation. I understand now. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
On behalf of the Spanish Data Protection Authority (AEPD) The attached document contains our comments on this topic. Thank you very much for this opportunity to contribute to this important discussion. |
Beta Was this translation helpful? Give feedback.
-
|
@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:
|
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Pseudonyms in eIDAS 2.0 and the ARF: A (lengthy) CritiqueHigh level summary: The proposal to use WebAuthn and Passkey credentials as pseudonyms is highly questionable. Treating a pseudonym as an authentication mechanism rather than an attribute transmitted during authentication needlessly increases complexity and is a flawed design choice. This critique considers both Regulation 910/2014 and Regulation 2021/1183 as well as CIR 2024/2979 (for a full analysis of the requirements as detailed in the legal text see here). It argues that several key questions remain unresolved, including the definition of a pseudonym itself:
Currently, both the legal text and the ARF can be interpreted to support treating pseudonyms either as attributes or as authentication mechanisms, which prevents clear answers to these questions. This text argues that pseudonyms should be treated as an attribute transmitted during authentication. Critical examinationThis section presents a critique of how pseudonyms are treated in CIR 2024/2979 and ARF Discussion Topic E, with particular attention to the proposal to use passkeys. CIR 2024/2979 Annex VCIR 2024/2979 Annex V designates WebAuthn Level 2 as the technical specification for pseudonym generation. This is a curious choice. WebAuthn defines four distinct values that play a role during user identification.
Importantly, This maps poorly to the legal texts as highlighted in the table below on how the legal texts treat pseudonyms:
Aligning this with WebAuthn is challenging:
WebAuthn is technically appealing for implementing device-managed, pairwise identifiers. However, it is poorly aligned with the concept of user-chosen and user-managed pseudonyms, as mandated by the legal framework. A more suitable approach is to replace name attributes in the (Q)EAA or PID with a clearly designated pseudonym attribute. This aligns with the flexibility provided in Annexes I, IV, and VII and directly supports user control and clarity in pseudonym representation. It also accommodates both pseudonyms that can be mapped to real identities under specific conditions (e.g., fraud, dispute resolution, AML compliance) and fully unobservable pseudonyms, where the PID or (Q)EAA provider cannot trace or link the pseudonym to an identity. ARF discussion topic EDiscussion Topic E aims to provide high-level details and clarify use cases where pseudonyms should be used. While the text accurately references applicable sections of the legal framework, it fails to address the significant misalignment introduced by CIR 2024/2979. Rather than critically examining this gap or proposing viable alternatives, Section 3 describes two use cases that both highlight and deepen the disconnect between the legal intent and technical implementation. Use case 1: Pseudonymous authenticationThe first use case, pseudonymous authentication, is described as:
This assumes that pseudonyms are user-chosen and that the RP does not need to identify the user. There are two main issues with this use case: Firstly, in WebAuthn, the user cannot select their pseudonym. The identifier is RP-assigned and not under user control, which directly conflicts with this model. Secondly, it is an unsuitable use case for the EUDIW, whose main benefit is that the relying party can be assured that the pseudonym is backed by a real person. Use case 2: Pseudonyms with additional attributesIn the second use case, pseudonyms are supplemented with person identification data:
This combination risks undermining the privacy benefit of pseudonyms. If the relying party receives identifying attributes alongside a pseudonym, it defeats the purpose of pseudonymity. Moreover, the user still has no meaningful control over the pseudonym. Perhaps the bigger issue is why a WebAuthn credential should be used jointly with a PID or (Q)EAA at all. If the pseudonym must be a public key, the user can rely on pairwise PoP keys for the verifier and use this key for authentication. If instead the pseudonym is treated as an attribute transmitted during authentication, the PID or (Q)EAA can simply include this attribute.
As described, this use case appears more relevant to WebAuthn flows where the verifier wants to identify the user during the user's first registration where the user registers for their account and their first passkey at the same time. Or where a user wants to add attested attributes (e.g., I am above 18) to an already registered account. Its benefit for the EUDIW remains unclear. PasskeysSection 4 introduces the use of passkeys for user authentication. This approach conflates several concepts and introduces significant design issues:
Proposing passkeys as the pseudonym mechnism also raises the question of what exactly the pseudonym is. Section 4.2.2. suggests using the public key as the pseudonym (or using a CA to link a pseudonym to a derived public key). This introduces several problems:
Large parts of the document lack critical self-review and offer limited analytical value, and will therefore be omitted from this critique. While the authors propose using extensions that may address some of the core issues outlined above (e.g., using However, the requirements listed in Section 6. are of particular interest. Several are problematic (many others are bothersome but not listed, e.g., R8-R10, R16):
Overall, proposing to use WebAuthn and passkey credentials to fulfill the legal requirement for pseudonyms represents a serious lapse in judgement. It is critical not to conflate authenticating with a pseudonym (thus strongly binding it to the authentication mechanism) with passing a pseudonym during authentication as an attribute. The discussion in this discussion thread suggests limited engagement with the above outlined concerns. Either my analysis is flawed, or the community has largely viewed pseudonyms through the lens of WebAuthn and CIR 2024/2979, rather than reevaluating whether this direction makes sense in light of the legal and functional requirements. Different interpretations of pseudonyms and final remarksThere exist fundamentally different interpretations and intended uses of pseudonyms, which are in conflict with each other. These tensions have not been surfaced and addressed. A pseudonym used as a user-chosen replacement for an attribute (e.g., a legal name) is conceptually and functionally different from a pairwise pseudonym used for credential management across multiple user-controlled devices (e.g., a passkey). Both are distinct again from derived identifiers in anonymous systems like Bitcoin, where pseudonyms based on public keys are viable and where transaction authorization cannot rely on known identities or attribute attestations. Treating these models as interchangeable leads to architectural confusion and misalignment with legal, usability, and privacy requirements. Arguably, the most appropriate interpretation of pseudonyms in the context of EUDIW is as a disclosable unique attribute value (passed during authentication) which replaces another attribute (e.g., name). This model aligns with Annexes I, IV, and VII, and requires no reliance on WebAuthn, passkeys, or other device-bound cryptographic mechanisms. All that is needed is a standard (Q)EAA / PID issuance and presentation. Pseudonyms as attribute values also enable re-identification when required (e.g., fraud or AML), and can be made entirely privacy preserving if necessary. With the above in mind, I suggest:
|
Beta Was this translation helpful? Give feedback.
-
|
An additional point: it is important to clarify both the definition and intended use of pseudonyms. It is unlikely that a single solution will fit every service. Consequently, it is not wise to have hard constraints like strong binding to PID or preventing mapping back to identity. For instance, in many cases, pseudonyms, issuer-signed attribute claims (e.g., PID or (Q)EAA), and passkeys should not be conflated. A more natural flow would be:
Whereas in other scenarios, it may be necessary to strongly bind the pseudonym to the user’s PID or (Q)EAA. Similarly, whether a party should be able to map a pseudonym back to the user is context-dependent. Each service provider must likely determine whether they require this capability. Making these or similar requirements mandatory will limit the use of pseudonyms to domains where that specific interpretation applies, preventing users from using pseudonyms in other contexts that do not share those constraints. In sum, the concept of pseudonyms likely requires an entirely different approach than the narrow focused, requirements oriented, and totally misguided passkey-based approach that has been presented in Topic E. |
Beta Was this translation helpful? Give feedback.
-
|
There are the "uniqueness" pseudoynms that first appeared in Bryan Ford's proof-of-personhood parties papers. In brief, the users has some secret VRF key sk not known by anyone else, not even an issuing authority, and changing sk incurs some delay for certifying their new pk, so then the user identifies themself in a particular context c by producing an anonymized VRF signature ((c,id),aux,sigma). This anonymized VRF signature proves that id = VRF.Eval(c,sk) and that pk is authorized, aka a person, citizen, etc. and acts like a signature on aux. Among other things the VRF ensures that if id1 = id2 for two then both c1=c2 and sk1=sk2, aka id is an anonymous identity in the constext c. As always, an identity system should never under any circumstances prove the user's identity without having first verified the verfiier. I therefore suggest that c take the form vpk++.. and that vpk provide a certificate for the web_head_pk that actually makes the identity request. As an example, vpk could be the site's internal root public TLS key certified by some CA, with which the site certifies its web heads. The cool part here is: If vpk changes, then id changes. Also the user agent checked a certificate for the requester that was signed by vpk . This means the user cannot provide an id they use elsewhere for a different vpk. This is in stark contract to a credential that provides real PII, as those must always verify some certificate chain rooted at the governmental DPA for the user. A user changing sk would be too heavy a way to handle the right to be forgotten. I therefore suggest proving two identities id[old] and id[current] for the same user where c[j] takes the form vpk[j]++year[j]++week[j] for j in {old,current}. The site first proves its own identity and then asks for a pseudonym, with which it looks up the values (vpk[old],year[old],week[old]) as well as the user's last login ((c[old],id[old]),aux[old],sigma[old]). After verifying their last login, the user agent provides ((c[old],id[old]),(c[current],id[current]),aux[current],sigma) which links id[old] to id[current]. If the user wishes a new identity, then they first sign the right to be forgotten request to delete their old pseudonym, and then they wait a week and start using a new pseudonym, so the new account is unlinkable to the old account, even if the site retains their old data. Aside from Bryan Ford's paper, we have https://eprint.iacr.org/2023/002 which provides extremely efficent constructions, and a UC model. |
Beta Was this translation helpful? Give feedback.
-
|
IMHO opinion a number of confusing problems are introduced here. First of all, the assumption that a Pseudonym should be per website as it inherently assume that larger more complex services should be able to link multiple transactions with the same user. This defeats the unlinkability requirement per se. A number of similar problems arise here - it makes no sense to talk about a "pseudonym" when e.g. FIDO2 link pseudonyms through CTAP2 and feed this link to the backend servers. It makes no sense to talk about a pseudonym where there is no protection against linking in the network layers. Second, the assumption that the pseudonym is somehow detached from eIDAS is problematic for two reasons. I get it that some consider unstructured anonymity a desirable trait, but that is not the objective of eIDAS. eIDAS deals with qualified unlinkability, i.e. data you can rely on. A key problem here is that there are no assurances that the authenticator is controlled by the same individual that the credentials are issues to. I can use your credentials or rent mine to you, Third and most importantly. If there are conditional means to identity post-transaction that do not break unlinkability without said conditions are meet, there are zero need for linkability in the transaction. In other words conditional identification is a pareto better security model than up front linkable identification and fully resolve the somewhat ambiguous aspect of art 5a.16 "where the attestation of attributes does not require the identification of the user.". If the transaction require some kind of linkable identification, this can be resolved with credentials instead of weakening security in the underlying structure. As big part of the above is related to the assumption of weak QSCD-devices acting according to BigTech FIDO2 defaults and credentials managed unrelated from the QSCD-device. As to user-chosen pseudonym. I would say this is fully resolved with a system-generated random identifier and default "name" generated from this identifier that the user can override if approved by the service provider. In summation - IMHO "pseudonyms" or QSCD-based Qualified Unlinkable identity represent the future of eDAS 2.0 - not the present focus on weak smartphone-based structures with poor cross-issuer integrity. The best way to save the zk-framework is to make pseudonyms PID documents and zk-credentials issued contextually, i.e. ensure unlinkable data re reusable. |
Beta Was this translation helpful? Give feedback.
-
Yes, ideally authenticator credentials should be issued only by some auditing agencies. National DPAs could certify these auditing agencies. National DPAs would certify one another too, but importantly say the French national DPA must have the power to revoke the Irish national DPA if the French DPA thinks the Irish DPA certifies bad auditors. FIDO2 sounds likea shitshow. Thanks for raising those oncerns. |
Beta Was this translation helpful? Give feedback.
-
|
In the attached PDF, we are proposing a potential definition for pseudonyms in this context, a set of requirements, and a first cryptographic sketch on how to achieve them in a fairly simple manner that integrates with existing components and standards. Please note that this is still a draft version, and we intend to incorporate changes based on feedback in this forum and other discussions before publishing it more formally and with a more stable archival service. Any comments are highly welcome :) |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I read this. This is a very important and even critical topic, but require a thorough discussion. Three main issues:
a) these would already be defined by the identifier established as part of the session including cryptographic means for re-authentication
The real issue which is not even addressed is de-anonymization as by far the most societal transactions will involve the ability to enforce consequences of a failure to comply to an agreement or law that cannot be fully ensured upfront, i.e. the very objective of eIDAS. I.e. in the words of 1.b) above global requirements to local attributes as law and agreement enforcement is a very valid stakeholder. Here we can and should distinguish between local trusted solution, e.g. a shared trusted party (perhaps with multi-party threshold mechanisms), and global which will almost always involve a court and a judge as the only entity trusted in a democracy to deal with such issues. There is a very real discussion on when a structure (including e.g. graceful degradation over time) and the court system become un-trustworthy and how to respond trustworthy to that (e.g. many would question trust in even US courts as they have clearly been politicized). There is also the hybrid aspect, i.e. if you share linkable information with a specific person (a doctor, a teacher, a friend etc.), but not We can always create linkability, just share an identifier verifiable in the process. But that can be end-to-end / localized instead of global and especially without exposing everything in infrastructure/cyberspace. Where pseudonyms and article 5a.16 clearly ends is the RARE cases where linkable identification is actually needed or required. E.g. the fact that e.g. a bank needs to do a KYC as part of enrollment and continuous banking relationship does NOT mean that the bank is able to link all payment transactions.
Finally - a democratic wallet also needs to incorporate means to shut-down in case of coup d'etat or invasion. As we saw with the unacceptably bad identity systems in both Afghanistan and Iraq, these where after withdrawal taken over by Taliban/ISIS and used to identify and kill anyone who had helped the allied forces. This was a predictable and predicted genocide-by-design which warned repeatedly about, e.g. here [(http://blog.privacytrust.eu/public/Danish_Biometrics_20071126.pdf|"7 Rules to Biometrics" in [2007]"] |
Beta Was this translation helpful? Give feedback.
-
|
Dear Stephan Engberg you write “Finally, the real problem here is of course that there is no way to make a trustworthy pseudonym within a smartphone environment.” As one of the first posts (January 29) on Topic E I referred to the Self Generated Verifiable Pseudonyms (SGVP) from my Proof of Association paper (https://eprint.iacr.org/2024/1444) that are trustworthy pseudonyms and that can be created in a smartphone environment using its limited cryptographic hardware (iOS/Secure Enclave, Android/HBK or Strongbox but also TPM and HSM). SGVP pseudonyms also meet all the requirements of Rene Mayrhofer at all. The soundness proof SVGP is based on the Diffie-Hellman protocol which is supported by this cryptographic hardware, i.e. with the DH-key being managed in this hardware in non-exportable fashion. Due to the nature of the Diffie-Hellman protocol, these correctness proofs only convince the relying party and are not transferrable. This is similar to the Restricted Identification (RI) pseudonym in the German identity card (neues Personal Ausweis) and where this non-transferability is considered a feature (deniability of the authentication) and not bug. 😃 So perhaps this non-transferable proof suffices in many use cases. In this paper I struck upon the same problem in the context of making non-reputable key-management instructions sent by the user to the wallet provider in the HSM-based wallet architecture. That is, in case of disputes I want the user cannot deny having sent a signing instruction to the wallet provider. In this context I am similarly limited to the Diffie-Hellman protocol in order to maintain compatibility with standard (PKCS11) HSMs. For this, I have come up with Protocol 2 and Algorithms 22-24 in Annex A.5 of the paper. Translated to SGVP pseudonyms, one can use Protocol 2 to settle disputes between the user and the relying party using a third party (think of a judge or a mediator). This party third can independently verify the correctness of the SGVP pseudonym and thereby settle the dispute. In addition, with Algorithms 22-24 (Annex A.5) of this paper a relying party can proactively use a trusted party to generate transferable correctness proofs of the SGVP pseudonym. Here the relying party would ask the trusted party to generate certain challenges that the wallet then would need to respond to proving correctness. For privacy reasons you do not want a trusted party to have an active role during wallet pseudonymous authentications. For these reasons I suggest the use of a bespoke HSM-module at the relying party generating these challenges in case transferable proofs are required. BTW Protocol 2 and Algorithms 22-24 actually show that the ‘deniability property’ of the Restricted Identification (RI) pseudonym in the German identity card (neues Personal Ausweis) does not hold. |
Beta Was this translation helpful? Give feedback.
-
Sure. But created in an environment you e.g. cannot secure against sidechannel linking on behalf of the user, can suffer from man-in-the-middle attacks between I/O and the cryptographic elements, and without means to ensure that the user is the rightful person. So, whereas the narrow crypto might be somewhat close, the environment violates the properties. This is not specific to this aspect, this is a general problem of using smartphone-based wallets. And that is before we start dealing with the specific problem that DH is not considered quantum-secure. |
Beta Was this translation helpful? Give feedback.
-
|
I guess you should have written your comment as "Finally, the real problem here is of course that there is no way to make a trustworthy wallet within a smartphone environment." The challenge we are faced with is to make a wallet that is technically as secure as possible whereby we also must train the user on how to use it avoiding certain vulnerabilities to be used. Such as "do not install APPs from outside the regular APP stores". My point is that we can have reasonably secure pseudonyms using the limited mobile cryptographic hardware. |
Beta Was this translation helpful? Give feedback.
-
Indeed. Which also means that we need to pay attention to the fact that high-AAAA security simply is unrealistic in a smartphone wallet. yet, this is all the ARF-community seems to pursue as of now.
Sure, but two very different issues.: b) I do not see this as a user problem, but as an inherent need to go for QSCD-based wallets. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
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.
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.
Beta Was this translation helpful? Give feedback.
All reactions