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.

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

ebxml-msg message