Weak eID means activation #589
Description
I see several issues in the enrolment phase as specified in ARF v2.4.0 for example under Section 6.6.2.6:
However, in fact no additional step is needed in the issuance process to ensure [activation of the Wallet Unit as an eID means as required in (EU) 2015/1502]. This is because the User always starts the issuance process from the Wallet Unit into which they want the PID Provider to issue the new PID. The PID Provider sets up a secure communication channel towards this Wallet Unit, using the flow specified in OpenID4VCI.
Additionally, the User uses an eID means on LoA High to authenticate towards the PID Provider. This process ensures that the new PID can only end up on the device used by the subject of the PID.
This approach assumes that the operational Wallet Unit is under control of the same person as the person who authenticates towards the PID Provider. For LoA High, this is very weak verification “that the electronic identification means was delivered only into the possession of the person to whom it belongs”, as required in (EU) 2015/1502. For example, Eve could apply for a Wallet Unit as an app on her own phone, and convince Alice to authenticate towards the PID Provider upon the app’s request. The non-EUDIW eID means that Alice uses may insufficiently warn her about the far-reaching consequences of this action.
Stronger would be for example if the Wallet Provider verifies the identity of the applicant to which it delivers the operational Wallet Unit, and records an identifier in that Wallet Unit, so that the user can activate it once that identifier is confirmed to match the PID. The WSCA could implement this activation mechanism so that the Wallet Provider does not need to record the identifier centrally.
Secondly, Section 6.6.2.6 fails to consider the common case where the user has no applicable eID means yet.
To address this case, the app could implement next to the Wallet Instance a means to perform identity proofing and verification, either locally or remotely. For example, this means could consist of an eMRTD reader and biometric verification module. In this example, the Wallet Provider and/or PID Provider apply this means for remote identity verification and activation.
As an extension to this example, possibly the organisation acting as Wallet Provider issues another eID means using the same app. Then the PID Provider can rely on that to meet its requirements. In this extension, the Wallet Unit has a second way of performing activation: it can verify whether the EUDIW PID matches the PID in the other eID means.
Do you agree that the issue of activation is insufficiently addressed in ARF v2.4.0, in particular when the user has no applicable other eID yet?
To validate the presented example solutions, do you consider these compatible with the ARF? To summarise the examples:
- WSCA activation using applicant–PID matching
- WP and PIDP use WI app for identity proofing and verification
- WP issues eID, PIDP relies on eID for PID issuance