Re: [ebxml-msg-as4] follow-up on Receipts

[Timothy Bennett <timothy@drummondgroup.com>]

My comments inline...  Ric, Dale, others... please share your thots...

Durand, Jacques R. wrote:

0D4373E9E1236F42AB63FD6B5B306AA3BCD43C@SV-EXCHANGE.fjcs.net" type="cite">

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.

One of the important aspects of the discussion on performance with regard to digest computation relates to the architecture of the ebMSv3 specification that supports the different processing modules as being swappable black boxes.  That is, the inbound stream passing through the security module, then the reliability module, then the ebMS module, etc.  In this context, the code that eventually generates the NRR receipt is not guaranteed to have access to the digest computed by the Security Module and if strict separation of modules was enforced, then the code that generates the NRR receipt would have to compute the digest of the original inbound message again.  That's the context of the performance question for large payloads.

Naturally, implementers can create integration points between modules for sharing information, but none of those interfaces are standard, and for implementers that are serious about black boxing the processing modules, this can be problematic.

There was no such "architectural" ideals with AS2 as there seems to be with ebMSv3, and it was in this context that some other ideas was *brainstormed* on the call yesterday -- including making the digest field in the NRR receipt optional (see #2 below).  The computed digest is a necessary legal data field for many types of transactions (retail/banking), but a simple "ebMSv2-like" Ack may be sufficient for other types of transactions.

0D4373E9E1236F42AB63FD6B5B306AA3BCD43C@SV-EXCHANGE.fjcs.net" type="cite">

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