Indeterminate Policy Targets [WAS: [xacml] Posted WD-19 of core and WD-14 of SAML profile]

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

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