Hamid,
Several people including me have attempted to provide requirements as
input to this discussion, based on actual end user requirements (including
requirements from communities that today use some form of intermediary using a
ebMS 2.0 or other protocols). These requirements are not confidential at
all and have been shared with the TC, in earlier TC meetings and also in
postings like:
http://www.oasis-open.org/archives/ebxml-msg-comment/200709/msg00000.html
Since you
seem to be unaware of this, perhaps we need to formally document these requirements
in a requirements document, then score them (e.g. MoSCoW) against user
requirements. Anyone proposing a particular solution should then attempt to
match those requirements against the capabilities of the solution. If the
attempt to align with other standards and profiles leads to a solution that does
not support some of the essential user requirements, the question is what
problem that solution solves.
Pim
From: Ben Malek, Hamid [mailto:]
Sent: 09 February 2008 05:42
To:
Subject: RE: [ebxml-msg] Intermediary
I-cloud "requirements" draft
David, I like your
“Sender Rights”. I actually agree with them because I prefer to give more rights
to the sender versus the I-Cloud. The I-Cloud is servicing the sender and not
the other way around J
Date, See inline my
comments …
From:
Moberg Dale [mailto:]
Sent: Friday, February 08,
2008 11:35 AM
To: Ben Malek, Hamid;
Subject: RE: [ebxml-msg] Intermediary
I-cloud "requirements" draft
[Dale]:
We have
use cases from CDC and EU,and these of course are a source of our
“requirements” The goals I listed were features that have come up as we
have been reviewing solutions for portions of the use cases. The features are
those whose absence has counted against solutions and whose presence was a “good
thing” (sm).
[Hamid]: Well, I
never saw the use cases from CDC and EU you are talking about. Are these
confidential information in Axway that cannot be shared? If they are not
confidential, I will be very happy to look at them if you could please share
them with us.
[Dale]:
I have a
very iterative view of the design process, so I think talk of axioms is bogus
worship of a logician’s reconstruction of mathematics. And I don’t think the
iterative solution process we are engaged in benefits from setting down “axioms’
– we don’t know that the models we can build (out of the specifications we are
building upon) can simultaneously satisfy your “axioms,” and many of the
things you are setting down are not understood the same way and are not at all
self-evident.
[Hamid]: Please
don’t take my words as offensive. I never meant it that way (I honestly
apologize if I may have slightly offended you in anyway). Let me just clarify
this: all I meant by my “design principles” is to guide any proposed solution to
the right path. It does not matter if we are using an iterative process or not,
the design principles are important to prevent any proposed solution from
drifting away to the world of “very bad and trashy solutions”. However, I must
say that the design principles are also of iterative nature (they are not
absolute and they may be changed slightly as a consequence of another iteration
on the requirements, but they have to be there along the process). I never said
the requirements are serving the design principles. It is the other way around:
the design principles are serving the requirement, and that’s why they have to
come after the requirements and goals have been fully specified (thus the order
flow, which does not contradict or oppose in any way an iterative
approach).
[Dale]:
Type of
message means the kind of collaborative information it contains. Service and
action indicate a message type, for example. Remap refers to a change in the
routing map, where messages from an original sender of a given type go to a new
recipient, but nothing has changed in the configuration of the original
recipient relevant to sending the message of that type.
[Hamid]: I see. But
what you are describing is nothing new. This is also implicit in principle #5.
If I say that two MSHs doing peer-to-peer must not change their implementation
(and even their configurations to make you happy) to switch from peer-to-peer to
Multi-hop, that’s exactly what you are saying. However, the word “new receiver”
is still bothering me. The ultimate receiver is a party application that has a
partyId. If I talk (peer-to-peer) with a partner called “sun.com”, and then I
switch to a muti-hop, and on the other side of the I-Cloud, there is a cluster
of MSHs behind the last Intermediary, all serving a party application called
“sun.com”, I don’t consider that a “new receiver”. It does not matter though
which cluster node my message might go in order to be finally delivered to a
party application called “sun.com”. As long as a party application with the name
“sun.com” is the one consuming my message, that’s the same receiver.
[Dale]:
Precisely
my point is to indicate that, contrary to your view, transparency is a “more or
less” thing in various dimensions. I could not accept your very clear (but
mistaken) “requirement” because it would mean that intermediaries would have to
violate the SOAP processing model.
[Hamid]: I don’t
ever recall saying that Intermediaries are allowed to modify messages.
[Dale]:
Well, we
could say sign the SOAP body at most. Then only badly behaved intermediaries
would break the signature. And we would want to know about that. We have also
discussed allowing intermediaries adding and modifiying headers, like the WSS
header. That may or may not be useful for certain proposed solutions. I say take
it a case at a time. The wholesale prohibition you espouse is extreme, and is
not directly motivated by features of the use cases.
[Hamid]: It might
be the case that we are not in common agreement on the definition of an
Intermediary. WSS module is not an “Intermediary” for me because it is a
sub-component of the sender MSH itself.
The logic of this
is very simple: Unless there is a requirement that needs to be absolutely
satisfied and as a consequence of this requirement, modification of the routed
message must occur, there is no point in allowing Intermediaries to do so.
There are many situations where it is desirable to also sign the
reliability headers for example (an intruder may modify my sequence numbers or
do something I won’t like). For security purposes, it is safer to start with the
assumption that a sender may encrypt/sign headers + body + attachments. Only if
we cannot find a solution that satisfy both this security concern + the set of
requirements, then, and only then, you start reviewing the set of principles to
see which one you can sacrifice. It is like taking away freedom from Americans
(you first need to prove that there is some kind of great danger such as a
terrorist act, in order to convince people to take away some of their freedom).
The sender has the freedom right to sign/encrypt whatever he likes (for his own
security purposes). So unless this clashes with some extremely important
requirement (which I don’t see yet), only then, I would go along the path to
constrain the sender and take away some of his liberty.
[Dale]:
The
notation hints at a disjunction at this point, because I am uncertain whether
some “modifications” (like telling the sender not to encrypt headers used for
routing) may be appropriately part of a good enough solution.
[Hamid]: No, what
you are talking about is not happening. Let’s take a simple example: Consider
the deployment case which actually you like (because the sender’s configurations
are not changed at all). In this deployment case, I have an extension module
that is deployed after my sender MSH. The extension module is the one
responsible for inserting the headers that are intended to Intermediaries. The
MSH will never be able to sign or encrypt those headers because they are
inserted after the message leaves the MSH sender. Secondly, the headers intended
for the Intermediaries have not been explicitly defined. In one design for
example, you could create a new header called <eb:Routing> for example
that is a direct child of the SOAP header and not within the
<eb:Messaging> element. Another design (the one I tend to prefer) is to
simply profile WS-Addressing: in other terms, instead of creating a new header
<eb:Routing>, I would simply populate WS-Addressing with the information
that the Intermediaries would need to correctly perform their routing job. With
this approach, the MSH sender will never sign/encrypt WS-Addressing (I have
never seen in my life WS-Addressing headers signed/encrypted).
Regards,
Hamid.
