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

Hi,

I reread the framework and I don't think it is entirely clear in this 
regard. I believe both points of view could be justified based on the 
text of the specification. It is very clear that all policy types in a 
policy expression constitute the policy vocabulary. It is apparently not 
clear what that means for policy assertions in nested policies.

Fabian


Yalcinalp, Umit wrote:
>> Frederick Hirsch wrote:
>>     
>>> I'm confused. Doesn't
>>>
>>>       
>>>> 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,
>>>>         
>>> this imply that since the assertions are in the vocabulary that none 
>>>       
>>> are allowed since not stated, hence the following sentence is wrong?
>>>       
>> None of the nested assertions listed above are in the 
>> vocabulary of the 
>> policy that the proposal gives as an example. Only concrete 
>> occurrences 
>> of an assertion somewhere in the policy expression are part of that 
>> policy's vocabulary.
>>     
>
> This is interesting. 
>
>
>   
>>>> it will indicate that none of the dependent behaviors namely 
>>>> authentication or client certificate is required.
>>>>         
>>> it will indicate that none of these are allowed or required?
>>>       
>> In the context of what I said above, I believe the original 
>> statement is 
>> correct. And note that the framework does not talk about allowed or 
>> required, it only states an indication that the assertion is 
>> not applied.
>>
>> Fabian
>>     
>
> Is there a difference of opinion about what constitutes the vocabulary
> of an assertion based on type vs instance ? 
>
> We recommend assertions to have a schema and state dependent behaviors
> as expressed as nested assertions. From a definition perspective, it is
> not about the "instance" as expressed in a document, it is a about the
> "type" of the assertion which lists all the dependent assertions. The
> type, hence the Qname in advance declares what it is composed of. 
>
> I have regarded that understanding a type would also imply understanding
> all possible nested children (close world model) which is not based on a
> specific policy expression instance. 
>
> Am I missing sth? 
>   

Received on Thursday, 1 March 2007 10:02:00 UTC