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?