This issue was opened according to the suggestion of Thoke Magnussen (EC DG CONNECT) mentioned at EUDIW reference implementation meeting on 2024-07-04.
Q: (aron.szabo@egroup.hu) Is supporting existing eIDAS nodes (eIDAS 1 ecosystem) to perform user authentication just a current interim(?) solution or is it planned to be a long-term supported feature in the reference implementation and in the model of eIDAS 2 (as an external user authentication service of wallet)?
A: (DG CNECT - Thoke Magnussen) That hasn't been decided yet. It was started as an interim/proof of concept to provide the LSPs and other stakeholders with a way of issuing PID that was readily available to many MS. If there is sufficient interest in maintaining this going forward then we will consider including this. Please create an issue on GitHub so we can track it.
Explanation:
The currently used eIDAS 1.0 ecosystem provides not just user authentication service but also provides access to (HSM-based and smart card-based) QES signature services, ERDS delivery service and signed PID/(Q)EAA attribute providers to the integrated public/private RP/SP entities. For that reason, if we want to adopt quickest the eIDAS 2.0 ecosystem with wallets and gain benefit of them, we should somehow use the existing eIDAS 1.0 building blocks instead of creating everything again from scratch. This is why we keep an eye on how we can improve eIDAS 1.0-based interfaces to eIDAS 2.0 interfaces. Fortunately, eIDAS 1.0-based SAML-interfaces can be easily mapped to OIDC and this can be easily further modified to support OID4VP. This means the currently used eIDAS 1.0 eIDAS nodes (citizen gateways) can act as an internal layer of EUDIWallet instances that present PID/(Q)EAA attributes to RP/SP entities on-the-fly/on-request (but of course, they can also present them to EUDIWallet instances to store them in local cache and forward them to RP/SP entities). The eIDAS 2.0 model described in ARF could support this.
This issue was opened according to the suggestion of Thoke Magnussen (EC DG CONNECT) mentioned at EUDIW reference implementation meeting on 2024-07-04.
Q: (aron.szabo@egroup.hu) Is supporting existing eIDAS nodes (eIDAS 1 ecosystem) to perform user authentication just a current interim(?) solution or is it planned to be a long-term supported feature in the reference implementation and in the model of eIDAS 2 (as an external user authentication service of wallet)? A: (DG CNECT - Thoke Magnussen) That hasn't been decided yet. It was started as an interim/proof of concept to provide the LSPs and other stakeholders with a way of issuing PID that was readily available to many MS. If there is sufficient interest in maintaining this going forward then we will consider including this. Please create an issue on GitHub so we can track it.
Explanation: The currently used eIDAS 1.0 ecosystem provides not just user authentication service but also provides access to (HSM-based and smart card-based) QES signature services, ERDS delivery service and signed PID/(Q)EAA attribute providers to the integrated public/private RP/SP entities. For that reason, if we want to adopt quickest the eIDAS 2.0 ecosystem with wallets and gain benefit of them, we should somehow use the existing eIDAS 1.0 building blocks instead of creating everything again from scratch. This is why we keep an eye on how we can improve eIDAS 1.0-based interfaces to eIDAS 2.0 interfaces. Fortunately, eIDAS 1.0-based SAML-interfaces can be easily mapped to OIDC and this can be easily further modified to support OID4VP. This means the currently used eIDAS 1.0 eIDAS nodes (citizen gateways) can act as an internal layer of EUDIWallet instances that present PID/(Q)EAA attributes to RP/SP entities on-the-fly/on-request (but of course, they can also present them to EUDIWallet instances to store them in local cache and forward them to RP/SP entities). The eIDAS 2.0 model described in ARF could support this.