RE: [ebxml-bp] Re: ebBP Implementation question - BPSS & CPA conflict regarding non-repudiation

Monica,

 

I also recall that the CPPA team had extended discussions as did we
around 2.0.3 and the alignment of conversations - handling failure and
time outs and signals interactions.  I beleive those discussions
were most complete - and especially Anders input on Swedish use cases
and needs.

 

I would note that with the new BPSS 2.0.3 and the pending ebMS/CPPA
v3 work - we have the best combinations yet available anywhere for more
precise orchestrations.

 

However - clearly nothing can ever be guaranteed to be 100% !

 

Also - in terms of the role of the CPPA itself - I'd say it is
encumbant on partners and industry groups to ensure that across their
own collaborations that they have common and consistent functionality
and interpretation.  The notion of a CPA has always contained that
- an agreement around the terms of operations.

 

If we look for examples of industry groups doing exactly this - I
would point to the ebXML adoption by the agricultural chemical industry
here in the USA - and to government adoptions such as NIA in Norway as
models of alignment of infrastructure.

 

Seems to me that this is where clarifications can occur and
implementers provide guidance as to the use patterns they expect and
best-practice within an industry.  

 

Our OASIS TCs in providing the specifications are offering the
common framework - and while we can anticipate most common use patterns
- there's always going to be room for people to interpret the intent
slightly differently - and we cannot legislate against
that!

DW

-------- Original Message --------
Subject:
[ebxml-bp] Re: ebBP Implementation question - BPSS &
CPA
conflict regarding non-repudiation
From: "Monica J. Martin"
<>
Date: Tue, August 22, 2006 7:55
pm
To: steve capell <>
Cc: "'ebXML
BP'" <>, James Bryce
Clark
<>, Dale Moberg
<>

>capell: Hello
all,
>
>It has been a while since I posted to this group..
:-)  
>  
>
mm1: We appreciate your comments
and questions. I don't believe your 
post actually was logged to
ebBP email list and may have bounded. May 
need to speak with OASIS
about that.  We'd appreciate if you would log 
any comment to
the comment form too (See:

http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=ebxml-bp).

>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.
>
mm1: The CPPA may override.

>
 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.
>
mm1: This has changed in ebBP v2.0.3 whereby the
type and structure of 
business signals are defined. In addition,
user defined signals are 
possible.

>here 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.
>
mm1: In the
context of ebBP v2.0.3, the BT patterns include the signals 
and map
to the BT and the BTA that implements it. See examples on our 
public
web site.

>
>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.
>
mm1:
There have been significant discussions between CPPA and ebBP

teams. I'd direct you to the latest working draft to CPPA v2.1 and
ebBP 
v2.0.3. Dale can provide more specifics although there can be
multiple 
delivery channels and there are signature requirements on
messaging 
characteristics. Two points here (and I defer to Dale),
business signals 
can be specified in addition to message signals in
CPPA and I've not 
addressed if the domain agrees to delegate to the
messaging layer.

>
>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.
 
>
mm1: Perhaps we should speak about the alignment that
has occurred 
before making any conclusions.

>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.
>
mm1: See previous
comments. Defer to Dale on more specifics in the 
context of
CPPA.

>
>For me this needs clarification or the
specifications are not
implementable.
>
>Comments?
>
mm1: See previous
comment on conclusions.
Thanks.

>
>
>
>Steve Capell
>Red
Wahoo
>www.redwahoo.com 
>p: + 61 2 94383700
>m:+ 61
410 437854
>f:  + 61 2 94392738
> 
>This email
message and any accompanying attachments may contain
information
>that is confidential and is subject to legal
privilege. If you are not the
>intended recipient, do not read,
use, disseminate, distribute or copy this
>message or
attachments. If you have received this message in error,
please
>notify the sender immediately, and delete this message.
Any views expressed
>in this message are those of the individual
sender, except where the sender
>expressly, and with authority,
states them to be the views of Red Wahoo Pty.
>Ltd.
>

>Before opening any attachments, please check them for viruses
and defects.
>We do not accept any liability for loss or damage
which may arise from your
>receipt of this e-mail.
>

>
>
>  
>