RE: [ebxml-msg] Business (Legal) analysis of ebMS 3.0

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: RE: [ebxml-msg] Business (Legal) analysis of ebMS 3.0

Andy:

>I would also appreciate if a clarification could be given if  ebMS
>includes the ebMS Acknowledge (intermadiary and party) found in ebMS 2.0?

The Reliability processing, as Ian said, will do the Acknowledging. As it will very likely comply with WS-Reliability, these acks will not formally be considered as "ebMS acks" (no ebMS headers involved). Yet the ebMS layer will transparently "package" reliability as any of its other features. Also we have identified one case that WS-Reliability does not cover, and for which an ebMS ack will be needed. About overhead, keep in mind that all acks can be batched (implementation decision), e.g. one ack be generated for a set of 100 messages, or every minute, etc. Intermediaries will very likely not ack in ebMS 3.0 unlike in ebMS 2.0 - reliability is considered an end-to-end QoS, and intermediate acks seem to add little value, not worth the complexity.

>... The first time an indication of receipt
>reaches the originator the originator knows that the message was
>properly received. If the originator get HTTP 2xx its an Ack but its an
>Ack with poor non-repudiation properties. A signed ack would be better
>but does not change the *fact* that the message was received. If the
>reciver disputes that he got the message then the originator may claim
>access to recivers information system and if the data message is found
>there the ruling will most likelly be that the data  message was
>properly recieved.

To give you a current status on non-repudiation issues in the TC:
he "reliability" Ack is not intended to be used for non-repudiation of receipt in 3.0 (although ebMS 2.0 provides for this usage, with signing of the Ack.)

Indeed, non repudiation of receipt involves usually more than just receiving the message:
the payload must also pass at minimum a basic validity test, which would guarantee
that the message had business value so that the receiver party can/could process it.
This validation may just be a schema validation of the expected business document (in case of XML payload). This calls for an Ack at different level - rather called a "Receipt"

that can be used for non-repudiation once signed. These are usually defined as part of the
business transaction choreography (e.g. RosettaNet PIPs, OAG collaborations) and ebXML BPSS supports these.
Now, the question we have been debating is whether ebMS 3.0 could in fact support these
receipts (e.g. have them generated by the MSH instead of having them initiated by the process layer). That could be possible when a receipt does not require much beyond schema validation, which could be a "payload service" in ebMS 3, supported by the MSH - but that should again just be an option (in some cases, to have legal meaning such receipts might be sent only after more advanced validation).

But the idea is to not overlaod reliability Acks with additional non-repudiation semantics like in ebMS 2.0. (also for other reasons that I do not detail here)

Jacques

-----Original Message-----
From: Anders W. Tell [mailto:anderst@toolsmiths.se]
Sent: Friday, November 19, 2004 12:07 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Business (Legal) analysis of ebMS 3.0

Hi,

Im doing an analysis of some protocols from a business (and legal)
requirements point of view. ebMS is one of analysed protocols. One area
of concern is Acknowledge of Receipt funcitonality and rules of
evidence. Looking at the older may 3.0 draft it seems as if ebMS
proposes, for some patterns, acknowledgements 5+1+1 times which seems to
be rather many.

Could someone pointme to the latest ebMS spec so I have the latest info
available?

I would also appreciate if a clarification could be given if  ebMS
includes the ebMS Acknowledge (intermadiary and party) found in ebMS 2.0?
thanks
/anders

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/members/leave_workgroup.php.