Next in thread →
Next in month →
Re: [xacml] Indeterminate Policy Targets [WAS: [xacml] Posted WD-19of core and WD-14 of SAML profile]
Hi Erik,
I will pull up your responses for ease of readability:
1. Yes, but the question is which type of Indeterminate? {P}, {D}
or {DP}? This was the issue which was posted on the comments list.
I was addressing Paul's "concern" that:
"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."
I was trying to say that the amount of evaluation that needed to
take place
depended on the combining algorithm and the possible values that had
been
returned and that this evaluation strategy was the same for Rules,
Policys,
and PolicySets, at least with the extended algorithms.
I then went on to discuss the explicit case of a Target
indeterminate, and what
potential impact that had on evaluating the children, and I said it
was the same
as if the "first child" evaluated to Indeterminate, one still needed
to look at
the combining alg and the results as one progressed to determine the
first
possible unambiguous break out time.
2. This is what Paul is proposing, but I think what I
wrote is safer. See my other response to Paul.
I don't see how what I was "proposing", which was not a proposal,
but an explanation
of how it currently operates, at least, as I interpret it, could be
in any way compared
to Paul's proposal which recommended a change.
As far as which "type" of Indeterminate to return to a XACML 2.0
environment,
I think your proposed language addresses the problem properly,
namely that
you just drop the qualifier, and 2.0 can proceed w/o taking
advantage of the
additional information that is possible in 3.0 but not in 2.0 as
specified.
Thanks,
Rich
On 4/19/2011 2:58 PM, Erik Rissanen wrote:
Hi
Rich,
See inline.
On 2011-04-19 20:55, rich levinson wrote:
Hi Paul,
A quick response is that it is basically the same as the rule
combining algorithms.
For example, in a deny-overrides policy, you have to continue
evaluating policies
until you either:
- find a deny,
- or a permit with no deny (basically all permits),
- or a permit and an indeterminate, which results in
indeterminate.
The only way to avoid evaluating all policies is if you
encounter a deny, then
you know the answer regardless of what the other policies might
return.
If the Target of the current PolicySet is Indeterminate, then I
expect one
would immediately return Indeterminate w/o evaluating the
children, since
they are all predicated on successful evaluation of the Target.
Yes, but the question is which type of Indeterminate? {P}, {D} or
{DP}? This was the issue which was posted on the comments list.
This is distinct from the case where say there is a parent
PolicySet that has
n child PolicySets, then if one of the child PolicySets is
Indeterminate, then
you still need to evaluate the other child PolicySets using the
algorithm above,
where the breakout point depends on what the combining algorithm
and the
current set of child results imply at that point.
Finally, I don't think finding Indeterminate in the parent
PolicySet Target is
ambiguous, because you would then look at the possible responses
from
its children and if they were only Permits it would be Ind(P),
if they were
only Denys then it would be Ind(D), and a mix would be Ind(DP).
I don't think there is much point in this last case of actually
evaluating the
child Policies after the parent Target is Indeterminate, but
there is a purpose
in "scanning" them to determine what their possible returns
would have
been.
This is what Paul is proposing, but I think what I wrote is safer.
See my other response to Paul.
Best regards,
Erik
Thanks,
Rich
On 4/19/2011 11:00 AM, 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:]
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
---------------------------------------------------------------------
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
Next in thread →
Next in month →