OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ebxml-msg] Intermediary I-cloud "requirements" draft

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


From: Ben Malek, Hamid [mailto:HBenMalek@us.fujitsu.com]
Sent: 09 February 2008 05:42
To: ebxml-msg@lists.oasis-open.org
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]
Sent: Friday, February 08, 2008 11:35 AM
To: Ben Malek, Hamid; ebxml-msg@lists.oasis-open.org
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).





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]