- From: David Orchard <dorchard@bea.com>
- Date: Tue, 25 Sep 2007 09:34:59 -0700
- To: <ashok.malhotra@oracle.com>, <public-ws-policy@w3.org>
Ashok, I had long thought that XML and Web services needed a generalized solution for embedding the "order" of operations in the instance document. I proposed a simple model at the XML processing model workshop many years ago. But it seems to me that things "kind of work" without it. Imagine a document that is described/defined by XML Schema with an Xinclude and XSLT. Schema gets done first, then "typically" Xinclude then XSLT. Now obviously the order of these could be inverted for some useful applications. But the complexity of the solutions, such as the one embodied in Xproc, seems to outweight the benefits of a "default" processing order. Now it may be that Xinclude deployment has been slow because there hasn't been an order of processing. But I'm always leery of blaming lack of adoption of one technology on missing other technology because that "problem" usually means that the first technology is problematic or there is low demand. If there was demand, it would happen. The topic also came up at the Web Services Workshop, in the Web Services Architecture Working Group, and in each of the WS-* working groups or TCs. I remember being dismayed that WS-Security was the "first" out of the chute for WS-* specs and only specified order for security. What if RM needed to happen in between signing and encrypting? But, it seems that if we again adopt a default model of security last on outbound and first on inbound, we can hit the 80/20 point of applications vs complexity. The number of applications where order matters that cannot be solved by the current technology seems small. I will observe that this "default" order appears to bring back the notion of layering of protocols that the flat SOAP header structure dispensed with. In the example of RM + Security, we do this "on the web" by using tcp/ip then layering SSL. This "layering" is approximated in SOAP by having security always last, aka another layer. Having said all that, if we imagine what a solution might look like that would allow order of assertions, then there appear to be considerable complexities that emerge. For example, if we wanted the ws-security applied to all headers, then RM applied after, then the new "order" header inserted, we'd have this multi-pass security model. The RM header and the new order header would probably need some kind of security, otherwise what's the point of having the rest of the message secure? The choices are: 1) have a message with security on most but none on RM and Order of processing; 2) re-apply security after the RM and Order of Processing meaning there are 2 passes of security. I find it hard to justify the costs to develop such technology for the limited applications. I think what's really needed is at least one "killer app" where Order of processing had to be in the message, and I haven't heard anything other than "abstract" or "what ifs". Cheers, Dave > -----Original Message----- > From: public-ws-policy-request@w3.org > [mailto:public-ws-policy-request@w3.org] On Behalf Of ashok malhotra > Sent: Wednesday, September 12, 2007 11:55 AM > To: public-ws-policy@w3.org > Subject: Issue 4951 -- Reformulation > > > Here is a reformulation of issue 4951 based on discussion on > morning's telcon. Thanks to Paul Cotton for contributing to this. > > The issue has to do with ordering between assertions. The > spec says that users can write special assertions that > control the ordering between assertions. Examples are the > "sign before encrypt" and "encrypt before signing" assertions > in WS-Security Policy. But the interesting issues come up > when ordering is desired between assertions from different > domains, for example adding RM headers and encrypting the > headers. In such cases, which namespace does the ordering > assertion go? > > The other response to this issue is that the semantics of > each assertion includes the ordering information. I think > this is problematic. > > Consider a universe of assertions U that includes assertions > A1, A2, ... An. Assume further that the semantics of each > assertion Am indicates its ordering wrt all other assertions > in U ... or at least the assertions where ordering matters. > Now, we add another assertion X into the universe U. Not > only do we need to specify the order of X wrt all the > assertions in U, we have to change the semantics of all the > existing assertions in U to specify the order wrt X. This > seems to be a problem to me. > -- > All the best, Ashok > >
Received on Tuesday, 25 September 2007 16:36:00 UTC