2. Spec, design and Development

• Licinio Kustra Mano: overarching approach for the e-SENS document:
  
  • epSOS Central Configuration Services - Specifications
    • It was never implemented. But even so, the specified solution is referenced in the epSOS Deliverables;
  • epSOS Central Configuration Services - As IS
    • A simplified solution was adopted, but needs to be better described for further enhancements and improvements.
    • Improve Massi document... that was no officially released.....
  • Gap between Specs. and As IS scenarios towards an OPERATION READY scenario
    • ...
      
  • How can we use SMP/SML to close some of the gap and open issues  
    • What current limitations or relaxations ca be resolved with moving to an SMP/SML.
      
    • Curent implementation:
      • They can provide (in a couple of weeks) a Public service for some kind of information
• Joao Cunha and @Uwe Roth research:
  • ++++++++++++++++++++++++++++++++++++++++
  • • Joao Cunha could you please add the Q&A resulting from your research here?

1. Q1: The deliverable D3.9.1 epSOS Pilot System Component Specification proposes a solution for the central services, which can be summarized by the following: 
   "The proposed solution for these central services is based on DNS and HTTP distribution: each country would maintain an HTTP-service on its NCP that would provide its documents in its responsibility, using a conventioned naming scheme. The DNS would order the requested DNS name for the proper MS NCP. Each NCP would have its data organized in two virtual versions (structures): Drop-zone ("drop", representing the TO-BE status) and Running Configuration ("running", representing the AS-IS status). These structures should be exposed as REST resources and group information related to configuration files and terminologies."
   This seems like the SMP approach to the central services problem, which is very different from what I believe is the current implementation. Was this ever implemented?
   A1: This was a proposed solution that was never implemented.
2. Q2: In D3.4.2 epSOS Common Components Specification, section 4.4 epSOS TSL specificates the TSL XML Envelope. It that info updated / does it still apply?
   A2: Yes.
   
3. Q3: What is the SyncApp? Is it TSL-Sync or something different?
   A3: The SyncApp borns from the fact that the NCP implementation should be an ATNA Secure Node (D3.7.2, section 5 – please confirm), that is, no manual administration/access should be provided. The SyncApp is a cronjob that fetches content from the private area of a country in the Central Services (connection made by SSH) and uses it to configure the NCP and write an audit trail. The private area contains things such as the Home Community ID, XDS_DOMAIN, Role mappings, Policies, Search Masks, PoC registration, etc. Each country would adapt the scheduling of the job according to their infrastructure specifications. The SyncApp was part of the F.E.T. implementation, its source code is not in OpenNCP's Bitbucket (perhaps Sören has the code).
   
4. Q4: If OpenNCP doesn't provide SyncApp, then how does it conform to the requirement of each NCP being an ATNA Secure Node?
   A4: It doesn't, it's one of the security relaxations approved by the Project Steering Committee, alongside the security profile and the VPN connection between each NCP and the Central Services.
   
5. Q5: Why do we keep country's specific configuration files (used only in its own NCP configuration) in the private area in the Central Services instead of each country having its own local server?
   A5: It could be like that.
   
6. Q6: From the specifications and from Masi's + Rainer's "NCP configuration files & epSOS central services specification" (2011), we see that the Central Services host a lot of content besides TSL files (e.g., Trust anchors, role mappings, policies & documents, XDS_DOMAIN, Home Community ID, PoC registration file, etc). Can we clearly list all this content and its goals (or even if they are used nowadays)?
   A6: This content was used in the beginnings of epSOS but right now we don't know what still exists and how it is used. We should stress this point and ask Conet for some clarifications. As for the policies, they were used in F.E.T. implementation, not in OpenNCP.
7. Q7: The current implementation is based on uploading an NSL (TSL) file with TSL-Editor to each country private area and then there's an internal script in the Central Services that copies each TSL file to the public area. What about the other content (previous question)? What happens in the inner workings of Central Services? Do they have an audit trail repository?
   A7: We don't know.

• • ++++++++++++++++++++++++++++++++++++++++

What is the data needed to configure an eHealth NCP

• Can we use SMP to standardise the had oc TSL;
  • How can allow a machine to collect all the data needed to operate.
• Ca exploit the SMP to obtain a secure node?