eID task force meeting.

25 Feb 2016

Estimated: 16:00 to 17:00 CET.

Performed: 16:00 to 17:20 CET.

Agenda:

Start the Discussion on regarding the eID and CEF articulation. CEF eID DSI, CEF eHealth DSI
Monitor progress regarding the integration of eID Level 2 status;
Monitor progress regarding the release of eID Level 3 and plan 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:

Licinio Kustra Mano

Massimiliano Masi

Soeren Bittins

@sebastiaan van der Peil

Joao Cunha

Hugo Soares

AliceV

Meeting Notes:

Housekeeping
Short intro on the state of play of eID from eSENS, eID JASeHn
1. The technical solution that we provide here has to consider evolution of horizon 2020, timeline of CEF DSI (e;g. SMART card...)
2. This eID taskforce should have a clear mandate and how success should look like for this OpenNCP task force
How success should look like?
1. Soeren Bittinsprovides an overview of the situation
  1. we have jumped in the regulatory alignment and are at the point that in the regulator framework we don't have ?
  2. Working now on alignment with EIDAS. We need to provide components that are good enough. And some MS are using those on a voluntary basis.
  3. General technology making usable job, but we do not include end users.
2. Massimiliano Masi:
  1. We are building the basis in OpenNCP
  2. end users: making eID components as usable as possible
3. Licinio Kustra Mano summarizes the situation as following:
  1. We have worked on a technical level (level 2) and now we need to reach the upper level of the technological roadmap. But at the same time we are lacking the political alignment, policy alignment and end users.
  2. Professional identifications? Signature? Tokens? Should be keep on board those questions?
  3. Soeren Bittins: With Stork there is signature assersions... In eHealth we need something else. Example of Portugal and health professionals is given. This point should be addressed
  4. Licinio Kustra Mano In eSENS, we should we remain patient centric or do we need to go a bit deeper. eID specific framework for eHealth.
4. Alexandre Santos:
  1. Integration of eID BB in OpenNCP, what would the success look like for 2016
  2. To provide a better way for the patient to have the ability to use the eID.
  3. Cf. Berlin. We have to focus on viable use cases for the patient. From experience of implementing the actual eID levels, sometimes it is not user-friendly, and blockage on security measures not being very friendly.
  4. More focus on user experience and how it could be overcome, using a technology used by all stakeholders (clinicians, pharmacists, patients.)
  5. A proof of concept which should be possible to implement.
5. Joao Cunha: engagement of MS in the usage of the eID BB.
  1. We need to convince the countries.
    1. to inform them on the usage
    2. to have a consolidated solution for eID BB
    3. Have a very stable level 3
  2. Next level, where we would need an even more important engagement from MS. Having at least for the second half of the year, an idea how we could reach a solid solution for level 4.
6. sebastiaan van der Peil (from DIGIT) working with Alice for eID and following-up the discussions here since eHealth is user of EID BB, what the difficulties are ...
  1. Focus currently on patient area than healhcare practicians. Focus to see how to move forward.
  2. Look what the difficulties are, possibilities, from more the political level (not an architect), but can engage with colleagues for technical issues
  3. To discover we can help each others
  4. Licinio Kustra Mano asks what is the expected outcome DIGIT is looking for for this Community?
    1. First step assessing the needs for CEF eHealth DSI. And to pick asmuch as information possible and see the needs
7. Licinio Kustra Mano summarizes as following:
8. 1. From eSENS: technological solution for eID BB. From eSENS: requirements + technical + legal issues that we find. Success to have an integrated eID BB into OpenNCP
  2. Policy: looking how the tech solution may fit the policy provided by eidas and eid BB
  3. JASeHN: understanding what eSENS is doing, not necessarily what OpenNCP is doing. JASeHN is composed of MS, so whatever tech choosen this would be the way for MS engagement.
  4. From OpenNCP Community: whatever the eID requirements from eSENS we are able to demonstrate how those requirements can be integrated without breaking the specs
    1. are the only ones that can integrate EID BB in a usable solution => How can we focus? (patient centric? Other perspective?)
      1. Licinio Kustra Mano will bring this topic to the OpenNCP Steering Committee + define what should be our target for success in 2016.
e-SENS WP5.2 eID Business Levels

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: provision of authenticated attributes 2nd Step: Capability of signing the SAML assertion created by the TRC service, with the certificates of the SmartCard instead of using the NCP certificates.	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 Soeren Bittins: will release the tech artefact and	NEEDS TO START Alexandre Santos + Joao Cunha + Hugo Soares wil work on the integration.	- 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", @Alice: Will be following this up. Report on (4th and 5th February workshop: focused on the adapter from STorK 2 to eIDAS) Soeren Bittins: Prepare problem Statement.
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.	NOT STARTED	NOT STARTED	Access to Stork 2 instance (DE is not part of the system) Currently is being evaluated by a German partner access to eIDAS service in Germany. For sake of integration, can we work with a citizen from a different nationality with a Stork 2 system running. For testing purposes STorK: @Alice may point the eSENS eID for eHealth, to a test environment so that development activities can proceed.
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.	NOT STARTED	NOT STARTED	Soeren Bittins is currently studying materials that just came out recently published materials from e-SENS. Follow up in next meeting. e-SENS WP5.2] [e-SENS] mobile eID actions and plan WP6 // TF eID Integration (Soeren Bittins email from 01 Feb 2016 10:51 CET) the eID Integration TF released the following documents in: [1] https://www.jol.nrw.de/bscw/bscw.cgi/6109921 [2] http://wiki.ds.unipi.gr/display/ESENS/.MobileID+v1.2.0

-------

Next Steps:

Meetings:
1. Biweekly meeting:
  - 10 Mar 2016 16:00 CET.
ACTIONS
- Licinio Kustra Mano: Prepare and send minutes 26 Feb 2016 ;
- Licinio Kustra Mano: Bring to OpenNCP Steering Board, concerns and expectations regarding eID for eHealth DSI 26 Feb 2016 ;
- Soeren Bittins: Make available eID BB Level 3, for OpenNCP integration team to start integration work 29 Feb 2016;
- Alexandre Santos + Joao Cunha + Hugo Soares Integrate eID BB Level 3 into OpenNCP 2.4.0 Start bt 01 Mar 2016;
- Licinio Kustra Mano: Promote among Member states the participation at the IHE 2016 CAT - 11-15 April 2016 26 Feb 2016;
Events:
1. IHE 2016 CAT - 11-15 April 2016 (Bochum, Germany) http://www.ihe-europe.net/connectathon/cat-2016
  - What can be tested?
    - December: we tested the eID, but the Change Proposal was not delivered in time.
    - February: DG Sante is taking over the the CP that can be incorporate in the Specifications;
    - April:
      - eID Level 3;
      - More MS testing the eID;