Re: ebBP Implementation question - BPSS & CPA conflict regardingnon-repudiation

["Monica J. Martin" <Monica.Martin@Sun.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.
> 
>
>
>  
>