Action-280 Re: [ISSUE 4393 PRIMER] Add text to strict and lax policy intersection discussion ...

Last week we took an action item to revise the proposal for 4393 to
address issue 280, amending the text we agreed on at the 2007-04-11
telcon to address Glen's concerns w.r.t. ignorable. 

 

After discussion last week we have developed an amendment. The amended
proposal is below:

 

See: http://www.w3.org/Bugs/Public/show_bug.cgi?id=4393

 

Title: Add text to strict and lax policy intersection discussion
describing how a policy consumer can determine issues due to
intersection mode conflicts

 

Target: WS-Policy Primer, Section 3.4.1

 

Description: While the Primer covers scenarios on applying intersection
modes, we do not have any content which illustrates how conflicts can be
detected. As such we need to indicate in the Primer how a consumer may
address such conflict detection and reporting.

 

Justification: As consumers have the option to choose one or more modes
for policy intersection (strict | lax | strict, delegate-to-user | lax,
delegate-to-user | strict, lax, delegate-to-user | ...), conflicts may
occur when providers intend for their policies to be applied only in a
lax mode - this is distinct from treating everything as ignorable. While
the end result may be the same (failure, being that no policy
alternatives are available), the consumer needs to be able to report why
this occurs.

 

Proposal: Perform the following changes to the Primer text 

 

Change in 3.4.1 Strict and Lax Policy Intersection, as follows
(highlighted in colour and bracketed with <<>> below):

 

"The previous sections outlined how the normal-form of a policy
expression relate to the policy data model and how the compatibility of
requester and provider policies may be determined. This section outlines
how ignorable assertions may impact the process of determining
compatibility.

 

In order to determine compatibility of its policy expression with a
provider policy expression, a requester may use either a "lax" or
"strict" mode of the intersection algorithm.

 

In the strict intersection mode two policy alternatives are compatible
when each assertion in one is compatible with an assertion in the other,
and vice versa. For this to be possible they must share the same policy
alternative vocabulary. The strict intersection mode is the mode of
intersection discussed in the previous sections of this document.

 

When using the strict intersection mode, all assertions are part of the
policy alternative vocabulary, including those marked with
wsp:Ignorable. Thus, the wsp:Ignorable attribute does not impact the
intersection result even when its attribute value is "true".

 

If a requester wishes to ignore ignorable assertions in a provider's
policy, then the requester should use the lax intersection mode. In the
lax intersection mode all ignorable assertions (i.e. with the value
"true" for the wsp:Ignorable attribute) are to be ignored by the
intersection algorithm. Thus in the lax intersection mode two policy
alternatives are compatible when each non-ignorable assertion in one is
compatible with an assertion in the other, and vice versa. For this to
be possible the two policy alternatives must share a policy alternative
vocabulary for all "non-ignorable" assertions.

 

<<Regardless of the chosen intersection mode, ignorable assertions do
not express any wire-level requirements on the behavior of consumers -
in other words, a consumer could choose   to ignore any such assertions
that end up in the resulting policy after intersection, with no adverse
effects on runtime interactions.>>

 

Domain-specific processing could take advantage of any information from
the policy data model, such as the ignorable property of a policy
assertion.

 

A requester can decide how to process a provider's policy to determine
if and how the requester will interact with the provider. The requester
can have its own policy that expresses its own capabilities and
requirements, and can make one or more attempts at policy intersection
in order to determine a compatible alternative and/or isolate the cause
of an empty intersection result. The requester can use and analyze the
result(s) of policy intersection to select a compatible alternative or
trigger other domain-specific processing options. For example, a
requester can at first attempt strict mode intersection, and then lax
mode as another choice, if the previous attempt returns an empty
intersection result."

 

Cheers,

 

-Charlton.

 

 

 

Charlton Barreto
Senior Computer Scientist
Adobe Systems Incorporated
345 Park Avenue, MS E15
San Jose, CA 95110-2704 USA
408.536.4496 p   
415.692.5396 m
charltonb@adobe.com