eu-digital-identity-wallet / eudi-doc-architecture-and-reference-framework

The European Digital Identity Wallet
https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/
Other
431 stars 60 forks source link

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 #281

Open itsme-id-RK opened 4 months ago

itsme-id-RK commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

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 commented 4 months ago

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:

itsme-id-RK commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

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?

digeorgi commented 2 days ago

Thank you for sharing your ideas. If we try to summarize, we can identify two main ideas in your paper:

  1. The use of different (government-issued and private sector-issued) Wallets Instances for different ecosystems.
  2. The use of a 'central' eID means on the user's device, which acts as a connector between the various Wallet Instances and a Relying Party.

Regarding the first idea: this is fully compatible with the EUDI Wallet ecosystem as described in the ARF. Nothing is preventing a user from installing multiple Wallet Instances and storing each of their attestations in the Wallet Instance that is most appropriate for it. We agree that this may have many advantages. The upcoming Digital Credential API would allow 'automatic' selection of the correct Wallet Instance, depending on the request. This may correspond to your idea of a 'central eID means'.