Cryptographers' Feedback on the EU Digital Identity’s ARF

[alysyans]

The EUDI Wallet Team of the European Commission invited subject-matter experts (i.e. cryptographers) to participate in a Webex meeting on June 5th or 6th, 2024, in which the team presented their current design of the EUDIW (ARF version 1.4.0), and requested feedback. They specifically requested feedback concerning attestations and zero-knowledge proofs. Our feedback is in this document: cryptographers-feedback.pdf

The attached document was co-authored by and thus represents the consensus opinion of the following cryptographers who were present on one of the two calls:

Carsten Baum, Technical University of Denmark
Olivier Blazy, École Polytechnique
Jaap-Henk Hoepman, Karlstad University & Radboud University
Anja Lehmann, Hasso-Plattner-Institute, University of Potsdam
Anna Lysyanskaya, Brown University
René Mayrhofer, Johannes Kepler University Linz
Hart Montgomery
Ngoc Khanh Nguyen, King's College London
abhi shelat, Northeastern University
Daniel Slamanig, Universität der Bundeswehr München
Søren Eller Thomsen, Partisia

Five additional experts (who were unable to participate in the calls, but carefully reviewed the ARF and other relevant materials) also co-authored this document:

Jan Camenisch, Dfinity
Eysa Lee, Brown University
Bart Preneel, KU Leuven
Stefano Tessaro, University of Washington
Carmela Troncoso, EPFL

Executive summary:

The eiDAS 2.0 regulation (electronic identification and trust services) that defines the new EU Digital Identity Wallet (EUDIW) is an important step towards developing interoperable digital identities in Europe for the public and private sectors. The regulation, if realized with the right technology, can make Europe the front runner in private and secure identification mechanisms in the digital space, and act as a template for future digital identity systems in other regions.

Unfortunately, we believe that some of the currently suggested design aspects of the EUDI and its credential mechanism fall short of the privacy requirements that were explicitly defined after extensive debate in the Digital Identity regulation. The main reason for this shortcoming in the current proposal is that it relies on cryptographic methods that were never designed for such requirements.
We do not see a way to fix the proposed solution to meet all the privacy features as required by the regulation; we believe that a larger redesign is in order.

In this document, we propose to use a different cryptographic mechanism instead; namely, anonymous credentials. Anonymous credentials were designed specifically to achieve authentication and identification that are both secure and privacy-preserving. As a result, they fully meet the requirements put forth in the eiDAS 2.0 regulation. Moreover, they are by now a mature technology. This technology was developed more than twenty years ago, and extensive efforts have been expended to analyze, improve, implement, standardize, test, and deploy it. Anonymous credentials are well understood by the scientific community.

Our specific recommendation is to use the BBS family of anonymous credentials. For BBS, thanks to prior work by the W3C, the Decentralized Identity Foundation, IETF/IRTF, ISO, and other standardization bodies, as well as the availability of open-source software libraries, the EC can develop a standard and reference implementation with only a modest effort. We additionally recommend that the EUDI be designed following the principle of crypto-agility, meaning that its underlying technologies can be upgraded quickly in the future if the need arises.

We thank the EC for this opportunity to weigh in. We would be excited to continue to provide feedback on this important endeavor, and see this document as the beginning of a longer dialogue.

cryptographers-feedback.pdf

NOTE: We are still polishing the document for readability and adding pointers to relevant literature; an updated version will likely be posted here in the near future.

[ad-Orange]

Hello,
We totally agree with your analysis of the current situation of the ARF and the direction you're proposing (anonymous credentials with BBS being the favourite). In response to the same request from the commission, we would like to stress the following points (that you also seem to share):

• The way forward is using anonymous credentials, preferably of the BBS type
• There is no "quick fix" to make sure the ARF becomes privacy-preserving. It needs to be rebuilt from the ground up with anonymous credential protocols
• This can be done today

In order to give more credibility to the last point, we just posted a proposal explaining how BBS/BBS+ can be implemented with already deployed SEs in a very efficient way. This can even be made compatible with mDL / SD-JWT.
Given the cumulative skills and knowledge of the authors of your paper, we would be very happy to get your feedback on the proposal we are making and are happy to provide more details if needed.

[rmayr]

I believe this document addresses details of #193, among other issues.

[alysyans]

@ad-Orange: thanks for your comment! Indeed, your post seems extremely relevant. Glad that we are all in agreement!

[ckahlo]

The one main question still is: Why signing at all?!

We successfully showed in BSI TR-03110, TR-03130, etc. how to perform ephemeral authentication without having to sign anything without the need of "zero knowledge proof" or similar algorithms. 15 years ago and every single bit of it is still valid.
(Besides relying party authentication, of course. But the relying party has to be known to the wallet holder anyway.)

The main problem of "verifiable credentials" is 3rd-party-verifiability by unauthorized, illegal / criminal 3rd parties. Also introducing data protection issues when verifiable credentials are accumulated at service providers. Verifiable credentials have their origins in the idea of "signed tokens" as used in OpenID Connect / OAuth2 tokens and SAML2 assertions (this was back in 2001!).

The concept of unprotected CWT (RFC 8392) claims set in COSE (RFC 9052) revives the idea of using encrypted, authenticated point-to-point channels to securely transmit all required claims WITHOUT SIGNATURES:
https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/

One could think about a hash or set of hashes to double-check overall integrity. But the idea of signing personally identifiable information is bad, obsolete and not needed at all. Proven during the past one-and-a-half decades in one of the largest EU member states.

Best,
CK

Edit 1: added missing link to current IETF draft for UCCS.

[kernoelpanic]

I fully support the general recommendation towards more privacy-tailored cryptographic approaches, such as BBS/BBS+ Signatures, which has been put forward in this issue.

In addition, I would like to mention the following two points:

• If the history of other cryptographic schemes and protocols has taught us anything, it is that any protocols/algorithms selected now will be subject to change sooner or later to keep up with evolving attacks (which only tend to get better over time). Keeping this aspect (sometimes referred to as cryptographic agility) in mind could be very helpful. Balancing this agility, while not compromising security or privacy by supporting a plethora of options and backward-compatible approaches, is a challenge that any solution will face. Designers should be aware of this challenge from the start.

• A well-maintained security/threat model, including a prioritized list of security and privacy threats for each use case targeted by the EUDIW, could be very helpful to objectify the discussion and select the appropriate protocols/algorithms. Ideally, this model/list should be derived from the eIDAS legislation and expert consensus and will probably need to be adapted over time as well as new, previously unthought-of security and privacy threats emerge. To provide one example, I would like to mention the potential requirement for repudiation, sometimes also referred to as deniable authentication or designated verifiability. This could be very helpful in some use cases while being mutually exclusive to the goals of other use cases. I am using this example because this property has not been a core design goal of most proposed solution approaches yet, but using the same underlying primitives, it can still be achievable in scenarios that require it, albeit requiring additional effort.

[ckahlo]

@kernoelpanic Thanks a lot. As we're on the jump to post quantum cryptography or currently hybrid mechanisms as well we need versatile "basic" cryptographic primitives. BBS / BBS+ is a DEAD END STREET under the view point of crypto agility and especially forward towards PQC interoperability.
Keep in mind: this process will still take some years until the technology stack is rolled out in production. And quantum supremacy is getting closer as well. In general it will help to stick to generic cryptographic primitives that can be transponed to future more modern mechanisms without throwing over the whole protocol stack.

[kernoelpanic]

@ckahlo I would not call BBS/BBS+ a "dead end", it is probably the most thoroughly researched algorithm specifically designed for the use case at hand and the most advanced in terms standardization (compared to other newcomers). Is it perfect? Probably not, as nothing will be.

I am getting your point regarding signatures and 3rd-party-verifiability and the demand for repudiation, which I also support. Although BBS+ as put forward in the RFC does not have this as an explicit goal, I believe the underlying primitives can be used to achieve schemes which can do it, at least with a performance decrease e.g, when used interactively (please correct me if I am wrong). So assuming, repudiation/deniable authentication could also be solved, what remains is the threat of a quantum computer, but abandoning a by-today's-standards well thought through approach that ticks almost all boxes (maybe all with some tweaks) because of this is also not the way to go my opinion. This does not mean, that we should not consider upgradeability right from the start.

Generally, it would be a good idea for the discussion to agree on a prioritized list of boxes which should be ticked by a solution first. Maybe, there is no one-size-fits-all solution ...

[rmayr]

Please note that the main basis for this document is the published legal text of the regulation, i.e. the list of requirements (unlinkability, selective disclosure, pseudonymity, etc.) is taken directly from the regulation. We intentionally did not want to go through the requirements analysis itself, because this is defined in the law at this point.
If somebody wanted to go back to the start, other requirements may be prioritized, but that was not the starting point for this recommendation.

[ad-Orange]

@kernoelpanic As regards to repudiation, there is indeed a technology invented in 1996 to implement plausible deniability for all ZKP based anonymous credentials. We detail its use with our BBS# proposal in page 20 of our paper (it is called DVP and referenced as [JSI96]). Please also note that contrary to popular belief, interactive ZKP do not provide plausible deniability.
@ckahlo We don’t think that authenticated channels present any sort of advantage for repudiation compared to our proposal (and the DVP technology in general).

[LittleDetritus]

@ad-Orange
Two points on this regard how do you ensure that reyling parties can not forward the verified data without the users knowledge?

Following IT-Security best practices:

• Assume breach
• Zero Trust

that the user does not need to rely on trusting the relying party that they do not forward the tokens?

If we also take the eIDAS2 requierments by heart following security by design at state of the art, do you see a way around 2FA for LOA high including an airgapped physical token?

[ad-Orange]

@ckahlo So in essence, you are opposing a possible but as of yet hypothetical threat (“quantum supremacy”) to a legal requirement (respect of GDPR including minimization and unlinkability) due today. Furthermore, it's not even clear how you would end up being GDPR compliant with your so called 'versatile "basic" cryptographic primitives'.
As explained in the original paper of this thread in section 6 and in our own paper, the “dead end street” of BBS/BBS+ ensures unconditional / everlasting privacy today.

Now, let’s talk about authenticated channels:

• For some options (e.g. option D in the “German ARF”) The security of it relies on properly implemented SE
  o As explained by Google here and here, if a SINGLE of these SE (CC certified or not) is compromised (reminder: 448,4 millions inhabitants in Europe, source: EU), the attacker could impersonate anyone
• None of the proposals we have seen supports full unlinkability (as also explained in part 2 of the original paper of this thread "Analysis of the ARF and Its Shortcomings")
• Repudiation / plausible deniability needs to be decided on a per use case basis and not imposed for all use cases indiscriminately
• How do you store all the necessary attributes and data structures in an SE ? If you don't, how do you combine multiple VCs in a single presentation ?
• How do you manage revocations in a privacy preserving way ?
• The implementation is subject to a lot of overhead. Depending on the chosen option, it could involve (potentially a combination thereof):
  o Changes in the ARF
  o Changes in the interfaces of the RP
  o Deployment of widespread extremely highly protected SE (see for point of this paragraph…)

As long as there is no clear advantage identified today for authenticated channels as opposed to other proposals (including the paper we just posted), especially taking into account the constraints that will be there at the launch of eIDAS in a few years, it doesn’t seem like less of a “dead street end” than BBS/BBS+…

[ad-Orange]

@LittleDetritus, I'm not sure you are understanding how DVPs work. Basically, you can steal or forward the ZKP to anyone you want, they will not be able to assess their validity (except its designated target, e.g. the verifier to whom the holder is doing the presentation). Once again, it's a technology that dates back to 1996 and how to use it in the realm of BBS signatures is explained in our paper around page 20.
As regards to air-gapped solutions, you can use a FIDO key if you want and think that makes sense from a usability point of view. It can be discussed whether it really adds anything in terms of security, but that's another discussion. As an inspiration, you can look at this architecture proposed by the GSMA and replace the SIM with a FIDO key or even just add a FIDO key to the intricated factors. You will not lose anything in terms of privacy.

[msporny]

Speaking as an Editor for the W3C work cited in the paper (W3C Verifiable Credentials, W3C Data Integrity, the W3C Data Integrity BBS Cryptosuite), and as someone deploying that technology with national and state governments globally, I agree with the findings of the cryptographic review and the experts that put the paper together.

The current approach taken by SD-JWT is deeply flawed, as it relates to unlinkability and cryptographic agility, and has been flawed from the beginning. This has been expressed multiple times over the years, but the review from the cryptographic experts listed above hopefully places more weight on the previous criticisms of the use of SD-JWT. It is not fit for purpose for the EU's Digital Identity initiatives.

I will also note that the W3C VCWG has known about these limitations for years and has provided a viable alternate path via W3C Verifiable Credentials, W3C Data Integrity, and the W3C Data Integrity BBS Cryptosuite. Additionally, future cryptographic innovations utilizing W3C Data Integrity wouldn't require a format change, by design. The same cannot be said for VC-JWT, SD-JWT, or JWP.

I will also note that a review of the ARF's data model choices and cryptographic primitives have not been requested of any W3C Working Group. I would strongly suggest that the European Commission (or relevant body) officially request a review from the W3C on the ARF, as many of the experts in the W3C would not feel comfortable volunteering an unsolicited review.

[ghost]

@ckahlo the German solution is well-known and from security point of view the best solution. The disadvantage: Lack of adoption. Germany achieved 15% usage rate after 14 (!) years since publishment

Your statement " But the idea of signing personally identifiable information is bad, obsolete and not needed at all. Proven during the past one-and-a-half decades in one of the largest EU member states." is a bit wrong looking at the less usage rate in Germany. Looking at Germany its proven that the German approach was best for security because it also mitigates the biggest security risk - the user.

"One could think about a hash or set of hashes to double-check overall integrity." - a hash without PoE is useless.

Majority of EU Member states use signed data in eID: Which fraud identity or data dealers for which signed eiD Data from which eID means based on which eID Scheme do you know? Please provide so that we can analyse commonly. This information is essential to assess the security risk and possible measures

[ckahlo]

At first: I gave a ❤️ emoji to the initial post, because I totally AGREE on BBS+ in case one has to rely on software certificates or weak key stores like Androids StrongBox or Apples SecureEnclave.

In absence of stronger protection mechanisms of the private key, signed ID data is the only option we have. I am very well aware of that and was looking for a clear answer, because we're talking about secure elements as if this was the very same thing as well.

So, without a secure element of any kind: BBS+ is probably the best way to go. Authenticated channels would lead to forgeable identities if the authentication key is leaked. A clear no-brainer I assume.

@ad-Orange 1st comment: my question "why signing at all" wasn't with repudiation in mind, it's an option. Reduced to repudiation I might agree.

@ad-Orange 2nd comment: Thanks for https://github.com/user-attachments/files/15905230/BBS_Sharp_Short_TR.pdf,
I already knew https://www.engr.mun.ca/~howard/SAC_SLIDES/slides_Barki.pdf and "Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials" from the past. Good work.

• But the Y2Q threat (https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later) isn't just my personal opinion. NIST explained their motivation here: https://csrc.nist.gov/Projects/post-quantum-cryptography - and the corresonding EU member state bodies and independent researchers I've been in touch with support this. I had been explicitely pointed to this by digital rights groups. It is something to keep in mind when designing new systems. Another 15 years and it is almost 2040.

• I said "dead end street" for crypto agility towards PQC mechanisms - I wasn't even discussing about long-term privacy of BBS+, but before someone claims "everlasting privacy" a peer-reviewed proof should exist. Both papers are new, so a credible peer-review does not exist yet. If your claims are correct, I'll be absolutely happy anyway. :)

Authenticated channels:

1. I am not in charge of the SPRIN-D architecture - and NEVER said I'm happy with this architecture. Don't mix that up, just because people are from the same country.
   But I know the numbers and from the existing system I can tell you the chip authentication key is either limited to 2 million documents or 3 months of issuance time. As the document signer is linked to the chip auth key and has a limited lifetime a breach of 1 key affects only this 1 batch and only if it is not expired yet. Expired batches are "allowed" (and somewhat expected) to breach. The national ID cards have a lifetime of 10 years, discussed lifetimes for the secure element version were between 6 months and 2 years. If a batch breaches within the validity period it enters the defect list, effectively blocking those documents. But if that happens the secure element users (and the OEM and the SE supplier) may have lots of other problems as well ;-) Think of payment and device encryption.
   For an EU-DI variant, a corresponding value for the key lifetime/number of wallets would have to be defined in any case. Probably further splitting the document signers by issuing institutions/countries, implementations, etc. any way.
   Even NXP P5 errata exists - a breach is not known yet. 15 years. How long lives your phone? Galaxy S24 lifetime is sought to be at 7 years at max (speaking of updates).
   And have a look into ISO 23220-4 §7.1.6 where they suggest publishig the document signer key after expiration. (Personally I don't like that, even it may be mathematically valid)
   I would only talk about CC EAL5+ evaluated "secure elements", no toys please.

2. Unlinkability is given in the 1-in-2-million-documents / 1-in-3-months-issued-documents frame. So, these numbers have to be chosen wisely. Don't blame me if SPRIN-D didn't.

3. As said before repudiation wasn't my idea when asking "why signing at all?". I won't discuss this here.

4. As per current proposals only keys and the minimum dataset and hashes of external attributes / attribute stores is stored in the secure element itself. Larger sets of attributes (or even PDFs) are stored in the wallet application / mobile device storage with an option for synchronization with a remote storage. But this affects a BBS+ implementation on secure elements as well. Concepts can be combined for shure.

5. Please see BSI TR-03110 restricted identification. There exist two distinct RIDs, one for revocation, one for pseudonymous access - that's the current implementation. For a wallet a revocation RID key-pair is generated during initialization and the public key returned to the issuer who adds the public key to a revocation database. The public key is then associated with a hash of some minimal PII (name, birthdate, metadata such as issuance date of the "document") and a randomly chosen revocation password and stored in the DB. But I'm totally happy if someone comes up with new ideas / better approaches. As said, this is ~15 years old.

6. I am speaking of this as an alternative approach. As said above I totally agree (and like) BBS+ for non-secure-element solutions. In another discussion I said "there have to be two types of wallets, one with signed data and BBS+ and another one with a different approach using secure channels / ECIES".

BUT: I would be interested in having a closer look into the backgrounds of your paper. Because from
https://www.gsma.com/gsmaeurope/resources/architecture-considerations-for-eidas-2-0/ page 10 in the section "Privacy" it is said BBS+ is not supported by SEs in the market in an efficient way. And with my knowledge until today I can confirm this. Regarding your paper you're talking about ECSchnorr and ECDSA as if it was the same. But the "real" ECSchnorr is only available as an option with the BSI CSP (https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03181/BSI-TR-03181.pdf?__blob=publicationFile&v=5). The standard JavaCard APIs (https://docs.oracle.com/en/java/javacard/3.1/jc_api_srvc/api_classic/javacard/security/Signature.html) only know classical ECDSA - not the "real Schnorr".

I would be happy if we could confirm your findings from your paper and would encourage our BSI to have a closer look at it. If it works out, we could push it together. Hint: I've some dozen top-notch secure elements here - but older ones as well. :-)
You'll find my contact coordinates on my profile or somewhere on the net.

@KeepTrust: what a bold comment from an account created just 15 hours ago!
If you cite statistics, please cite with sources. Statistics differ. As you may know the German eID system isn't "centralized" at all - bigger service providers have their own eID servers and mostly smaller ones use eID-services such as those from Governikus and Bundesdruckerei.
So, there are no consolidated transaction logs or counts on them. The best options are surveys and what I could find using Google is 3 years old. I've got different more up-to-date numbers, but I'm probably not authorized to publish them without talking to BSI/BMI before.

That being said: Germany has a high population density with a good offline infrastructure compared to more rural areas within the EU. Additionally there is the "silver generation" with a fear of technology.
BUT: Corona was a game-changer, the adoption increased during the shutdowns and more service providers entered the show.
AND: Germany was never forcing anybody "you have to use the eID" as other countries did, this started only slowly in the past time and well, the adoption rate increased.

Let's have a look how the adoption in the EU will be before judging too early.

Technically the usage rate is not linked to the underlying protocols. We started to issue the first
"QES" signature cards in 1999 - other EU countries would claim this as "oooh, look we started with
eID that early" - basically, all signature based ID schemes claimed as "eID" would be the same.
But we chose to split "signature" and eID. And some people mix that up.

And we're also aware about some EU members not applying any reasonable security measures as well! Thanks for the fish.

Just a hint: use Google with "estonian identity disaster", look up how Petr Švenda became able to impersonate basically everybody in Estonia. And continue, there are more examples. But that's your homework, not mine.

From my side this is end of discussion.

Good bye & good night,
CK

[ghost]

@ckahlo Interesting comment. REality on eID in Germany. The reality is given below.
Corona was no gamechanger for German eID because usage rate didn`t increase

https://www.personalausweisportal.de/SharedDocs/kurzmeldungen/Webs/PA/DE/2021/10_eGovernment_Monitor_veroeffentlicht.html#:~:text=In%202021%20haben%2035%20Prozent,Smartphone%20(Smart%2D%20eID%20).

https://de.statista.com/statistik/daten/studie/1306900/umfrage/nutzung-des-online-personalausweises-in-deutschland/

Adoption in Europe

https://www.strategyand.pwc.com/de/en/industries/public-sector/global-eid-country-report.html

https://www.zealid.com/en/blog/the-state-of-eidas-eid-and-impact-on-the-eu-wallet

eID is no QES as you may know - so bad argument

Estonia is > 8 years old and no Identity trade or similar. So long story short: Your arguments are less. 29 of 31 EU/EFTA Members use signed data - no Identity Thefts nor trade known.

So please do your homework and look at real issues

[ckahlo]

@KeepTrust You're citing the old survey numbers from June 2021. Please read again what I said above.

And I never said "QES is eID". I said "signature based schemes" claimed as eID - basically all the countries you mention.
We also have ELSTER in OZG2.0 and in several variants from software certificates to hardware tokens - also used for identification processes: https://www.elster.de/eportal/login/softpse?locale=en_US

And please re-read the part about BBS+ support in secure elements. @ad-Orange claims this to be solved and I said I would be happy if this is the case. But I don't see any support for real ECSchnorr in "standard secure elements on the market" as claimed in the paper.
So an implementation hint to verify the paper would be very useful. Especially for this group. BTW: we've eSIMs here that only support exactly NIST and Brainpool curves. If you supply different curve parameters - as needed for BN P256 and BLS12-381 you get an exception.

We all agreed on SD JWT being flawed as @msporny also said. So to support a PQC-forward selective disclosure scheme with all the properties defined by the ARF on current secure elements I am still at https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/.

Well, the Estonian model has no way to detect forged identities and if the private key is known to the attacker it doesn't matter anymore if you "know" about the theft. The theft happened already, if used or not does not matter for the situation.

So, your ad hominem "your arguments are less" from an anonymous(!) account applies very well to yourself.
Send greetings to the killfile when you arrive there. :)

Edit1: BTW, BSI confirmed BBS+ has not yet seen any national standards body for review or standardization. This should happen as soon as possible. I've no personal feelings about which national standards body this is.
BBS+ had been presented to NIST in last October:
https://csrc.nist.gov/csrc/media/presentations/2023/crclub-2023-10-18/images-media/20231018-crypto-club--greg-and-vasilis--slides--BBS.pdf
So, if anyone from NIST, ENISA, ANSSI, etc. or connections to the right people within those institutions reads this please have a look and start an official standardization process. So, BBS+ can be officially supported by other standards bodies as well.

[ghost]

@ckahlo ELSTER is a software certificate and only authentication no identification mean. Youll get it if you identify yourself with eID. So you shouldnt compare apples and oranges, ELSTER will foreseeably be substituted as it clearly not fulfill LoA "high" acc. 2015/1502, TR-03147 and TR-03107.

That PID on SecureElement is most secure solution is common sense. But as you can see in decision by German Federal Office for Information Security: Its no solution which promise high adoption rate - thats why the SmarteID Project was stopped and PID in SecureElement postponed.

The Estonian Breach didn`t lead to identity theft nor identity trade. The lessons learned are different from your claims. The issue was not related to signed data in SmartCard. And the issue was eliminated 2017, means your claims on Estonian eiD are not valid anymore.

https://ria.ee/media/742/download

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3644664

Except this thread theres no expert agreement that SD-JWT is flawed on cryptographic subjects (but on other ones e.g. lightwight JAdES-Signing). On the other hand theres not core SD-JWT planned anymore - so the discussion here starts from wrong ankle. Also SD-JWT does not use BBS+ signatures (but JOSE and JAdES as Format). BBS+ is only integrity proof but no credential format (which could be JSON-LD). For details on Credential Formats see:

https://decentralized-id.com/web-standards/w3c/verifiable-credentials/jose-jwt+cose-cbor/

The standardization on signatures in ongoing in ETSI ESI - with currently no view on BBS+ as it`s not established yet. The cryptographers feedback is great but has to be analysed further without the mission to sell one solution on how to put the PID in EUDIW.

[rmayr]

I suggest opening a separate issue for proposing schemes that do not rely on asymmetric signatures, as that would be a completely different approach to the ones analyzed in this paper. It seems hard to discuss the technical details of two completely different approaches, even if the main security and privacy requirements largely agree.

[alysyans]

@ad-Orange: there is no contact info in the paper you posted, and no contact information for you in your GitHub profile. How do we get in touch with you?

[ckahlo]

@rmayr I fully agree on that. Neithertheless I wanted to hear your opinions and I think the discussion already solved a part of that.
And I am really thankful for your paper.
I would leave the task to open this ticket up to the authors of the IETF draft.

[ckahlo]

@KeepTrust You don't need to tell me about TRs I know. And I am not comparing apples and oranges, I am pretty aware of the different LoA levels and I hope ELSTER will never be LoA high - as it is clearly not suitable for that. While "qualified" signature cards - as accepted by ESLTER as well are considered to fulfill LoA high. But we're not discussing LoA levels here.

My argument about Estonia AS AN EXAMPLE is still valid, because what I said is not introducing such problems AGAIN.
Furthermore get a clear name or simply shut up. I'm done with you.

If you need to discuss anything regarding SD JWT vs. BBS+ talk to @rmayr, @alysyans, @msporny but NOT TO ME.
I already said BBS+ has to be evaluated and standardized by a national standards body - so the cryptographers feedback needs to be evaluated there. I never said anything different.

[ghost]

@msporny "The current approach taken by SD-JWT is deeply flawed, as it relates to unlinkability and cryptographic agility, and has been flawed from the beginning. This has been expressed multiple times over the years, but the review from the cryptographic experts listed above hopefully places more weight on the previous criticisms of the use of SD-JWT. It is not fit for purpose for the EU's Digital Identity initiatives."

This can`t be confirmed based on results of Large Scale Pilots. Unlinkability required by law see Art. 6 ff. eIDAS 2.0. It fits perfectly for EUDIW as it allows integration of W3CVCDM but also JAdES Signatures which are widely used across Europe and as AdES easily adoptable by existing QTSP.

@ckahlo: Signature Cards don´t fulfill LoA "high". The LoA is related to eID Schemes and means only. See. Art. 8 eIDAS. As you can get a Signature card with VideoIdent - it will never fulfill LoA "high",

You are seemingly done with everything which fits not in your mission to sell one solution which was stopped by German BSI due to lack of adoption.

BBS+ has to be evaluated correct but not from National Standardization Body but European one as only standards from ETSI/CEN will be referenced by implementing acts and so relevant for eIDAS. Your claims on SD-JWT are limited as the format also used for QEAA, not only PID and "So to support a PQC-forward selective disclosure scheme with all the properties defined by the ARF on current secure elements I am still at https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/." would IMHO not fit but if you have further knowledge on this please elaborate.

Your claim " But the idea of signing personally identifiable information is bad, obsolete and not needed at all. Proven during the past one-and-a-half decades in one of the largest EU member states." remain unproven as German eID lacks of utilization - which was reason why SmarteID stopped.

[ckahlo]

@KeepTrust Again, I am NOT involved in Smart-eID. I NEVER WAS involved in the Smart-eID project. My part in the past (literally 5 years ago!) delivering prototypes long before Smart-eID started was related to technical evaluation. And I am not selling anything to anybody, I am not "Sales". I was just trying to help realizing the idea "eID on mobile device". NOTHING ELSE.

Smart-eID was not stopped by BSI. And it was not stopped because lack of adoption, it was stopped by BMI, because the SRPIN-D challenge should be started. You're mixing up things completely.

Consider ETSI being a "national standards body" on EU-level, I am fine with that.

For the others: @KeepTrust is obviously some German account involved in the OpenID4VC / SD JWT implementation for SPRIN-D. As you can see WE DO NOT AGREE :-) @ad-Orange: may be that helps to understand not every German is the same ...

[msporny]

@KeepTrust wrote:

This can`t be confirmed based on results of Large Scale Pilots. Unlinkability required by law see Art. 6 ff. eIDAS 2.0. It fits perfectly for EUDIW as it allows integration of W3CVCDM

As hesitant as I am to respond to an account that was created less than 24h ago...

There has been very little focused effort or work in the W3C VCWG on how the W3C VCDM works with SD-JWT. For example, there is no guidance how contexts at multiple levels of objects in the VCDM would work with SD-JWT, no guidance of how type is processed... we do know that the only way unlinkability could possibly work is by issuing MANY SD-JWTs (which requires highly-available infrastructure and if that infra goes down, you can't identify yourself), issuing multiple copies of the same VC is also strongly advised against by some in the WG due to the management issues that will cause for digital wallets, not to mention that the tie to a hardware bound key defeats unlinkability entirely in SD-JWT... and so on.

Additionally, the group has done zero official review on SD-JWT-VC (or whatever that alternate format which claims to be VCDM compatible, but doesn't seem to actually be compatible, is called these days). Some of us have seen presentations with flawed premises, but are unsure where the work is these days.

If anyone associated with the ARF believes that SD-JWT can encapsulate VCDM in its current form, they are misinformed.

Again, I suggest the relevant parties set up a liaison relationship with the W3C VCWG and work with the group to determine a safe profile for the EUDIW, or at least get some official review on what the ARF is proposing, whether that is SD-JWT or SD-JWT-VC or something else.

[ghost]

@msporny As polite as I`m I focus on content not on the time an account was created.

The standardization on SD-JWT VCDM is ongoing and currently your claim that SD-JWT and W3C VCDM 2.0 are not compatible is wrong. The official review of ARF is done in LSP - so already ongoing. There are many subjects in optimizing SD-JWT (e.g. possibility for lightwight signing with JAdES Signatures for Integrity proof and fulfilment of Annex V eIDAS.

The W3C VCWG is currently not involved in ARF process, the work on SD-JWT VCDM is ongoing in European Standardization bodies. So if W3C WG has concrete claims would be great if you contact eIDAS Toolbox Group or ETSI/CEN. Long Story short: You focus on wrong group to get the status quo.

So if you focus on W3C VCWG and use this as basement for your claims - you are misinformed. Means the relevant parties already work to determine a safe profile for the EUDIW, What ARF is proposing can be seen in ARF...

@ckahlo "Smart-eID was not stopped by BSI" - the reality given in following Video: https://www.youtube.com/watch?v=LHMIYTZc2SM (from 6.58h). The SPRIND Challenge started in March, the stop of SmarteID was in December 2023....

You was involved in previous projects as you mentioned on which SmarteID was based on - so fully understandable that you propose this approach (which from security point of view is best one - but lack of adoption which was one main reason why SmarteID was stopped - but planned as final goal for German EUDIW as BSI mentioned)

ETSI = European Standardization Body not national one.

BTW: I don`t work for SPRIND but thanks for the flowers ;-)

[msporny]

As polite as I`m I focus on content not on the time an account was created.

Please identify yourself, you seem to be speaking on behalf of ARF. Who are you?

[ghost]

@msporny Nobody is allowed to speak on behalf of eIDAS toolbox except maybe Paolo da Rosa but Im not Paolo ;-) But yes Im deeply involved in the subject.

[msporny]

Nobody is allowed to speak on behalf of eIDAS toolbox except maybe Paolo da Rosa but Im not Paolo ;-) But yes Im deeply involved in the subject.

Then, identify yourself, please.

[filip26]

@KeepTrust hiding your identity, pretending be an insider, making bold statements, and creating distrust in a discussion that must be transparent - as it is in every EU citizens interests - makes your comments irrelevant and possibly even a threat. How is the weather in Moscow today?

[OBIvision]

NOTE: We are still polishing the document for readability and adding pointers to relevant literature; an updated version will likely be posted here in the near future.

First - compliment for addressing the main issues so clearly. ARF is obviously not compliant legally nor state-of-the-art technically. Whatever the reasons.

Second - we support the main discussion and support for BBS-style credentials as a key building block. BBS# (when scrutinized) look like a good first step.

Third - it is, however and without contradicting the first two above, also clear the this minimum credential approach may be able to support simple transactions, but most realworld transactions such as all ARF Use Cases require moving beyond this integrating different technologies and supporting multiple issuers, providers and more complex security requirements.

We will be incorporating trustworthy PKI and atomic credentials within the present standards as a way to resolve these critical issue even more generic in the basic structures IN ADDITION to BBS# on the application layer.
https://www.edps.europa.eu/system/files/2022-07/03_-_stephan_engberg_-_edps_trustworthy_pki_engberg_20220622_en_0.pdf

[ad-Orange]

@ckahlo
So, here is some feedback, in disorder, but hopefully covering most of the pending points:
• Our paper indeed also covers ECDSA and not only ECSDSA/ECSchnorr. Please note that as no pairings are involved, the BBS# proposal is also compatible with standard curves. Here are a bit more details:
o In 2.1.6, we show how to calculate the issuer signature 𝜎𝐼𝑠𝑠𝑢𝑒𝑟𝐵𝑙𝑖𝑛𝑑 = (𝐴̂ , 𝐵̅ , 𝐷, Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦). We give the Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 formula for ECDSDSA / ECSchnorr in this chapter and the corresponding formula for ECDSA in note 31 (sorry, we understand this is a bit unwieldly).
o Then, we explain how to calculate the signature of the user for both ECSDSA/ECSchnorr and ECDSA.
o The whole challenge is having the SE producing a signature with the non-randomized key and the software on the phone completing it into signatures with the randomized key (both for 𝜎𝑈𝑠𝑒𝑟 and for what is much more of a challenge: Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦)

• Hardware support: We much prefer ECSDSA / ECSchnorr to ECDSA due to better theoretical security properties but as explained above, both work.
o We think at it is implementable in hardware today on most platforms using ECDSA (we have actually done it leveraging Android Strongbox) with very good reach. For more details on the tests we’ve already carried out, I think it would be easier to have a call.
o Whenever CSP has been properly deployed (and ECSchnorr properly included into it…), we can gradually migrate to ECSDSA on SEs
o Already today, ECSchnorr can be used on HSMs

• As you probably understand, BBS# is quite new, but:
o While BBS# is a new iteration of the BBS family of protocols, it build on top of MAC_BBS, the pairing free variant of BBS/BBS+ that was published in 2016 (reference [BBDT16] in our technical report).
o In “3. Security”, we are providing succinct proofs for both security (unforgeability of the VPs) and privacy (everlasting privacy).
o For privacy specifically, it is proven in the reference above ([BBDT16]) that MAC_BBS (on which BBS# relies) satisfies the everlasting property.
o As you righteously pointed out, the GSMA paper is not updated to reflect this new situation. We’ll try and tackle that in the coming weeks.

• BBS# has the everlasting / unconditional privacy property
o If you don’t believe us (on our proof) on everlasting/unconditional privacy, then have a look at what the renowned cryptographers wrote on the paper linked in the first post of this thread, namely “We note that for the BBS family of anonymous credentials, the privacy property holds unconditionally.”
o They also wrote that “Consequently, as for most use-cases of signatures (apart from specific use cases like long-term archiving), the switch to post-quantum alternatives is not extremely urgent. This is in stark contrast to encryption schemes, where due to the “store now decrypt later” problematic a switch to post-quantum encryption schemes needs to happen timely.”
o So, if you don’t believe us, believe them. If you don’t believe them, well…

• For crypto agility for PQC, I think the situation is all but clear and I wouldn’t draw immediate conclusions on the present from forward looking assumptions about the future

• For authenticated channels, I’ll try and be brief but basically, while they were probably amazing for Germany when it was first invented decades ago, we have much better tools today as advocated by these renowned cryptographers in their position paper: “Our specific recommendation is to use the BBS family of anonymous credentials”
o The security model doesn’t seem right to me: even if the SE is certified EALGod+, having the failure of a single one of them leading to potential mass impersonation is just not possible. And BTW, I’m not really sure why you and keeptrust seem to agree (that’s the only thing you seem to agree on) on the fact that the authenticated channel architecture is “the best for security”. I must have missed something.
o You were asking for security proofs and review for BBS#: is there (or can there even be) any security proofs (ideally formal proofs) for something as complicated as the protocols proposed in the “German ARF” ?
o I have to say that what you’re saying in 1. And 2. Is not crystal clear to me, but your “1 in a million” assertion on unlinkability seems wrong to me: as mentioned in the comparison of the “German ARF”, none of the options seems to support full unlinkability whereby, when issuers and verifiers collude, still nothing can be revealed
o For the BBS line of protocols, you only need one secret key, and that’s the only thing you need to store in the SE. One private key. That’s it. So, no, you don’t have the same issue as with authenticated channels. And even with all what you explained, I’m still not too sure how you make presentation involving multiple VCs/(Q)EAA coming from multiple issuers
o For the revocation part, I didn’t have the courage to read all the BSI stuff, but I doubt there is a method that is completely “unlinkability safe”.
o I’m still not convinced that there is any benefits in using the authenticated channels architecture given that the actual solutions based on the BBS family provide, almost for free, better guarantees both in terms of security and privacy.

[spheroid]

As a side note, please use the Markdown formatting when composing the messages. It's really hard to follow the discussion when the messages are filled with ad-hoc formatting characters and there's no proper spacing between paragraphs, lists, and headings. Also, when replying to a message, please use proper quotations. Thanks!

[ckahlo]

@ad-Orange thanks a lot for your response, I'll try to make it short and clear as possible:

@ckahlo So, here is some feedback, in disorder, but hopefully covering most of the pending points:
• Our paper indeed also covers ECDSA and not only ECSDSA/ECSchnorr. Please note that as no pairings are involved, the BBS# proposal is also compatible with standard curves.

Thanks for this clarification. In the meantime I had more time to read your paper more thoroughly and realized you were talking about ECDSA and ECSchnorr as two options. And thanks for pointing out, you don't need to use Weiterstraß transformations of other curves, but can work with standard curves. It also helped pointing out, that the complex operations are done on the mobile device as already shown 2016/2017 with MAC_BBS. As said I am aware of the paper.

• Hardware support: We much prefer ECSDSA / ECSchnorr to ECDSA due to better theoretical security properties but as explained above, both work.

Totally agree. ECSchnorr has even more desireable attributes. That's why it is used in Chip Authentication v3. (BSI TR-03110-3)

• We think at it is implementable in hardware today on most platforms using ECDSA (we have actually done it leveraging Android Strongbox) with very good reach. For more details on the tests we’ve already carried out, I think it would be easier to have a call.
• Whenever CSP has been properly deployed (and ECSchnorr properly included into it…), we can gradually migrate to ECSDSA on SEs

Of course CSP is deployed to "higher end" embedded secure elements, but don't expect it to be "everywhere".
I would more rely on pushing ECSchnorr into the next release of the JavaCard standard. Some verndors have extension APIs, possible supporting ECSchnorr - and as in the past BN P256.

• Already today, ECSchnorr can be used on HSMs

Yes, HSMs and on natively programmed (no GlobalPlatform/JavaCard) Secure Elements as well, but those aren't used within mobile phones. They only would be an option for air-gapped devices.

• As you probably understand, BBS# is quite new, but:
. . .
• In “3. Security”, we are providing succinct proofs for both security (unforgeability of the VPs) and privacy (everlasting privacy).

I saw that and I simply said "let's have peer reviews on your paper" and "a standards body should evaluate and standardize it".

• BBS# has the everlasting / unconditional privacy property
• If you don’t believe us (on our proof) on everlasting/unconditional privacy, then have a look at what the renowned cryptographers wrote on the paper linked in the first post of this thread, namely “We note that for the BBS family of anonymous credentials, the privacy property holds unconditionally.”

. . .

• So, if you don’t believe us, believe them. If you don’t believe them, well…

Again: it is NOT about believing someone. It is about peer review, evaluation and standardization. Don't get triggered just because I say "let's have a closer look and let's have a review from other experts".
History has taught us, that different experts have different views on the subject. Regarding the somewhat related BN curves from past BBS+ implementations someone answered this here: https://crypto.stackexchange.com/questions/103524/weaknesses-in-pairing-crypto-with-bn-curves/103527#103527 and
here: https://crypto.stackexchange.com/questions/44732/bn-curves-for-256-bit-symmetric-security

So, all I say: let's have a review und evaluation.

• For authenticated channels, I’ll try and be brief but basically, while they were probably amazing for Germany when it was first invented decades ago, we have much better tools today as advocated by these renowned cryptographers in their position paper: “Our specific recommendation is to use the BBS family of anonymous credentials”

Again, I am not against BBS+/# and I also said those approaches are older and were implemented in abscence of better choices. BUT: authenticated channels also have more and other properties than just credential transport. They also ensure an encrypted link between the authenticating and relying parties cryptographic endpoints.

• The security model doesn’t seem right to me: even if the SE is certified EALGod+, having the failure of a single one of them leading to potential mass impersonation is just not possible.

Please don't mix up toy secure elements and EAL5+. Show me an attack on NXP P71D321 and I might change my mind. :-)

• And BTW, I’m not really sure why you and keeptrust seem to agree (that’s the only thing you seem to agree on) on the fact that the authenticated channel architecture is “the best for security”.

First: I would probably not agree with keeptrust on anything, it may happen by accident. But it is not the intention of keeptrust.
Second: I never said "the best for security", I said in my initial statement that signing of PII is a bad idea - and if I shall extend IF you've better options for secure key storage. I already agreed on BBS+/BBS# in case of weak stores.

• I must have missed something.
• You were asking for security proofs and review for BBS#: is there (or can there even be) any security proofs (ideally formal proofs) for something as complicated as the protocols proposed in the “German ARF” ?

Correct, you missed the point I was never talking about the "German ARF" as I said in my reply before: I am NOT involved in that. You may ask that question to someone in charge of the "German ARF", of course. But I am the wrong contact person in this case.

• I have to say that what you’re saying in 1. And 2. Is not crystal clear to me, but your “1 in a million” assertion on unlinkability seems wrong to me: as mentioned in the comparison of the “German ARF”, none of the options seems to support full unlinkability whereby, when issuers and verifiers collude, still nothing can be revealed

1 and 2 is also described in the ANSSI-version of TR-03110. The document signer lifetime is subject to issuance policy.
You mention an important point "full unlinkability" vs. call it "general unlinkability". Full unlinkability would mean assuptions such as 1-in-2-million would not exist, while general unlinkability may use M-in-N assumptions. Can we agree?
Again, I was not talking about the "German ARF" - this is a completely different thing compared to the existing eID scheme I was talking about. And again: it is not about "protecting" this scheme, it's meant as a real-world example.
I'm pretty open to innovative changes, after 15 years it's super fine to have something new. I hated the long-winded ISO7816-8/9-protocol parts (having lots of single read binaries, general authenticates, etc. instead of simplification) a lot.
And may be something that isn't known to the EU community: I was always the guy who proclaimed "let's do something new, let's try other approaches" in the last - let's say 10 of 15 years.

But as you also can see it is clearly en vogue in Germany to discredit and attack people - and this is a long story. I probably even know the person behind keeptrust and it's probably already blocked by me on other plattforms.

I hope we can agree on: moving forward is a good option.

• For the BBS line of protocols, you only need one secret key, and that’s the only thing you need to store in the SE. One private key. That’s it. So, no, you don’t have the same issue as with authenticated channels.

The same applies for authenticated channels as this is only one ECDHE-private key (or a PQC KEM scheme) with a KDF creating the key material for AES-GCM / AES-CMAC - whatever you want.
At this point your claim is wrong and I get the impression you just want to protect your idea while not reading the ANSSI/BSI technical reports? ;-) As said BSI TR-03110 is also available in French and collaboration with ANSSI was always good,

Sorry for the harsh words, but please have a closer look at the previosly mentioned technical reports before doing such claims.

• And even with all what you explained, I’m still not too sure how you make presentation involving multiple VCs/(Q)EAA coming from multiple issuers

First: this was never subject to the "old system".
Second: ANSSI introduced mERA, the modular enhanded role authenication protocol for that.

And again: take this an example, I'm not saying we have to stick to that.
Furthermore when using authenticated channels you can "just" add another datagroup containing the new/additional attribute.
We had been using this as well for quite a while. But this concept is not even well understood in Germany. BSI of course, but only rarely among the related community.

• For the revocation part, I didn’t have the courage to read all the BSI stuff, but I doubt there is a method that is completely “unlinkability safe”.

It is, you should read before making such claims. As restricted identification splits the revocation information in an ECDHE-manner on the "document signer CA"-level, the point where the relying party keys are known.
You wouldn't be able to create links between a credential and two different relying parties. However restricted identificaton is EXPLICITELY MEANT to provide pseudonymous linkability to the exact relying party the user is authencating to.

• I’m still not convinced that there is any benefits in using the authenticated channels architecture given that the actual solutions based on the BBS family provide, almost for free, better guarantees both in terms of security and privacy.

It mostly depends on secure element support and peer review and standardization of your paper as said before.

Thanks & best,
CK

Edit1 PS: regarding the BBS# / authenicated channels comparison from above. You could also use this very exact private ECDSA signer key and sign the emphemaral chosen public key for ECDHE ... so implementation properties are reduced to "securely store an ECDSA" key. ;-) And this is hopefully a point we can also agree on. Anyway thanks for discussing as well! I am sure this also helps to emphasize the key facts of your (BBS#) and BBS+ work.

[jurajsarinay]

We would be excited to continue to provide feedback on this important endeavor, and see this document as the beginning of a longer dialogue.

The authors of the feedback document are confident that anonymous signatures based on BBS are relevant to the ARF, in particular that they are practical and secure. Anonymous credentials are described as a mature technology well understood by the scientific community.

Tessaro and Zhu recently noted that analyzing the security of the (entire) credential system is non-trivial.

I am a bit confused.

$q$-SDH (and flavours thereof)

The hardness of the computational problem behind the ("provable") security of BBS remains unclear. The problem is commonly referred to as "standard". Let us recall what Koblitz & Menezes pointed out:

There is another questionable use of the word “standard” that is frequently encountered in the literature. After a complicated (interactive) problem $\mathcal{P}$ has been used in a couple of papers, subsequent papers refer to it as a standard problem. The casual reader is likely to think that something that is standard has withstood the test of time and that there's a consensus among researchers that the assumption or problem is a reasonable one to rely upon — although neither conclusion is warranted in such cases. The terminology obfuscates the fact that the new problem is highly non-standard.

One does not have to side with Koblitz & Menezes, other opinions are available. That precisely is my point. The (by all means legitimate) opinions of @alysyans et al. are not universally shared by the wider cryptography community.

(Those unfamiliar with the so-called "controversy" may look here.)

Real-world examples

DAA within TPMs as well as EPID keep popping up in discussions on anonymous credentials in the context of eID systems. There are vast numbers (hundreds of millions) of TPM chips implementing DAA or CPUs implementing EPID, both based on a variant of BBS. This fact alone is a legitimate argument in favour of deploying BBS elsewhere. It is indeed kind of "cool" that the very device I am typing this on supports such advanced cryptography in hardware. At the same time, the chips seem to simply sit there without ever being used for anything. The protocols are "deployed", but not really used.

How exactly do these protocols serve real-world users? What would the impact be, if the underlying computational problems turned out to be easy or even a way to forge DAA signatures appeared? The latter apparently happened in the past and the impact was minimal.

In most examples of DAA (or EPID), there appears to be no role in the protocols for the user of the computer. The manufacturer of the chip is typically the issuing party, "credential" holder and often even the relying party.
Revocation is almost non-existent. The very fact that despite millions of chips, only a handful of parties are involved in the system, may have facilitated deployment.

Where the technology is (to be) used in the context of Digital Restrictions Management (DRM), the user is even considered the adversary.

The experience the vendors may have made with DAA within chips may not easily transfer over to the eID setting. There will be many holders (hundreds of millions), relying parties (thousands?) and credential issuers (tens of thousands?). Revocation matters. Institutions and a legal framework are in place, neither the human users of the EUDIW nor governments are typical adversaries.

British Columbia

OrgBook BC is a (recurring) example of production use case of anonymous credentials by government. There are five issuers in total, two have never issued anything. The overwhelming majority of credentials are issued by the BC Corporate Registry. The content of every single credential appears to be public. All the holders are businesses and the credentials appear to mirror records and permits maintained and issued elsewhere (likely in "old-fashioned" ways). It is unclear what the legal force of a (forged) credential would be or even what legitimate interest a business may have to hide (parts of) their identity when interacting with business partners or customers. The OrgBook is of limited relevance.

(Engineering) complexity

The scope, scale and significance of the future EU Wallet ecosystem are unprecedented. The only thing that comes close are probably the existing electronic identites provided by the member states. Unlinkability of presentations has never really been in focus of the proposal to amend the regulation.

Most security protocols pale in comparison to the complexity of anonymous credentials based on BBS. The vast experience with relatively "straightforward" protocols (such as TLS) suggests that deploying anonymous credentials within the time frame the member states imposed on themselves would be almost impossible, even if BBS credential systems were available "off the shelf". (They are not.) The detailed technical specifications are due in less than five months.

Benefits

Any hope of unlinkability is limited by the content of the attributes one discloses to a relying party. Unlinkability can only ever make sense where the attestation of attributes does not require the identification of the user (cf. Article 5a, §16b of the regulation). Such scenarios are far and apart.

The ARF itself spells out what matters the most:

The EUDI Wallet is primarily designed to facilitate secure user identification and authentication at a high Level of Assurance (LoA) for various online services, both public and private.

Their (users') primary goals include reliably identifying themselves to services that demand user identification while maintaining control over the sharing of their personal data.

Selective disclosure as described by the current ARF is a perfectly reasonable way to achieve the primary goals.

Even with anonymous credentials, the participants within the EU Wallet ecosystem (RPs in particular) will have access to a lot of (user) information that are out of scope of the technical framework. Think of IP addresses, OS/browser versions and in particular the actual user interactions following the privacy-preserving attribute attestations. The use of all this data is and will remain heavily regulated (GDPR?).

No practical technical solutions seem to exist to enforce the privacy the users are entitled to. Within the current ARF, the fixed values of digital signatures do provide RPs with an extra correlation key (but no extra user data). With anonymous credentials, there would indeed be one fewer key available. Many will remain (even if they are "out of scope") and the next best thing is regulating their use. Anonymous credentials are by no means useless, but the benefits are rather limited.

Conclusion

The EU identity wallet should remain a Real World Crypto operation. The ARF v1.4 is reasonable. There is no immediate need to start over and replace simple & well-known cryptographic primitives (salted hashes; ECDSA) by anonymous credentials. The latter are no doubt fascinating. Within the context of the eIDAS Regulation, their limited benefits do not outweigh the security risks, the significantly higher complexity and cost. This, too, is a mere opinion of a single cryptographer. It is conceivable that the Commission reach a different conclusion.

[OBIvision]

@jurajsarinay

Within the context of the eIDAS Regulation, their limited benefits do not outweigh the security risks, the significantly higher complexity and cost.

So you just chose to ignore the regulation considering your opinion more valid than the regulator?

Unlinkability is not "limited benefits" - it is a difference between a functional market-based democracy or not. Without this, all transaction will feed centralized profiling.

[OR13]

Unlinkability is not simply a function of a cryptographic format.

Its also impacted by ecosystem properties, such as competition / concentration, and protocol support.

I would recommend considering security based on the protocol and format, and not just looking at the format by itself.

[ckahlo]

@OBIvision: I agree on the unlinkability pattern. However, for centralized profiling due to observing transactions this would imply the observer is able to see the transaction (... in clear-text or harvest-now,decrypt-later pattern as mentioned with the Y2Q link from above). This is the case e.g. for TLS-breaking company proxies.
That's why an integrated encryption pattern, such as secure channels with ephemeral keys, are useful to protect the transaction information on "ID-protocol level" (not the transport protocol such as TLS - if you want to call it that way @OR13?).

On the other hand unlinkability towards the relying party relies on the user not providing attributes or other means of information undermining unlinkability. We had these discussions a lot with restricted identification as the goal of RID was making it impossible for 2 or more relying parties to match their users using RID credentials. In past discussions with Thomas Lohninger / EDRi I explained the concept of RID for unlinkablity in existing systems as a reference. I, myself, also proposed unlinkability in past EU meetings in 2022.

It heavily depends on what you want to achieve by "unlinkability" - hiding from observers, or having "pseudonymous" (as anonymous makes it impossible) accounts at service providers.

Best,
CK

[veikkoeeva]

ECSchnorr. Please note that as no pairings are involved, the BBS# proposal is also compatible with standard curves. Here are a bit more details: o In 2.1.6, we show how to calculate the issuer signature [...]

A quick (rookie) question, if allowed, would this work with TPM 2.0?

[ckahlo]

@veikkoeeva Yes. E.g. ECSchnorr as signing scheme in the toolchains. The TCG specs also specify it.
https://github.com/tpm2-software/tpm2-tools/blob/master/man/common/alg.md

[OBIvision]

Based on the touted use cases, this is supposed to be the future of identification in the EU. It is incredibly important to get this right.

It is pretty clear that ARF is heading for BIG TIME failure - doing the exact opposite (i.e. total surveillance) of what is needed (empowerment of citizens).