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

CsKnownIssues (last edited 2011-03-29 11:29:27 by erik)