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

["Anders W. Tell" <anderst@toolsmiths.se>]

Thanks for the clarifications Jacques!

Jacques Durand wrote:

> 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.
>
In many discussions the layering comes up as a key component. I ve asked 
numerous people about how and why (business information system) layering 
has a business/legal meaing but I got few answers. Im trying to 
understand the layering argument(s) better and could you share ebMS 
groups reasoning on this topic?

> 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.
>
There may be an important value for Interediary Acks. From Aerospace 
Industries Association, Inc.in their Global Trading Partner Agreement 
(GTPA)

"6. MEANS OF TRANSMISSION
....
(B) Each party warrants that its Service Provider has been placed under 
a contractual obligation stipulating that in performing its services, 
the Service Provider shall make no change to Data and shall not disclose 
such Data to any Third Party without prior written approval."

Here intermedieries/service providers are under contactual obligations 
and an Intermediary Ack seems resonable.

> >... 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.)
>

With respect to functions the Aerospace Industries Association, Inc.in 
their Global Trading Partner Agreement (GTPA) defines Ack as: "(A) 
“Acknowledgment” means an electronic indicator verifying receipt or 
access of the Data."
which seem to be consistent with the first Ack sent .


> 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.
>
Yes, and the exact requirements may vary from legal domain and 
applicable laws.

> 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"
>
Layering seems to be a key motivating factor and I would appreciate any 
comments on how layering (in this sense) is legally releant?

> 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).
>
A good differentiation to keep in mind is between legal 
relevanece/meaning/effect and evidentiary value. A data message sent 
with a proper signature could be expected to have better evidentiary 
strength in order to prove or disprove an existence of a fact.

> 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)
>

Is there a summary somewhere on this reasoning?

thanks
/anders

> -----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.
>