mutual authentication

[paolo-de-rosa]

Under the new eIDAS regulation (EU Digital Identity Wallet), there is a mandate for mutual authentication between the Relying Party instance and the Wallet Instance during each attestation (credential) presentation. In this context, what is your perspective on the impact of mutual authentication on the API? Should this process occur at the transport layer or at the application layer, involving an exchange of a specific attestation (credential)?

[timcappalli]

@paolo-de-rosa just to help with discussion, can you provide a deep link to that specific section of the regulation?

[ve7jtb]

I agree that the wallet needs to identify the verifier so that it can apply the correct policy around attribute disclosure or even returning a credential at all.

I think the main line EU thinking is that Verifiers will need to get a certificate that they present, possibly via TLS that attests they are trusted to receive PID information. I think the assumption in this case is that the verifier and wallet have a direct connection. In my opinion that is the worst model for scalability.

The better option would be to provide that certificate as a parameter and the API validate the origin and pass the verified origin to the wallet where it could compare them and if the origin matches the certificate use it for encrypting the response.

The model I prefer is that the wallet only needs the verified origin. From that it can find the meta-data for the verifier and get appropriate encryption keys. It can also retrieve any x509 certificates or other trust marks the verifier has,.

I prefer the latter approach as the verifier doesn't need to know the nationality of the individual or the wallet. It can make a simple request for a PID and the wallet can then retrieve metadata for the verifier and get the correct trust info to assure itself.

Having the verifier try and identify itself on the request without knowing the wallet is madness in my opinion. It would require the API to get challenges from all wallets and then send them to the Verifier for signing with each trust certificate the verifier has and then sending the signed challenges and certificates in the credential request.

We will have to deal with the matches not being able to get metadata unless it is cached somehow. That will leave the possibility that a matcher will say Yes I have a PID, invoke the Estonian wallet, and then the wallet rejects the request because the verifier in Argentina doesn't have a QWAC (https://www.europarl.europa.eu/RegData/etudes/ATAG/2023/739285/EPRS_ATA(2023)739285_EN.pdf)

So in reverse order of preference:
1: QWAC certificates or equivalent at the TLS layer.
2: QWAC certificate or equivalent at the application layer for encryption. (Note the key may not be appropriate for encryption)
3: Verified origin and the Wallet looks up meta-data to determine encryption keys and other client info such as trust memberships.

[timcappalli]

Related: #46

[paolo-de-rosa]

@paolo-de-rosa just to help with discussion, can you provide a deep link to that specific section of the regulation?

The agreed draft of the regulation has been published here and the relevant articles for the discussion should be the following:

• Article 6a 4a. European Digital Identity Wallets shall, in particular (…)
  • (4c) for interaction with another person’s European Digital Identity Wallet for the purpose of receiving, validating and sharing identity data and electronic attestations of attributes in a secured way between two wallets;
  • (4d) for authenticating relying parties by implementing authentication mechanisms in accordance with Article 6b;
  • (4e) for relying parties to verify the authenticity and validity of European Digital Identity Wallets;
• Article 6a. 5a. Member States shall provide free of charge validation mechanisms to (…) ensure that the authenticity and validity of European Digital Identity Wallets can be verified.
• Article 4a. 5a. Member States shall provide means to revoke the validity of the European Digital Identity Wallet
  (a) upon the explicit request of the user;
  (b)when its security has been compromised;
  (c) upon the death of the user or cease of activity of the legal person

[bc-pi]

The model I prefer is that the wallet only needs the verified origin.

This likewise seems like the appropriate level/amount of authentication information for a web API to be conveying.

[Willewragtag]

@paolo-de-rosa , you wrote:

Under the new eIDAS regulation (EU Digital Identity Wallet), there is a mandate for mutual authentication between the Relying Party instance and the Wallet Instance during each attestation (credential) presentation.

Looking at the latest draft of the regulation, I see:

Article 6a
4. European Digital Identity Wallets shall, in particular:
(a) support common protocols and interfaces:
...(4d) for authenticating relying parties by implementing authentication
mechanisms in accordance with Article 6b;

Are there more requirements beyond these? The above appear to say that a wallet must support the authentication of a relying party, which is different from saying that the wallet must authenticate the relying party.

I am asking since a world where an mDL in an European wallet can only be shared with relying parties that are approved by an EU body bodes ill for the international use of your driving licence. I find it unlikely that all entities that consume European driving licences today (think road traffic enforcement officers world-wide) will register with an EU body. And if other issuers of driving licences were to institute similar requirements, it means that all relying parties in the world would have to register with all issuers (or groups of issuers) in the world - clearly not a very attractive proposition.

[jogu]

The current thinking in the DCP working group is that this (if it continues to be needed) can potentially be solved at the OpenID4VP level without needing any changes to the Browser API; there's an issue discussing this here:

openid/OpenID4VP#141

[paolo-de-rosa]

The requirement for mutual authentication stems from mandates outlined in the amended EU Regulation No 910/2014 as regards establishing the European Digital Identity Framework.
The key provisions are summarized as follows:

1. Article 5a, 5(a) (vii): "European Digital Identity Wallets shall, in particular: ... support common protocols and interfaces: ...
   for authenticating and identifying relying parties by implementing authentication mechanisms in accordance with Article 5b;"
2. Article 5a, 5(a) (viii): "European Digital Identity Wallets shall, in particular: ... support common protocols and interfaces: ...
   for relying parties to verify the authenticity and validity of European Digital Identity Wallets;"
3. Article 5a, 8 (a): "Member States shall provide validation mechanisms free-of-charge, in order to: ensure that the authenticity and validity of European Digital Identity Wallets can be verified;"
4. Article 5a, 8 (b): "Member States shall provide validation mechanisms free-of-charge, in order to:
   allow users to verify the authenticity and validity of the identity of relying parties registered in accordance with Article 5b."
5. Article 5a, 9 (a,b,c):  Member States shall ensure that the validity of the European Digital Identity Wallet can be revoked in the following circumstances: (a) upon the explicit request of the user; (b) where the security of the The key provisions are summarized as follows: has been compromised; (c) upon the death of the user or cease of activity of the legal person.

Points 1 and 4 focus on identifying and authenticating relying parties registered within the EU Digital Identity Framework.
Given this, it appears necessary to authenticate the OpenID for Verifiable Presentations (OID4VP) requests from relying parties (RPs). Simply authenticating the origin of these requests may not be sufficient.

Points 2 and 3 emphasize the need for interfaces and protocols that enable the relying parties to verify the authenticity and validity of the "European Digital Identity Wallet." It remains ambiguous whether this refers to the wallet as a solution or as an individual instance.
Point 5 makes clear that the co-legislators intend for the revocation of individual wallet instances under three specific circumstances and not necessary the whole Wallet Solution.

Given the points 2,3,5 it might be necessary to have a Wallet Instance Attestation that once presented to the relying party could be used to verify authenticity and validity of the Wallet Instance and also to revoke the Wallet Instance. Obviously privacy considerations need to be made but for now, I am personally open to accepting a threat model that assumes issuers do not collude with relying parties (RPs), and that RPs do not collude with each other, given that there are sufficient checks and balances in place to make such abuses unlikely.

I believe implementing these changes at the level of OID4VP should not impact the API. However, I'm eager to hear if there are any differing opinions on this matter.

[timcappalli]

Raw notes from 2024-05-15 call: https://github.com/WICG/digital-credentials/wiki/2024-05-15-Meeting-Notes#mutual-authentication

AI generated summary of the 2024-05-15 call notes on this topic:

• Hicham and Lee express concerns about adding wallet instance authentication at the top level of the API, citing it as a potential privacy leak and a source of unnecessary complexity. They suggest that this feature should be built as part of the issuance process, not added as another cryptographic mechanism.
• Manu agrees with Hicham and Lee, emphasizing that adding this feature could lead to privacy leaks and misguided legislation.
• Lee further questions the practicality of having Relying Parties (RPs) deal with credentials that are valid but come from unapproved wallets.
• When Heather asks about the appropriate layer for this feature, Lee and Joseph suggest it should be at the issuance or credential format level.
• Clecio raises questions about the problem this feature is intended to solve and emphasizes the importance of maintaining the integrity of identity throughout the whole flow.
• Lee clarifies that the current API does not cover issuance yet.

In conclusion, the group seems to agree that wallet instance authentication should not be handled at the API level.

[hlozi]

Beyond legislation, to ensure that we are considering the proper security goals, we need to understand the security problem that the legislation is expecting to be mitigated.
We also need to explore why this cannot be solved as part of issuance. Solving this as part of the presentation requires us to ensure that the wallet authentication mechanism does not introduce any privacy problems on its own (e.g. tracking based on the wallet authentication information).

[timcappalli]

2024-07-29 call: agreed with conclusion, closing issue.