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

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

From: Asir Vedamuthu <asirveda@microsoft.com>
Date: Tue, 30 Jan 2007 15:41:28 -0800
To: Frederick Hirsch <frederick.hirsch@nokia.com>, "public-ws-policy@w3.org" <public-ws-policy@w3.org>
CC: Paul Cotton <Paul.Cotton@microsoft.com>, Yalcinalp Umit <umit.yalcinalp@sap.com>, Ferris Christopher <chrisfer@us.ibm.com>, Hondo Maryann <mhondo@us.ibm.com>
Message-ID: <C9BF0238EED3634BA1866AEF14C7A9E53469FB6A9D@NA-EXMSG-C116.redmond.corp.microsoft.com>

+1 with two minor editorial changes:

a) s/domain authors/assertion authors/ - WG agreed to use 'assertion author' for issue 3983 [1].

b) s/Care should be taken to not/Assertion authors should not/ - active voice makes it clear who should not duplicate existing assertions.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=3983

Regards,

Asir S Vedamuthu
Microsoft Corporation


-----Original Message-----
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Frederick Hirsch
Sent: Thursday, December 21, 2006 12:48 PM
To: public-ws-policy@w3.org
Cc: Paul Cotton; Yalcinalp Umit; Ferris Christopher; Hondo Maryann; Hirsch Frederick
Subject: Re: Issue 3953 [Guidelines] Update to issue on domain interactions and assertion nesting


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 Tuesday, 30 January 2007 23:41:41 GMT

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