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
>
