20160524 - Meeting minutes, Tuesday 24th May 2016 - OpenNCP Task Force - eID.
eID task force meeting.
Estimated: 16:00 to 17:00 CEST.
Performed: 16:00 to 17:25 CEST.
Agenda:
- OpenNCP Steering Committee notes
eID Universe Expansion
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:
Tomé
Klara Jirakova
OpenNCP Steering Committee notes
Composed by SANTE (Markus), 1 external partner from industry (Soeren) + 1 JASeHN (Licinio replaced by?)
How OpenNCP will present itself to MS, scope? (how large?: eHDSI Community, OpenNCP Community, reference implementation?)
This task force has worked on integration of eID levels 1, 2 and 3. What is the mandate and definition of tasks (definition of mandate, success factors...) for this task force?
Meetings discussing on:
- What is missing?
- What is to be done for levels 4 and 5 (which are not yet specified).
We should not only be implementers but we should also raise our voice. Today we are struggling with our vision of what is next to do?
eID Universe Expansion
- eHOMB
- Feasibility Study (from Deloitte) (available probably by )
- How far will this study put pressure on the work of this task force?
- No one fits all solution, no idea if the study will put pressure?
- How far the study would be? Focus on CEF eID building block, part of the study was to understand who is who, work done after eSENS workshop in Brussels to coordinate on the implications. DIGIT recommendation to SANTE: several options are available, MS are welcome to come with their options
- Study will be available from the 30th June (intermediary version available beginning of June)
- No one fits all solution, no idea if the study will put pressure?
- What other points should we follow-up, what should we look upon?
- eSENS component and specs are to be considered as recommendations. No guarantee, nor obligation. We're a project, downstream activities.
- We need to provide the best OpenNCP reference implementation ever
- From eSENS, providing recommendations. It leaves a huge gap (legal requirements, security...) + timeline towards eHealth DSI
- eHDSI has a need to have something operation ready
- Proposition that OpenNCP Steerco should raise the voice to fill the gaps and communicate strongly with other stakeholders to make the OpenNCP a success.
- eSENS handover sustainability? End eSENS in March 2017, developments may end this summer, no support anymore... the only entity to ensure continuity activity is OpenNCP.
- To be scaled to the Steering board.
- Piloted this summer and then handover
- how far are we going towards EIDAS? It cannot deviate. eHealth is the only domain that has eID token leveraged on qualified material but not notified. Only PT, IT and AU have merged their cards
- Level 4 and 5: EIDAS nodes defined. For level 3 we could use them.
- eSENS component and specs are to be considered as recommendations. No guarantee, nor obligation. We're a project, downstream activities.
- eIDAS
- Legal Regulation
- Relevant aspects to OpenNCP integration?
- Are being dealt in eSENS => Zoi
- Relevant aspects to OpenNCP integration?
- Specification
- Relevant aspects to OpenNCP integration?
- Public space available on Joinup
- Waiting for sector specific attributes
- Topics to be raised at the Steering Committee:
- Should we (OpenNCP Community) reinforce eSENSE request for these attributes?
- and recommend JASeHN to communicate these attributes ASAP to the eID governance otherwise we may loose the opportunity window for he specifications
- How far and how much do we want OpenNCP engagement in the eID topic and eSENSE revamp in the following couple of months?
- Should we (OpenNCP Community) reinforce eSENSE request for these attributes?
- Need to empower OpenNCP to develop further level 4 and 5
- There will be recommendations from different domains
- Public space available on Joinup
- Relevant aspects to OpenNCP integration?
- Legal Regulation
- eSENS
- eHealth Pilot (WP5.2 timeline extension has been approved, the project will run until March 2017)
- Scope:
- eID BB
- Non-repudiation BB:
- SMP/SML BB:
- JAseHN
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) | 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 meetings: 16:00 to 17:00 CEST. +
- Most probably lead by @Tome since Licinio Kustra Mano will be on holidays (leaving SPMS on the )
- Proposed agenda:
- steerco messages
- eSENS progress level 4 and 5
- MS attributes
- CEF eID
- e-SESN eHealth Pilot:
- Is there anything to be prepared by the OpenNCP Community?
- Next meetings: 16:00 to 17:00 CEST. +
- ACTIONS