Implementation guide - e-SENS: Non-repudiation/Evidence Emitter BB feature

"At this point, are we able to clearly identify to our development team what should be done towards the implementation on the Non-Repudiation BB, based on all of the discussions and the documents that have been shared by the members, including Masi, on this subject?"

As pointed out by Konstantin Hyppönen:

"My opinion (an this is only an opinion) is to implement the non-repudiation feature in the OpenNCP in a very simplified manner, in order to have a theoretical chance of getting it ready for the connectathon:

• sign the incoming and outgoing messages exchanged by the NCPs.
• include in the messages the attributes required by ISO 13888 and currently not included in the messages.
• provide interfaces to the national connectors (to NI A and B) to be able to push the messages and store them as evidence in NI.
• as an alternative to the previous option, extend audit logs, which currently only include SOAP headers, to include also SOAP bodies and signatures of the messages. Demand the NCP implementors to place the audit repository in NI instead of the NCP.
• skip extensions of the XACML policies for the time being, because they increase complexity, and investigate in more detail what is the value potentially provided by them.
• skip the implementation of ETSI REM -styled evidences for the time being, because they increase complexity, and investigate in more detail what is the value potentially provided by them.

 We need to prepare more detailed specs for this, or alternatively ask for more information about the solution that is being currently proposed."

Licinio Kustra Mano proposed implementation:

• 1) Identify in the OpenNCP flow the part where the audits are sent

• 2) Implement the message inspector which inspects the message (e.g., read the SOAP Action and the body) and create the XACML context

• 3) Feed the already existing PDP with policies out of the spec document provided (to be amended with Soeren's comments, I can't do that alone)

• 4) Implement the Obligation Handler that will Instantiate the method for fake ETSI REM (we are waiting for their input) and ATNA.

NOTE: how the messages are handled (e.t., sent to the ARR, sent back to the caller in a backchannel, handled by the epSOS Service flow) it is out of scope of the current implementation/test

Questions:

Can we predict the estimated effort on:

- The Specs Definition - Konstantin Hyppönen and Heiko Zimmermann, could you help on this?
- The Developments needed - maybe Kostas Karkaletsis and Stéphane Spahni, could you help us on this?