All the issues from the comments list

[Erik Rissanen <erik@axiomatics.com>]

All,

There was recently a number of posts made on the XACML comments list. I 
have summarized them with my proposals for how to deal with them.

ISSUE A: Typo in the web services profile and core (2.0 and 3.0)

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00000.html
http://lists.oasis-open.org/archives/xacml-comment/200808/msg00001.html

PROPOSED ACTION:

Core 3.0, section A.3.8: Change the identifier for time-in-range so it's 
urn:...:2.0:...
Errata 2.0, section A.3.8: Change the identifier for time-in-range so 
it's urn:...:2.0:...



ISSUE B: Wrong publication date of core working draft

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00002.html

PROPOSED ACTION:

Nothing. Try to be more careful next time. :-)



ISSUE C: "Complex" definition of higher order functions

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00003.html

PROPOSED ACTION:

Nothing. It't not broken, so let's save the effort of changing it. 
Besides, if we change it, we might make a mistake, or users might think 
there has been a functional change.



ISSUE D: Multiple typos in identifiers in core 3.0 wd-06

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00004.html
http://lists.oasis-open.org/archives/xacml-comment/200808/msg00005.html
http://lists.oasis-open.org/archives/xacml-comment/200808/msg00006.html
http://lists.oasis-open.org/archives/xacml-comment/200808/msg00007.html

BTW, thanks Oleg and Roland for the script and running it for us. :-)

PROPOSED ACTION:

In core 3.0:

Section 4.2.4.2: fix date-less-or-equal identifier so it's 1.0

Multiple sections: fix so the "...:target-namspace" resource attribute 
identifier is always 2.0, not 1.0 or 3.0.

Section 7.15.3: fix so the identifier for missing status is 
urn:...:1.0:status:missing-attribute, not just 
urn:...:1.0.missing-attribute.

The script also reported a typo for "...:data-types:xpathExpression", 
but I had already changed that to "...:data-type:xpathExpression" in my 
working copy of the upcoming wd 7.

Section 10.2.8: update the three xpath function identifiers so they are 
3.0. (The functions have been redefined in 3.0.)

Section A.3.10-11: update the explanatory text so that functions such as 
urn:oasis:names:tc:xacml:1.0:function:type-is-in are called 
urn:oasis:names:tc:xacml:x.x:function:type-is-in instead since they are 
defined in various versions of XACML.

Section A.3.14: Fix typo in x500 name data type so it's 1.0, not 2.0.

OPEN ISSUE: The following two identifiers are in conflict, and I don't 
know which one is the correct one.

"urn:oasis:names:tc:xacml:1.0:subject:authentication-method"
"urn:oasis:names:tc:xacml:1.0:subject:authn-locality:authentication-method"

The rest from the list are false positives.




ISSUE E: Definition of string equal

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00008.html

Since we are XML-based, our strings are unicode strings.

OPEN ISSUE: String comparison in unicode is really complicated. See here:

http://www.w3.org/TR/xquery-operators/#string-compare

I haven't tried to understand this yet.



ISSUE F: Use of keyword 'MAY'

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00009.html
http://lists.oasis-open.org/archives/xacml-comment/200808/msg00011.html

PROPOSED ACTION:

Core 3.0, Section 5.1, 5.14, 5.21: The wording "a policy set MAY be 
evaluated, in which case..." refers to the fact that policies/sets are 
evaluated only when they are needed by the PDP. This does not conform to 
RFC 2119, so I propose that we lower case these occurences of "MAY".

Core 3.0, Errata 2.0: Say that the add function "MUST accept" two or 
more arguments. (I don't think it should work for zero of one argument 
only.)

OPEN ISSUE: Should the multiply functions take multiple arguments?



ISSUE G: Typos of "<AttributeValue>"

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00010.html

PROPOSED ACTION:

Core 3.0, Section 5.17, 5.47: Change AttributeValue to <AttributeValue>



ISSUE H: Whitespace in example attribute values

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00012.html

PROPOSED ACTION: remove the whitespace




ISSUE I: Wording

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00014.html

PROPOSED ACTION:

Nothing. This has no impact on the specification.



ISSUE J: Reference to floating point standard

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00015.html

PROPOSED ACTION:

Core 3.0, Errata 2.0: Remove references to IEEE 754 for integers and 
instead say "numbers are equal" or "less", etc.


ISSUE K: Wording of "indeterminate" in arithmetic

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00016.html

I think this should be rephrased as 'For all of these functions, if any 
argument is "Indeterminate", then the expression SHALL evaluate to 
"Indeterminate"'.



ISSUE L: Integer overflow in conversion

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00017.html

OPEN ISSUE: I think this should be such that the result is 
indeterminate, but I haven't thought about exact phrasing.



ISSUE M: Ambiguous use of "policy"

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00018.html

PROPOSED ACTION: Add "or a policy set".



ISSUE N: Various typos and issues

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00019.html

PROPOSED ACTIONS:

Ignore problems with oasis template. It's no big deal.

The schema location attribute doesn't hurt, and helps verificaiton in a 
schema aware editor.

"name-format" is an attribute which is not used in the example, so it 
could be removed.

Fix the typos in the example in section 4.2.2.

Fix the "integer-greater" typos.

"simple-filename" is defined in XACML 1.0. It's only an attribute id 
with no meaning to the PDP, so I don't care either way. Should it be 
removed or should the definition copied into the current spec? (1.1. 
defines it with full text.)

Fix "rx500Name" typo.

There is no "duration-equal" equal function in XACML, so I don't 
understand what he means with that. The two *Duration-equal seem to be fine.

<xf:dt-yearMonthDuration> type should be fixed. (I had already done so 
in my copy of the upcoming core draft.)

Section 4.2.4.2 example variable names should be as they are. No need to 
change them just because they have a "horrible" appearance.

Change "date-less-or-equal" description in example to say "compare" 
rather than "compute difference"

"therefore Rule 3 has to be formatted as a <Policy> element" is 
meaningful since rules cannot carry obligations. The fact that there are 
other policies as well is not significant.


ISSUE O: The normative status of XML fragments.

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00020.html

The schema fragments are not normative since the actual schema files are 
normative, and we want a unique normative statement in the specification.

PROPOSED ACTION:

Fix the typos in the descriptive texts:

Change that the policy issuer may contain "Zero to many" <Attribute> 
elements.

Keep "One to Many" since that makes explicit that many are allowed.



ISSUE P: Match evaluation

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00021.html

PROPOSED ACTION:

I agree. We should say "take two arguments" rather than "compare two 
arguments". Also, I think we can drop the list of example matching 
functions.



ISSUE Q: Misc multiple issues

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00022.html

Regarding the EffectType, Section 5.22 in the draft of 3.0 I am looking 
at has a definition of simple type EffectType, so I don't see any need 
to make a change on this issue.

Regarding variable references, this is an issue we should fix. PROPOSED 
ACTION: We should say that variable definitions which contain a circular 
dependency are invalid and they should either be detected at policy 
loading time, or result in an indetermininate runtime value for the 
particular variable reference evaluation.

There was nothing posted on the list about policy references, but I 
think the standard currently does not define anything about circular 
policy references either. PROPOSED ACTION: The standard should say that 
if a circular policy reference is detected, then the value of the policy 
for which the loop was detected must be indeterminate, or alternatively 
the PDP may refuse to load such policies if it can/prefers to detect the 
loop at runtime.

Regarding section 5.28, I agree. The treatment of the <Function> element 
is determinated by the specification of the higher order functions, and 
depends on the particular function. PROPOSED ACTION: Remove this statement.

Regarding section 5.29, I think the text is intended as advice to the 
reader so she can understand the standard more easily. I don't think 
there is any need to change this section.

Regarding data type of XML attributes, these can be seen in the 
normative schema, and expanding the text would make it more verbose and 
redundant, so I propose that we make no changes.

Regarding <AttributeValue>, it can be seen from the normative schema 
that it is an expression. I propose that we make no changes.

Regarding "has" vs "contains", there is no difference. I don't think 
this is an issue.

Regarding the "xacml:" prefix, I don't understand what is intended with 
this comment. I couldn't find any use of this prefix. If the comment 
refers to the use of the prefix in references to types or elements in 
the schema, like this:

<xs:element name="Rule" type="xacml:RuleType"/>
<xs:complexType name="RuleType">
    <xs:sequence>
        <xs:element ref="xacml:Description" minOccurs="0"/>
etc...

The use of the prefix in type="xacml:RuleType" and 
ref="xacml:Description" is required by XML Schema. type="RuleType" would 
mean something entirely different. So I don't see any need of any change.


Regarding section 5.37, "attribute" is defined as "Characteristic of a 
subject, resource, action or environment that may be referenced in a 
predicate or target". The <Content> element contains attributes in free 
form XML, not as <Attribute> elements. There is no need to change anything.

Regarding Deny-biased PDP, I agree, it contradicts the definitions of 
the PEP bias. I have marked this with a Word comment in the copy I have. 
I don't recall if the comment was in wd-06 as well. PROPOSED ACTION: We 
should replace the the text with "If the PDP does not understand or 
cannot fulfill an obligation, then the action of the PEP is determined 
by its bias. See section X.Y.Z"

Regarding "rule", Yes, it's a typo introduced during search and replace 
for setting the formatting of keywords. (BTW, I am not sure that the 
keyword stuff is very valuable. I could drop it.) PROPOSED ACTION: 
Change the formatting of the word "rules" so it is not highlighted as a 
keyword.

Regarding AttributeValue, this was already reported earlier so this is a 
duplicate of one of the issues in this email. Will fix...



ISSUE R: User defined set functions.

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00023.html

No, there is no way to use the set functions on user defined data types. 
Users defining data types need to define their own functions for them as 
well. If they want set functions for the new data type, those must be 
explicitly defined. I think this is correct, since there is no way to 
define set functions in general because the set functions depend on for 
instance equality testing for their implementation/definition, and 
equality may not always be defined for all data types. I propose that we 
make no changes here.



ISSUE S: rule combining algorithms

http://lists.oasis-open.org/archives/xacml-comment/200808/msg00024.html

I am not sure which is the normative description. Is it the textual 
description, or the pseudo code? Before we fix this issue, we need to 
decide. And then I think we should drop the one that is not normative. 
Without having given it any consideration, I would be inclined to prefer 
the pseudo code before textual description, at least as long as we don't 
need to define a formal language for the pseudo code. Pseudo code is 
easier to understand and read, and we are probably less likely to make a 
mistake there than in a textual description.

OPEN ISSUE: Which is normative? Check that the definitions are ok.



ISSUE T: Empty target

http://lists.oasis-open.org/archives/xacml-comment/200809/msg00000.html
http://lists.oasis-open.org/archives/xacml-comment/200809/msg00001.html

I think this could be clarified.

PROPOSED ACTION: Add the following text to the target evaluation 
definition "An empty target matches any request." Change the rule match 
table so that instead of "Match" it says '"Match" or no target' and add 
", or there is no target in the rule," in the text below the table.


Best regards,
Erik