[Primer] Proposal to close action 196

This email contains proposal which should complete action item 196

regards, Frederick

Frederick Hirsch
Nokia

Proposal:

Add the following text to the end of section 3.4.1 in the Primer  
(Strict and Lax Policy Intersection), starting a new paragraph.

When using strict mode the Ignorable attribute on assertions does not  
have an impact on determining the compatibility of policy  
alternatives. When the requestor chooses to use the lax policy  
intersection algorithm, use of the Ignorable attribute on assertions  
does have an impact on determining compatible policy alternatives.   
However, the requester is still able to control what constitutes an  
acceptable compatible policy alternative in a meaningful way.  
Specifically, the requester may choose to not require a provider  
assertion that is marked Ignorable by not including a would-be  
compatible assertion in its requester policy. Similarly, the  
requester may choose to require the compatible policy alternative to  
contain an assertion marked as Ignorable, by including a compatible  
assertion in the requester policy,  but not marking it as Ignorable  
in the requester policy.

To give an example, suppose a requestor requires assertions A & B to  
be in a compatible policy alternative. This can be represented in the  
following example requestor policy:

<Policy>
  <A/>
  <B/>
</Policy>

Now consider a Provider that has a policy which has two ignorable  
assertions, C and D. Since the requester policy does not include C or  
D the policies will not be compatible in strict mode, since no  
requester alternative will contain an assertion compatible to C or D.  
If the requester chooses lax intersection, then C and D will be  
ignored in calculating the compatible alternatives, so a compatible  
alternative is possible, consisting of A and B (hence the Ignorable  
provider assertion was ignored).

<Policy>
  <A/>
  <B/>
  <C wsp:Ignorable="true"/>
  <D wsp:Ignorable="true"/>
</Policy>

Now suppose that the requester wishes to use lax intersection so as  
to generally ignore Ignorable provider assertions but wishes to  
require compatibility with one specific provider assertion, even if  
marked Ignorable, e.g. D. In this case the requester can enforce this  
by adding an assertion to its policy that is compatible with the  
required Ignorable assertion D, and not making it Ignorable in the  
requester policy:

<Policy>
  <A/>
  <B/>
  <D/>
</Policy>

This will result in a lax policy intersection that requires the  
provider alternative to include assertions compatible with A, B and  
D, but for which the Ignorable provider assertion C is ignored.

By use of Ignorable on provider assertions and thoughtful inclusion  
of assertions in the requester policy, it is possible to either  
ignore or require provider assertions in a lax policy intersection.

Received on Tuesday, 30 January 2007 23:02:47 UTC