Specification Schema extract

[Martin W Sachs <mwsachs@us.ibm.com>]

Karsten,

Here are my thoughts on the "reliability levels" extract from the
specification schema that you sent.

Covering note:  It seems to me that there is a big difference between
persistent and non-persistent security, which is spelled out in the
extract.

   Persistent:  Must be encrypted at the application level and delivered
   encrypted to the receiving application.  I think that this would be
   controlled in the Process Specification Document and not in the delivery
   channel in the CPA.

   Non-persistent:  Encryption takes place in the transport (e.g. SSL);
   decryption takes place in the receiving transport and the document is
   passed in the clear to the receiving application.  I think that this
   relates to the "need proper definition" notation in "Document Flow
   security".  If IsSecureTransportRequired is "yes" but persistence is not
   required, the CPA must specify an encrypting transport.

   If persistence is required, the CPA should not specify an encrypting
   transport since encrypting and decrypting is at the application level.

1.1, "How to use the Specification Schema..."

   Second paragraph ("specifically used to instruct the CPP and CPA"):  I
   have been assuming that these attributes inside the Process
   Specification document are effectively defaults or recommendations and
   they may be overridden by values of the corresponding attributes in the
   delivery channels in the CPP and CPA.  Currently the CPP-CPA spec states
   that when the CPA and Process Specification document are installed in
   the runtime, the values in the CPA override the values in the Process
   Specification document.

   To keep terminology consistent, please replace "channel" by "delivery
   channel" throughout the Specification Schema spec.

   Fourth paragraph: possibly terminology mismatch.  I am not sure what
   "transport facility and transport service level" are.  In the CPP-CPA
   specification, there is a Transport element which specifies the protocol
   (e.g. HTTP) and transport security (e.g. SSL), and there is a
   DocumentExchange element which specifies the message-service parameters.

1.1.1.2 Document Flow security

   I infer that IsSecureTransportRequired is effectively equivalent to the
   combination of isConfidential, isTamperProof, and isAuthenticated in
   which the values of all three are either "yes" or "no".  If I am not
   interpreting it correctly, then more words of explanation are needed.
   In particular, an explanation is needed of how the set of values of the
   four attributes is to be interpreted.
   For example:  if IsSecureTransportRequired = "yes", does this override
   the value "no" for the other three?

1.1.2 Reliability:  Does IsGuaranteedDeliveryRequired" control whether
reliable messaging must be specified in DocExchange (i.e. CPA must specify
that the Message Service use reliable messaging)?  If not, what?  If so, it
should be so stated.

1.1.3 Synchronous or Asynchronous:

   Does this indicate that the messaging service must use synchronous
   replies?  This would have to be specified in the CPA.

   If this actually relates to the use of business signals, so far there is
   no means of specifying this in the CPA.  At the Boston F2F (12/00),
   business signals were viewed as strictly a middleware (BSI?) matter and
   nothing is needed in the CPA.

1.1.4.1  Action security

   It appears that isAuthorizationRequired is strictly a business-level
   issue and as of now there is nothing is the CPA to cover it.  The
   software would go strictly on the basis of the attribute in the Process
   Specification Document.

1.1.4.2 Non-Repudiation

   There is a non-repudiation element under the CPA DocExchange (message
   service) element.  However it does not distinguish between origin and
   receipt.  If one or both attributes is "yes", signing would be applied
   to both requests and responses.  Also, I recall from the Boston F2F that
   some of the business signals are involved.  As I noted above, thus far,
   these are not covered in the CPA at all.

Regards,
Marty


*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Karsten Riemer <Karsten.Riemer@east.sun.com> on 03/14/2001 04:21:00 PM

Please respond to Karsten Riemer <Karsten.Riemer@east.sun.com>

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   ebxml-tp@lists.ebxml.org, ebxml-bp@lists.ebxml.org
Subject:  Re: next conference call



Marty and TP team,
The specSchema group is up against the March 19th deadline too,
and I apologize for not having had the bandwidth to participate in your
meetings. I have reworked, mostly editorially, a number of the sections of
the
spec schema  document, and I would like to hear opinions on the TP related
section attached here. There are no new concepts, just a rearranged
presentation. Does the division into channel related attributes and BSI
related attributes make sense to you? What do you recommend for the final
solution to the secure transport persistent vs. non-persistent. The BP
folks
didn't see a need for the distinction.

Note the attached is a cut and paste from a doc that is in progress, so
there
may be typoes, mis-cut-and-pastes, etc., but please comment on the basic
message it gives.

-karsten