Re: [xacml] Making progress?

[Erik Rissanen <erik@axiomatics.com>]

Hi Rich and all,

See inline.

Rich.Levinson wrote:
> Hi Seth,
>
> Thanks for the feedback. Couple of quick comments:
>
>    1. If returning the information at the Rule level is sufficient,
>       then the suggestion I made in my email that using the "extended"
>       combining algorithms in combination with moving the Rules into
>       their own Policies (which is ok w extended algorithms that are
>       the same at the policy and rule levels (for more info see
>       http://lists.oasis-open.org/archives/xacml/200812/msg00015.html))
>       would effectively enable Obligations to be returned at the Rule
>       level in existing policy structures.
>

This is correct, but there is the overhead of having lots of Rules 
inside Policies, just for the sake of encapsulating the obligation. It 
will work, but allowing obligations in rules would be nicer.


>    1. I tend to look at the inputs and outputs to the PDP as being
>       collections of Attributes and since the Response only allows
>       Attributes to appear in Obligation elements, then that seems
>       adequate to me (except there may be a problem returning the
>       "category" of a particular Attribute this way). I tend to view
>       the term "Obligation" as meaning that the PEP has to do whatever
>       it has to do with the information within, which can be sending
>       an email somewhere, possibly returning challenge information to
>       the requestor or simply delivering the contents to the caller to
>       be passed along to the destination. i.e. I see no reason to
>       place semantic restrictions on what a PEP should or should not
>       do w the info.
>

I agree.

>    1. I recognize that the Obligation mechanism probably cannot be
>       extended to lower levels below Rules in a benign manner such as
>       (1) above which does it by simply using "improved?" combining
>       algorithms. Also, it does not address the "dynamic" issue, which
>       I am still trying to understand (I thought the fact that
>       Obligations contain AttributeAssignment elements, which contain
>       AttributeValue elements, which are in Expression substitution
>       group would make them "dynamic", but I admit I have not yet had
>       the time to pursue this further.).
>

The fact that AttributeValue is in the Expression substitution group 
means that and AttributeValue can appear anywhere where an Expression 
can occur. It does not mean that an Expression can occur anywhere an 
AttributeValue can appear. We fixed this issue at the previous meeting 
where we changed so obligations in policies now contain an Expression.

Best regards,
Erik

>     Thanks,
>     Rich
>
>
> Seth Proctor wrote:
>> Hi Rich.
>>
>>   
>>> Unfortunately I missed the meeting this morning, however, Hal filled me in 
>>> on some details. In particular, Hal mentioned that in the Boeing 
>>> presentation that there was indicated a requirement for having Obligations 
>>> available at the Rule level, while they are currently available only at the 
>>> Policy level.
>>>     
>>
>> To provide some context, the actual requirement was slightly different. The
>> use-case here is being able to communicate back to a PEP why a decision
>> (typically a Deny) was made. This is something I've heard many others ask
>> for as well, so personally I think it's a good thing to support.
>>
>> The discussion turned to Obligations because this is the only mechanism we
>> currently have to support the use-case. That is, a policy can include an
>> Obligation that (statically) describes why a given Policy resulted in
>> Permit or Deny.
>>
>> I think this is hard to work with for several reasons. The main reason we
>> discussed is that Obligations cannot be included on Rules (or even lower),
>> though personally I think the name "Obligation" implies something specific
>> about what's returned that isn't really what we're trying to address here.
>> It's also harder to work with something that can't be dynamic in its use
>> of the Context (though Erik has suggested ways to address this).
>>
>> I hope that helps in terms of why we were discussing this issue..
>>
>>
>> seth
>>