Current ARF is not flexible and too monolithic for a successful experience and rollout - proposal for a component based certification scheme leveraging on what was already built under eiDASv1

[itsme-id-RK]

Description

The current ARF only provides a static, monolithic approach which hinders a successful rollout, a good UX for as well the end user, the relying parties as the wallets themselves.

The issues are described in the document attached as well as an alternative proposal to go for a component based approach leveraging on assets that were already built under eIDASv1 and working with a component based certification scheme. The proposal also improves on the privacy and security concerns posed by many on the monolithic wallet approach. 240621_eIDAS IA ARF recommendations_itsme.pdf

Dependencies

We recommend to integrate this in a revised ARF as well as in the Implementing Acts.

[ad-Orange]

The proposal also improves on the privacy and security concerns

Hello, can you provide more details on how your proposal would improve anything in terms of privacy ?

Thanks

[itsme-id-RK]

The proposal also improves on the privacy and security concerns

Hello, can you provide more details on how your proposal would improve anything in terms of privacy ?

Thanks

• Wallets do not know who the Relying Party is. Especially in the private sector this prevents market disruption between competitors (e.g.Bank A provides credit card info in their wallet, Bank B = relying party)
• The eIDMeans uses pair wise identifiers for each connection, making it not possible for any party to connect data with each other
• The eIDMeans doesn't store any data (which remains at the authentic source or the wallet in its own eco system that manages the lifecycle of the data and all the regulation that goes with it), but only provides a safe and easy transfer mechanism towards the market = Relying Parties
• The relying party doesn't need to know which wallets or data sources the end user is connected to. They only need to know the data they get is trustworthy.
• In this setup, nobody has all the data and the end user chooses freely which (trusted) wallets or sources he/she wants to use.
• eIDMeans already have in place data minimisation principles for ID and transaction data since the launch of eIDAS v1, only providing the necessary claims to the Relying Party for the particular use case. In fact for authentication and some other claims (e.g. age), no real data is needed. Only a pairwise identifier that is only existing between the end user and that particular relying party and the claim could be just a yes/no.

In terms of security, eIDmeans today (at least some) are already providing contextual security data which allows relying parties (e.g. gov, banks, ...) to use that metadata in their risk engines for transactions risk scoring and treatment.

[ad-Orange]

It's very difficult to draw conclusions on such a succinct description of things with no technical details. I won't go into the analysis of everything (which would be warranted for such a radical departure from the usual issuer/holder/verifier model) but looking just at privacy in everything you're mentioning:

• What you call the "e-ID mean" looks an awful lot like a centralized system in a federated setup
• I didn't see anything that would make me think that your proposal is advancing the state of the art for privacy
• On the contrary, I have the impression that this centralized system makes it way worse that even the current ARF 1.4 proposal

[itsme-id-RK]

The proposal does not describe a centralised system at all. On the contrary, the data remains at the authentic source. The authentic source does not know who the requesting relying party is. The eIDMeans doesn't store or see any of the data but only foresees a secure transfer protocol. Only the end user is able to see the data with his own personal secret which is not known by any party, including the eID means.

[ad-Orange]

I believe you but there is no magic and I don’t believe that full unlinkability can be achieved with simple architectural means like the ones you’re describing, much less everlasting privacy. The devil is in the details and there are not enough details here to get a proper understanding of what would make all this fully unlinkable without resorting to “trust” in a particular entity.

[baronsz]

Probably, here is the point where I can ask some clarification in connection with the authentication requirements of communicating parties. The reason for this is that eIDAS 2.0 ARF describes strict requirements on how signed requests have to be used (and it is also in line with eIDAS 1.0 requirements) however, proposed OID-based protocols does not mandate such things.

Based on currently proposed OID4VCI draft 13 and OID4VP draft 20 of eIDAS 2.0, it seems that

• wallets do not know who the requester Relying Party is and
• authentic sources, PID/(Q)EAA providers do not know who the requester wallet is because there is no REQUIRED signature layer on request messages.

In OID4VCI draft 13 (eIDAS 2.0): The Request Object as signed JWT is not available before the "End-User Authentication / Consent" step. The signature layer on "5.1. Authorization Request" message (of Authorization Endpoint) is neither REQUIRED, nor OPTIONAL.

In OID4VP draft 20 (eIDAS 2.0): The Request Object as signed JWT may be available before the "User Authentication / Consent" step. The signature layer on "5. Authorization Request" message (of Authorization Endpoint) is not REQUIRED, just OPTIONAL.

In eIDAS SAML Message Format v1.4 (eIDAS 1.0): "SAML AuthnRequest messages MUST be signed according to [eIDAS-Interop-Architecture]."

In ARF v1.4 (eIDAS 2.0): "Relying Party Authentication: Before sharing attributes, the Wallet Instance must verify the Relying Party, and conversely, the Relying Party might authenticate the Wallet Instance. This can involve dynamic or static exchange of keys and metadata. [..] Relying Parties are registered by a Relying Party Registrar in their Member State. [..] As a result of successful registration, a Relying Party Access Certificate Authority (CA) issues one or more access certificates to the Relying Party. A Relying Party Instance needs such a certificate to authenticate itself towards Wallet Instances when requesting the presentation of attributes [..]". "[..] a Wallet Provider, during activation of a Wallet Instance, issues a Wallet Trust Evidence (WTE) to the Wallet Instance. When the Wallet Instance sends a request for a PID or an attestation to a PID Provider or to an Attestation Provider, it includes the WTE in the request. The PID Provider or Attestation Provider verifies the signature over the WTE, using the Wallet Provider trust anchor obtained from the Trusted List. Next, the PID Provider or Attestation Provider verifies that the Wallet Instance possesses the private key belonging to the public key in the WTE. This proves that the Wallet Instance is authentic and is provided by a trusted Wallet Provider."

So, is it planned to modify OID4VCI and OID4VP in next draft (final?) version to mandate using signature layer also in request messages?