W3C home > Mailing lists > Public > public-ws-policy@w3.org > December 2006

Re: Issue 3953 [Guidelines] Update to issue on domain interactions and assertion nesting

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Tue, 19 Dec 2006 14:09:26 -0500
Message-Id: <110CBA75-5025-45C6-9C0A-7E65FFD3FEB4@nokia.com>
Cc: Cotton Paul <pcotton@microsoft.com>, Hirsch Frederick <frederick.hirsch@nokia.com>
To: public-ws-policy@w3.org

Umit and I have a proposal to close issue 3953, <http://www.w3.org/ 
Bugs/Public/show_bug.cgi?id=3953>

The proposal is to replace the following text in the guidelines  
document that comprises section 6 [1]:

""Domain authors must be aware of the interactions between their  
domain and other domains. For example, security assertions interact  
with other protocol assertions in a composition. Although modeling  
protocol assertions may appear to be an independent behavior,  
protocol assertions and security assertions affect transport bindings  
and their interactions must be considered. For example utilization of  
WS-Security Policy with other protocols affects transport bindings  
and would result in nested policy assertions when additional
protocols are composed with WS-Security 2004. Thus, domain authors  
should be aware of the compositional semantics with other related  
domains. The protocol assertions that require composition with WS- 
Security should be particularly aware of the nesting requirements on  
top of transport level security."

with

"Domain authors need to be clear about the relationship of assertions  
defined in their domain and core assertions defined elsewhere such as  
the relationship of security assertions in their domain and the core  
WS-SecurityPolicy assertions. One example is the definition of  
additional assertions related to security in  Web Services Reliable  
Messaging Policy Assertions [WSRMP]. Since any domain might include  
additional assertions related to security it is necessary for the  
assertion author to understand the implication of the entire set of  
policy assertions related to security taken as a whole. [WSRMP]   
<http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-spec- 
wd-11.pdf>"

[1] <http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy- 
guidelines.html?content-type=text/html;%20charset=utf-8#inter-policy>

regards, Frederick

Frederick Hirsch
Nokia


On Dec 5, 2006, at 9:00 AM, Frederick Hirsch wrote:

> This message (and the corresponding update to bugzilla 3953 are for  
> this action noted in the previous agenda:
>
>> d) 3953 - Remove language that use of security policy assertions  
>> forces >nested assertions for other domains, Frederick
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3953
>> http://lists.w3.org/Archives/Public/public-ws-policy/2006Nov/ 
>> 0039.html
>> Status: Frederick to update proposal against more recent  
>> Guidelines doc.
>
> Updated bug 3953: <http://www.w3.org/Bugs/Public/show_bug.cgi?id=3953>
>
> In latest revision of Guidelines [1], the full text in section 6 is:
>
> "Domain authors must be aware of the interactions between their  
> domain and other domains. For example, security assertions interact  
> with other protocol assertions in a composition. Although modeling  
> protocol assertions may appear to be an independent behavior,  
> protocol assertions and security assertions affect transport  
> bindings and their interactions must be considered. For example  
> utilization of WS-Security Policy with other protocols affects  
> transport bindings and would result in nested policy assertions  
> when additional protocols are composed with WS-Security 2004. Thus,  
> domain authors should be aware of the compositional semantics with  
> other related domains. The protocol assertions that require  
> composition with WS-Security should be particularly aware of the  
> nesting requirements on top of transport level security."
>
> (a) In particular, the following sentence needs more elaboration:
> "For example utilization of WS-Security Policy with other protocols  
> affects transport bindings and would result in nested policy  
> assertions when additional protocols are composed with WS-Security  
> 2004."
>
> Which other protocols? Why should independent security headers  
> affect other non-security SOAP headers? Which policy assertions  
> would become nested because of an interaction, headers in another  
> domain?
>
> A paragraph explaining (with an example) the issue in reliable  
> messaging would help. It isn't obvious which assertions would  
> become nested in which, so a concrete example could make the issue  
> clearer.
>
> (b) In addition, the following sentence needs clarification:
> "The protocol assertions that require composition with WS-Security  
> should be particularly aware of the nesting requirements on top of  
> transport level security.""
>
> What nesting requirements?
>
> Proposal
>
> i) add "can" to second sentence:
> "For example, security assertions can interact with other protocol  
> assertions in a composition"
>
> ii) replace "WS-Security Policy" with "WS-SecurityPolicy" (editorial)
>
> iii) Add text to clarify and answer questions associated with (a)  
> and (b) above.
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
> [1] http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy- 
> guidelines.html?rev=1.11
>
>
>
>
Received on Tuesday, 19 December 2006 19:09:45 GMT

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