assessing the non-repudiation feature

Summary of non-repudiation
of receipt feature/issues, possible support in V3:

 

1. Assumptions:

 

- in some cases,
non-repudiation applies to messages that do not need additional validation

beyond the receiving MSH, (just
need be properly “delivered”) but in most other cases it will. 

Well-formedness of payload
possibly including some semantic checks, may be needed. 

In other words, the decision
process for acknowledging, [often] has to be delegated to the application.

 

- in all cases however, the
method of non-repudiation (packaging process of the receipt, including a 

digest of the acknowledged
message, and signing) can be standardized. 

 

2. Scenario to be supported:

 

(a) an MSH B is supposed to
provide non-repudiation assurance for some Purchase Orders sent by A. 

This requirement appears in
a P-Mode parameter.  

 The P-Mode also tells
whether (a1) the receiving MSH can send the receipt without further 

validation, or (a2) needs to
wait for application validation and decision.

 

(b) When the MSH receives
the PO, it persists the PO or a digest of it,
because it knows per its P-Mode 

that a signed receipt would
be needed. It delivers the PO to the
application. Then in case of (a1) above,

the MSH creates a receipt
and send it back on its own.

 

(c) In case of (a2), the
application validates the content, and gives the MSH the OK for sending back

the receipt. All what the
application gives the MSH is the messageID of the PO
to acknowledge (optionally,

an additional Receipt
payload). 

The MSH knows which message
this is a receipt for (it had persisted the PO
or a digest of it). 

 

(d) The MSH builds the
receipt: add the digest of PO, signs and sends
back.

 

(e) the MSH that initially
sent the PO gets the signed receipt. It must
be able to compare digest 

with original PO, and must be able to persist enough info from this
receipt for future legal usage. 

In case of invalid receipt,
it notifies its application side (PO sender)
that non-repudiation 

is not ensured yet (calling
for action at app level).

 

3. Questions to be answered if
we add support for this feature:

 

- which standard packaging
(and process) for generating the receipt?

- need to define how enough
identity data and security data (e.g. signature) should/can be
persisted/delivered  by the MSH receiver of the receipt, knowing that
security processing normally removes wss:security header. 

- the status of the receipt
message has to be determined: it has both a UserMessage aspect 

(full part of an MEP, can be
pulled, can be subject to delivery) while it has also properties of a 

Signal (requires specific
unique processing, both on sending and receiving sides.)

 

 

-Jacques & Hamid