20160310 - Meeting minutes, Thursday 10th March 2016 - OpenNCP Task Force - eID.
eID task force meeting.
Estimated: 16:00 to 17:00 CET.
Performed:
Agenda:
House Keeping
Bring feedback on the Steering Board position on the global strategy for eID here at the OpenNCP Community;
Monitor the progress towards the integration of eID Level 3;
- Plan joint effort towards IHE CAT on the 11th and 15th of April.
- 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:
@Aleksandra Malecka
----Invited---
@sebastiaan van der Peil
House Keeping
Last meeting actions follow up
Bring feedback on the Steering Board position on the global strategy for eID here at the OpenNCP Community;
- 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:
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 |
|
-------
-------
Level 3:
- Scope: validation of patient signature in TRCA
- 2 steps:
- #1) validate signature in country-B
- Who signs the assertion:
- a) LAM+
- b) NCP-B
- Who checks the match between the citizen signing and the citizen present in the assertion
- Who signs the assertion:
- #2) validate signature in country-A (as a double-check)
- validate linkage between patient and certificate in country-A (e.g., avoid a TRCA from patient Massi to be validated when signed by a certificate from Marcello)
- #1) validate signature in country-B
- Integration of level 3 into the Portal (country-B) is already done (and was tested in EXPANDathon). The component is able to perform validation of signature in country-B.
- Currently the validation is performed against FH server and not against the national authority that issued the certificate.
- For operation readiness, MS must provide their national validation servers to be configured on LAM+ component
- This does not impact IHE tests
- MS should provide certificate validation servers
- For operation readiness, MS must provide their national validation servers to be configured on LAM+ component
- #2) validate signature in country-A
Validation of second step should, ideally, be done by means of the Access Control component to be developed in the scope of the National Connector developments (for which a change proposal is being prepared). Since the National Connector is a country-specific component, there's nothing to change or integrate in the OpenNCP, this is a country-A national concern.
Second step will not be tested at IHE Connectathon in Bochum (no schematrons have been developed). All the other things of eID level 3 will be tested.- michele.foucart Schedule meeting with IHE to confirm test tools preparation regarding eID 10:00 CET
Level 4: 30th and 31th of March a meeting from e-SENS IOP Team will take place, and it is expected that new specs will be provided allowing the start of adoption for eHealth;
- Soeren Bittins: provide clarifications about inputs MS are required to provide to proceed with level 4 implementation
Level 5: there are already mobile app prototypes that can be use to implement the scenario, but no e-SENS 5.2.1 MS manifested interest in piloting it.
- Start by e-SENS MS and then enlarge the group to OpenNCP Community MS.
- Soeren Bittins: provide clarifications about inputs MS are required to provide to proceed with level 5 implementation
Licinio Kustra Mano: e-SENS MS meeting: Goals: know the status of piloting and obtain feedback about mobile eID
- Joao Cunha: verify with e-SENS if there's any inconvenience on scheduling the meeting for the 16th
Licinio Kustra Mano: Level 5 eID - will be the have special attention in the next meeting.
- Biweekly meeting:
- 16:00 CET.
- Biweekly meeting:
- ACTIONS
- Licinio Kustra Mano: Prepare and send minutes ;
- Licinio Kustra Mano: Prepare and send minutes ;
- Other actions have been identified in the minutes above
- 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;
- What can be tested?