David,
I believe you mean section 4.1.4.2 and not 11.1.4. This section should be
referenced from 7.3.2.6.
There are at least two issues in this I raised in my "first half" email and
not seen any response:
1) As Shimamura-san mentions, the text in 4.1.4.2 is vague enough to be
useless. The definition you've provided below doesn't really help though it
might be worthwhile somewhere in the document. What does "consistent" mean?
Do these words describe the ds:Reference elements in the eb:Acknowledgment
or the list in the ds:Signature element? In either case, we've said the
ds:Reference should be consistent with the corresponding eb:Reference
element and eb:Reference should use the cid: scheme if and only if the
payload is part of the current message. Use of ds:Reference pointing to
payloads in the original message violates these recommendations and
requirements. Is that the intention? What should happen if the
ds:Signature from the original message didn't reference all payloads in that
message? What should happen if the original message wasn't signed at all?
2) Why must a signed Acknowledgment also sign the contents of the original
message (when the sender's signatures would have locked that down already)?
This raises the implementation cost and means a signed acknowledgment can't
be just a signed acknowledgment. (No, I'm not sure what this document
containing eb:Acknowledgment/ds:Reference+ and ds:Signature would be called.
Probably NRR in your terms.)
On a much more minor level, "a ds:Reference element" is incorrect. If it's
necessary to sign the contents of the original message, one ds:Reference
allows you to sign only the soap:Envelope or your favourite payload.
thanx,
doug