OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


On Fri, 9 Apr 2004, Michiharu Kudoh wrote:

> Hi, Polar
>
> >But please answer me this, what does a Rule with the Effect of Deny mean
> >with Obligations of FullfillOn="Permit" mean? What am I supposed to do
> >with that?
>
> Suppose we have a rule like:
>
> <Rule Effect="Deny">
>   <Condition> ... </Condition>
>   <Obligations>
>     <Obligation ObligationId="email" FulfillOn="Permit"/>
>   </Obligations>
> </Rule>
>
> If this rule fires, then the result should be "Deny". Since there is no
> obligation for "Deny", then the result is just "Deny". I guess what you are
> concerned is that the obligation is never used.
> Right.

I guess, I'm just worried about ala Microsoft, throwing features into
things without fully thinking of the implications.

> But everybody can make this type of meaningless policies.
>
> For example,
>
> <Policy RuleCombAlgo="ordered-deny-overrides">
>   <Rule Effect="Deny"/>
>   <Rule Effect="Permit"/>
> </Policy>

I see. You can get the Republicans to invade Iraq with justifications like
that.

> The second rule never fires because the first rule always fires. In my
> opinion, the case above and this are the same problem. Possible way to
> avoid this problem would be to use some intelligent policy authoring tools
> that detect meaningless policy specifications.

This is just all getting way too friggin complicated, especially for
something that is supposed to be optional.

So, here we go, are the many possibilities, nobody thought about when one
simply added obligations to rule:

First of all, what does "if this rule fires" means?

Does that mean that this rule's <target> is true?,

Does that mean this rule's <target> got "evaluated"?

Does it mean that this rule's <Condition> is true?

Does it mean that the <Condition> is "evaluated" (whether it becomes true
or false)?

And what does "evaluated" mean? Do you consider a rule "firing" if its
been evaluated once and cached for later decisions?

So, if the rule's <Condition> gets evaluated to False, and its Effect is
(well who cares), and its obligation is FullFillOn="Deny", does the
obligation apply if the final decision of the policy is Deny?

What about the reverse situation, the <Condition> evaluates to False and
the rule's effect is (again, who cares), and its obligation is
FulFillOn="Permit", does its obligation apply if the final decision of the
policy is Permit?

Any answers that may accompany these questions into the spec?

Before, it was easy and simplistic. The rule combining algorithm decides
the Effect of the Policy by combining the determined Effects of the rules.
You get your obligations from the policy based on the final effect of the
combining algorithm. What more do you need here?

What is the use case that you cannot support?

-Polar

> Best,
> Michiharu
>
>
>
>              Polar Humenn
>              <polar@syr.edu>
>                                                                         To
>              2004/04/09 05:07          XACML <xacml@lists.oasis-open.org>
>                                                                         cc
>
>                                                                    Subject
>                                        [xacml]
>                                        oasis-xacml-2_0-core-spec-wd-08.zip
>
>
>
>
>
>
>
>
>
>
>
> I'm looking at this new document and I have a couple questions.
>
> 0. I went to considerable effort to make glossary items for the
>    CombinerParameter proposal. None of them made it in there. I think it
>    would be good to have those definitions.
>
> 1. I removed CombinerParameters from the Rule as we now have
>    RuleCombinerParameters. They are still there. They need to be removed.
>
> 2. I removed the sentence "<VariableDefinition> MAY contain undefined
>    <VariableReference>, but if it does, corresponding <VariableDefinition>
>    MUST be defined later in the encompassing policy."
>
> I removed this sentence because a variable reference cannot be "undefined"
> if it *has* a definition.
>
> Anyway, it's not about the VariableDefition. It's about the Expression.
> It's probably better to say "An expression SHALL not contain any undefined
> variable references."  but that should be included in section 5.33
> Expression.
>
> Perhaps, if we must stay something about it, please say it in the
> VariableReference section. Perhaps stating that,
>
> "A <VariableReference> that does not have a corresponding
> <VariableDefition> in the encompassing policy shall be considered
> undefined".
>
> And that takes care of both problems.
>
> 3.  In both Policy and PolicySet evaluation, I removed a sentence that
> says, "In such a case, the values of these parameters associated with the
> policies, MUST be taken into account when evaluating the policy set."
>
> I removed this sentence because it is not really true. First of all, I
> don't know what "taken into account" means.  It is perfectly up to the
> implementation of the combining algorithm to do what it wants with the
> arguments, even ignore them if it wants to.  So, I think this sentence is
> really meaningless. I added a sentence that states,
>
> "If the implementation supports combiner parameters and if combiner
> parameters are present in a policy, then the parameter values MUST be
> supplied to the combining algorithm implementation."
>
> What more really needs to be said here?
>
> 4. and finally, I noticed that Obligations made it into Rules. Did I loose
> that battle? Maybe so, I don't remember.
>
> But please answer me this, what does a Rule with the Effect of Deny mean
> with Obligations of FullfillOn="Permit" mean? What am I supposed to do
> with that?
>
> Cheers,
> -Polar
>
>
>
>
>
> 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.
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]