OASIS eXtensible Access Control Markup Language (XACML) TC

All,

During the call yesterday we decided to introduce a new "type of 
obligation", perhaps called 

On Dec 18, 2008, at 11:56 PM, Erik Rissanen wrote:

> 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.


Does this mean that all Policies not applicable to a decision would  
return an Obligation? Taken one step further with the TC's current  
decision re: Obligations, that all Rules that are not applicable will  
return Obligations?

Also, NotApplicable and "not allowed" are not explicitly correlated,  
since the latter is defined as a "Deny", so I am not sure I understand  
the use case fully. Are they looking for the logic behind each  
decision to be passed to the PEP? (Which could be unwieldy if the  
answer to my first question is yes :)

thanks

b 

bill parducci wrote:
>
> On Dec 18, 2008, at 11:56 PM, Erik Rissanen wrote:
>
>> 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.
>
>
> Does this mean that all Policies not applicable to a decision would 
> return an Obligation? Taken one step further with the TC's current 
> decision re: Obligations, that all Rules that are not applicable will 
> return Obligations?

What I mean is that if a PolicySet/Policy/Rule contains an 

On Dec 19, 2008, at 7:15 AM, Erik Rissanen wrote:
> What I mean is that if a PolicySet/Policy/Rule contains an 

bill parducci wrote:
>
> On Dec 19, 2008, at 7:15 AM, Erik Rissanen wrote:
>> What I mean is that if a PolicySet/Policy/Rule contains an 

On Dec 20, 2008, at 12:49 AM, Erik Rissanen wrote:

> bill parducci wrote:
>>
>> On Dec 19, 2008, at 7:15 AM, Erik Rissanen wrote:
>>> What I mean is that if a PolicySet/Policy/Rule contains an 

bill parducci wrote:
>
> On Dec 20, 2008, at 12:49 AM, Erik Rissanen wrote:
>> And yes, if you mix policies across domains, you would get 

Erik Rissanen wrote:
> All,
>
> During the call yesterday we decided to introduce a new "type of 
> obligation", perhaps called 

Anil Saldhana wrote:
> Erik Rissanen wrote:
>> All,
>>
>> During the call yesterday we decided to introduce a new "type of
>> obligation", perhaps called 

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 

Anil Saldhana wrote:
> Erik Rissanen wrote:
>>
>> Like this:
>>
>> 
>>
>>   
> 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.

The 

> The 

>

Wanted to chime in that I think both "obligation" and "advice"  are a  
bad choice of terminology.

My choice would be "decision attribute" for the XACML 2.0 obligation,  
or rule "effect attribute" for the rule scoped obligations.

Rule combining algorithm would be responsible for combining effect  
attributes into a decision attribute set.

Daniel;


> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>