FW: [xacml] All the issues from the comments list

["Hal Lockhart" <hal.lockhart@oracle.com>]

The following resolutions have been proposed. The open issues are on the Agenda for today's TC call.

Hal

-----Original Message-----
From: Erik Rissanen [mailto:erik@axiomatics.com] 
Sent: Wednesday, September 03, 2008 1:47 PM
To: XACML TC
Subject: [xacml] All the issues from the comments list

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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php