[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:dmoberg@axway.com] [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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]