Hi Matthew,
For convenience to all, the extended indeterminate is defined
in section C.1 of the spec.
http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.html#_Toc265751171
(link to the current CS version).
You are right that it's underspecified now that I read it
again. Specifically, as you say, the following is not well
defined:
- How shall an "Indeterminate" returned form a "normal"
algorithm be treated by an "extended" algorithm?
The intent has been that a "legacy" indeterminate corresponds
to a Indeterminate{DP} since the legacy algorithms do not
track the different cases. It should have been written out.
Regarding the reverse question, what a legacy algorithm should
do with an extended value, then the legacy algorithm would
ignore the additional indeterminate value, and treat it just
as a plain Indeterminate. I think that is what the spec
implies as it is, but it should have been explicitly spelled
out.
Regarding your question about the target, I agree that it's
underspecified and there are also a couple of sensible things
that could be done. I guess the most sensible thing would be
that depending on what the combination algorithm returns
(Permit, deny, a variant of indeterminate), you would return
the appropriate extended value for the policy/policy set as a
whole if there is an Indeterminate in the target.
Not sure how to fix this in practice as errata. Hal?
Best regards,
Erik
On 2011-03-11 21:07, Wood, Matthew D wrote:
The 10/8/2010 committee specification
(using urn:oasis:names:tc:xacml:3.0:core:schema:wd-17
namespace) appears to be incomplete with respect to
extended indeterminate states in the combining
algorithms. The new combining algorithms are defined
entirely in terms of extended indeterminate, but there
are cases where extended indeterminate values are not
available:
- Algorithms
present since the XACML 1.x, whether or not they are
marked for deprecation, are only specified in terms of
indeterminate
- Indeterminate
results from evaluating a policy target
There are no indications about how to
handle unextended indeterminate values in the new
algorithms or how an extended indeterminate should be
propagated through pre-3.0 algorithms.
For the first-applicable combining
algorithms, it seems reasonable to propagate the variant
of indeterminate as the result of the algorithm on lines
5646 and 5685 for the rule and policy combining
algorithms, respectively. The others are unclear to me,
though specification about how to handle unextendend
indeterminate results in the new algorithms would also
solve the problem in a seemingly simpler manner.
This issue makes it unclear about
what should be proper conforming behavior.
Another minor omission is lack of
explicit indication that obligations and advice should
be handled according to section 7.16 after the
pseudo-code for the first-applicable rule combining
algorithm, as appears for all other rule and policy
combining algorithms.
Matthew Wood
Sr. Software Engineer
SSG Software Pathfinding Initiative