MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ebxml-msg] Business (Legal) analysis of ebMS 3.0
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
>