Date: Fri, 29 Mar 2024 08:13:36 +0000 (UTC) Message-ID: <233547574.21.1711700016683@1d72af3c1a92> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_20_1807742149.1711700016682" ------=_Part_20_1807742149.1711700016682 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Evidence Emitter Architectural Building Block enables National Conta= ct points to generate and emit electronic evidence used for non-repudiation= purposes, based on each domain respective regulations and technological ne= ed.
Harmonizing the non-repudiation requirements for all the different e-SEN= S domains is a challenging task. Every domain has a vertical specialization= (both from a technical and from a regulatory standpoint) with respect of t= he non-repudiation services. The White Paper on Non Repudiation Services[1][2] highlighted a path towards a common set of cross-border and= cross-sector interoperable non-repudiation services using a per-hop (e.g.,= per-corner) evidence-based mechanism. The mechanism allows for a generic, = horizontal, and legally stable technology used to emit and store evidence g= uaranteeing both interoperability and the per-domain specific needs.
The core of the abovementioned mechanism is the Evidence Emitter ABB, wh= ich can run in any corner of the e-SENS model. By inspecting the incoming (= or outgoing) message, it provides a mechanism to guess the application doma= in (e.g., eProcurement, eHealth, eJustice) and triggers the emission of the= specific set of evidence, by evaluating a previously agreed security polic= y. The expected set of evidence emitted is the domain-specific one (e.g., I= HE ATNA) and the generic, interoperable one (e.g., ETSI REM) and it may be = signed according to the domain needs.
For the detailed discussion of the non-repudiation aspects in the 4-corn= er model, please refer to [1].
The current epSOS specifications tackle non repudiation aspects in = [3] by further specifying the t= he audit trails. However these recommendations are not inlined with the ISO= 13888 standard neither with the ETSI REM standard, which is selected as th= e target architecture for the eDelivery CEF building block.
The non-repudiation framework proposed by e-SENS aims at providing a cro= ss-sector technology that selects and feeds the correct evidence emitter fo= r the specific domain. For instance, by the usage of a policy eval= uation outcome, the obligations contain the necessary data to be used = to feed the audit trail emitter in parallel with the ETS= I REM. The Non Repudiation implementation is an instance of the well known&= nbsp;Message Inspector and Secure Session Fa=C3=A7ad= e Core Security Patterns.
[3] See e.g., epSOS D3.4.2, Section = 4.5.6 Audit Trail Data for Non-Repudiation
Why non-repudiation is needed? When NCPs exchange messages, they should = produce enough evidence for further investigation in case of disputes. Here= are some examples of the cases when this might be needed:
In these cases, the contents of the documents exchanged by the NCPs shou= ld be available for later examination during dispute resolution.
[1] = ;http://wiki.ds.unipi.gr/display/ESEN= S/SAT+-+Non+Repudiation
[2] http://wiki.ds.unipi.gr/display/ESENS/Whitepaper+-+Non+Repudi= ation
[3] Se= e e.g., epSOS D3.4.2, Section 4.5.6 Audit Trail Data for Non-Repud= iation
Other Documents: