...

1. Vision of the software will be developed (purpose of the project)

The Evidence Emitter Architectural Building Block enables National Contact points to generate and emit electronic evidence used for non-repudiation purposes, based on each domain respective regulations and technological need.

Harmonizing the non-repudiation requirements for all the different e-SENS domains is a challenging task. Every domain has a vertical specialization (both from a technical and from a regulatory standpoint) with respect of the 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 guaranteeing both interoperability and the per-domain specific needs.

...

The non-repudiation framework proposed by e-SENS aims at providing a cross-sector technology that selects and feeds the correct evidence emitter for the specific domain. For instance, by the usage of a policy evaluation outcome, the obligations contain the necessary data to be used to feed the audit trail emitter in parallel with  with the ETSI REM. The Non Repudiation implementation is an instance of the well known Message Inspector and Secure Session Façade Core  Core Security Patterns.

[3] See e.g., epSOS D3.4.2, Section 4.5.6 6 Audit Trail Data for Non-Repudiation

What modules are implicated:

• ...

What must it be implemented

...

...

Functional description

2. Stakeholders (role description)

• Health Professional: information system/information service user;
• Patient: service beneficiary; 
• National Authority: national responsible for the eHealth National Contact Point;
• Data Controller: responsible for and must put in place processing contracts with their 'data processors'. 
• Data Processor: actor processing personal data in a specific context and with regard to specific sets of data or operations.

3. Users (need of each user)

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 should be available for later examination during dispute resolution.

4. Features that will be developed (from here we will create jira issues)

• When in the workflow there is the need to send an audit trail, instead of directly calling the method that creates the audit, the framework is invoked, by passing the message and the context (e.g., TLS, datetime) as parameters. The framework decides which evidence emitter to trigger
  
  

5. Features that will NOT be developed (very important in order to be easily found what decided not to be developed for further reference)

Action Items:

•  

  person - task -date

...