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

["David RR Webber \(XML\)" <david@drrw.info>]

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" <Monica.Martin@Sun.COM>
Date: Tue, August 22, 2006 7:55 pm
To: steve capell <steve.capell@redwahoo.com>
Cc: "'ebXML BP'" <ebxml-bp@lists.oasis-open.org>, James Bryce Clark
<jamie.clark@oasis-open.org>, Dale Moberg <dmoberg@us.axway.com>

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