Introduction

The following table depicts the key functionalities that the solution architecture MUST support in order to fulfill the functional requirements of the architecture, as they are identified and GOOPRA

Key FunctionalityCentral Components UsedImplemented InData Model MappingVariations
Data Discovery

TOOP Directory

CEF BDMSL (BDXL)

SMP Service

TOOP Connector
N/A
Semantic MappingSemantic Mapping ServiceTOOP Connector
  • Semantic Mapping Done on the DC Backend (no use of SMS)


Data Subject IdentificationeIDAS NodeDC System
  • Data Subject Identification as a Natural Person, using eIDAS
  • Data Subject Identification as a legal entity, using eIDAS
  • Data Subject Identification as a Legal Representative, using eIDAS
  • Data Subject Identification done directly by the DC system, (not using eIDAS)
  • No Data Subject Identification done (Public Data)


eDelivery Message SubmissionAS4 GatewayTOOP Connector
N/A
Record Matching-DP System






Key Functionality Assumptions

Data Discovery

  • Every DC and DP System MUST have a participant identifier following the ISO6523 scheme for representation organizations and organization parts
  • DC and DP Systems must be registered for all document types of interest in a Service Metadata Publisher (SMP) and it must be published in TOOP Directory (TD)
    • The SMP MUST follow the OASIS BDXR SMP 1.0 specification
    • The TD is made available centrally and is publicly accessible and needs to interact with all SMP instances. It strictly follows the specification of the PEPPOL Directory (PD).
  • Sending requirements
    • The R2D2 module needs to know the endpoint address of the central TD to indirectly retrieve the AS4 endpoint URLs and certificates of the respective receivers
    • The DC System needs to know the destination country code, the document type identifier and the process identifier to perform a data exchange
    • It is possible that a single DC query result in multiple AS4 transmissions leading to a required merging of DP responses
  • Receiving requirements
    • DC and DP systems MUST register an AS4 endpoint URL as well as certificate for receiving TOOP messages inside an SMP
    • All SMP participants (= service groups) MUST publish their Business Cards in the central TD

Semantic Mapping

In order for the MP to work properly, the following assumptions and prerequisites have to be taken into account by the DC with respect to the Semantic Mapping Service (SMS):

  • A TOOP Common Semantic Model (CSM) has been constructed in the form of an ontology that contains concepts that are common for the scope of the TOOP project, i.e. the domain of business and company data.
  • Two cases can be distinguished depending on whether the DC wants to use the CSM directly or not.
  • 1: in case the DC uses the CSM directly:
    • the DC MUST use TOOP concepts through the interface of the MP.
  • 2: in case the DC uses its own local representation of the concepts (and not directly the CSM):
    • The DC must construct an organizational semantic model (also in the form of an ontology) that contains the concepts they maintain in the domain of business and company data.
    • A mapping has to be made between the organizational concepts and the TOOP concepts.
  • The CSM, the organizational semantic models as well as their mapping will be made available via the SMS that is used by the MP.

For constructing the CSM and the organizational semantic models, the following rules need to be followed:

  • The definition of a concept can be found in the Domain Core Semantic Model wiki page
  • The CSM can contain different subdomains of concepts, e.g. concepts about a registered organization, concepts about business financials, etc.
  • Each subdomain in the CSM has a specific namespace. The namespace of the CSM subdomain on registered organization is http://toop.eu/registeredOrganization.
  • Each CSM concept consists of a namespace and an identifier, e.g. the concept http://toop.eu/registeredOrganization#CompanyCode is the CompanyCode as defined by TOOP.
  • A subset of concepts can be grouped into a document type, such as company registration data document type, birth registration document type, mandate evidence document type, etc.
  • All document types are created, agreed upon and maintained by a central governance TOOP agency (Philip & Jack).
  • These document types can be used by DC and DP for registering its capabilities (see above).

Data Subject Identification

  • The architecture does not explicitly requires the eIDAS Node for the Identification Data Provisioning. It assumes that at least the minimum data set, as is it described in the eIDAS profile, but also as it is specified in the TOOP Exchange Data model, can be provided by the DC in the TOOP Data Request Message. It is a responsibility of the DP, and its process and requirements  on doing the Identification Record Matching

    Normally the national eIDAS Node available in each country should be used to authenticate the user. Since the eIDAS deployment throughout Europe however has not been completed, the playground will offer an eIDAS network for testing and piloting.
  • The eIDAS node will be able to identify natural persons and will return the minimum data set of the identification attributes, with an eIDAS formatted identifier that can be used by the DP to determine the data to be returned. If the identifier is not sufficient to determine the data subject, record matching on the minimum data set needs to be performed by the DP.
  • For the first release cycle, the authenticated Natural Person is assumed to be a legal representative of just one legal entity.



  • No labels