Re: Issue 4951 -- Reformulation

Hi

What about a custom assetion Chros talked about ?
If your application falls in that 20% area then why don't just come with a domain-specific
assertion like <RMFirstSecuritySecond/> and use it like this :

<Policy>
<!--What needs to be done first, RM or Security ? -->
<RM/>
<!--What needs to be done first, RM or Security ? -->
<Security/>

<!--RM wins -->
<RMFirstSecuritySecond/>
</Policy>

Cheers, Sergey

----- Original Message ----- 
From: "ashok malhotra" <ashok.malhotra@oracle.com>
To: "David Orchard" <dorchard@bea.com>
Cc: <public-ws-policy@w3.org>
Sent: Tuesday, September 25, 2007 9:57 PM
Subject: 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

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Received on Wednesday, 26 September 2007 15:57:28 UTC