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: Indeterminate Policy Targets [WAS: [xacml] Posted WD-19 of coreand WD-14 of SAML profile]


I believe the intent has always been "2", that is a target is not just 
syntactic sugar. But I joined after 2.0 was done, so I cannot say for 
sure. In any case, that is what I think it should be. It is also what 
the spec unambiguously specifies because the evaluation tables are as 
they are. (Sure, the spec does not say explicitly that it "1" is not 
intended, but that's good. I don't think we should be specifying what 
the spec is not. ;-))

Anyway, I appreciate the analysis, but I think it's good as it is. I 
also agree with you Paul that the "deny-unless-permit" and 
"permit-unless-deny" algorithms are very bad practice. But some like 
them, so that's their concern. ;-)

Best regards,

On 2011-04-20 20:52, Tyson, Paul H wrote:
> See below.
>> -----Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Wednesday, April 20, 2011 09:00
>> To: Tyson, Paul H
>> Cc: xacml
>> Subject: Re: Indeterminate Policy Targets [WAS: [xacml] Posted WD-19
> of
>> core and WD-14 of SAML profile]
>> Hi Paul,
>> See inline.
>> On 2011-04-20 15:19, Tyson, Paul H wrote:
>>> I agree that conventional usage and interpretation of the spec could
>>> support this view (i.e., that a policy with a target should not
>> always
>>> give the same result as a policy with the target matching conditions
>>> distributed to rules).
>>> I'm saying that this is a logical inconsistency that we might want
> to
>>> consider fixing, rather than adding more special evaluation
>> procedures.
>> I don't think this is a logical inconsistency. It has to be like this
>> or
>> otherwise many of the current combining algorithms could not be
>> implemented. For instance the deny-unless permit also converts,
>> intentionally, Indeterminates to Denys.
> We can't have it two ways.  Either: 1) Target is syntactic sugar to
> avoid repeating conditions in rules (and to allow indexing of policies
> and rules); or 2) Target is a distinguished semantic component that
> plays an independent role in policy evaluation.
> As long as Target evaluates to "Match" or "No Match", it doesn't matter
> how you look at it--you will get the same results.  But when it
> evaluates to "Indeterminate", you must choose.  Your wd-19 proposal
> (section 7.13) assumes the 2nd interpretation.  I think there are
> advantages to choosing the 1st interpretation, and making the necessary
> changes to the specification to ensure consistent evaluation of policies
> according to this interpretation.
> If the TC has already considered this issue and decided that Target is a
> distinguished semantic component, then I will withdraw my objection.
> But I don't think there's enough evidence in the specification to make a
> definite interpretation.
> As for the "permit-unless-deny" and "deny-unless-permit" algorithms,
> they are dangerous syntactic sugar for policy writers who care not to
> structure their policies to fall through to an explicit Permit or Deny
> default rule.  Nevertheless, interpreting an indeterminate target as
> "all rules are indeterminate" would actually fortify the intent of these
> algorithms, which are to be used in cases where "NotApplicable" or
> "Indeterminate" are never wanted.  Under section 7.13 of wd-19, these
> algorithms would be overridden with an "Indeterminate" flavor of
> result--something the policy writer definitely did not want.
>> "The target evaluates to Indeterminate, so we do not know whether this
>> policy applies" is not the same thing as "all rules in this policy are
>> broken and return Indeterminate". In the latter case the policy
>> combining algorithm could override the rules and return something else
>> than Indeterminate.
> The first question only arises if Target is a distinguished semantic
> component, which I am arguing against.  The latter case may be
> occasionally surprising, but overall it is consistent.
> Regards,
> --Paul

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