eID task force meeting.
Estimated: 16:00 to 17:00 CEST.
Performed: 16:05 to 17:02 CEST
Agenda:
Debrief from eHOMB, e-SENS eID, Health pilot F2F meetings;
- Plan joint efforts towards eID Level 4 and 5 integration into openNCP.
- Next Steps
Location:
- AdobeConnect:
http://ec-wacs.adobeconnect.com/openncp/
Room Passcode: Ask if necessary michele.foucart or markus.kalio
------------------------------------------------------------------------------------------------
If you have never attended an Adobe Connect meeting before:
Test your connection: http://ec-wacs.adobeconnect.com/common/help/en/support/meeting_test.htm
Get a quick overview: http://www.adobe.com/products/adobeconnect.html
Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.
------------------------------------------------------------------------------------------------
Participants:
Debrief from eHOMB, e-SENS eID and Health pilot F2F meetings
- eHOMB meeting
- eSENS/JASeHn eID focus meeting eHealth face 2 face
- eHMSEG
Update on how things are going from a vision point of view and start to have the visibility on the other initiatives, especially eID study conducted by DIGIT (conclusion end of June, beginning of July).
The eID study was presented to the MS at the eHMSEG which are now aware.
DIGIT emphasised that they are alligning with the other ongoing initiatives.
CZ Republic was very interested on this topic, from a National point of view, recomment to go to the eSENS/eHealth eID group.
Briefing regarding the meeting 27/4
CEF team represented by Alice and Sebastiaan.
ERN stakeholders were also present (rare disease networks accross MS).
Approch the most important issues: legal issues EIDAS regulation. Alignment of eHealth eID and EIDAS. In EHealth, linkage with the electronic identity. Reference to another id than patient id. Patient id needs to be safeguarded by eHealth, ensure link between patient id and patient is correct.
Authentication/identification: we need to define minimum data set to identify/authent. For eID, not for immediate interest, but will be important in the future to align eID OpenNCP and NCPs.
We'll probably get pressure regarding eID not only to patient identification but also from health professionals. Best usage possible of eID component provided by eSENS (not only providing the tech but technology aligned with the regulation).
Marcello Melgara heard at the occasion of WP6 of eSENS on eID that 27th April was a deadline for providing technical input of eHealth elements to EIDAS framework.
Need clarity on actors, timing and roadmap?
DIGIT does not share this impression, this message did not come from DIGIT/Deloitte. Additional requirements towards infrastructure and those were taken into account.
It comes from the eID DSI expert group meeting where it was decided to leave the freedom to the different domains regarding sector specific attributes. EIDAS technical subgroup only give their opinion.
No additional level of assurance towards eHealth, rather a mapping.
From the legal analysis made by eSENS, there was an attribute (patient identifier) that is domain specific but which requires same protection as EIDAS attribute. Soeren Bittins brought this requirement to JASeHN. Alice refers to EIDAS reglementation: any sector specific attribute will not be bind to the CEF regulation. AliceV will ask the question directly to the EIDAS task force.
eSENS meeting on 20th April:
- How to demonstrate what we have "eID pilot in eHealth": simulate encounter where we can show interactions between 2, 3 MS
- How to ensure that the levels 4 and 5 are compliant to eIDAS regulation
- Agreed: in 1 months H2 implement level 4 and level 5
- Also agreed that non technical audience (policy), what are soft recommendations to fill the gaps. Will be distributed to WP 5.2 (High level policy scenario)
End of the year: objective is to have something very good to deploy on MS. We need to integrate eID before the end of the year and align with the last OpenNCP release.
Reference to level 4 and 5: Soeren outlined possible sequences for implementating level 5 (including level 4). 3 countries have identifiers that are aligned with EIDAS identifier (IT, PT, AT). Concern, those countries do not need additional help. With the new, it will ease the work for them too. For other Members, it will be an enabler (e.g. Germany). The political message received it to concentrate on providing a solution for the 3 countries piloting, for assuring success => Conflict of interest. Topic to be discussed in Steerco to look for a better way to find a solution.
Other issues on level 4 and 5: erosion of capacity in the team (Alexandre already left, Licinio will...), Italy decided to stay at the level they are... Level 4 and 5 with a very limited team. Should we do a sanity check to see what are the tought of the other countries, not only focussing on the 3 countries.
Need to bring in some further knowledge. No answer. Issue on skills and people working on this integration. It is not enough to have technicians but also policy people + people able to translate technical topics to policy people. Which is relevant to OpenNCP too. Need someone to liaise with policy makers.
2 diagrams have already been prepared by Soeren, but before we share it to a large group, Speren would like to have first feedback of the internal team (IT and PT).
Effort on the go to acheive level 4 and 5. At the same time lacking resources and skills.
Impact if we do not have velocity to implement: We need to be represented in the relevant forums. How could we incluse this topic into JASeHN agenda. There is a need of clear direction.
Licinion will look for alternative source of funcing to capacitate the OpenCP team to work on eID scheme.
Plan joint efforts towards eID Level 4 and 5 integration into openNCP.
| LEVEL | Description | BB Dev STATUS | OpenNCP Integration Status | Open Issues |
|---|---|---|---|---|
| Level 0 – manual input of ID – traditional epSOS | This is the most basic level of identification. It only requires the Health Professional to identify the patient by requesting his/her ID, and enter it manually in the system. This is the approach used in the epSOS pilot. The main advantage of this level is in an emergency setting where no other method of identification and authentication is available. | NONE | DONE | NONE |
| Level 1 – Passive read of eID token – e-SENS LARMS | This level requires the existence of an eID token, usually this token is a smart card. The token has identification attributes that can be publicly read. In the eSENS project the asset used provide this level is the e-SENS Local Attribute Mapping and Retrieval Service (LARMS). This level is safer than the previous, because of the input of the identification is automatic and not manual. | DONE | DONE | NONE |
| Level 2 – Localy signed eID with token – e-SENS LAM | This level also requires the existence of an eID token, as the previous on, but this token has to be capable of patient authentication, usually by entering a PIN code. In the eSENS project the asset used provide this level is e-SENS Local Authentication Module (e-SENS LAM) with the Digital Signature Add-On (DSig). Signing of a patient consent is made possible with the introduction of this level. This level is safer than the previous, because the introduction of the identification attributes is authenticated by the patient. In this level, as well in the previous ones, a network connection is not needed. The inexistence of a network connection, and thus the connectivity to a PKI (Public Key Infrastructure) to validate this authentication is a liability, which, however, can be mitigated by the signature and certificate validation performed through the ACS in country-A. Consequently, it is possible to issue a mismatched data disclosure request (e.g. signing with a certificate of someone else) or using an irregular certificate (e. g. suspended) in country-B but it should not be able to successfully pass ACS inspection in A. | DONE (maintenance) | DONE 1st Step:
2nd Step:
| Issues identified on: --- https://openncp.atlassian.net/projects/EID/issues/EID-1?filter=allopenissues Licinio Kustra Mano: decision was taken regarding including eID Level 2 on the OpenNCP 2.4.0. -- So far this is the best ever released version of OpenNCP; |
| Level 3 – Localy signed eID with realtime validation – LAM+ | This level has the same functionality of the previous, but with the availability of a network connection and connectivity to the required PKI infrastructures. This level mitigates the liability introduced in the previous level. So the validation of the authentication of identification and patient consents is possible.- Full advantage of having access to Country A to validate the identification and signature of certificates. | DONE
| NOTHING TO BE DONE | - Codification of attributes, with STorK and eIDAS there is a limitation on the attributes can be coded (Doctor name), that causes loss of semantic on the exchange of the information. - Wow can the eIDAS token support this requirements? "http://www.futureid.eu/attributes/common/cardIssuerCountry":"it", "http://www.futureid.eu/attributes/cardType":"it-cns", "http://www.futureid.eu/attributes/common/healthInsuranceId":{"urn:oid:1.2.3.4.5.6.7.8.9":"030225BM526"}, "http://www.stork.gov.eu/1.0/surname":"INCONTATTOZERO",
|
| Level 4 – Distributed Cross-Border Authentication (DCA) | This level introduces the e-SENS Authentication Broker, that is leveraged by the STORK 2.0/ eIDAS infrastructure. All authentication and authorisation activities are fulfilled outside of the local environment based on an initial authentication information acquired locally from an eID token. If interested, MS need to provide the following information:
| NOT STARTED | NOT STARTED | Access to Stork 2 instance (DE is not part of the system)
For sake of integration, can we work with a citizen from a different nationality with a Stork 2 system running.
|
Level 5 – Virtual eID (mobile eID)DONE | This level leverages the previous by giving the possibility of authentication and authorisation on without the need of a physical eID token, just using a mobile app a smartphone with a virtual token, specifically developed for this. If interested, MS need to provide the following information:
| NOT STARTED | NOT STARTED |
|
Next Steps:
- Next meeting:
- 16:00 to 17:00 CEST.
- Update on legal issue + eID DIGIT report
- Next meeting:
- ACTIONS
- Licinio Kustra Mano will following the funding alternative to work done in eSENS.
- Would it be possible to take into consideration was Austria and PT has done regarding use case 5.5? Soeren Bittins will send the document to michele.foucart