OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ebxml-msg] Receipts validation


OK, thanks.  For AS4 we have defined the NRR to depend on PMode and on whether the original message was signed, not on whether the sender requests this,  so with AS4 it would perhaps be easier to automate the comparison of the sets of ds:References than with AS2.  
 
AS4 already has a "Missing Receipt" error that can be reported back to the producer,  so it could make sense for products or community profiles to define a similar "Bad Receipt" error that can be reported back.    I agree it is a somewhat theoretical problem.
 
Pim


From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Dale Moberg
Sent: 18 January 2013 16:33
To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Receipts validation

Within EDIINT, it is the expectation that the originator of the business message, if requesting evidence for NRR from the receiver, will have kept a hash value of the message enabling a check of the NRR. No failure behavior/protocol is defined for that audit—I think because it would be expected to be exceedingly rare to have that error once PKI is set up and tested. So it would as a business process be kicked up to a human to IM/phone/email about the anomaly.

 

Actually because standards are almost always compromises, within AS2 it would be possible for a sender to ask for a signed MDN even though the sender had only sent an encrypted message (no signature, no hash from sender POV available or even stored). Clearly in such a case, the checking would have to be done after an issue arose. If a hash were made (algorithm of the receiver, I guess) on a copy of the payload data that had been kept, perhaps some evidence for NRR or non-NRR could be cobbled together. These are all forensic process additions to the situation “prior to litigation” or whatever, and are not communication protocol concerns IMO.

 

So, to get back to your question Pim: does EDIINT/AS2/AS4 mandate the auditing procedures for the NRR process? IMO, it is implementation dependent precisely what and how much is done, and for both the implementations of  the developer and the end user. I would urge developers, however, to make the check and log the outcome at the minimum. Hooking into internal workflows would at least be enabled in that case. In the case that the original hash has been stored and NRR requested, then the NRR process strongly would benefit from making this final check (even though it is expected to be a “waste of time”  -- if the value returned differed from what had been sent, the receiving party should have flagged a signature error, no?)

 

For these reasons, I would not favor mandating rolling NRR failure behavior up into the protocol. The protocol stops somewhere, even when processing continuations are enabled. So I don’t think we should in ebMS mandate an error value. Let a community profile out if they really care about it as an addition.

 

From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Pim van der Eijk
Sent: Friday, January 18, 2013 8:10 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Receipts validation

 

 

Another issue from discussion with an AS4 implementer:

 

If MSH A sends a message M to MSH B and B sends a Receipt back to MSH A,  MSH A can correlate the messages based on MessageId and RefToMesssageId.  

 

Apart from correlation of identifiers, is MSH A also required to validate that the receipt indeed matches M?    I.e. for a reception awareness receipt, the UserMessage headers should have the values from the correlated UserMessage.  For an NRR receipt,  there should be a one-to-one match for ds:References and their href and digest values.    

 

If there is such a validation and MSH A detects a difference,  which ebMS error is used to report this? 

 

Pim

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]