OASIS ebXML Messaging Services TC

Hey folks, Would like everyone's thoughts on the following clarification needed from the AS4 profile: From Section 2.1 on the ebHandler Conformance Profile: “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: 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)? 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? <eb3:Messaging S12:mustUnderstand= true id= ValueOfMessagingHeader > <eb3:SignalMessage> <eb3:MessageInfo> <eb3:Timestamp>2009-11-06T08:00:09Z</eb3:Timestamp> <eb3:MessageId> orderreceipt@seller.com </eb3:MessageId> <eb3:RefToMessageId> orders123@buyer.com </eb3:RefToMessageId> </eb3:MessageInfo> <eb3:Receipt> </eb3:Receipt> </eb3:SignalMessage> </eb3:Messaging>

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 Sent: Tuesday, November 27, 2012 11:57 AM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] AS4 spec clarification on receipts   Hey folks, Would like everyone's thoughts on the following clarification needed from the AS4 profile: From Section 2.1 on the ebHandler Conformance Profile: “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? <eb3:Messaging S12:mustUnderstand="true" id="ValueOfMessagingHeader"> <eb3:SignalMessage> <eb3:MessageInfo> <eb3:Timestamp>2009-11-06T08:00:09Z</eb3:Timestamp> <eb3:MessageId> orderreceipt@seller.com </eb3:MessageId> <eb3:RefToMessageId> orders123@buyer.com </eb3:RefToMessageId> </eb3:MessageInfo> <eb3:Receipt> </eb3:Receipt> </eb3:SignalMessage> </eb3:Messaging>

  Hello,   Section 5.1.8 describes two f ormats 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 Sent: Tuesday, November 27, 2012 11:57 AM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] AS4 spec clarification on receipts   Hey folks, Would like everyone's thoughts on the following clarification needed from the AS4 profile: From Section 2.1 on the ebHandler Conformance Profile: “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? <eb3:Messaging S12:mustUnderstand= true id= ValueOfMessagingHeader > <eb3:SignalMessage> <eb3:MessageInfo> <eb3:Timestamp>2009-11-06T08:00:09Z</eb3:Timestamp> <eb3:MessageId> orderreceipt@seller.com </eb3:MessageId> <eb3:RefToMessageId> orders123@buyer.com </eb3:RefToMessageId> </eb3:MessageInfo> <eb3:Receipt> </eb3:Receipt> </eb3:SignalMessage> </eb3:Messaging>

On 11/28/2012 3:34 AM, Pim van der Eijk wrote:   Hello,   Section 5.1.8 describes two f ormats 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. Goo d reminder about the encapsulation of the various processing aspects of modular approach of the spec .  That is an advantage of ebM S3 /AS4.   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. Perhaps in the theory from a technical/spec perspective, but from a legal perspective my understanding is the conditions of NRR is generally not met unless both the user message and the receipt is signed.  Not saying that trading relationships can define NRR in such a way that unsigned messages are acceptable, but verification of origin i s generally a legal requirement for NRR.   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 Sent: Tuesday, November 27, 2012 11:57 AM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] AS4 spec clarification on receipts   Hey folks, Would like everyone's thoughts on the following clarification needed from the AS4 profile: From Section 2.1 on the ebHandler Conformance Profile: “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? <eb3:Messaging S12:mustUnderstand= true id= ValueOfMessagingHeader > <eb3:SignalMessage> <eb3:MessageInfo> <eb3:Timestamp>2009-11-06T08:00:09Z</eb3:Timestamp> <eb3:MessageId> orderreceipt@seller.com </eb3:MessageId> <eb3:RefToMessageId> orders123@buyer.com </eb3:RefToMessageId> </eb3:MessageInfo> <eb3:Receipt> </eb3:Receipt> </eb3:SignalMessage> </eb3:Messaging>

Right for Section 5.1.8 , although the statement in the feature table 2.1.1: “… Use of the ebbpsig:NonRepudiationInformation element (as defined in [ebBP-SIG]) is REQUIRED as content for the eb:Receipt message,” Is misleading and can be interpreted as  NonRepudiationInformation being always present in any Receipt, even for reception awareness. (in fact this statement was not necessary at this place and could be removed w/o altering the spec.)   -jacques   From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Pim van der Eijk Sent: Wednesday, November 28, 2012 1:35 AM To: Jacques Durand; timothy@drummondgroup.com; ebxml-msg@lists.oasis-open.org 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 Sent: Tuesday, November 27, 2012 11:57 AM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] AS4 spec clarification on receipts   Hey folks, Would like everyone's thoughts on the following clarification needed from the AS4 profile: From Section 2.1 on the ebHandler Conformance Profile: “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? <eb3:Messaging S12:mustUnderstand="true" id="ValueOfMessagingHeader"> <eb3:SignalMessage> <eb3:MessageInfo> <eb3:Timestamp>2009-11-06T08:00:09Z</eb3:Timestamp> <eb3:MessageId> orderreceipt@seller.com </eb3:MessageId> <eb3:RefToMessageId> orders123@buyer.com </eb3:RefToMessageId> </eb3:MessageInfo> <eb3:Receipt> </eb3:Receipt> </eb3:SignalMessage> </eb3:Messaging>

Turns out that X509 signatures are optional for 4 of the 5 usage profiles in the SuperStream draft spec, so perhaps the definition of NRR in that context takes on meaning not dependent on signed messages. On 11/28/2012 1:53 PM, Jacques Durand wrote: Right for Section 5.1.8 , although the statement in the feature table 2.1.1: “… Use of the ebbpsig:NonRepudiationInformation element (as defined in [ebBP-SIG]) is REQUIRED as content for the eb:Receipt message,” Is misleading and can be interpreted as  NonRepudiationInformation being always present in any Receipt, even for reception awareness. (in fact this statement was not necessary at this place and could be removed w/o altering the spec.)   -jacques   From: ebxml-msg@lists.oasis-open.org [ mailto:ebxml-msg@lists.oasis-open.org ] On Behalf Of Pim van der Eijk Sent: Wednesday, November 28, 2012 1:35 AM To: Jacques Durand; timothy@drummondgroup.com ; ebxml-msg@lists.oasis-open.org 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 Sent: Tuesday, November 27, 2012 11:57 AM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] AS4 spec clarification on receipts   Hey folks, Would like everyone's thoughts on the following clarification needed from the AS4 profile: From Section 2.1 on the ebHandler Conformance Profile: “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? <eb3:Messaging S12:mustUnderstand= true id= ValueOfMessagingHeader > <eb3:SignalMessage> <eb3:MessageInfo> <eb3:Timestamp>2009-11-06T08:00:09Z</eb3:Timestamp> <eb3:MessageId> orderreceipt@seller.com </eb3:MessageId> <eb3:RefToMessageId> orders123@buyer.com </eb3:RefToMessageId> </eb3:MessageInfo> <eb3:Receipt> </eb3:Receipt> </eb3:SignalMessage> </eb3:Messaging>