- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Thu, 21 Dec 2006 15:48:15 -0500
- To: public-ws-policy@w3.org
- 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>
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 UTC