[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]