VERSION 1.0.0 MANDATORY

Contents

1. Introduction

To support the operation of the OOTS, events related to the use of the system need to be logged. Legal requirements for logging are defined in Article 17 and 28 (6) of the Implementing Act. The article covers specifics for evidence exchange in 17(1) and also provides general requirements.   

This section covers logging functionality related to evidence exchange, and more specifically specifies the logging requirements on the relevant sub-system categories involved in evidence exchange: the evidence requester systems (Online Procedure Portals), evidence provider systems (Data Services and  Preview Areas) and the eDelivery Access Points.   

2. Objectives

Article 17(5) states that competent authorities shall make log data available to each other on request in case of “strong suspicion of incidents and for the purposes of audits and random checks of security”. More generally, and on a voluntary basis, log data can possibly also support:  

  • troubleshooting of OOTS (whether in testing, acceptance, production setup and operation) by IT specialists of connected competent authorities.  
  • handle support requests raised by users of the OOTS. 

In OOTS, as explained in Chapter 1: Introduction - High Level Architecture (Draft) section 7.4, eDelivery provides, in a delegated role, support for integrity, confidentiality, authenticity and non-repudiation of origin and receipt as explained in the CEF Security Controls guidance document. Non-repudiation is a requirement for evidence exchange as explained in section 2 of the HLA. The logging of eDelivery event data as required by Article 17(1)(c) provides the non-repudiation feature for OOTS evidence exchange.  

3. Log data correlation

Since the OOTS is not a single monolithic system, but a collection of sub-systems of different competent authorities in different Member States, the OOTS log system is similarly not a single system but an abstraction for the logging of the various sub-systems.  

The flow of an evidence request, and the reverse flow of the evidence response, corresponds to a series of events in various components. Both flows also involve lower-level technical eDelivery signals that support reliable messaging, non-repudiation and error handling. To log the complete flows, events generated in different modules and related log data need to be correlated.   

Different components process and have access data elements. Multiple layers in message structures and their packaging and un-packaging results in different sets of identifiers. Storage of content data (including personal data) in event logs can be avoided by using unique identifiers and identifier correlation.  

In this section, Evidence Requester generalizes over Online Procedure Portal and Preview Area. Both these and Data Services can also be provided using intermediary platforms. 

3.1. Evidence Request

According to article 17(1)(a), the evidence request must be logged. The following table lists identifiers in the evidence request data model that enable correlation of log data and where they are processed.  

Data to be logged 

Source from which data can be be captured 

Evidence Requester 

Access Points 

Data Service 

Preview Space

Party identifier for requesting competent authority or intermediary platform 

originalSender @type attribute and content (eDelivery) 

 

* 

 


Agent Identifier @schemeID attribute and content in RegRep4 EvidenceRequester slot (RegRep4) 

* 

 

* 


Party identifier for providing competent authority or intermediary platform 

finalRecipient @type attribute and content (eDelivery) 

 

* 

 


Agent Identifier @schemeID attribute and content in RegRep4 EvidenceProvider slot (RegRep4) 

* 

 

* 


Identifier for the evidence request and reverse response flows  

eb:ConversationId (eDelivery) 

* 

* 

* 


Message Identifier 

eb:MessageId (eDelivery) 

* 

* 

* 


Evidence Request identifier 

query:QueryRequest/ @id (RegRep4) 

* 

 

* 


Evidence Subject 

A NaturalPerson, LegalPerson or Representative Slot, filled with attributes from eIDAS or supplied by the user. 

* 

 

* 


Preview LocationContent of the PreviewLocation slot and URL visited by user*

*

Non-Repudiation Information 

eb:Messaging and wsse:Security headers from eDelivery AS4 message (eDelivery) 

 

* 

 


Signature validation date and time and outcome (success or error; eDelivery) 

 

* 

 


MIME type and full content of first MIME part (includes query:QueryRequest metadata document). 

* 

 

* 


3.2. Evidence Response and Evidence Error 

According to article 17(1)(b), for the evidence response, the information included in the evidence response, with the exception of the evidence itself, must be logged. For the error response, an error report is sent and logged. For the error that transports preview information, the preview location is logged.

For this flow, the following table lists identifiers that enable correlation of log data.

Data to be logged 

Source from which data can be be captured 

Evidence Requester 

Access Points 

Data Service 

Preview Space

Party identifier for requesting competent authority or intermediary platform 

finalRecipient @type attribute and content (eDelivery) 

 

* 

 


Agent Identifier @schemeID attribute and content in RegRep4 EvidenceRequester slot (RegRep4) 

* 

 

* 


Party identifier for providing competent authority or intermediary platform 

originalSender @type attribute and content (eDelivery) 

 

* 

 


Agent Identifier @schemeID attribute and content in RegRep4 EvidenceProvider slot (RegRep4) 

* 

 

* 


Identifier for the evidence request and reverse response flows  

eb:ConversationId (eDelivery) 

* 

* 

* 


Message Identifier 

eb:MessageId (eDelivery) 

* 

* 

* 


Evidence Request identifier 

query:QueryResponse/ @RequestId (RegRep4) 

* 

 

* 


Evidence Response Identifier 

rim:SlotValue/ rim:Value content for EvidenceResponseIdentifier Slot (RegRep4) 

* 

 

* 


Evidence Identifier (for evidence response) 

Evidence/ Identifier value in EvidenceMetadata Slot (RegRep4) 

* 

 

* 


Error report (for error response) 

rs:Exception element 

* 

 

* 


Preview LocationPreviewLocation Slot content and URL visited *
**

For responses, the following table summarizes log data supporting non-repudiation. Note that for non-repudiation to work, the evidence provider must have a record, for each piece of evidence it exchanged using OOTS, in an eDelivery message part referenced using a rim:RepositoryItemRef, to the actual identical evidence content for the evidence. The ds:SignedInfo in the AS4 message includes the ds:DigestValue for that content, after GZIP application. 

Data to be logged 

Source from which data can be be captured 

Evidence Requester 

Access Points 

Data Service 

Preview Space

Non-Repudiation Information 

eb:Messaging and wsse:Security headers from eDelivery AS4 message (eDelivery) 

For evidence responses, includes signed hash values of all MIME evidence content payload parts to which eDelivery compression has been applied.   

 

* 

 


 

Signature validation date and time and outcome (success or error; eDelivery) 

 

* 

 


 

MIME type and full content of first MIME part (includes query:QueryResponse metadata document which, for evidence responses, includes one or more rim:RepositoryItemRef elements and, for error response, an rs:Exception) 

* 

 

* 


 

For evidence content referenced using rim:RepositoryItemRef elements , MIME type and MIME content identifier.  

* 

* 

* 


 

For evidence content referenced using rim:RepositoryItemRef elements , data such as submission time stamps and identifiers allowing relating the exchanged evidence content to evidence content submitted by the evidence provider.

 

 

*


 

For evidence content referenced using rim:RepositoryItemRef elements , data such as delivery time stamps and identifiers allowing relating the exchanged evidence content to evidence content delivered to the evidence requester.

*

 

 


3.3. Message Acknowledgment, Error or Fault 

Any OOTS evidence exchange protocol message uses eDelivery, and therefore for both evidence request and evidence response or evidence error messages, eDelivery protocol level responses are generated. Three such responses are AS4 receipts, AS4 errors, and SOAP Faults. 

All logging related to these messages and the events they report is handled at the level of eDelivery Access Points as shown: 

Data to be logged 

Source from which data can be be captured 

Evidence Requester 

Access Points 

Data Service 

Preview Space

Correlation identifier (for Acknowledgment) 

eb:RefToMessageId 

 

* 

 


Correlation identifier (for Error) 

eb:RefToMessageInError 

 

* 

 


Error information 

eb:Error/ @shortDescription, eb:Description and eb:ErrorDetail 

 

* 

 


Fault information 

soap:Fault/ Code and Reason  

 

* 

 


Non-Repudiation of Receipt (for Acknowledgments) 

eb:Messaging and wsse:Security headers from eDelivery AS4 message, including the eb:Receipt 

 

* 

 


Message Non-Repudiation Information 

Signature data and time validation outcome (success or error) 

 

* 

 


4. Non-Repudiation 

The OOTS relies on eDelivery and the OOTS log system for non-repudiation. For an OOTS message: 

  • Non-repudiation of origin protects against the originator’s false denial of having originated the message. 
  • Non-repudiation of receipt protects against the recipient's false denial of having received and recognized the content of the message.   

For example: an evidence requester that has received a particular piece of evidence with a particular evidence identifier from an evidence provider can use the following trace for non-repudiation of origin: 

  • For the evidence identifier, find the related evidence response that carried it. 
  • Apply GZIP (eDelivery compression algorithm) to the evidence content data and compute its digest.  
  • From the evidence response identifier, find the Message Identifier of the evidence response eDelivery message that carried it, and MIME content identifier in which it was packaged. 
  • From the eDelivery message identifier, obtain the eDelivery message non-repudiation metadata (Signed Info). 
  • From the non-repudiation metadata, obtain the digest value. 
  • Verify that the evidence content has not been altered since it was transmitted to the Evidence Requester Access Point. 

For example, an evidence provider that has sent a particular piece of evidence with a particular evidence identifier to an evidence requester can use the following trace for non-repudiation of receipt. 

  • For the evidence identifier, find the related evidence response that carried it. 
  • From the evidence response identifier, find the Message Identifier of the evidence response eDelivery message that carried it, and MIME content identifier in which it was packaged. 
  • From the eDelivery message identifier, obtain the eDelivery message non-repudiation metadata (Signed Info). 
  • Verify that the compressed evidence content digest matches the value for the eDelivery MIME part that has the MIME content identifier. 
  • Apply GZIP (eDelivery compression algorithm) to the evidence content data and compute its digest.  
  • Verify that the Access Point received an AS4 non-repudiation receipt from the Access Point of the evidence requester. 

5. Log System Security and Privacy 

Article 28(6) requires the OOTS to ensure the confidentiality, integrity and availability of the OOTS logs through appropriate and proportionate security measures, each for the logs that is has recorded.  

Evidence requests and evidence content in evidence responses hold personal data. However, any storage of this content by the eDelivery Access Points for operational message exchange is temporary. Logging for these components can be set up such that no personal data is stored in the log sub-system. For logging and non-repudiation just having the hashes of evidence content can be enough. But parties must be able to provide the full evidence content in case of a dispute. 

6. Log Retention

 Article 17 4. of the Implementing Act states that, without prejudice to longer retention periods required under national law for the logs referred to in paragraphs 1, 2 and 3 for the purposes of the OOTS or for other purposes, the Commission and the evidence requesters, evidence providers or intermediary platforms, where applicable, shall keep those logs for a period of 12 months


  • No labels