Page tree
Skip to end of metadata
Go to start of metadata

Related Documents

SMP:

Summary

This module is a replacement of TSL Files which is the definition of PN services and endpoints. It has as add-on more detailed configuration according to the communication of two PN's

What is described in e-Sens

  • There will be a configuration for each country defining the following:
    • Service Locator
      • It is a service locator to determine connectivity information / routes / location of the service which shall be connected too. 
      • If a sender of an information wants to get information about the capabilities of an endpoint, it first has to learn the location of the capability service, therefore the service lookup is needed
      • It is something like the configuration manager service that OpenNCP asks in order to get the endpoints for other PN's
    • Capability Lookup
      • which business processes the receiver can participate in (define the workflows that can be particiapate)
      • which eDocuments can be received (define the document class coded can be exchanged)
      • the security setup (i.e. is it required vpn)
      • the evidence setup (i.e. is it required to send evidence tokens)
      • the communication protocol setup (will it be http or https)
      • the location of receiver's gateway (ip address)
      • Different service locator metadata for different systems (production and test)
    More details needed for capability lookup configuration 

What modules are implicated:

  • TSLSync
  • TSLEditor
  • Configuration Manager Changes (???)
  • VPN Configuration (???)

What must it be implemented

  1. Central Configuration Service for accepting such king of documents. This has to be implemented and hosted centrally
  2. User Interface for creating the definition file of services (replacement for TSLEditor). We could implement it now with a web interface.
  3. TSL Sync changes to adopt the changes of the services definition file

Functional description

  • ...

 

Questions

  • WE HAVE TO THINK what added value will this file gives to OpenNCP, and if it solves any existing problem 
  • What kind of file has each PN to prepare in order to register its services (something like tsl?)
  • Will it be a replacement for TSL? If yes, we have to assume for replacement of tsleditor and tslsync
  • Is service locator aware of the status of the service (up-down)?
  • Service locator shall also have information about test systems?
  • Is it meant only for the purpose of providing information about the location of the capability services?
  • As a central service, which can be used/requested by the senders, e.g. accessing by OpenNCP
  • Problem: what about the technical network connections and configurations necessary, e.g. firewall restrictions. For example currently you can download the TSL file from the configuration service, the local OpenNCP database is updated with the endpoint information, the certificates are installed in the truststore, but to be able to connect successfully, the firewall rules of the receiving site must allow access from the caller´s side, the VPN connection must be configured properly, ...
  • As a component of OpenNCP ? Not in my opinion, central service,  but OpenNCP may register there at startup
  • As a central service, which can be used/requested by the senders, e.g. accessing by OpenNCP

Action Items:

  • person - task -date

1 Comment

  1. Some answers to the questions. 

    • What kind of file has each PN to prepare in order to register its services (something like tsl?). The PN has to generate the SignedMetadata file, as self declaration of the PN's NCP capabilities and configuration items
    • Will it be a replacement for TSL? If yes, we have to assume for replacement of tsleditor and tslsync. The replacement of TSLEditor should produce the signedMetadata file. The TLSSync is not needed anymore. 
    • Is service locator aware of the status of the service (up-down)? Yes
    • Service locator shall also have information about test systems? The behavior does not change with respect to TSLs
    • Is it meant only for the purpose of providing information about the location of the capability services? No. It should have a twofold use: one is to comply with ATNA SN, second to list its own capabilities, to be discovered a remote peer.
    • As a central service, which can be used/requested by the senders, e.g. accessing by OpenNCP question not clear
    • Problem: what about the technical network connections and configurations necessary, e.g. firewall restrictions. For example currently you can download the TSL file from the configuration service, the local OpenNCP database is updated with the endpoint information, the certificates are installed in the truststore, but to be able to connect successfully, the firewall rules of the receiving site must allow access from the caller´s side, the VPN connection must be configured properly, ... This behavior is not changed, however a survey on the current deployments is welcomed, to see if SMP can be used to overcome the problem
    • As a component of OpenNCP ? Not in my opinion, central service,  but OpenNCP may register there at startup. The pilot will be with a centralized SMP SML, but a decentralized solution is available