RE: RosettaNet response to ebXML MSS 0.98b

["Burdett, David" <david.burdett@commerceone.com>]

Pete/Chris

Comments marked below with <DB></DB>

David

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Saturday, April 07, 2001 6:44 AM
To: Pete Wenzel
Cc: ebxml-transport@lists.ebxml.org
Subject: Re: RosettaNet response to ebXML MSS 0.98b


Pete,

Thanks for the careful and detailed gap analysis of RNIF and ebXML.

Your comments will be formally logged and the disposition will be 
based on email discussion on the list as well as in con-call votes 
(if it comes to that) in the next few days.

You may want to subscribe temporarily so that you are part of the 
discussion.

My comments/responses follow. They represent my views, not necessarily
those of the rest of the team.

Cheers,

Chris

Pete Wenzel wrote:
> 
> Chris, Ralph and Ian, a comparison and gap analysis between RNIF 2.0
> and ebXML MSS 0.98b resulted in this list of issues.  Anyone who would
> like to discuss these items or needs more information should feel free
> to contact me.  Thank you.
> 
> 1. ebXML does not allow headers to be encrypted; RNIF 2.0 does allow
> Service Header to be encrypted.  There is too much sensitive
> information in the header (what business processes/actions are being
> executed between the participants, for example).  While SSL offers
> some protection, it is limited to point-to-point, leaving headers
> exposed to third-party transaction routers, and at the internal hops
> before and after SSL.  Further, SSL is not available in most SMTP
> implementations.
> 
>   An alternative is to encrypt the entire RNIF 2.0 package (with full
> headers) in a payload container and fill in ebXML header/body elements
> generically, but this does not allow RosettaNet users to take
> advantage of the ebXML MSS specification fully, for cases in which
> header encryption is required.

We acknowledge this limitation, but in truth, we feel it is only
temporary (inability to apply persistent confidentiality to 
selected header information). We have had the W3C XML Encryption 
identified as the technology/mechanism that will allow for
selective encryption of header and body when that technology becomes
available, probably some time in the next year or so.

In the meantime, S/MIME or PGP/MIME can be applied to the payload
objects if persistent confidentiality is required for the
application payload information. 

As you correctly cite, SSL (or IPSEC) may be used to provide
for transient confidentiality, e.g. on the wire of messages, but this
clearly doesn't protect the message from intermediary access,
nor does it protect the message once it is inside the sending or
receiving
enterprise (where in truth is is far more vulnerable!)

It does, however, satisfy the 80/20 rule in that we believe that
this level of security is adequate for a large majority of
prospective users and the technical approach that would need to have
been applied to allow for selective encryption of header elements
would have significantly increased the complexity of the
solution space to a point that it might become impractical if
not impossible to engineer a low-cost solution that could be
targeted to SMEs.

<DB>I agree.</DB>

> 
> 2. The RNIF 2.0 Receipt Acknowledgment contains the Message Digest of
> the original message.  This is stronger proof than ebXML's inclusion
> of the MessageHeader.MessageData.RefToMessageId, because it does not
> depend on the originator having generated a truly globally unique ID.

This is currently under discussion. In fact, the Business Process
specification has adopted the RNIF Receipt Acknowledgment and we
are working towards a process of reconciling the specifications.

<DB>I am re-working the Acknowledgment and Delivery Receipt elements. I will
include a field to hold the digest.</DB>


> 
> 3. Non-repudiation of Relay message is not supported by ebXML.  While
> RNIF 2.0 also does not yet allow for this feature, it is an important
> member requirement that will affect future direction decisions.

I'm not sure that I understand what a Relay message is. Are you
talking about NR of messages exchanged p2p between nodes of a network
of RNIF systems (what we have called intermediaries) as a message
works its way from To->From?

Can you please explain why the extension mechanism isn't
adequate to your needs if the feature you require is not
directly supported?

> 
> 4. ebXML supports multiple digital signature components.  Suggested
> use cases for this feature would be desirable.

If a message is augmented as it passes through an intermediary
it might be desirable to have the intermediary sign the augmented
message. Of course, this requires that the signature of the originator
of the message not be invalidated by the change, but that is another
matter.

Another use case is a message generated by an individual, signed
by her certificate keys, that is authenticated by her enterprise
and asserted so by including a signature generated with the
certificate of the enterprise authentication service.

See the work being done in the OASIS Security Services TC on
SAML.

> 
> 5. RNIF has the concept of UnknownInitiatingPartner that includes
> explicit routing information (URL) for the (unknown) initiator.  It is
> not clear where this information could be carried in ebXML.  If this
> is not included, initiator's information would have to exist in a
> registry.

Quite possibly. In truth, there is no reason why the URL may not be
used as the identifier.

<DB>I agree. A PartyId can contain a URL such as an SMTP or HTTP
address.</DB>

> 
> 6. RNIF also has a locationID that allows partner identification to
> be more granular than DUNS+4.  It is not clear how one might encode
> DUNS+4 plus additional locationID in ebXML.

<DB>Again, the PartyId can be any URN, so you could have URN along the lines
of urn:duns.com:id:1234578:locn:1234
What ebXML has not done is define the structure of PartyId.</DB>

> 
> 7. RosettaNet PIP(tm) specifications define three levels of process
> granularity:  (process, activity, and action).  ebXML BPSS defines
> only two (transaction and activity).  This difference is evident in
> the design of the MSS Service and Action elements.  It is not clear
> how to specify a RosettaNet process-activity-action instance using the
> ebXML headers without resorting to RosettaNet-specific extensions.

The BPSS defines a process in terms of a collection/choreography
of transactions and activities. The CPA identifies a specific BPSS
(ProcessSpecification) for a given CollaborationRole. The ServiceBinding
is the technical mapping for the identified role in the BPSS.
The ServiceBinding name == the Service element in the TR&P header.
The Action equates to a request/response in a conversation. It is
expected that the conversational state is maintained such that
the mapping to the correct handler can be achieved.

The CPAId and ConversationId provide all of the other contextual
information needed to effectively process the message.
<DB>To make life easier for RosettaNet (and possibly other folks), I think
we should include a non-mandatory "ProcessId" within the ebXML header that
was defined along the lines of "Identifies the business or other process or
protocol that identifies the sequence in which messages are exchanged
between the parties involved". Pete. Would this help?</DB>


> 
> 8. RNIF Delivery Header element isSecureTransportRequired is used by
> an intermediary router, to select a secure transport mode (or not).
> In the absense of this, router would have to have out-of-band
> information (access to the parties' TPA or process specification)
> to make this determination.  Suggest adding this indicator to
> QualityOfServiceInfo.

Good point.
<DB>I agree, Chris, do you want to draft the suggested changes?</DB>

> 
> 9. RNIF inReplyTo.ActionControl.ActionIdentity element tells what type
> of message is being responded to.  This is implied by a combination of
> the process specification and RefToMessageId, given some effort to look
> them up first, but some implementations find it useful to have this
> information in the header.
>
> 10. RNIF's GlobalUsageCode is used to indicate test mode, negating the
> legally binding effect of transactions that aren't meant to be
> enforced.  Without it, out-of-band legal agreements must likely be
> made in order to distinguish binding transactions from testing.

This issue was discussed ad nauseum a while back (late last year I
believe)
and we concluded that because you could extend the message envelope,
that we need not provide for this.
<DB>Agreed</DB>

> 
> 11. RNIF Service Header contains KnownInitiatingPartner, which remains
> constant throughout the conversation.  This, can be determined through
> analysis of the choreography specification and "From" element of logged
> messages, but not easily.

In the present version, we only consider the exchange of messages
between two parties. This describes a collaboration between multiple
parties. That is a horse of a different color;-) We will need to
address multi-party collaborations in whatever comes next for ebXML.
<DB>Agreed</DB>

> 
> 12. There is confusion about the differences between ebXML MSS
> Header.ErrorList and ebXML BPSS ExceptionSignal (payload message);
> also between Body.Acknowledgment and BPSS
> Receipt/AcceptanceAcknowledgment Signals.  They seem to serve the same
> purpose.  Clarification is needed to determine under what conditions
> the MSS elements would be used, as opposed to the BPSS content.

Yes, I have raised this issue with BP team. 

<DB>I agree there is confusion. What I think we should do is have three
types of errors:
1. SOAP related errors (i.e.l SOAP Fault) which report errors with SOAP
2. ebXML TRP errors (i.e. TRO ErrorList) which report other errors with the
message, apart from errors in the Payload, and
3. Business Process errors (i.e BPSS ExceptionSignal) which report errors
with the Payload or other aspects of the business process.

This then provides a very clear layering between the three. Thoughts?</DB>

> 
> --Pete
> Pete Wenzel <Pete.Wenzel@RosettaNet.org>
> Chief Technical Architect, RosettaNet
> On Loan from SeeBeyond
> +1-626-577-5784 (US-Pacific)