20160607 - Meeting minutes, Tuesday 7th June 2016 - OpenNCP Task Force - eID.

Owned by ToméV
Last updated: Jun 09, 2016 by Soeren Bittins
6 min read

eID task force meeting.

 

Estimated: 16:00 to 17:00 CEST.

Performed: 16:00 to 17:35 CEST.

Agenda:

  1. Steering commitee messages
  2. eSENS progress level 4 and 5
  3. MS attributes
  4. CEF eID

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.
------------------------------------------------------------------------------------------------

Massimiliano Masi

Soeren Bittins

S

ToméV

Joao Cunha

michele.foucart

Meeting Notes:

OpenNCP Steering Committee notes

There were no steering commitee notes, there were no time to discuss about eID on the last meeting, but its on the agenda

eSENS progress on level 4 and 5

 

  • The architecture changed to separate each member state to favour the specific national connector. The problem is not to big,  and for for second wave is not a problem.
  • There is a new document, sent by Soeren Bittins to Licinio Kustra Mano aboun this.
  • We have eIDAS in Austria.
  • We do not have a eIDAS to test a node, we only have one and need a second.
    • AMA(Portugal) is funded for that and should provide
  • We cannot use STORK 2, we should use eIDAS (eSENS requirement).
  • There is a bugfix for level 3, but it is not yet included on the OpenNCP release.
  • João asked if we could include the sources for the jar (binaries) car signing components in the OpenNCP source: 
    • We cannot provide sources for signing, because the componente need to be legal certified. There is a need for a governance on this matter. 
    • (not discussed in TelCo, added for clarity by soeren) the eHealth eID components are comprised of a core, the OASIS DSS signature addon, and the AuthN addons LARMS and LAM. 
      • The DSS service is based on SD-DSS and has been extended to support more signatures and signature placements. Fully available as source code.
      • LARMS and LAM are fully available as source code. 
    • It is, however, currently inadvisable to publish the source code of the eID core alongside with the OpenNCP as the unchanged binary version carries a certification towards BSI TR-03124. Unintended or uncovered changes may invalidate the certification. There is a need for strict governance on this matter. The source code is naturally available through e-SENS WP 5.2.1. 

MS attributes

 

  • We have employed the legal work to have the eHealth DSI.
  • PatientIdentifier is mandatory
  • There were some misunderstandings, now they are working on professional antributtes - we have to realign.
  • How do we protect the patient identifier, without eIDAS?

 

    • WP6 has an integration taskforce for  Record matching attribute - Soeren thinks this activity will help us, the solution adopted can solve our problem with the patient identifier.

 

 CEF eID

 

  •  Replace some infrastructure by official CEF building blocks.
    • eIDAS adapter.
    • SD-DSS (Digital signature component)
    • We could benefit by adopting these components, they are already certified.

e-SENS eHealth Pilot

There is no need from the OpenNCP community point of view to do anything for the piloting on    .

Plan joint efforts towards eID Level 4 and 5 integration into openNCP.

LEVELDescriptionBB Dev STATUSOpenNCP Integration StatusOpen 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

NOTHING TO BE DONE

Joao Cunha + Hugo Soares

- 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.

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)

  • 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. 

If interested, MS need to provide the following information:

  • ....

 

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.

Next Steps:

  1. Meetings:
    1. Next meetings: At eHealth Summer Week  will send an invite
      1. Proposed agenda:
        1. Steerco messages
        2. eSENS progress level 4 and 5
          1. news on the governance of the card signing components
        3. MS attributes (progress on WP6 record matching taskforce)
        4. CEF eID
         
    2. e-SESN eHealth Pilot:   
      1. Is there anything to be prepared by the OpenNCP Community?
  2. ACTIONS