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

[Polar Humenn <polar@syr.edu>]

Michiharu,

On deeper analysis by the water cooler, I think I may see the very thing
that you are after. And it is not the <Rule> with obligations, but *just*
conditionalized obligations? Is that correct?

If Condition X  is true then emit obligation Y on Permit (or Deny).

If so, then why not just add a condition wrapper around a single
obligation or set of obligations, instead of screwing around with the
rules and complicating their combining algorithms, and forcing them to
pull obligations out of the rules.  We can just add this item (or more) to
the Policy:

<ConditionalizedObligations>
    <Condition>
         <Expression> (which could be a variable reference)
    </Condition>
    <Obligation/>
        ....
    <Obligation/>
</ConditionalizedObligations>

I'd be much happier with this approach than sticking them into rules.
And the semantics would be cleaner and quite less confusing, and more
intuitive.

Especially, if the purpose is to conditionalize an obligation. If the way
to do this was by putting the obligation in a <Rule> then you would have
to think up a bogus <Rule> and give it an Effect that you don't think will
affect the rule combination.  In other words, a hack.

Cheers,
-Polar

On Mon, 12 Apr 2004, Polar Humenn wrote:

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