The known issues in XACML 3.0 CS 01

[Erik Rissanen <erik@axiomatics.com>]

All,

I have collected from the mailing lists all issues found in the current 
committee specifications for XACML 3.0. (Let me know if I have missed 
something.) I have added my personal comment to each issue. Some of 
these are non-issues, but a couple of them should be fixed sooner or later.

Now, regarding how to fix this. The problem is that it takes so long 
time to do a round of approval. It's several months. For instance, I 
posted XACML 3.0 WD 18 on the 23rd of June, 2010. It was approved as a 
CS on the 10th of August 2010, which is close to two months, and this 
was done using weekly meetings, so it would be much longer with 
bi-weekly meetings.

So given how long it takes to drop back to WD, I would prefer that we go 
with the specs as they are and publish errata at a later stage. None of 
the issues are extremely severe. Issues 1, 4 and 6 or probably the most 
significant ones.

If we would do it through the whole thing again, I would ask that: 
Please respond to this email on the list now!! This way I can have a new 
spec ready for approval and public review vote for the next call. It's 
so slow to work in the TC because everything ends up being a four week 
cycle of no discussion on the list, discussion on the call, and then 
deferring to the next call. Also, I would ask us to go to weekly 
meetings until the process has completed again since it is so slow 
otherwise.

Anyway, here are the issues:

1 -- Missing functions for the new dayTimeDuration andyearMonthDuration 
datatypes

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.

Severity: incorrect conformance spec with some missing identifiers


2 -- Inappropriate use of xsi:type in SAML profile protocol schemas

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.)

Severity: 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 -- 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

Severity: non-issue.


4 -- Inconsistent definition for the any-of-all function

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.

Severity: 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.


5 -- A suggestion for better handling of multi-valued attributes in 
conditions

http://lists.oasis-open.org/archives/xacml-comment/201101/msg00007.html

This is not errata, rather a suggestion for a new feature, so I am not 
commenting on it further in this list.

Severity: non-issue (for 3.0).


6 -- Specification of extended indeterminate in combining algorithms is 
incomplete

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 functions. In practice implementation 
can be made correct by errata or discussion here.


7 -- Erratum concerning the 'Expression Substitution Group'

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.)

Severity: probably no impact.


8 -- Obligations problem

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

Severity: non-issue

Best regards,
Erik