20150909 - Meeting minutes, Wednesday, September 9th, 2015 - OpenNCP integration with SMP

OpenNCP integration with SMP

 

Estimated - 13:00 to 14:00 CEST

Performed - 

AGENDA

  1. Overview
  2. Spec, design and Development
  3. AOB

 

 

LOCATION

- Wiki+ WorkBench + AdobeConnect

PARTICIPANTS

Today's Meeting Participants:

Licinio Kustra Mano

Joao Cunha

Rui Alves (Unlicensed)

S

Stéphane Spahni

@Uwe Roth

Markus (Unlicensed)

Massimiliano Masi

Adrien Ferial (DG Digit)

michele.foucart

@Gwenaelle Quivy

Marcello Melgara

 

Invited Members List:

@François

Natasha Carl

Alexandre Santos

Kostas Karkaletsis

Heiko Zimmermann

Ortwin Donak

 

MEETING NOTES

0. Overview

  • Work Scope

    • USE SMP to convey public information of TSL (Certificates, End Points) and International Patient Search Mask;
      • TSL files should be removed and replaced by SMP Signed Information files. 
      • (Maybe not to delete the TSL EDITOR, explore TSL EDITOR to prepare the information to submit to the SMP )
        • INTEGRATE a REST client to CRUD the information...
      • About "International Patient Search Mask", how to include on the  SMP configs
        • Can be a child on an XML node on the SMP file.
    • USE SMP to the establishment of VPN?
      • Certificates, End Points and OpenSwan Config (PRIVATE)
    • OUT OF SCOPE BY NOW - Automate the configuration of OpenNCP

  • Time Scope: 

    • New release OpenNCP 2.3.0-RC0 Released in August.


  • Relevant Documentation: 

    • SMP:

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.
  • FROM LAST MEETING:
  • Markus (Unlicensed):
    • This is an e-SENS task that is being supported by EXPAND/OpenNCP Community.
      • We MUST make sure that everyone understands that the request is an e-SENS pilot request and not something that the OpenNCP just decided to do.
    • Good approach, instead of stop everything, work for clarifying what opportunities are there to use the SMP as bridge to remove relaxations adopted during epSOS.
  • Joao Cunha Provide an overview on the work done so far:

 

CONGRATULATIONS and thank you!

Joao Cunha and @Uwe did a MAGNIFICENT work on recovering information and making it available for all of us that use the services but never went down there do understand how they have been implement.

Thank you so much guys and please keep digging (wink)

 

 

3. Document on SMP:

Draft version shared for comments: e-SENS-eHealth-SMP_SML-v02-Draft_ForComments.docx

Joao Cunha: some questions were identified and this is a good oportunity to ask them to the community.

    • How will we do the creation/update for SMP file for the country: update the TSL-Editor?
      • Masi: 
        • Define the scope. If we agree on priority to have SMP initially to private TSL - yes.
        • Stephane: Propose to have two phases. Do not change tsl for now... Later we can refactor design TSL-Editor...
        • Masi: (CONET?) is giving us a REST client
        • Stephane: we can provide an application with TSL.Editor...
      • 20150616_Masi_SMP-TRUST.docx
      • Technical discussion about the open questions about the document...

 

1) How is the update of the SMP file of a country going to be made? TSL-Editor to produce SMP files and integrate a REST client in the TSL-Editor to communicate with the SMP server?

Answer: A short-term solution would be:

i) Use the TSL-Editor to create TSL files as it currently happens;

 

ii) Create a script to run in the NCP to transform TSL files in SMP (1 to 1 mapping).

iii) Create an app to communicate with the rest client from DIGIT which is running in the SMP server.

A long-term solution would be to refactor TSL-Editor to be a component that generates SMP files natively and speak REST to the DIGIT client. It must be noted that TSL-Editor was created to not infringe security rules (we must not break the circle of trust). It must not be used in real cases, only test environment.

2) How will the workflow be regarding the storage of configurations and their refresh after being modified?

Answer: TSL-Sync won't be needed anymore. SMP clients are expected to retrieve the metadata and store it in cache (e.g. for 1 hour). A cache invalidation algorithm must be applied to detect changes and perform a new lookup.

3) In TSL files, certificates are associated to NCP-Gateway (encryption+signature), VPN-Gateway and Signature. In SMP files we have 1 certificate per service. Are they for encryption or signature? TLS or WS?

Answer: To be used by gateway, do whatever you want, not restricted to signing or encryption 

                - The purpose of the certificates is not defined in the SMP spec.

4) Is DocumentIdentifier mapped with epSOS EventIDs (D3.4.2 - 4.5.8.1)?

Answer: yes.

5) SAMLIssueServiceInformation.xml: extension with certificate from IdP-B, STS SAML issuer and trusted STSs 

Answer: Proposed idea for automatic configuration of NCP (with establishment of trust between STS), but is out of scope.


Other Questions)

- DNS domain name (single domain name? one per country?) - Massi to explain in a document or email

- 1 SMP with a single node (University of Piraeus)

 

4. AOB

Many questions, doubts, still needs to be adressed and answered before we can proceed to conclude the document.

Next meeting ASAP is needed to proceed.


Today's meeting actions and next meeting: