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):

Error rendering macro 'code': Invalid value specified for parameter 'lang'
{'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?