FW: [Fwd: ebMS 9/12/2006: Questions Raised re: Non-Repudiation of Receipt]

[<ian.c.jones@bt.com>]

Team,

	this is a question that appear relevant to our recent discussion
on exactly what we say about delivery and acknowledgements a part of the
Version 3 Core spec.


Ian Jones
Chair OASIS ebXML Messaging Services TC 
Email: ian.c.jones@bt.com
 

-----Original Message-----
From: Monica.Martin@Sun.COM [mailto:Monica.Martin@Sun.COM] 
Sent: 13 September 2006 00:33
To: Dale Moberg; Jacques Durand; Jones,IC,Ian,XDT63 R
Cc: Breininger, Kathryn R
Subject: [Fwd: ebMS 9/12/2006: Questions Raised re: Non-Repudiation of
Receipt]

For some reason, I get permanent failures when trying to post to this
list. May be an error still lingering from the email issues (don't
know).
Please complete TOI.

=======
The CPPA and ebBP teams received this question from Steve Capell
regarding non-repudiation of receipt, and synergy/compatibility between
CPPA/ebBP/ebMS. As the inquiry came to Dale Moberg and I, we answered
briefly. [1]

References:
http://lists.oasis-open.org/archives/ebxml-bp/200608/msg00027.html
http://lists.oasis-open.org/archives/ebxml-bp/200608/msg00029.html

This was briefly discussed on the JC call on Monday, and some
observations provided by Ian Jones and Jacques Durand.
This is a transfer of information. Thanks.

[1] I've attached the two references. The original question is provided
below as it bounced the list when sent:

22 August 2006
Hello all,
It has been a while since I posted to this group..  
I have an implementation question about the interpretation of the
business transaction characteristics in both the BPSS and the CPA from
the point of view of expected BSI behaviour.

Here is my understanding - from both specifications and from previous
correspondence on this issue:
1    The business meaning of the transaction characteristics in both the
BPSS and the CPA are the same.  The values in the CPA simply overrule
the values in the BPSS if different.  This allows a global process to be
defined with a set of default transaction characteristics but also
allows specific
bilateral relationships to modify them.  2    The transaction 
characteristics are transport and messaging protocol neutral.  They are
implemented with business signals such as ReceiptAcknowledgement and
AcceptanceAcknowledgement.  So, for example, if
"isNonRepudiationReceiptRequired" = "true" then a sending BSI will
expect to create and send a signed receiptAcknowledgement business
signal and a receiver BSI should validate the signature and persist the
signed 
receipt.  3    The form of the business signal should be defined by a 
schema.  In
BPSS 1.1 there is no place to do that so it is left to CPA Package
element.
There is no explicit link of the business signal definition to the
corresponding transaction activity in which it is used - but CPA2.0
defines a controlled vocabulary of names for the signals so a BSI will
just look for a signal definition "receiptAcknowledgement" (for example)
in a CPA. BPSS 2.0 overcomes this slight ambiguity and explicitly
defines the signals and related them to the transaction.

So far, so good.  My problem is with how to implement non-repudiation of
receipt:
1    The CPA spec says that when transaction characteristic
"isNonRepudiationReceiptRequired" = "true" then the CHANNEL should
specify (through ebXML messaging binding) that the ebXML technical
acknowledgement should be signed.
2    The BPSS spec says that when "isNonRepudiationReceiptRequired" =
"true" then the receiptAcknowledgement business signal (which is NOT the
same thing as the ebXML MS technical ack) should be signed.

So the risk is that we have two message handlers from two different
vendors, both consuming a CPA with a transaction that says
"isNonRepudiationReceiptRequired" = "true".  One might interpret that to
mean that the ebXML MS technical ack should be signed.  The other might
interpret that to mean that a receipt acknowledgement business signal
must be created and signed (and persisted).  Both could argue they are
correct.
But the result is an interoperability failure.

In my opinion, the CPA is treading on dangerous territory when it starts
to express business semantics like that.  I would say that
"isNonRepudiationReceiptRequired" = "true" means that a signed
receiptAcknowledgement business signal.  And that is the only
interpretation.  If, in the CPA, the Chanel specifies that technical
acknowledgements should be signed then that is a totally separate thing
- validated by the MSI only and not associated with the setting of the
transaction characteristic - which should ALWAYS be regarded as a parter
specific override of the global values in the BPSS.

For me this needs clarification or the specifications are not
implementable.

Comments?
Steve Capell
Red Wahoo
www.redwahoo.com p: + 61 2 94383700
m:+ 61 410 437854
f:  + 61 2 94392738