Re: RosettaNet response to ebXML MSS 0.98b

[christopher ferris <chris.ferris@east.sun.com>]

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.

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

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

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

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

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

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

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

> 
> --Pete
> Pete Wenzel <Pete.Wenzel@RosettaNet.org>
> Chief Technical Architect, RosettaNet
> On Loan from SeeBeyond
> +1-626-577-5784 (US-Pacific)
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard