Difference between revisions of "EIDAS 2.0"

From MgmtWiki
Jump to: navigation, search
(Full Title)
(=Regulation)
 
(36 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Title==
 
==Full Title==
European Identifier Standard
+
Electronic Identification, Authentication and Trust Services (eIDAS)
  
 
==Context==
 
==Context==
 +
European Identifier Standards<ref>European Commission, ''eIDAS Regulation'' https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation</ref>
 +
 +
eIDAS (electronic IDentification, Authentication and trust Services) is an EU regulation on electronic identification and trust services for electronic transactions in the European Single Market. It was established in EU Regulation 910/2014 of 23 July 2014. All organizations delivering public digital services in an EU member state must recognize electronic identification from all EU member states from September 29, 2018.
 +
 +
European Digital Identity (EUDI)
 +
 +
* The European Digital Identity is based on a European Commission document called “European Digital Identity Architecture and Reference Framework” that has established the functional and architectural requirements for an upcoming European Digital Identity Wallet.
 +
 +
* [https://eidas.ec.europa.eu/efda/intl-pilot/#/screen/home/demo Pilot for the International Compatibility of Trust Services]
 +
* [https://eidas.ec.europa.eu/efda/home eIDAS dashboard]
 +
===eIDAS 2 defines three different legal regimes===
 +
 +
# [[EU Digital Identity Wallet]] (EUDIW) - a new, harmonized, electronic identification means
 +
# (Qualified) electronic attestations of attributes ((Q)EEAs) - expansion of the trust services market, with legal effect and access to authentic sources for attribute verification
 +
# Electronic attestations of attributes issued by or on behalf of a public sector body responsible for an authentic source (EEAPSBs) - administrative procedure-based authentic data legal cross-border legal recognition, based in fulfilling requirements equivalent to QEEAs.
 +
 +
The EUDIW will support (Q)EEAS and EEAPBS, of course.
 +
 +
But (Q)EEAs or EEAPSBs can be issued to EUDIWs or elsewhere, and according to different identity management approaches, specially federated and decentralized approaches, and data spaces as well.
 +
 +
But the eIDAS proposal does not cover federations or other sources of [[Identifier]]s and so "is not providing a full solution."<ref>Ignacio Alamillo, ''Standardization in Digital Credentials for Education Workshop'' Logalty (2023-09-21) https://www.youtube.com/watch?v=jjOd6JAEJmk</ref>
 +
 +
* [https://docs.google.com/spreadsheets/d/1acR0O0Ue_Zqw0RsHrmLclu1WaYuz2iH2VcCIg6CAO4Y/edit?gid=0#gid=0 eIDAS data attributes] 3034-08
 +
===Architecture===
 +
* [https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/tree/v1.2.0 eudi-doc-architecture-and-reference-framework]
 +
* [https://gitlab.opencode.de/bmi/eudi-wallet/eidas-2.0-architekturkonzept eIDAS 2.0 Architecture Concept - Public]
 +
* See the wiki page on [[Hardware-Enabled Security]] for details on the hybrid HSM/[[TPM]] approach to key security.
 +
===Regulation===
 +
* [https://www.european-digital-identity-regulation.com/Article_5a_(Regulation_EU_2024_1183).html Articles, European Digital Identity Regulation] 2025-02
  
 
==Problems==
 
==Problems==
[[File:EIDAS not trustworthy.jpg]]
+
Much the the slide below makes sense for many implementations, but given a good security [[Framework]], they can all be mitigated. What is unclear is whether there will be any such [[Framework]] in place prior to roll-out of eIDAS wallets.
 +
[[File:EIDAS not trustworthy.jpg|844px]]
 +
 
 +
===Comments from IIW 2023-04===
 +
from Giuseppe
 +
Working on the next release of the ARF (1.2) [Architectural Reference Framework]. Tech spec that must be adopted in the EIDAS system
 +
User stories from the Italian Delegation -- https://docs.google.com/document/d/1SLoEHBLcsPJ-TCt9iIBCCGk4CzXehFn0ijswMBPUbFY/edit
 +
References OIDC4VP, OIDC4VCI, SIOPv2, Selective disclosure JWTs
 +
Specified specs for online and offline use cases
 +
Working on the details of the trust model
 +
Also pushing OpenID Connect Federation as part of the trust model
 +
Have the wallet ecosystem leverage OpenID Connect Federation
 +
Won't use only x509
 +
Revocation list is another area that needs more specification
 +
Status-list uses JSON LD
 +
Need "official"  specs not just individual drafts
 +
x509 PKI Trusted list
 +
More interested in OpenID Federation trust chain
 +
Working with European Blockchain group for digital identity to propose an API based on OpenID Federation
 +
TLS is not sufficient for trust
 +
Italian Delegation shared doc  https://docs.google.com/document/d/1uL61cfbFsOxC9zMJV81iTTUc7ZOv_WFgLD5Ruyr_fJ8/edit#
 +
 
 +
targeting IETF for this work, Some discussion on revocation lists (status list) - Christian
 +
Tobias working on a proposal
 +
Trust Management
 +
small session at IIW
 +
an area that still needs work across the industry
 +
===Consent and Purpose===
 +
Everyone seems to agree that user consent is required before data is released to a [[Verifier]].  In spite of [https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/principles-gdpr/what-information-must-be-given-individuals-whose-data-collected_en this link] the member of the OID4VP community do not require purpose to be provided to the user (2024-12-01).
 +
====[https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52021SC0124&qid=1733159643223 IMPACT ASSESSMENT REPORT for the EUDI]====
 +
In general the "purpose" of the wallet is Identification and [[Authentication]] which are not further defined in terms of attributes. Where Authentication is defined as an Electronic process that enables the electronic identification of a natural or legal person, or the origin and integrity of data in electronic form to be confirmed.
 +
* An EU-wide trust framework for attributes and credentials linked to strong identity verification would for example be able to protect sensitive health data and facilitate its exchange across borders upon user consent.
 +
*Although the GDPR applies, data management, including activity data management, is not transparent in these situations and often the user has no other option than to consent to the disclosure of data in return for using the platform’s identification service.
 +
* A qualified trust service provider with prior user consent will access the data source and provide these credentials to the user thus allowing their exchange.
 +
*Qualified service providers would only be allowed to query specific data from national registries via standardised Application Programming Interfaces (APIs) with prior consent of and mandate from the user
 +
*The Digital Markets Act proposal, which lays down harmonised rules ensuring contestable and fair markets in the digital sector, gatekeepers shall refrain from combining personal data sourced from core platform services with personal data from any other service offered by the gatekeeper (such as identity data with other personal data) or from third party services unless the end user has been presented with the specific choice and provided consent in the sense of Regulation (EU) 2016/679 150
 +
*All measures to qualified and non-qualified trust service providers would be set out in line with the rights conferred to citizens by the GDPR, which also provide individuals the right to withdraw consent for the processing of their data and will support the implementation of the principle of privacy by design 153 .
 +
*personal data protection and privacy by design 158 (the wallet will enable convenient discretional disclosure of data and guarantee by its design that personal data is private and cannot be seen by service providers, credential providers of wallet providers unless the user consents. This supports the implementation of the GDPR requirements and helps providers manage data security risks)
 +
* The notion of minimum data set is linked to GDPR requirements and obligations. Any additional data will have to be provided only whenever needed and with the explicit consent of the user. This mean that such additional data will have to be made available at the request of the owner of the eID means.
 +
*Draft DMA regulation, Art 5 (a): “gatekeepers shall refrain from combining personal data sourced from these core platforms with personal data from any other services offered by the gatekeeper or with personal data from third-party services, and from signing in end users to other services of the gatekeeper in order to combine personal data, unless the end user has been presented with the specific choice and provided consent in the sense of Regulation (EU) 2016/679”
 +
*Allowing qualified trust service providers access to data stored in authentic sources with prior consent of the user would require the development at EU level of standardised Application Programming Interfaces (APIs) enabling integration from target public administrations across Europe
 +
* “[t]he concern of using data from profiles for different purposes through algorithms is that the data loses its original context. Repurposing of data is likely to affect a person’s informational self-determination, further reduce the control of data subjects’ over their data, thus affecting the trust in digital environments and services” 85 .
 +
* An effective enforcement of data protection rules, in particular the purpose limitation principle, needs to consider the specificities of the market segment in question and its main dominant actors. A key requirement considered for market actors in this context is ‘Keep Identity Data Separate from other personal transactional / behavioural data’
 +
* The wallet will provide unique features when compared to options 1 & 2, namely empowering the user to be in full control over which personal data are shared with whom, while the recipient service provider will be able to quickly verify the requested data, strictly limited to the purposes of that respective transaction.
 +
*Currently, the unique identifier should be “as persistent as possible “ and it can vary since it is constructed by the sending Member State in accordance with the technical specifications for the purposes of cross-border identification, with the aim of being as persistent as possible in time.
 +
* There are different trust services under eIDAS that serve different purposes: electronic signatures, electronic seals, time stamps, electronic delivery services and website authentication certificates.
  
 
==References==
 
==References==
  
 
[[Category: Regulation]]
 
[[Category: Regulation]]

Latest revision as of 16:31, 10 February 2025

Full Title

Electronic Identification, Authentication and Trust Services (eIDAS)

Context

European Identifier Standards[1]

eIDAS (electronic IDentification, Authentication and trust Services) is an EU regulation on electronic identification and trust services for electronic transactions in the European Single Market. It was established in EU Regulation 910/2014 of 23 July 2014. All organizations delivering public digital services in an EU member state must recognize electronic identification from all EU member states from September 29, 2018.

European Digital Identity (EUDI)

  • The European Digital Identity is based on a European Commission document called “European Digital Identity Architecture and Reference Framework” that has established the functional and architectural requirements for an upcoming European Digital Identity Wallet.

eIDAS 2 defines three different legal regimes

  1. EU Digital Identity Wallet (EUDIW) - a new, harmonized, electronic identification means
  2. (Qualified) electronic attestations of attributes ((Q)EEAs) - expansion of the trust services market, with legal effect and access to authentic sources for attribute verification
  3. Electronic attestations of attributes issued by or on behalf of a public sector body responsible for an authentic source (EEAPSBs) - administrative procedure-based authentic data legal cross-border legal recognition, based in fulfilling requirements equivalent to QEEAs.

The EUDIW will support (Q)EEAS and EEAPBS, of course.

But (Q)EEAs or EEAPSBs can be issued to EUDIWs or elsewhere, and according to different identity management approaches, specially federated and decentralized approaches, and data spaces as well.

But the eIDAS proposal does not cover federations or other sources of Identifiers and so "is not providing a full solution."[2]

Architecture

Regulation

Problems

Much the the slide below makes sense for many implementations, but given a good security Framework, they can all be mitigated. What is unclear is whether there will be any such Framework in place prior to roll-out of eIDAS wallets. EIDAS not trustworthy.jpg

Comments from IIW 2023-04

from Giuseppe 
Working on the next release of the ARF (1.2) [Architectural Reference Framework]. Tech spec that must be adopted in the EIDAS system 
User stories from the Italian Delegation -- https://docs.google.com/document/d/1SLoEHBLcsPJ-TCt9iIBCCGk4CzXehFn0ijswMBPUbFY/edit
References OIDC4VP, OIDC4VCI, SIOPv2, Selective disclosure JWTs
Specified specs for online and offline use cases
Working on the details of the trust model
Also pushing OpenID Connect Federation as part of the trust model
Have the wallet ecosystem leverage OpenID Connect Federation
Won't use only x509
Revocation list is another area that needs more specification
Status-list uses JSON LD
Need "official"  specs not just individual drafts
x509 PKI Trusted list
More interested in OpenID Federation trust chain
Working with European Blockchain group for digital identity to propose an API based on OpenID Federation
TLS is not sufficient for trust
Italian Delegation shared doc  https://docs.google.com/document/d/1uL61cfbFsOxC9zMJV81iTTUc7ZOv_WFgLD5Ruyr_fJ8/edit#
targeting IETF for this work, Some discussion on revocation lists (status list) - Christian
Tobias working on a proposal
Trust Management 
small session at IIW
an area that still needs work across the industry

Consent and Purpose

Everyone seems to agree that user consent is required before data is released to a Verifier. In spite of this link the member of the OID4VP community do not require purpose to be provided to the user (2024-12-01).

IMPACT ASSESSMENT REPORT for the EUDI

In general the "purpose" of the wallet is Identification and Authentication which are not further defined in terms of attributes. Where Authentication is defined as an Electronic process that enables the electronic identification of a natural or legal person, or the origin and integrity of data in electronic form to be confirmed.

  • An EU-wide trust framework for attributes and credentials linked to strong identity verification would for example be able to protect sensitive health data and facilitate its exchange across borders upon user consent.
  • Although the GDPR applies, data management, including activity data management, is not transparent in these situations and often the user has no other option than to consent to the disclosure of data in return for using the platform’s identification service.
  • A qualified trust service provider with prior user consent will access the data source and provide these credentials to the user thus allowing their exchange.
  • Qualified service providers would only be allowed to query specific data from national registries via standardised Application Programming Interfaces (APIs) with prior consent of and mandate from the user
  • The Digital Markets Act proposal, which lays down harmonised rules ensuring contestable and fair markets in the digital sector, gatekeepers shall refrain from combining personal data sourced from core platform services with personal data from any other service offered by the gatekeeper (such as identity data with other personal data) or from third party services unless the end user has been presented with the specific choice and provided consent in the sense of Regulation (EU) 2016/679 150
  • All measures to qualified and non-qualified trust service providers would be set out in line with the rights conferred to citizens by the GDPR, which also provide individuals the right to withdraw consent for the processing of their data and will support the implementation of the principle of privacy by design 153 .
  • personal data protection and privacy by design 158 (the wallet will enable convenient discretional disclosure of data and guarantee by its design that personal data is private and cannot be seen by service providers, credential providers of wallet providers unless the user consents. This supports the implementation of the GDPR requirements and helps providers manage data security risks)
  • The notion of minimum data set is linked to GDPR requirements and obligations. Any additional data will have to be provided only whenever needed and with the explicit consent of the user. This mean that such additional data will have to be made available at the request of the owner of the eID means.
  • Draft DMA regulation, Art 5 (a): “gatekeepers shall refrain from combining personal data sourced from these core platforms with personal data from any other services offered by the gatekeeper or with personal data from third-party services, and from signing in end users to other services of the gatekeeper in order to combine personal data, unless the end user has been presented with the specific choice and provided consent in the sense of Regulation (EU) 2016/679”
  • Allowing qualified trust service providers access to data stored in authentic sources with prior consent of the user would require the development at EU level of standardised Application Programming Interfaces (APIs) enabling integration from target public administrations across Europe
  • “[t]he concern of using data from profiles for different purposes through algorithms is that the data loses its original context. Repurposing of data is likely to affect a person’s informational self-determination, further reduce the control of data subjects’ over their data, thus affecting the trust in digital environments and services” 85 .
  • An effective enforcement of data protection rules, in particular the purpose limitation principle, needs to consider the specificities of the market segment in question and its main dominant actors. A key requirement considered for market actors in this context is ‘Keep Identity Data Separate from other personal transactional / behavioural data’
  • The wallet will provide unique features when compared to options 1 & 2, namely empowering the user to be in full control over which personal data are shared with whom, while the recipient service provider will be able to quickly verify the requested data, strictly limited to the purposes of that respective transaction.
  • Currently, the unique identifier should be “as persistent as possible “ and it can vary since it is constructed by the sending Member State in accordance with the technical specifications for the purposes of cross-border identification, with the aim of being as persistent as possible in time.
  • There are different trust services under eIDAS that serve different purposes: electronic signatures, electronic seals, time stamps, electronic delivery services and website authentication certificates.

References

  1. European Commission, eIDAS Regulation https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation
  2. Ignacio Alamillo, Standardization in Digital Credentials for Education Workshop Logalty (2023-09-21) https://www.youtube.com/watch?v=jjOd6JAEJmk