- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Wed, 26 Sep 2007 08:01:20 -0400
- To: "David Orchard" <dorchard@bea.com>
- Cc: ashok.malhotra@oracle.com, public-ws-policy@w3.org, public-ws-policy-request@w3.org
- Message-ID: <OF58E0D4DE.7D63A0B4-ON85257362.003F0C3B-85257362.0041ECD9@us.ibm.com>
+1 Christopher Ferris STSM, Software Group Standards Strategy email: chrisfer@us.ibm.com blog: http://www.ibm.com/developerworks/blogs/page/chrisferris phone: +1 508 234 2986 public-ws-policy-request@w3.org wrote on 09/25/2007 12:34:59 PM: > > 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 Wednesday, 26 September 2007 12:01:44 UTC