follow-up on Receipts

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Summary of discussion about Receipts today:

 

1. In case of large payloads, there is a performance problem for generating digests to be included in Receipt for NRR: such payloads would have to be first saved on disk. Indeed, streaming is not sufficient, as it is a read-only-once procedure, and here we'd need two readings: one for creating the digest, the other for delivery.

 

2. There seems to be a consensus to make the inclusion fo digest(s) optional in the Receipt, e.g. based on agreement (PMode). Rationale: the Receipt serves several purposes (including simple Ack) and in some cases NRR is not the primary concern.

 

3. "small" documents are expected to be the most common case, when NRR is required. In such cases it is not a problem to compute a hash for each attached payload.

 

4. In case NRR may still be required for large payloads, some alternative solution could be considered for support in AS4: e.g. the original message must be signed. By validating the signature , the receiving MSH (i.e. its Security module) effectively computes a digest. In tightly integrated implementations, could this digest by accessible by the ebms processor? Or, would it be sufficient for NRR to send back in the Receipt the signature of the original message (itself signed over by the Receipt signature), so that the Receiver cannot deny having received the original (signed) message from which this signature was generated?

 

Jacques