Re: Issue 4951 -- Reformulation

Thanks, Dave!  That's a good note.

I think there is a problem there but I also realize that if we wanted to 
attack this problem seriously it should have been brought up earlier.  
The simplest solution I have is to add an AllInOrder operator but that 
requires a change to the Framework.  Other solutions, such as a Policy 
Constraint  language that Monica has talked about are even more 
heavyweight.  And, as you say, with a few band-aids, things sort of work!

So, here is what I suggest:
- We close issue 4951
- I work on additional wording for the Guidelines which would go in as a 
Last call comment
  (all help gratefully appreciated)
- We may want to open a vNext issue

All the best, Ashok

David Orchard wrote:

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


-- 
All the best, Ashok

Received on Tuesday, 25 September 2007 20:58:45 UTC