Technical Requirements List for OpenNCP and integration design

TSL-sync

TSL-sync connects to Central Services and downloads the Trusted Service Lists (TSL) with NCP endpoint addresses and certificates of the other Participating Nations.

As is

Connects to epsos properties DB
- For each <countrycode> listed in ncp.countries property
- Fetches the value of the property tsl.location.<countrycode> which has the path to the TSL file of that country stored in the Central Services server
- Parses the XML file
- Stores the downloaded certificates in the path given by certificates.storepath property
- Imports the certificates to the keystores/truststores (??)
- Updates the DB with the values for the endpoints defined in the file

To be

TSL-Editor

This tool is used to create or update a country's TSL file in order to upload it to the Central Services, so that other countries can update their information regarding that specific country.

As is

Takes a already prepared TSL file "NCP_Service_Status_List__<Country>_<COUNTRYCODE>_.xml" (XML) and parses its information to display in a GUI for editing
Creates a TSL file (XML) and uploads it via SFTP to the specific country repository in the Central Services server (??)

To be

Should integrate a REST client to support CRUD operations regarding each country configuration in the SMP
Should we have different "resources" (REST terminology) to the different types of information, structured already in public/private information?

/smp
	  |- /resources
	     |- /<country>
		    |- /PPT
		      |- /public
		        |- /endpoints
		        |- /certificates
		        |- /internationalsearchmask
		      |- /private
		        |- /openswan

So updating the endpoints of Portugal, would consist of performing a HTTP POST /smp/resources/PT/PPT/public/endpoints, passing the JSON/XML as the content (just an example, not supposed to be well-formated or valid):

{'PatientIdentificationService': 'http://12.12.12.12:8080/epsos-ws-server/services/XCPD_Service'}

I'm not sure if this will be dependent on the REST service provided by the SMP server. This raises the question of when will the SMP file be built: should TSL-Editor do it or can it be built dinamically in the SMP server? The answer will afect the availability of the proposed REST solution...
Will we need to continue to support the TSL files we use nowadays in the same way (XML + SFTP)? How will we adapt this new REST approach? Will we use the same approach for CRUDing SMP-files and TSL-files?