[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] AS4 spec clarification on receipts
|
Hello,
Section 5.1.8 describes two formats for receipts:
- Receipts for reception awareness: those
use the UserMessage of the received message (rather than an empty
NonRepudiationInformation structure as below in (2)).
- Receipts for nonrepudiation of receipt:
those use the ebBP Non-Repudiation element with ds:Reference elements.
If the NRR is for a signed message, these ds:Reference
elements can be reused from the wsse:Signature in the message being
acknowledged. This has the advantage that the AS4/ebMS3 parts of an MSH
need to know nothing about creating message digests, only about XML processing
(see the XSLT in the appendix). All the security processing is done in the
WS-Security module.
Perhaps in theory (I would need to check) the spec allows
a situation where NRR is requested for an unsigned message, in that case
the AS4 module would have to create those ds:References itself including Digests
(which the XSLT does not do), but that would be an unusual
case.
Pim
From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Jacques Durand Sent: 27 November 2012 23:31 To: timothy@drummondgroup.com; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] AS4 spec clarification on receipts Tim: 1.
Is setting PMode.Security.SendReceipt.NonRepudiation =
false a non-conformant configuration with respect to the ebHandler conformance
profile? In other words, does the ebHandler profile effectively require
the sending of signed user messages and the return of a signed receipt
containing a populated ebBP-SIG infoset, or does the ebHandler profile just mean
that ebBP-SIG infoset is required in the receipt even if it is empty (either
because the user message was unsigned or because the PMode non-repudiation
parameter = false)? In my
view, the latter is true: the profile does not impose a particular value for the
PMode.Security.SendReceipt.NonRepudiation parameter, so its value remains a
configuration choice at usage time. (in fact, I notice that the PMode section
2.1.3.6 does not even mention this parameter – it should). The only requirement
here is how the Receipt must be formed, not its usage. 2.
What would the XML of the receipt look like for a Pmode
non-repudiation parameter = false look like? This
parameter =false means that Receipts are only to be used for “reception
awareness” if any (but if the other parameter PMode[1].Security.SendReceipt is
not set or set to false, then no reception awareness is intended and then no
Receipt at all needs be sent). I’d say it should look like this and even
<ebbp:NonRepudiationInformation/>
should
not have to be there, but I leave it to a schema check to decide of
this: 3.
<eb3:Messaging
S12:mustUnderstand="true" id="ValueOfMessagingHeader"> 4.
<eb3:SignalMessage> 5.
<eb3:MessageInfo> 6.
<eb3:Timestamp>2009-11-06T08:00:09Z</eb3:Timestamp>
7.
<eb3:MessageId>orderreceipt@seller.com</eb3:MessageId>
8.
<eb3:RefToMessageId>orders123@buyer.com</eb3:RefToMessageId>
9.
</eb3:MessageInfo> 10.
<eb3:Receipt> 11.
<ebbp:NonRepudiationInformation/> 12.
</eb3:Receipt> 13.
</eb3:SignalMessage> 14.
</eb3:Messaging> 15.
-jacques From:
ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On
Behalf Of Timothy Bennett Hey folks, “Use of the ebbpsig:NonRepudiationInformation element (as
defined in [ebBP-SIG]) is REQUIRED as content for the eb:Receipt message,
i.e. when conforming to this profile a Receiving MSH must be able to create a
Receipt with such a content, and a Sending MSH must be able to process
it.” Further, in Section 5.2.1, the spec suggests a
usage: “For non-repudiation, the
eb:Receipt
element must contain a well-formed ebbpsig:NonRepudiationInformation
element.
This is indicated by the new P-Mode parameter:·
PMode[1].Security.SendReceipt.NonRepudiation
: value
= ‘true' (to be used for non-repudiation of receipt), value = 'false' (to be
used simply for reception awareness).” So, here's my couple of questions: 16. Is setting
PMode.Security.SendReceipt.NonRepudiation = false a non-conformant configuration
with respect to the ebHandler conformance profile? In other words, does
the ebHandler profile effectively require the sending of signed user messages
and the return of a signed receipt containing a populated ebBP-SIG infoset, or
does the ebHandler profile just mean that ebBP-SIG infoset is required in the
receipt even if it is empty (either because the user message was unsigned or
because the PMode non-repudiation parameter = false)? 17. What would
the XML of the receipt look like for a Pmode non-repudiation parameter = false
look like? Would it be just an empty eb3:Receipt infoset (like below), or would it also
contain an empty ebbpsig:Non-RepudiationInformation infoset?
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]