Re: Issue 4951 -- Reformulation

Hi

I agree with the comments made during the concall that this suggestion needs to be talen with a grain of salt,
if WS-Security provides guidelines people are looking for in cases like this then it'd be better to refer to WS-Security.

That said, I think this suggestion is more generic. While in this specifc case we're talking about RM and Security, there'll be other cases when the issue of ordering will arise. As such, the idea of custom domain-specifc assertions specifying the needed ordering (as suggested by Chris and I believe by Dan Roth at some earlier stage) seems to work well...
"Ordering" as a concept does not seem to fit well into the framework; it may be important for some domain-specific scenarios, but it's difficult to see how it can be generalized, for ex, what a policy engine can do with such ordering constraints ? 
By the way, when a policy engine start processing All operator, I'm not sure it can be guaranteed it will get the assertions in the same order as was desired by the policy author, for ex :
<Policy>
<AllinOrder>
<B/>
<A/>
</AllinOrder>
</Policy>

Is there any guarantee that the XML processor will give <B/> first to the policy engine. In most case it will probably happen, but ensuring the engine will always get assertions in the right order might complicate the processing and might make such expressions less portable.
Anyway, when relevant specs advise on the ordering of processing then it's good, otherwise custom assertions seem like a working and lightweight solution.  

Cheers, Sergey

----- Original Message ----- 
From: "Sergey Beryozkin" <sergey.beryozkin@iona.com>
To: <ashok.malhotra@oracle.com>; "David Orchard" <dorchard@bea.com>
Cc: <public-ws-policy@w3.org>
Sent: Wednesday, September 26, 2007 4:54 PM
Subject: 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

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