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:
[mailto:] On Behalf Of Dale
Moberg
Sent: 18 January 2013 16:33
To: Pim van der Eijk;
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:
[mailto:] On
Behalf Of Pim van der Eijk
Sent: Friday, January 18, 2013 8:10
AM
To:
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
