RE: [ebxml-cppa] Proposed schema changes, plus illustrative example

[Dale Moberg <dmoberg@cyclonecommerce.com>]

I am attaching the draft notes for the security changes.
(Yesterday was a school vacation day that I also took off!)

Many issues have been identified in this draft
and are included in the midst of 
the discussion. Since some of the issues interact with
Arvola's proposals, you may wish to consult both
documents for a potential merged view.

Thanks Arvola for the hard work. I will be 
reading the documents today.

Dale

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Monday, October 22, 2001 4:46 PM
To: ebxml-cppa@lists.oasis-open.org
Subject: [ebxml-cppa] Proposed schema changes, plus illustrative example


I like to propose a strawman set of changes to the CPP/A schema to
address
the following issues:
  1.. Clarify the purposes of various certificate references
  2.. Allow both server and client certificates to be specified for
transport level security
  3.. Allow a default delivery channel to be used for multiple actions
with
different Packaging
  4.. Allow multiple override elements for the same action
  5.. Allow a SimplePart to be reused
  6.. Allow multiple types of response to be returned on a synchronous
delivery channel
More specifically, please take a look at the attached XSD file for the
following proposed changes:
  a.. Clarify purpose of CertificateRef under CollaborationRole. See

  CollaborationRole.DefaultSigningCertificate

  b.. Add client certificate for transport security and distinguish
between
client and server certificates. See

  Transport.TransportSecurity.ServerCertificateRef
  Transport.TransportSecurity.ClientCertificateRef

  c.. Clarify purpose of CertificateRef in NonRepudiation element. Add
signing CertificateRef for receiver in case the DocExchange is used in
conjunction with a synchronous delivery channel. See

  DocExchange.ebXMLBinding.NonRepudiation.initiatorCertificateRef
  DocExchange.ebXMLBinding.NonRepudiation.responderCertificateRef

  d.. Make SimplePart a top-level element to allow for reusability.

  e.. Allow ServiceBinding to specify different Packaging for different
actions. (It is not sufficient to provide a single Packaging for one
ServiceBinding because multiple actions with different schemas may not
be
able to share the same Packaging.) Default delivery channel can be
synchronous or asynchronous. If synchronous, packaging for request
message
and packaging for response must both be specified. See

  ServiceBinding.ActionBinding

  f.. Allow action level override within ServiceBinding to specify
(synchronous or asynchronous) channels along with Packaging. If channel
is
synchronous, can specify packaging for the response. Remove uniqueness
constraint on action name to allow both synchronous and asynchronous
channels to be used for the same action, for example. See

  ServiceBinding.OverriddenActionBinding

  g.. Allow for more than one response packaging for a synchronous
delivery
channel because an exception can be returned in lieu of a response. See

  Packaging.CompositeList (maxOccurs="unbounded")
The attached sample CPA is intended to illustrate:
  a.. BPSS instance for a RosettaNet PIP (see attached 3A4.xml).
  b.. CPA for a BPSS business process that corresponds to a RosettaNet
PIP.
  c.. Synchronous and asynchronous delivery channels.
  d.. Packaging used with synchronous and asynchronous delivery
channels.
  e.. Packaging for stand-alone business signals and exceptions.
  f.. Reuse of SimplePart for message header.
If you want to examine the example using an XML Schema aware editor,
please
be aware that xsi:schemaLocation is currently set to be
c:\ebxml\draft-cpp-cpa-02.xsd. The sample BPSS instance cannot be read
using
an XML Schema aware editor because the corresponding BPSS schema is not
provided.

Looking forward to your comments,
-Arvola