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: Thu, 21 Dec 2006 15:48:15 -0500
Message-Id: <2441DB50-4672-428B-8224-717F218E23EF@nokia.com>
Cc: Cotton Paul <pcotton@microsoft.com>, Yalcinalp Umit <umit.yalcinalp@sap.com>, Ferris Christopher <chrisfer@us.ibm.com>, Hondo Maryann <mhondo@us.ibm.com>, Hirsch Frederick <frederick.hirsch@nokia.com>
To: public-ws-policy@w3.org

We (Umit, myself, Chris and Maryann) were able to discuss issue 3953  
and agree on the following revised proposed resolution:

"Domain authors need to be clear about how assertions defined in  
their domain may fit with assertions for interrelated domains. A  
classic example of such an interrelated domain is security, because  
security tends to
cut across all aspects of a solution. One example is the definition  
of additional assertions
related to the interrelated security domain [WS-SecurityPolicy] in  
Web Services Reliable Messaging Policy
Assertions [WSRMP]. Care should be taken to not duplicate existing  
assertions and also to make sure that new assertions are consistent  
with pre-existing assertions, when adding assertions related to an  
interrelated domain. [WSRMP] http://docs.oasis-open.org/ws-rx/wsrmp/ 
200608/wsrmp-1.1-rddl-200608.html"

In addition to the text, I suggest we make this section 4.8 in the  
Guidelines, and eliminate section 6 (which only contained the text  
which is being updated).  Section 4 is the General Guidelines for  
Assertion authors, and this seems to fit that section.

regards, Frederick

Frederick Hirsch
Nokia


On Dec 19, 2006, at 2:09 PM, Frederick Hirsch wrote:

> 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 Thursday, 21 December 2006 20:48:45 GMT

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