Contents

1. Scope & Goals

The OOTS Exchange Data Model design describes a process providing electronic messaging support for requesting Evidence documents. The specification, therefore, differentiates between the Evidence Request transaction and the Evidence Response transaction. Differences between these two transactions are found on the conceptual and process level. While the Evidence Request enables Evidence Requesters (ER) to initiate document queries to the Evidence Providers (EP), the Evidence Response provides the possibility to return the requested Evidence and its associated Evidence  metadata. Thus:

• The Evidence Request describes the transaction from ER to EP to request certain structured or unstructured pieces of evidence.

• The Evidence Response describes the transaction from EP to ER to deliver the requested evidence and its accompanying metadata or to inform the ER about exceptions or unavailability of the evidence until a given time.

The OOTS Exchange Data Model structure is generic in its design, meaning that the structure itself is independent of specific Evidence Types. However, the OOTS Exchange Data Model's abstract structure must be filled with concrete information established in certain business domains. The Evidence Request then enables ERs to ask for certain Evidence Types (e.g. Birth Certificates), formats and to adress particular data services in the business domains. The Evidence Response then enables the EPs of that business domain to deliver the corresponding Evidence Type as evidence document (positive case) or to inform the ER about excpetions that occured (negtive case).

To ensure a high level of interoperability, comprehension and reusability, the OOTS Exchange Data Model is based on several core vocabularies and metadata profiles such as CCCEV,  DCAT, CBV and CPV that are captured within the OOTS Generic Metadata Profile. These standards are integrated and combined with the overarching standard OASIS ebXML RegRep Version 4.0 to form a generic query model for the OOTS. The combination of these standards enables the OOTS Exchange Data Model to address information entities raised by other OOTS High-Level Architecture components (e.g. eDelivery, eID, DSD, Evidence Broker) and to facilitate their interaction. 

Thus, the main goals to be gained by implementing the OOTS Exchange Data Model are:

2. Architecture Requirements

To enable this evidence exchange, the OOTS Exchange Data Model requires several information elements. It needs to describe and identify the Evidence Subject (ES) uniquely, being either a legal person or a natural person (taking into account whether authorized representatives have appropriate authorization to act on behalf of the ES). The ES or its authorized representative (denoted as user in the architecture requirements) must then provide its explicit request to an ER to initiate an Evidence Request for a piece of evidence. On the other hand, an ER needs to identify the requested evidence type required for a procedure (capability provided the Evidence Broker), identify an appropriate evidence provider and/or data service to deliver/issue the evidence (capability provided through the Data Service Directory) and authorize the ES through eIDAS.  

When the Evidence Request has been send it needs to enable the EP to identify the ES through record matching using appropriate ES identity attributes of the Evidence Request. In order to initiate the evidence provision, the EP may require from the ER that the ES (or user) is redirected from the ER procedure portal to the preview space of the EP (indicated through an Error Response with information about the preview space) in order to perform an EP-side authorization and to preview and select the evidence. Throughout the preview process the EP may ask the ES (or user) to provide further information (e.g. jurisdiction information or other classification values) to address the correct data service and find the evidence.  When compiling the Evidence Response, an EP needs to place the requested evidence and evidence metadata inside the response. In cases where evidences are not available yet, the EP needs to signal a date of availability to the ER in the Evidence Response that indicates when the evidence can be retrieved through another Evidence Request.  If an EP cannot answer an Evidence Request, it must provide notification back to the ER by sending an appropriate Error Response with the reasons for failure.       

The following architecture requirements describe the architecture requirements connected to the EDM which are further detailed in the business requirements section.