Housekeeping (Michèle)

eHOMB

1. Decisions

2. Approval to start a task force on terminology server FH Dortmund
   
   

   1. Main activities: test the stability of the server, perform a GAP analysis highlighting the changes that have to be done on the server side, analyse the integration with OpenNCP, upload the MVC for 2 different MS and introduce it in the server (we've asked 2 experts from the Member States), testing

   2. Final decision on the choice of terminology server (open source or open a call) will be taken in June 2016, based on this study.

3. Decision to delegate work to the OpenNCP Community

4. Next eHOMB (to be confirmed) on Feb 17, 2016 ; MS expert group Feb 4, 2016
   
   
   

Task forces

1. eID - We should receive input from eSENS

2. Release management - meeting postponed to this afternoon. In principle, no major change are foreseen to the current release management process, except in term of user administration to ensure that EC is the guarant of the releases.

3. Terminology server: Kick off meeting on 20/01 with participants from Dortmund. Discussions on release management with regards to the terminology server. EC will launch a discussion based on a proposition via e-mail in preparation to the next task force meeting. Feb 8, 2016
   
   
   

Task force Security

1. Decision to fix issues on the client, then security tests can be launched again to validate the bug fixes.

2. Security for the client - Question received from @... to reproduce a security issue

   1. @...: it is difficult to provide the information because a report is automatically generated by the software when the test session is finished with the advices. So it is easier to fix the issue and then to relaunch the test

   2. It takes 1 or 2 days to re-execute the test (info confirmed with @... after the Technical Committee meeting)

3. Test component per component will start when issues are fixed

4. Implementation deviations
   
   

   1. Workflow manager (cf. e-mail between Kostas and Massi):

      1. @...:
         
         

         1. Doubt that there is component missing from the OpenNCP implementation. Not convinced that the solution will solve the security issue. It is rather a problem with the client connector.

         2. Portal is in a different trust zone than the trust zone of the NCP. So security of NCP B and of other components can be compromised => Deviation from the specifications.

   2. @...: There is a missing component national connector on the B side (and not the portal). There is room to discuss about the implementation of the solution because there are functional specs (e.g.  the national implementation must provide the best effort to satisfy security) but no specifications on how to implement.

   3. Idea would be to have a set of standard based instructions, that developers of fat clients could use to initiate the workflow with NCP B...

   4. We should kick off the discussion on this, in order to collect  the requirements.

   5. 1. This topic could be merged into security task force but better to have start a specific task on this because there is enough topics to deal on the security task force. In addition this issue is also an architecture topic.
         
         

         1. Build a common understanding (identify what is the problem and what needs to be fixed) then continue on another group.

         @... will centralize the info to share the knowledge with the people with the previous discussions.

         There is a specific section on the wiki for the different task forces. We can create a new space for workflow manager that we could keep private the time of the discussion

   6. SHA1 obsolete & insecure. It is in epSOS specs that we have to work with SHA2. @...: this is a security relaxation mentioned in epSOS doc. e.g.still used by Czeck Republic... This security relaxation should be removed.

   7. NCP to NCP messages: Signature per message or secure conversation? @... cf. deliverable 3A7 section 5.5.2 defines messages. It is said in the specs that each message MAY be signed, not mentioning which technology to use.

   8. XSPA role "medical doctor" is not among the list of possible values in D3.A.7 epSOS EED SAML Binding v1.1 - 2.3 (technical committee). In the same doc, the medical doctor value is used. Is this value is important or not? The list of values comes from a proprietary document. @..., the medical doctor value is in the example and might be wrong (cf. section 2.5: not normative)

    @... will create a JIRA issue related to the TRC component.

Development status

1. Release 2.4.0 => cf. OpenNCP bi-weekly meeting, Licinio proposed to ask MS to use version 2.4 RC1

2. @... mentions that the code of @... was not comited for TSL editor
   
   
   

AOB

1. Reminder from @... to upload the tsl files.;

   1. @...: Upload via TSL editor. With command 1, server asked for a password even if used a private key.

   2. @...: Attention if you use an external tool to upload, there is a configuration to be done

   3. @... uploaded the files successfully with user name and key
      
      
      

 Next meeting