List of known issues in CS 01
This is a list of known issues in the current Committee Specification (CS 01).
The target of the issue is indicated in the title as follows:
ADMIN Administrative Policy Profile (including administrative policy topics that affect 3.0 Core)
CORE XACML 3.0 Core
SAML SAML 2.0 profile of XACML Version 2
1. CORE: Missing functions for the new dayTimeDuration andyearMonthDuration datatypes
See http://lists.oasis-open.org/archives/xacml-comment/201012/msg00000.html
Yes, these function identifiers should be added to the lists, and yes, the old ones should be listed as deprecated.
Impact: incorrect conformance spec with some missing identifiers
2. SAML: Inappropriate use of xsi:type in SAML profile protocol schemas
See http://lists.oasis-open.org/archives/xacml-comment/201012/msg00001.html
Yes, it should say “type” instead of xsi:type. (Note though that the schemas work, as pointed out by the reporter of the issue.)
Impact: works in an implementation, but the schema is not as strict as it could be. Fairly limited real world impact. (An implementation should check the content of the XML messages more carefully after schema validation has been passed.)
3. CORE: The x500Name-match function is not clearly defined
http://lists.oasis-open.org/archives/xacml-comment/201101/msg00005.html
I don’t agree that there is an ambiguity. See my response here:
http://lists.oasis-open.org/archives/xacml-comment/201103/msg00004.html
Steven suggested adding an example, which we should.
Impact: non-issue, but add clarifying example.
4. CORE: Inconsistent definition for the any-of-all function
See http://lists.oasis-open.org/archives/xacml-comment/201101/msg00006.html
I agree with the poster that the Haskel definition does not appear to match the English language definition, and his suggested alternative does match the English text. I think the English description is the one which was intended, so we should change the Haskel definition.
Personally, I would prefer to take out the Haskel definitions altogether, rather than providing the missing ones, since it’s better to have only one normative definition.
Impact: there are two descriptions of a couple of functions, where some or wrong or incomplete. There are also correct definitions for everything. Not nice, but practical impact is probably small.
6. CORE: Specification of extended indeterminate in combining algorithms is incomplete
See http://lists.oasis-open.org/archives/xacml-comment/201103/msg00000.html
This points out a couple of cases where the new combining algorithms do not have undefined behavior. My suggestions are here:
http://lists.oasis-open.org/archives/xacml-comment/201103/msg00001.html
Severity: incomplete definition of combining algorithms.
7. CORE: Erratum concerning the 'Expression Substitution Group'
See http://lists.oasis-open.org/archives/xacml/201103/msg00036.html
This is an error. The <Condition> element should be removed from this list. (Though I don’t think this change has any impact on any implementation since the normative schema file is correct.)
Impact: probably no impact.
8. CORE: Obligations problem
See http://lists.oasis-open.org/archives/xacml/201103/msg00037.html
There is no incorrectness here, just awkward use of language. See my response:
http://lists.oasis-open.org/archives/xacml/201103/msg00053.html
Impact: non-issue
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
The identifiers should be removed.
Impact: Incorrect conformance section
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
This should be specified.
Impact: Ambiguous definition of functions
11. CORE: Non-deterministic output of the string-from-type functions
See http://lists.oasis-open.org/archives/xacml-comment/201103/msg00007.html
Probably a good idea to canonicalize as defined by the XSD spec.
Could probably leave the LDAP DN form free as it is.
Yes, it should say that the functions should evaluate to indeterminate if the input is not a valid lexical representation of the data type.
Impact: Non-c14n behavior in some function outputs
XACML Wiki