[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 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]