Re: Action 216 Proposal for Addition to Guidelines Document on Nested Policy Expressions

>>hirsch: 
>>(1) Would it be correct and clearer to replace
>>
>>"it will indicate that none of the dependent behaviors namely  
>>authentication or client certificate is required"
>>
>>with
>>"it indicated that none of the specified authentication mechanisms  
>>(sp:HttpBasicAuthentication, sp:HttpDigestAuthentication and  
>>sp:RequireClientCertificate) are to be used, and will not be  
>>compatible with an assertion containing these nested assertions."
>>    
>>
>yalcinalp: I am fine with this change. 
>  
>
mm1: Umit beat me to the gun as I was composing some comments. :>)

Perhaps we should look at some of these statements together. In the 
preceding paragraph, the proposed text specifies they will not be 
compatible unless otherwise specified. In order to be consistent, and if 
we accept the amendment proposed by Frederick, it may read:

"it indicated that none of the specified authentication mechanisms (sp:HttpBasicAuthentication, sp:HttpDigestAuthentication and sp:RequireClientCertificate) are to be used, and will not be compatible with an assertion containing these nested assertions unless otherwise specified by the assertion definition."

  

Note, if this is included, it is an ideal place to speak to / 
differentiate domain specific processing and the (first approximation) 
intersection algorithm.

>>(2) Also, shall we change "This use must not be interpreted 
>>as being"  
>>to "By default, this use MUST NOT be interpreted as being"
>>    
>>
>yalcinalp: This reminds me of a discussion with Monica. I am surprised she did not
>respond to this. 
>I am not sure whether the Guideline document can be positioned to be a
>normative specification. 
>Thus, I avoided the use of MUST. 
>  
>
mm1: If this is the intent, the specification should be in the Framework 
(and it is not).  Section 3.1 alludes to this and Section 4.3.2 may be 
an appropriate place to address it. As Umit correctly indicates, the 
Guidelines is positioned other than as a normative document. Note, this 
conversation has occurred on other occasions.

>>(3) The meaning of the last sentence is not clear, since it isn't  
>>clear what it means to ignore incompatible policies and to proceed:
>>
>>"A non-anonymous client who requires authentication or client  
>>certificate will not be able to use this provider solely on 
>>the basis  
>>of intersection algorithm alone."
>>    
>>
>yalcinalp: The intent of the sentence is to indicate that intersection algorithm is
>a first approximation. Thus, if domain specific processing were
>involved, the result could be different. 
>  
>
Suggest:

"A non-anonymous client who requires authentication or client certificate will not be able to use this provider solely on the basis of the first approximation of the intersection algorithm. Domain-specific processing could be required and could affect the result."
  

>>hirsch: Perhaps we should replace this sentence with the following
>>"A client that requires authentication, as indicated by nested  
>>authentication assertions, will not be able to find a compatible  
>>assertion intersection with a provider that specifies an 
>>empty set of nested assertions. In this case the provider and/or client will need  
>>to offer alternatives to make a compatible set of assertions 
>>possible."
>>    
>>
mm1: This addition or change may require more discussion.  Be cognizant 
between the relationship between these ideas and ensure the text is clear.

----original email for context---
Assertion authors should note the effect of nested policy  expressions 
on policy intersection in their nested policy design.  The result of 
intersecting an assertion that contains an empty  nested policy 
expression with an assertion of the same type without  a nested policy 
expression is that the assertions are not  compatible. Therefore, when 
providers require dependent behaviors  these behaviors should be 
explicitly specified as assertions in a  nested policy expression. When 
the definition of an assertion  allows for nested dependent behaviors, 
but the use of the assertion  only contains an empty nested policy 
expression, this specific use  indicates the specification of no nested 
dependent behaviors. This  use must not be interpreted as being 
compatible with "any" of the  nested dependent behaviors that are 
allowed by the assertion,  unless otherwise specified by the assertion 
definition.

As an example, WS-Security Policy defines sp:HttpToken assertion to  
contain three possible nested elements, sp:HttpBasicAuthentication,  
sp:HttpDigestAuthentication and sp:RequireClientCertificate. When  the 
HttpToken is used with an empty nested policy in a policy  expression by 
a provider, it will indicate that none of the  dependent behaviors 
namely authentication or client certificate is  required.

<sp:TransportToken>
        <wsp:Policy>
                <sp:HttpsToken>
                        <wsp:Policy/>
                </sp:HttpsToken>
        </wsp:Policy>
</sp:TransportToken>
A non-anonymous client who requires authentication or client  
certificate will not be able to use this provider solely on the  basis 
of intersection algorithm alone.

Received on Tuesday, 20 February 2007 21:10:11 UTC