RE: Action 309 Wording to Resolve Bug 4583

>The output of the intersection of two policies is one or more compatible alternatives.

The output of the intersection of two policies may contain ZERO or MORE policy alternatives.

If two policies are compatible, their intersection is the set of the intersections between all pairs of compatible alternatives, choosing one alternative from each policy. If two policies are not compatible, their intersection has no policy alternatives.

>Each compatible alternative contains pairs of compatible assertions

Well, in the case of ignorable, there may be a single assertion. In the general case, there may be 1 or more assertions of the same type. If the Framework were to say anything about the aggregate behaviors of multiple assertions of the same type then the Framework should address the general case: > 1 or multiple assertions of the same assertion type.

>Thus, the two sp:EncryptedParts assertions are redundant.

The sp:EncryptedParts assertion example in Section 4.5 carries a parameter: <sp:Body/>. The WS-SecurityPolicy specification specifies the semantics of multiple assertions of the EncryptedParts assertion type [1]. In this case, a default statement in the Framework would not apply.

[1] http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-cs.html#_Toc161826515

>Add a final bullet to the bullets at the start of section 5.4.

There is a paragraph in Section 4.5 that carries the necessary context for specifying any default rule if the assertions authors did not specify the semantics of multiple assertions of the same type:

"See Section 3.2 Policy Alternative<http://www.w3.org/TR/2007/CR-ws-policy-20070605/#rPolicy_Alternative> for mechanisms for determining the aggregate behavior indicated by multiple assertions of the same policy assertion type<http://www.w3.org/TR/2007/CR-ws-policy-20070605/#policy_assertion_type>."

We suggest adding any related clarification to the above paragraph.

> If the assertions have no parameters and the assertions in nested policies have no parameters

The default statement should be little more tighter and cover nested policy expressions at all levels.

>If domain policy assertion language authors fail to specify

Our suggestion would be to maintain a positive tone - s/fail to specify/did not specify/.


Applying these changes:

a) Change 1

In Section 3.2, append the following sentence to the third paragraph:

If policy assertion authors did not specify the semantics of repetition of policy assertions of a type that allows neither parameters nor nested policy expressions within a policy alternative, then repetition is simply redundancy, and multiple assertions of the assertion type within a policy alternative have the same meaning as a single assertion of the type within the policy alternative.

b) Change 2

In Section 4.5, append the following sentence to the paragraph that starts with 'See Section 3.2 Policy Alternative for mechanisms for determining the aggregate behavior ...'

If policy assertion authors did not specify the semantics of multiple assertions of the same assertion type within a policy alternative and the type and its descendant assertion types (within a nested policy expression outline, if any) do not allow any parameters, then multiple assertions of the type within a policy alternative in the intersection result have the same meaning as a single assertion of the type within the policy alternative.

c) NO changes to the example because the above default rules do not apply to the SignedParts or the EncryptedParts assertion.

Regards,

Asir S Vedamuthu
Microsoft Corporation



From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Ashok Malhotra
Sent: Saturday, June 09, 2007 8:57 AM
To: public-ws-policy@w3.org
Subject: Action 309 Wording to Resolve Bug 4583


1.      Change Section 3.2 of the Framework Document as follows:

Was:

Section 3.2: A policy alternative MAY contain multiple assertions of the same type. Mechanisms for determining the aggregate behavior indicated by the assertions (and their Post-Schema-Validation Infoset (PSVI) (See XML Schema Part 1 [XML Schema Structures]) content, if any) are specific to the assertion type and are outside the scope of this document.

Suggested (based on wording from Dale and Asir):

Section 3.2: A policy alternative MAY contain multiple assertions of the same type. Mechanisms for determining the aggregate behavior indicated by the assertions (and their Post-Schema-Validation Infoset (PSVI) (See XML Schema Part 1 [XML Schema Structures] content) are specific to the assertion type and are outside the scope of this document. If domain policy assertion language authors fail to specify the semantics of  repetition of policy assertions of a type that allows neither parameters nor nested policy expressions within a policy alternative, then repetition is simply redundancy, and multiple assertions of the assertion type within a policy alternative have the same meaning as a single assertion of the type within the policy alternative."

2.      Add a final bullet to the bullets at the start of section 5.4.

*       The output of the intersection of two policies is one or more compatible alternatives.  Each compatible alternative contains pairs of compatible assertions, one from each of the input policies.  The contents of both assertions in the pair are used to indicate the correct behavior.  Whether the two assertions in the pair are compatible or redundant depends on the domain-specific semantics of the assertion type. If the assertions have no parameters and the assertions in nested policies have no parameters the assertions of that type are redundant.

3.      Change the paragraph that follows the result of the intersection in section 4.5.

Was:

Note that there are > 1 assertions of the type sp:SignedParts; when the behavior associated with sp:SignedParts is invoked, the contents of both assertions are used to indicate the correct behavior. Whether these two assertions are compatible depends on the domain-specific semantics of the sp:SignedParts assertion. To leverage intersection, assertion authors are encouraged to factor assertions such that two assertions of the same assertion type are always (or at least typically) compatible.

Suggested (adds wording specific to the example).:

Note that there are 2 assertions of the type sp:SignedParts and 2 assertions of the type sp:EncryptedParts, one from each of the input Policies. In general, whether the two assertions in each pair are compatible or redundant depends on the domain-specific semantics of the assertion types. As mentioned above, if the assertions have no parameters and the assertions in nested policies have no parameters, the assertions are redundant.   Thus, the two sp:EncryptedParts assertions are redundant.  Whether the two sp:SignedParts assertions are compatible or redundant depends on the semantics defined for this assertion type.

All the best, Ashok