Re: [xacml] oasis-xacml-2_0-core-spec-wd-08.zip

[Polar Humenn <polar@syr.edu>]

On Tue, 13 Apr 2004, Michiharu Kudoh wrote:

> To me, it is still easy and simplistic. The complication of the rule
> combining algorithm after introducing the obligation is nearly the same
> with that of the policy combining algorithm for XACML 1.0.

The complexity of evaluating the the PolicySet is the very thing that I am
trying to avoid in evaluating a simple <Policy> with <Rules>.

Somehow, I think this is all leading to, "hey, why don't add rule
reference, since we just added enough complexity so that they are just as
complex as policy sets!"

It looks to me like simply adding an obligation with FulfillOn="Permit" on
to a rule with the effect of "Deny", or visa versa seems like a not well
thoughtout hack.

I still don't see the use case in which obligations for rules are
necessary, and why policies cannot handle the complications of
obligations.

-Polar

> The policy
> combining algorithm for 1.0 has to deal with similar situation as we face
> here after all. For example,
>
> <PolicySet Alg="ordered-permit-overrides">
>   <PolicyIdReference>policy1</>
>   <PolicyIdReference>policy2</>
>   <PolicyIdReference>policy3</>
>   <Obligations>
>     <Obligation ObligatoinId="encryption" FulfillOn="Permit"/>
>   </Obligations>
> </Policy>
>
> The policy combining algorithm has to remember the decision and the
> obligation of each policy (policy1,2,3). Suppose the policy1 returns "Deny"
> with "email", the policy 2 is not applicable, and the policy3 returns
> "Permit" with "log". The policy combining algorithm returns  "Permit" with
> "log" and "encryption" from the definition of 3.3.3.2 and 7.11. The similar
> semantics has been specified in XACML 1.0, though it happens in PolicySet.
>
> Best,
> Michiharu
>
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
>