3953 2006-11-04 16:03:22 +0000 [Guidelines] Remove language that use of security policy assertions forces nested assertions for other domains 2007-01-31 18:22:29 +0000 1 1 1 Unclassified WS-Policy Guidelines FPWD Macintosh All RESOLVED FIXED P2 normal --- 1 w3c w3c public-ws-policy-qa oldest_to_newest 12826 0 w3c 2006-11-04 16:03:22 +0000 Target: Guidelines Justification: Use of WS-SecurityPolicy assertions in policy does not necessarily require nested assertions related to other domains. Proposal: Rewrite end of section 6, including sentence ending with "would result...Security 2004." and last sentence in section "The protocol assertions...level security." 13079 1 w3c 2006-12-05 13:55:40 +0000 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. [1] http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?rev=1.11 13255 2 w3c 2006-12-19 19:09:00 +0000 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> 13270 3 w3c 2006-12-21 20:48:59 +0000 Updated proposal: "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. 13862 4 chrisfer 2007-01-31 18:22:29 +0000 See http://www.w3.org/2007/01/31-ws-policy-irc#T18-21-13 RESOLUTION: resolve 3953 with amendment proposed in http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0090.html