Hi Seth,
Thanks for the feedback. Couple of quick comments:
- 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.
- 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 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.).
Thanks,
Rich
Seth Proctor wrote:
20081208203455.GH8754@cadfan.east.sun.com"
type="cite">
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
|