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]

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.

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

> In either case, this sentence in Section 5.6 cannot stand as is:
> "For the parent of the<Target>  element to be applicable to the decision
> request, there MUST be at least one positive match between each<AnyOf>
> element of the<Target>  element and the corresponding section of the
> <Request>  element."
> This would imply that policies with indeterminate targets must always
> return "NotApplicable".

Well, I guess this is true. And I guess there are lots of other cases 
like this in the text. The problem is that there are three places with 
normative descriptions for target evaluation, for instance. The tables 
in the evaluation section, the text in the evaluation section and 
finally the text in the schema fragments section.

I am also saying that the way the text is written in human language, it 
will never be perfect. But the meaning should be clear from the context.

> Regards,
> --Paul
> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com]
> Sent: Wednesday, April 20, 2011 06:21
> To: Tyson, Paul H
> Cc: xacml
> Subject: Re: Indeterminate Policy Targets [WAS: [xacml] Posted WD-19 of
> core and WD-14 of SAML profile]
> Paul,
> See inline.
> On 2011-04-19 23:57, Tyson, Paul H wrote:
>> Erik,
>> I see your point.  But then we would force everyone to deal with
>> extended indeterminate values, even if they don't use any of the 3.0
>> algorithms that rely on them.  That doesn't sound right.
> The 3.0 algorithms are mandatory to implement, so they have to be dealt
> with anyway. In any case, if an implementation should choose to skip
> those algorithms, they can easily also skip anything to do with {D}, {P}
> and {DP}. So I would not worry about this.
>> Logically, a policy with a target is equivalent to a policy with the
>> target element transformed to an Apply expression and conjunctively
>> appended to the Condition of all descendant Rules.  So the result of
>> evaluating a policy with an indeterminate target should be the same as
>> the result of evaluating the re-written policy (with no target) as if
>> all rules returned "Indeterminate".
> No, this is not true. Currently the tables in the spec specify that if
> the target is Indeterminate, then the policy is Indeterminate (of some
> extended type). Transforming the policy like you say, would not lead to
> the same result in general since the combining algorithm is in principle
> free to do whatever with the Indeterminate from the rules. In fact, some
> of the 2.0 policy combining algorithms convert an Indeterminate to a
> Deny. So this transformed policy is not equivalent to the original
> policy in general.
> Best regards,
> Erik
>> For Policy evaluation, this could be specified like: "When the Target
>> value is Indeterminate, the result of the policy shall be determined
> by
>> applying the rule-combining-algorithm to the child Rules, while using
>> "Indeterminate" as the fixed return value from each Rule evaluated."
>> For PolicySet evaluation:  "When the Target value is Indeterminate,
> the
>> result of the policy set shall be determined by applying the
>> policy-combining-algorithm to the child policies and policysets, while
>> using "Indeterminate" as the fixed return value from each Rule
>> evaluated."
>> In either case it is not necessary that the implementation actually
>> evaluate the children--only that the results are identical to that
>> procedure.
>> Regards,
>> --Paul
>> -----Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Tuesday, April 19, 2011 13:55
>> 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,
>> I thought about the same issue. I think this is the most correct
>> interpretation of the extended indeterminate values and their meaning.
>> Just parsing the tree for effect might give unsafe results. Olav
>> Bandmann did some intereting analysis on the legacy combining
> algorithms
>> a few years ago, and I am afraid something similar might become an
> issue
>> in a more simplified processing model.
>> And I figured that Indeterminates are not a normal case anyway, so
> it's
>> unlikely that the extra overhead is going to have any real world
> impact.
>> Best regards,
>> Erik
>> On 2011-04-19 17:00, Tyson, Paul H wrote:
>>> Erik, good job on the spec.
>>> I have some misgivings about the "extended indeterminate" solution
> for
>>> policy[set] targets.
>>> When a policy or policy-set target evaluates to Indeterminate, are we
>>> saying that the PDP must still evaluate the children and apply the
>>> combining-algorithm?  I think that will result in a lot of extra
>>> evaluation for marginal benefits.
>>> At the root of the "extended indeterminate" problem for policy
> targets
>>> is the question: are we returning the possible indeterminate values
>> that
>>> could result from evaluating the policy in *this* request context, or
>> in
>>> *any possible* request context.  The 1st answer requires much more
>>> sophisticated processing (and might be undecidable in some cases);
> the
>>> 2nd answer can be determined simply by getting the unique values of
>> the
>>> descendant Rule/@Effect attributes (including those reachable by
>> policy
>>> references).
>>> Perhaps the "extended indeterminate" range of values should include
> an
>>> "Indeterminate{U}" value, interpreted as "it is unknown whether
> either
>> a
>>> Deny or a Permit could be returned".  The default "Indeterminate{DP}"
>>> value says "it is certain that either a Permit or a Deny decision
>> could
>>> be returned".  If this value bubbles up from rule evaluations, it is
>>> legitimate and perhaps helpful.  But if it comes from a policy
> target,
>>> it is ambiguous.
>>> We should reconsider whether to require full evaluation of policies
> or
>>> policy sets when the target is Indeterminate.  As a possible
>> evaluation
>>> shortcut, we could specify returning an extended indeterminate value
>>> based on the descendant Rule/@Effect values, without requiring full
>>> evaluation.
>>> If the new sections 7.11, 7.12, and 7.13 stand as is, there are some
>>> additional editorial changes to make, but I will save those pending
>>> result of discussion.
>>> Regards,
>>> --Paul
>>> -----Original Message-----
>>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>>> Sent: Thursday, April 14, 2011 12:17
>>> To: xacml
>>> Subject: [xacml] Posted WD-19 of core and WD-14 of SAML profile
>>> All,
>>> I have just uploaded XACML 3.0 core WD 19 and SAML profile WD 14. The
>>> fixes are for the recently found issues in CS-01:
>>> 1. CORE: Missing functions for the new dayTimeDuration and
>>> yearMonthDuration datatypes
>>> See
> http://lists.oasis-open.org/archives/xacml-comment/201012/msg00000.html
>>> The missing functions have been added and the old ones moved to
>> planned
>>> for deprecation.
>>> 2. SAML: Inappropriate use of xsi:type in SAML profile protocol
>> schemas
>>> See
> http://lists.oasis-open.org/archives/xacml-comment/201012/msg00001.html
>>> The schema has been corrected. Note that there is also a new spec
>>> document since the namespaces were changed. I also changed the
>> assertion
>>> schemas although there were no errors in them, but just to make the
>>> "wd-14" in the namespaces the same. I figured that unless I do that,
>>> somebody is going to ask about it...
>>> 3. CORE: The x500Name-match function is not clearly defined
> http://lists.oasis-open.org/archives/xacml-comment/201101/msg00005.html
>>> I added an example.
>>> 4. CORE: Inconsistent definition for the any-of-all function
>>> See
> http://lists.oasis-open.org/archives/xacml-comment/201101/msg00006.html
>>> I removed the Haskell stuff.
>>> 5. This issue intentionally left blank.
>>> 6. CORE: Specification of extended indeterminate in combining
>> algorithms
>>> is incomplete
>>> See
> http://lists.oasis-open.org/archives/xacml-comment/201103/msg00000.html
>>> I added the missing specifications as discussed on last week's
>> meeting.
>>> 7. CORE: Erratum concerning the 'Expression Substitution Group'
>>> See http://lists.oasis-open.org/archives/xacml/201103/msg00036.html
>>> I removed the<Condition>    element from this list.
>>> 8. CORE: Obligations problem
>>> See http://lists.oasis-open.org/archives/xacml/201103/msg00037.html
>>> I changed the wording as suggested by Greg.
>>> 9. CORE: Incomplete definition of the ipAddress-is-in and
>> dnsName-is-in
>>> functions
>>> See
> http://lists.oasis-open.org/archives/xacml-comment/201103/msg00006.html
>>> I removed these functions. Note that the other higher order functions
>>> were not defined for these data types anyway. They would have had the
>>> same issue.
>>> 10. CORE: Which argument is subtracted from the other by the
>>> integer-subtract function?
>>> See:
> http://lists.oasis-open.org/archives/xacml-comment/201103/msg00008.html
>>> I specified the order which is used in the 2.0 conformance tests.
>>> 11. CORE: Non-deterministic output of the string-from-type functions
>>> See
> http://lists.oasis-open.org/archives/xacml-comment/201103/msg00007.html
>>> I used the XSD canonical form where available, otherwise specified
> the
>>> form from the original XML encoding. Note, I also updated many other
>>> functions which also depended on datatype to string conversion. BTW,
>> one
>>> of the functions was uri equals, and I checked the spec for XML
>>> namespaces, which depends heavily on uri equality testing, and they
> do
>>> the same as we, namely just compare the string representation
>> straight,
>>> without any kind of interpretation or canonicalization of the URIs.
>>> Best regards,
>>> Erik
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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