W3C home > Mailing lists > Public > public-ws-policy@w3.org > September 2007

Re: Issue 4951 -- Reformulation

From: Monica J. Martin <Monica.Martin@Sun.COM>
Date: Tue, 25 Sep 2007 15:04:39 -0700
To: ashok.malhotra@oracle.com, David Orchard <dorchard@bea.com>
Cc: public-ws-policy@w3.org
Message-id: <46F985F7.10407@sun.com>


>> orchard: ...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".  
>
mm1: Dave, thanks for this post. We (Fabian, our security experts and I) 
discussed this similarly. Taking Fabian's case from last week's call, we 
assessed what could potentially transpire. If you had a policy assertion 
that indicated for example to encrypt all headers and you use RM, how is 
unspecified. Two examples of how could be:

    * Add all the headers first, then apply encryption in one shot.
      (most common case)
    * Apply the encryption whenever you add a header.

This could infer that despite the order implicitly assumed in the policy 
assertion, the processing logic used may vary (behavior and use). This 
is a simplistic approach that doesn't account for more complex 
requirements (your 80-20 rule). Thanks.
Received on Tuesday, 25 September 2007 22:02:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:53 GMT