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. ----------------
Joao Cunha could you please add the Q&A resulting from your research here?
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.
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.
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).
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.
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.
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.
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?
4. AOB
Nothing to declare.
Today's meeting actions
Licinio Kustra Mano: Follow up minutes + Schedule next meetings (Next SMP/SML 5th August, 13h00 CET).
Joao Cunha: lead the task force on the assessment and distribute some Questions and Tasks to other team members;
Licinio Kustra Mano: Communicate to e-SENS that the OpenNCP release integrated with SMP/SML is on hold, until further clarification and alignment of eHealth specific requirements, but we might have a first version of eID integration by the end of July.