Re: [xacml] The new advice "obligation"

[Anil Saldhana <Anil.Saldhana@redhat.com>]

Erik Rissanen wrote:
> Anil Saldhana wrote:
>   
>> Erik Rissanen wrote:
>>     
>>> All,
>>>
>>> During the call yesterday we decided to introduce a new "type of
>>> obligation", perhaps called <Advice>.
>>>
>>> I have two things to say.
>>>
>>> 1. Here is a syntax which we could consider:
>>>
>>> <Advice AdviceId="urn:...." AppliesTo="Permit">
>>> <AttributeAssignment>.....</>
>>> </Advice>
>>>
>>> Any other ideas for naming it?
>>>
>>>       
>> Erik, provide some context to the naming, please. :)
>>     
>
> Like this:
>
> <Policy>
>   ....
>   <Advice AdviceId="urn:...." AppliesTo="Permit">
>     <AttributeAssignment>.....</>
>   </Advice>
> </Policy>
>
>   
I was asking why there is a need for this new element "Advice".  If I do 
not know the requirement (what I called context), I cannot participate 
in this discussion. :(
 I kind of joined the TC phone discussion late and got my mind turned off.
>   
>>> 2. Should it be possible to have this apply to NotApplicable as well,
>>> not just Permit/Deny?
>>>
>>> I am asking since a customer of mine wanted to use obligations on
>>> NotApplicable to return a reason for why access was not allowed.
>>>
>>> I haven't thought it through properly yet, but it seems like a good
>>> idea. Typically I would expect policies to list stuff that is
>>> allowed, with perhaps some exceptions which deny. In general it's a
>>> good principle for security design to "enumerate goodness", rather
>>> than to try to list everything which is bad/dangerous. If one does
>>> so, if a policy does not match, it would  be NotApplicable, not Deny,
>>> so it would not be possible to return advice about what did not
>>> match. If we don't allow advice on NotApplicable, then policy writers
>>> need to refactor their policies to return Deny instead of
>>> NotApplicable when they do not match.
>>>
>>> Refactoring like that gives a fundamentally different "architecture"
>>> for the policies. Now we will have policies which say "Deny" on
>>> things they do not apply to, and policies which apply say "Permit".
>>> This forces the user to use a permit-overrides algorithm, which
>>> further limits how policies can be structured. Essentially the policy
>>> writer is forced to work with Permit/Deny only, and NotApplicable is
>>> not something he can use in his policies.
>>>       
>> Essentially, you are sending a debug info back via the obligation? 
>> You missed these attributes in your request for your receipt of NA.
>>     
>
> Well, I wouldn't call it debug info. It would be insufficient for any
> real debugging. It's more about giving particular advice to the end user
> in a specific, limited context.
>
> See the XACML interop policies for one example where itis done with a
> FulfillOn="Deny" obligation in refactored policies.
>
> Regards,
> Erik
>