Thanks Bill, In that case, what about if we agree on the next call for the minutes on the intended meaning, which can stand as implementation advice to users and vendors? Best regards, Erik On 2011-03-14 16:25, bill parducci wrote:
2CC859E6-1D39-49DD-AD85-CC55870053B7@parducci.net type= cite > Unfortunately, underspecification typically doesn't qualify as errata. Any material change to the meaning will require a formal update. b On Mar 14, 2011, at 4:37 AM, Erik Rissanen <
erik@axiomatics.com > wrote: 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