[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Actions taken on XACML Comments, 11/21/02 and 11/25/02
Comment submitters, Thank you all for the time and effort you are taking in helping review the XACML Specification and schemas. Your comments are extremely valuable, and should help make the final XACML specification much more clear, consistent, and useful. Rather than respond individually to each of your comments, I am attaching the file containing resolutions to all comments to date. I hope this is satisfactory to you. It allows me to post responses to your comments in a more timely manner. Please continue submitting comments! Anne Anderson, Comments Editor -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
Title: Comments on XACML 1.0 Committee Specification Maintainer: Anne Anderson Version: 1.10, 02/11/25 (yy/mm/dd) Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.Comments.txt This file contains a link to every comment received on the xacml-comment@lists.oasis-open.org mailing list reporting any kind of problem with the specification since the public review was announced on November 8, 2002. Each comment is broken down into specific sub-comments, and the response to each is described, along with any actions to be taken by the TC. This version of the file contains e-mail up through http://lists.oasis-open.org/archives/xacml-comment/200211/msg00106.html CATEGORIES ---------- Editorial: Formatting error or formatting inconsistency. Inconsistent: Specification says one thing in one place and another thing in another place. Incomplete: Specification omits information required for full specification of a feature. Incorrect: Specification describes functionality that will not work due to external or internal constraints. Unclear: Description of feature is not clear or is ambiguous. Undesirable: Feature is not desirable. Alternative: Proposed alternative to a feature ====================================================================== COMMENTS ====================================================================== 0001. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00003.html Subject: An editorial comment on the XACML 1.0 document From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Sat, 09 Nov 2002 02:16:43 +0900 Appendix B.1 says that two namespaces are defined, but there are three URIs there. The URI for XACML datatypes should be removed? CATEGORY: Inconsistent. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: Remove B.1 lines 4332-4333 describing the urn:oasis:names:tc:xacml:1.0:data-type identifier from the specification. ============================================================================= 0002. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00004.html Subject: xs:time From: Seth Proctor <seth.proctor@sun.com> Date: Fri, 08 Nov 2002 12:33:59 -0500 Sections A.2 (Primative types) and B.4 (Data types) include date and dateTime, but not time. The time type is used by many functions and at least one standard attribute, and should be on those list. CATEGORY: Inconsistent. SEE ALSO: 0004 STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: Add http://www.w3.org/2001/XMLSchema#time to Sections 10.3.7, A.2, and B.4. ====================================================================== 0003. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00005.html Subject: resubmission: v_1.0 - niggling editorial nuggets From: bill parducci <bill.parducci@overxeer.com> Date: Fri, 08 Nov 2002 10:01:51 -0800 --------------------------------------------------------------------------- 0003a. line 520: '...element from each of the policies or policy' the word 'policy' is *half* bold. CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: Line 520, make word 'policy' all bold. --------------------------------------------------------------------------- 0003b. line 793: '[c01] <?xml version="1.0" encoding="UTF-8"?>' inconsistent font (times) actually, upon further inspection, the document seems to use proportionally spaced, sans serif fonts (e.g. 'arial') in the listings and example code starting at line 641 and continuing to line 826, at which point it uses the correct font, non proportional serif font (courier). CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: On lines 641-826, use non-proportional serif fonts. --------------------------------------------------------------------------- 0003c. line 1039: starting with line 1039 the examples are color encoded. the snippets prior to this are not. given the darkened background i think that the color makes it harder to read (and print), but either way i think that it should be consistent (sections 5 & 6 go back and forth twixt the two). this continues thorough [portions] of the primer. CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: Remove all color-encoding from XML fragments in the document. --------------------------------------------------------------------------- 0003d. line 3278: 'xacml:Policy:PolicySet' there seems to be an extraneous border line above the row in the table CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: Remove border line above xacml:Policy:PolicySet in the table following line 3278. --------------------------------------------------------------------------- 0003e. line 3291: 'Urn:oasis:names:tc:xacml:1.0:environment' there seems to be extraneous border lines above each of the rows in this table CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: Remove border lines between urns in table following line 3291. --------------------------------------------------------------------------- 0003f. line 3385: '<AttributeValue' snippet font (should be 'courier') CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: Use courier font in schema fragment following line 3385. --------------------------------------------------------------------------- 0003g. line 3399: '[IBMDSA]' i thought that the IBMDSA reference was replaced with an IEEE spec throughout the doc, or was this only in a specific instance? CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: In A.4, lines 3398-3399, change reference from "IBM Standard Decimal Arithmetic [IBMDSA]" to "IEEE Standard for Binary Floating-Point Arithmetic [IEEE754]". --------------------------------------------------------------------------- 0003h. line 4277: 'first argument of Anderson@sun.com?' question mark should be quotation mark CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: On line 4277, change 'Anderson@sun.com?' to 'Anderson@sun.com"' --------------------------------------------------------------------------- 0003i. line 4434: ' urn:oasis:names:tc:xacml:1.0:resource:scope' leading spaces or indentation (should be left margin aligned) CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: On line 4434, align "urn:oasis:names:tc:xacml:1.0:resource:scope" with the left margin. --------------------------------------------------------------------------- 0003j. finally, there seems to be some squooshing going on with lines 2618, 2742, 2778 in the pdf. can others confirm? CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: "squooshing" confirmed. ACTIONS: Unsquoosh lines 2618, 2742, 2778. ====================================================================== 0004. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00006.html Subject: followup to xs:time comment From: Seth Proctor <seth.proctor@sun.com> Date: Fri, 08 Nov 2002 14:51:42 -0500 all of the functions defined as type-* (like the type-one-and-only function) need to have a time-* version added in 10.3.8 (and maybe elsewhere, though I don't think so) CATEGORY: Inconsistent. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: Add function:time-one-and-only, function:time-bag-size, function:time-is-in, function:time-bag functions as mandatory-to-implement in the table in Section 10.3.8 "Functions". ====================================================================== 0005. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00007.html Subject: Inconsistent specification of <*Match> elements and-match functions From: Anne Anderson <Anne.Anderson@Sun.com> Date: Mon, 11 Nov 2002 14:28:14 -0500 (EST) Problem: MatchId functions used in a target take one AttributeDesignator or AttributeSelector argument, and one literal AttributeValue argument. The order of the two arguments is specified differently in different parts of the specification. Also, the *-match functions can only be used in a Target if the order of their arguments (template, specific value) agree with the order of arguments in a MatchId function (the AttributeDesignator or AttributeSelector, and the literal value). Recommendation: Option 1: Specify that the first argument to each *-match function is the specific value to be compared to the template, and the second argument is the template. To be consistent, rename "regexp-string-match" to "string-regexp-match". This requires the least change to the specification. Option 2: Specify that the first argument to a MatchId function is a literal AttributeValue and the second argument is the AttributeDesignator or AttributeSelector. Text locations where references occur: 1 must change if Option 1 selected 2 must change if Option 2 selected 2 - Every occurrence of <SubjectMatch, <ResourceMatch, or <ActionMatch except as called out below: Change order of AttributeSelector or AttributeDesignator argument and AttributeValue argument 2 - Section A.12 lines 3491-3493: reword as follows: "Each argument to the named function MUST match the appropriate primitive types for the explict attribute value and the following <AttributeDesignator> or <AttributeSelector> element, ... 1 - Section A.12, lines 3493-3496: reword as follows: "... such that an element of the bag returned by the <AttributeDesignator> or <AttributeSelector> element is placed as the first argument to the function, and the explicit attribute value is placed as the second argument to the function." 1 - Section A.14.12, lines 4250-4281: reverse order of arguments in the specifications for the -match functions, such that the first argument is the full value to be compared to the template or dominating value, and the second argument is the template or dominating (higher in the tree of values) value. 2 - Section A.14.13, lines 4306-4313: the specification of the xpath-node-match function probably needs to change to be consistent with the above if xpath-node-match is to be allowed in a Target expression. Note that several examples use xpath-node-match as MatchId functions, and line 3503 implies that this is permissable, but lines 3535-3540 indicate that xpath-node-match is NOT permissable in a MatchId function. CATEGORY: Inconsistent. STATUS: Resolved 14 November 2002. RESPONSE: Rejected. While the wording of Appendix A.12 needs improvement to be more clear, and while it is confusing to have the order of function arguments mean one thing in a Target and another thing in an Apply, the specification and semantics are consistent. Since several implementations are already successfully handling the varying argument order, we feel it is better to leave the argument order as currently specified. We encourage you to submit a proposed re-wording of Appendix A.12 that would make the current semantics more clear, however. ACTIONS: None. ====================================================================== 0006. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00008.html Subject: present function From: Seth Proctor <seth.proctor@sun.com> Date: Tue, 12 Nov 2002 11:00:52 -0500 Section A14.5 still lists a present function. I think the decision was to remove this functionality entirely for the time being. CATEGORY: Inconsistent. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: Remove lines 3730-3738, describing the "present" function, from the specification. ====================================================================== 0007. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00009.html Subject: a few typos From: Seth Proctor <seth.proctor@sun.com> Date: Tue, 12 Nov 2002 11:08:13 -0500 --------------------------------------------------------------------------- 0007a. 10.3.7: dayTime and yearMonth durations should read "xquery-operators" not "xquey-operaqtors" CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: In Section 10.3.7, change two instances of "xquey-operaqtors" to "xquery-operators". --------------------------------------------------------------------------- 0007b. 10.3.8: function:rfc822Name-equal is listed as rfc822name-equal (lower case 'n' in 'name') CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: In Section 10.3.8, change "function:rfc822name-equal" to "function:rfc822Name-equal" ====================================================================== 0008. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00010.html Subject: ...IsPresent and Qualified... From: John Merrells <merrells@jiffysoftware.com> Date: Tue, 12 Nov 2002 16:40:59 -0800 --------------------------------------------------------------------------- 0008a. In draft 18f section 5.30, 5.31, and 5.32 documents the AttributeIsPresent elements, but the 18f schema doesn't contain these. CATEGORY: Inconsistent. STATUS: Resolved 14 November 2002. RESPONSE: Rejected. The *AttributeIsPresent" elements were removed from the specification in XACML 1.0, which is the version being reviewed. ACTIONS: None. --------------------------------------------------------------------------- 0008b. Also, the 18f schema contains the QualifiedSubjectAttributeDesignator element, but this isn't described in the 18f draft, it first appears in the conformance tables 10.3.1 CATEGORY: Inconsistent. STATUS: Resolved 14 November 2002. RESPONSE: Rejected. The "QualifiedSubjectAttributeDesignator" element is named "SubjectAttributeDesignator" in the XACML 1.0 version of the specification, which is the version being reviewed. ACTIONS: None. ====================================================================== 0009. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00010.html Subject: Urn versus urn From: Seth Proctor <seth.proctor@sun.com> Date: Tue, 12 Nov 2002 11:03:53 -0500 in a number of sections in 10.3 (10.3.2, 10.3.4, 10.3.5, 10.3.6, 10.3.7) the 'u' in 'urn' has become a 'U' CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: Change "Urn:" to "urn:" in Sections 10.3.2, 10.3.4, 10.3.5, 10.3.6, and 10.3.7 (two types at the end of the table). ====================================================================== 0010. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00012.html Subject: missing functions in 10.3.8 From: Seth Proctor <seth.proctor@sun.com> Date: Wed, 13 Nov 2002 17:52:46 -0500 Section 10.3.8 is missing the regexp-string-match function as well as all of the Set functions CATEGORY: Inconsistent. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: To Section 10.3.8, as mandatory-to-implement, add the following functions: function:regexp-string-match <type>-intersection <type>-at-least-one-member-of <type>-union <type>-subset <type>-set-equals where <type> is "string", "boolean", "integer", "double", "date", "time", "dateTime", "anyURI", "hexBinary", "base64Binary", "dayTimeDuration", "yearMonthDuration", "x500Name", and "rfc822Name". ====================================================================== 0011. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00013.html Subject: The namespace URI for XACML data types From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Thu, 14 Nov 2002 14:11:15 +0900 Section 1.3 mentions a namespace URI for XACML data types. It should be removed. CATEGORY: Editorial. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: In Section 1.3 "Schema organization and namespaces", remove lines 320-321 that describe the urn:oasis:names:tc:xacml:1.0:data-type namespace. ====================================================================== 0011. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00014.html Subject: The footnote 1 in Appendix A.4 From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Thu, 14 Nov 2002 14:17:39 +0900 There is a footnote in Appendix A.4. An earlier RFC, RFC 1779 "A String Representation of Distinguished Names", is less restrictive, so xacml:x500Name uses the syntax in RFC 2253 for better interoperability xacml:x500Name should be replaced with the correct identifier. CATEGORY: Inconsistent. STATUS: Resolved 14 November 2002. RESPONSE: Approved. ACTIONS: In footnote "1" under Section A.1, change "xacml:x500Name" to "urn:oasis:names:tc:xacml:1.0:data-type:x500Name". ====================================================================== 0012. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00015.htm Subject: Section A12 From: John Merrells <merrells@jiffysoftware.com> Date: Thu, 14 Nov 2002 01:03:04 -0800 I'm finding section A12 difficult to understand. I think the information could be more clearly presented. 1) It introduces the Target element and its immediate child elements, and then the standard functions that can be used for a MatchID. But then a couple of paragraphs later it says that the only functions that can appear in a MatchID of a Target child are a different bunch of functions. This is confusing. 2) <i>type</i>-match appears as a standard function. (And does not appear in the conformance tables.) The subsequent paragraph starts "The evaluation semantics for a match is as follows...' But is this referring to the standard match functions as a whole, or just the behaviour of the <i>type</i>-match function itself. If not then where's the definition of <i>type</i>-match ? 3) The text and the examples refer to the special match functions before they've actually been defined. I think a reorg of section A12 would improve the legibility quite a bit. And followup in http://lists.oasis-open.org/archives/xacml-comment/200211/msg00016.html: > 2) <i>type</i>-match appears as a standard function. (And does not appear > in the conformance tables.) The subsequent paragraph starts "The > evaluation > semantics for a match is as follows...' But is this referring to the > standard > match functions as a whole, or just the behaviour of the > <i>type</i>-match > function itself. If not then where's the definition of > <i>type</i>-match ? I think I've worked out that the <i>type</i> place holder in the list of the standard match functions is not meant to stand in for all the types recognized by xacml, but is meant as a kind of wildcard to refer to the functions actually specified. So <i>type</i>-match doesn't mean integer-match, double-match, etc, but actually just rfc822Name-match and x500Name-match.I think other readers might be confused by this too. CATEGORY: Unclear. STATUS: Resolved 11/21/02. RESPONSE: Approved. We agreed that this section is unclear and needs to be re-worded. We agreed to keep the existing difference in argument order between MatchId functions and FunctionId functions, despite agreeing that this is very confusing and error-prone. The changes required to the specification (including most examples), implementations, and conformance tests are too pervasive to change at this point for a feature that is not actually broken. If the XACML specification is not submitted to OASIS for standardization on 15 December 2002, however, we agreed that the argument order should be made consistent before the specification is re-submitted. ACTIONS: Replace Appendix A.12 "Matching elements" with the revised text attached to e-mail message http://lists.oasis-open.org/archives/xacml/200211/msg00157.html. ========================================================================= 0013. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00032.html Subject: The PolicySet Schema (Line 1759--1762) From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Mon, 18 Nov 2002 15:02:24 +0900 A minor comment on Line 1759--1762. I found the type of two attributes (PolicySetId and PolicyCombiningAlgId) specified by a long URI http://www.w3.org/2001/XMLSchema#anyURI I'm not sure this is wrong, but I can say it's strange in the sense that the qname xs:anyURI is used in other schema descriptions (e.g., Line 1819, 1889). I think it's better to replace the long URI with the (short) qname. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved. Change to use qnames, since this is a fragment from the schema, not from an instance. ACTIONS: Change document lines 1759 and 1762 such that xs: is used instead of "http://www.w3.org/2001/XMLSchema#". ========================================================================= 0014. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00033.html Subject: No description about the PolicyDefaults element From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Mon, 18 Nov 2002 15:48:16 +0900 The <PolicySetDefaults> element is described in Section 5.3, but I could find no section describing the <PolicyDefaults> element. As a result, no syntax is defined for it in the specification document. Is this okay? CATEGORY: Incomplete. STATUS: Resolved 11/21/02. RESPONSE: Approved adding PolicyDefaults description. ACTIONS: Add PolicyDefaults section as new 5.21 as follows: 5.21 Element <PolicyDefaults> The <PolicyDefaults> element SHALL specify default values that apply to the <Policy> element. <xs:element name="PolicyDefaults" type="xacml:DefaultsType"/> <xs:complexType name="DefaultsType"> <xs:sequence> <xs:choice> <xs:element ref="xacml:XPathVersion" minOccurs="0"/> </xs:choice> </xs:sequence> </xs:complexType> <PolicyDefaults> element is of DefaultsType complex type. <XPathVersion> [Optional] Default XPath version. ACTION ITEM: #14. [Michiharu Kudo] submit following as new comment: COMMENT: In Section 5.20 Element <Policy>, under <Description> description, say "See 5.2 Element <Description>". In Section 5.2 Element <Description>, add <Rule> to the list from which this applies. ========================================================================= 0015. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00034.html Subject: conformance tests (NotApplicatble or Not-Applicabale) From: John Merrells <merrells@jiffysoftware.com> Date: Sun, 17 Nov 2002 23:32:46 -0800 The spec says 'Not-Applicable', but the tests (eg. IIB003Response.xml) say 'NotApplicable'. CATEGORY: Inconsistent. SEE ALSO: #16 STATUS: Resolved 11/21/02. RESPONSE: Approved changing specification text to "NotApplicable". ACTIONS: Change specification text throughout to use "NotApplicable" rather than "Not-Applicable". ========================================================================= 0016. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00035.html Subject: NotApplicable From: Seth Proctor <seth.proctor@sun.com> Date: Mon, 18 Nov 2002 10:07:50 -0500 The schema uses "NotApplicable" in a Decision, but the spec says that it's "Not-applicable" ... I'm pretty sure the schema is correct here, right? CATEGORY: Inconsistent. SEE ALSO: #15 STATUS: Resolved 11/21/02. RESPONSE: Approved changing specification text to "NotApplicable". ACTIONS: Change specification text throughout to use "NotApplicable" rather than "Not-Applicable". ========================================================================= 0017. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00036.html Subject: Another A.12 comment From: Seth Proctor <seth.proctor@sun.com> Date: Mon, 18 Nov 2002 10:09:47 -0500 Section A.12 (which I know Anne is re-working) makes several mentions of the EnvironmentMatch type ... there is no such type, so this should probably be removed from A.12 CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Remove EnvironmentMatch type. ACTIONS: Replace Section A.12 with the text supplied in e-mail message http://lists.oasis-open.org/archives/xacml/200211/msg00157.html. ========================================================================= 0018. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00039.html Subject: xacml:Policy:XpathVersion mandatory-to-implement? From: Anne Anderson <Anne.Anderson@Sun.com> Date: Mon, 18 Nov 2002 11:45:24 -0500 (EST) In Section 10.3.1, "xacml:Policy:XpathVersion" is listed as mandatory-to-implement. ------------------------------------------------------------------------ 0018a. This should be spelled "XPathVersion" CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved. Spelling should be "XPathVersion". ACTIONS: Change 10.3.1 to use "XPathVersion" spelling. ------------------------------------------------------------------------ 0018b. This should not be mandatory-to-implement, since support for XPath functionality and the containing PolicyDefaults are not mandatory-to-implement. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved. XPathVersion is not mandatory-to-implement. ACTIONS: Change 10.3.1 M/O column for "xacml:Policy:XPathVersion" to "O". ------------------------------------------------------------------------ 0018c. 10.3.1 should contain "xacml:Policy:PolicyDefaults", and it should be marked not mandatory-to-implement CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved. Add an entry for PolicyDefaults marked not mandatory-to-implement. ACTIONS: Add to 10.3.1 an entry for "xacml:Policy:PolicyDefaults", marked "O" (optional). ========================================================================= 0019. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00040.html Subject: Incomplete: behavior if <Obligations> present but notsupported From: Anne Anderson <Anne.Anderson@Sun.com> Date: Mon, 18 Nov 2002 13:25:13 -0500 (EST) The behavior of a PDP that does not support the optional <Obligations> element when presented with a Policy containing <Obligations> is not specified. Possible behavior: if a Policy or PolicySet is Applicable to a Request and the Policy or PolicySet contains <Obligations>, but the PDP does not support <Obligations>, that the PDP MUST return "Deny". CATEGORY: Incomplete. SEE ALSO: #20 STATUS: Resolved 11/21/02. RESPONSE: Approved specifying behavior. Behavior SHALL be to return "Indeterminate". ACTIONS: Add new Section 7.12 "Unsupported functionality" as follows: 7.12 Unsupported functionality If the PDP attempts to evaluate a PolicySet or Policy that contains an element type or feature that the PDP does not support, then the PDP SHALL return a response of "Indeterminate". If a StatusCode is also returned, the PDP SHALL return a StatusCode value of "urn:oasis:names:tc:xacml:1.0:status:syntax-error" for an unsupported element type error , and "urn:oasis:names:tc:xacml:1.0:status:processing-error" for an unsupported feature error. ========================================================================= 0020. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00041.html Subject: INCOMPLETE: behavior when XPath encountered,but not supported From: Anne Anderson <Anne.Anderson@Sun.com> Date: Mon, 18 Nov 2002 13:37:35 -0500 (EST) The behavior of a PDP that does not support the optional XPath *Defaults, selectors, functions, etc. when presented with a policy containing such elements is not specified. In some cases, the XPath elements may appear in a <Target> element, making it impossible to determine whether or not a PolicySet, Policy, or Rule is applicable. In other cases, the <Target> element may not require any XPath functionality, and a PolicySet, Policy, or Rule may be applicable, but evaluating the <Condition> in the Rule may require XPath functionality. Possible behavior: If, during evaluation of a Request, any unsupported element is encountered, then the PDP MUST return a result of Indeterminate. CATEGORY: Incomplete. SEE ALSO: #19 STATUS: Resolved 11/21/02. RESPONSE: Approved specifying behavior. Behavior SHALL be to return "Indeterminate". ACTIONS: Add new Section 7.12 "Unsupported functionality" as follows: 7.12 Unsupported functionality If the PDP attempts to evaluate a PolicySet or Policy that contains an element type or feature that the PDP does not support, then the PDP SHALL return a response of "Indeterminate". If a StatusCode is also returned, the PDP SHALL return a StatusCode value of "urn:oasis:names:tc:xacml:1.0:status:syntax-error" for an unsupported element type error , and "urn:oasis:names:tc:xacml:1.0:status:processing-error" for an unsupported feature error. ========================================================================= 0021. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00042.html Subject: C.3 First-Applicable policy-combining alg inconsistent From: Anne Anderson <Anne.Anderson@Sun.com> Date: Mon, 18 Nov 2002 16:29:27 -0500 (EST) In the description of the policy-combining algorithm for FirstApplicable, lines 4752-4754 say: if error occurs while evaluating a policy, then evaluation shall continue looking for an applicable policy, returning Indeterminate only if no applicable policy found. But lines 4755-4758 say: if error occurs while evaluation a policy, then evaluation shall halt and policy set shall evaluate to "Indeterminate". Lines 4752-4754 should be deleted. That would be consistent with the pseudo-code and with the "safety" of not allowing any "Permit" if there is an Indeterminate that should have returned a Deny. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved deleting pdf:4752-4754. This removes the first, incorrect description of how the PDP behaves in the face of an error and retains the second, correct description. ACTIONS: Delete lines pdf:4752-4754 ========================================================================= 0022. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00044.html Subject: Section 5.24 From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Tue, 19 Nov 2002 14:31:14 +0900 There is no description about the child element <xacml:SubjectAttributeDesignator> in Section 5.24. Some description should be added between Lines 2162 and 2163. CATEGORY: Incomplete. STATUS: Resolved 11/21/02. RESPONSE: Approved adding a description of SubjectAttributeDesignator. ACTIONS: Add the following before line pdf:2168: <SubjectAttributeDesignator> [Optional] A subject attribute argument. ========================================================================= 0023. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00045.html Subject: Line 308: The SAML prefix From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Tue, 19 Nov 2002 14:41:02 +0900 In Line 308, the SAML prefix (saml:) is mentioned, but it never appears anywhere in the document. The line should be removed. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved removing line pdf:308 ACTIONS: Remove line pdf:308 ========================================================================= 0024. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00046.html Subject: Comments on the prefix xf From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Tue, 19 Nov 2002 14:56:39 +0900 In Line 1295, the QName xf:yearMonthDuration should be replaced by the correct URI. In Line 1345, the QName xf:yearMonthDuration should be replaced by the correct URI. Appendix A14.7: In Lines 3759, 3766, 3773, 3782, 3790, 3796, the QName xf:yearMonthDuration should be replaced by the correct URI. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved using full uri. ACTIONS: In lines 1295 and 1345, use "http://www.w3.org/TR/xquery-operators#yearMonthDuration" instead of "xf:yearMonthDuration" ========================================================================= 0025. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00047.html Subject: Line numbering is inconsistent From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Tue, 19 Nov 2002 15:08:56 +0900 Line numbering is inconsistent between the PDF file and the Word file. I have downloaded them from: http://www.oasis-open.org/committees/xacml/repository/cs-xacml-core-01.doc http://www.oasis-open.org/committees/xacml/repository/cs-xacml-core-01.pdf An example: In the PDF file Line 43 is a blank line. In the Word file Line 43 is about the copyright. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Commenters should specify which version is being used. Accept comments from either version. In the future, Bill Parducci will generate both versions before we post either so that we can verify that numbers match. ACTIONS: None for now. ========================================================================= 0026. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00048.html Subject:The type of the RequestContextPath attribute From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Tue, 19 Nov 2002 15:34:25 +0900 The current type of the RequestContextPath attribute is xs:anyURI. (Section 5.31) I don't think that a valid XPath expression is always a valid URI (according to RFC2396). So I think the type should be xs:string rather than xs:anyURI. Please correct me if I'm wrong. In the XML-Signature specification, the type of XPath expressions is xs:string. Follow-on: http://lists.oasis-open.org/archives/xacml-comment/200211/msg00068.html Date: Thu, 21 Nov 2002 15:36:40 +0900 For example, /xml[2] is not a valid URI. CATEGORY: Incorrect. STATUS: Resolved 11/21/02. RESPONSE: Approved changing DataType in line 2421 to xs:string. ACTIONS: Change line 2421 DataType from xs:anyURI to xs:string. ========================================================================= 0027. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00049.html Subject: Function Identifiers in Section 10.3.8 From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Tue, 19 Nov 2002 21:11:44 +0900 Section 10.3.8 uses QName as function identifiers. Don't use the namespace prefix "function" and replace all the qnames with the corresponding URIs. Remove line 3302 (xmlns:function="urn:oasis:names:tc:xacml:1.0:function"). CATEGORY: Inconsistent. SEE ALSO: #29,30 STATUS: Resolved 11/21/02. RESPONSE: Approved. Use full urn; remove xmlns:function line. ACTIONS: Use full "urn:oasis:names:tc:xacml:1.0:function:" throughout the specification rather than just "function:". Remove line 3302 that describes the xmlns:function. ========================================================================= 0028. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00050.html Subject: equality & set/bag functions From: Seth Proctor <seth.proctor@sun.com> Date: Tue, 19 Nov 2002 17:34:32 -0500 The set and bag functions (along with others), are defined as type-[name] where this is expanded to include one function for each standard type. Presumably this includes the two duration attribute types. One of the bag functions and several of the set functions also specify that their definitions are based on using the type-equal function for the coresponding type. The equality functions, however, are defined individually for each type, and no equal functions are defined for the two duration types. So, the question: should there be equality functions defined for the two duration types, or should certain type-[name] functions not be able to handle the two duration types? It seems like one of those two must change to make this work. CATEGORY: Incomplete. STATUS: Resolved 11/21/02. RESPONSE: Approved. Add dayTimeDuration-equal and yearMonthDuration-equal functions. Use XQuery semantics. ACTIONS: Add following text at end of Section A.14.1, following line pdf:3639: o dayTimeDuration-equal This function SHALL take two arguments of type "http://www.w3.org/TR/xquery-operators#dayTimeDuration" and SHALL return an "http://www.w3.org/2001/XMLSchema#boolean". This function shall perform its evaluation according to the "op:dayTimeDuration-equal" function [XQO Section 8.3.5]. Note that the lexical representation of each argument is converted to a value expressed in fractional seconds [XQO Section 8.2.2]. o yearMonthDuration-equal This function SHALL take two arguments of type "http://www.w3.org/TR/xquery-operators#yearMonthDuration" and SHALL return an "http://www.w3.org/2001/XMLSchema#boolean". This function shall perform its evaluation according to the "op:yearMonthDuration-equal" function [XQO Section 8.3.2]. Note that the lexical representation of each argument is converted to a value expressed in integer months [XQO Section 8.2.1]. ========================================================================= 0029. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00053.html Subject: The prefix "function:" is used in Section 4 Examples From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Wed, 20 Nov 2002 12:34:21 +0900 The namespace prefix "function:" is used in the explanation for the examples in Section 4. There are too many places where it is used and so I cannot list all here. All should be replaced with the correct URIs. E.g., function:string-equal Function:string-equal (Capital F is used) function:and function:string-one-and-only function:date-less-or-equal function:date-one-and-only CATEGORY: Inconsistent. SEE ALSO: #27,30 STATUS: Resolved 11/21/02. RESPONSE: Approved using full urn. ACTIONS: Use full "urn:oasis:names:tc:xacml:1.0:function:" throughout the specification rather than just "function:". ========================================================================= 0030. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00054.html Subject: The prefix "function:" is used in Appendix A From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Wed, 20 Nov 2002 12:39:38 +0900 The namespace prefix "function:" is used in Appendix A. There are too many places where it is used and so I cannot list all here. All should be replaced with the correct URIs. CATEGORY: Inconsistent. SEE ALSO: #27,29 STATUS: Resolved 11/21/02. RESPONSE: Approved using full urn. ACTIONS: Use full "urn:oasis:names:tc:xacml:1.0:function:" throughout the specification rather than just "function:". ========================================================================= 0031. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00055.html Subject: The default value of the MustBePresent attribute(Section 5.26) From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Wed, 20 Nov 2002 16:08:50 +0900 The default value "false" of the MustBePresent attribute is NOT specified in the schema in Section 5.26. It should be added. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved adding default="false". This is correct in the schema. ACTIONS: Add default="false" to line pdf:2203 ========================================================================= 0032. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00058.html Subject: Problems understanding XACML spec From: Graham Klyne <GK@NineByNine.org> Date: Wed, 20 Nov 2002 13:40:25 +0000 I'm having a really hard time understanding what you're trying to say in the XACML spec: http://www.oasis-open.org/committees/xacml/repository/draft-xacml-schema-policy-18d.doc ACTIONS: Anne Anderson sent Graham Klyne a message explaining that the public review is being held with respect to XACML 1.0, and not draft 18d. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00060.html Comments may still apply, since they are fairly general, so I have listed them below. ------------------------------------------------------------------------ 0032a. The description of a rule seems to be inadequately motivated. The description in section 2 (background) says "The <Rule> element contains a boolean expression that can be evaluated in isolation..." which doesn't do anything to prepare me for the description I find in section 3.3.1. I'm finding it particularly hard to see (a) what this Boolean expression is evaluated over (it seems to have something to do with the rule target), and (b) how the Boolean result relates to the evaluation of the rule. I can see that a Boolean true results in Permit or Deny depending on the value of the rule's effect field, but what happens if the Boolean value is false? As far as I can tell, understanding this is crucial to understanding all the other stuff about combining rules and policies. CATEGORY: Unclear. STATUS: Discussed 11/21/02. RESPONSE: Approved in general. It is unclear. ACTION ITEM: #32a. [Tim Moses] propose an introductory paragraph for 3.3.1 motivating Rule. ACTIONS: ------------------------------------------------------------------------ 0032b. Under what circumstances is a rule found to be "NotApplicable"? CATEGORY: Unclear. STATUS: Resolved 11/21/02. RESPONSE: We believe this is specified clearly in Section 7.5 of XACML 1.0. ACTIONS: No change. ------------------------------------------------------------------------ 0032c. I also find the reference to the fact that a rule may "inherit" target information from a policy is particularly obscure. It seems to me that the idea of a rule is fundamental to understanding this specification, but that vital idea is not adequately explained. It may be that the information is present somewhere in this document, but it is a big and complicated document and I can't tell what's important. CATEGORY: Unclear. STATUS: Resolved 11/21/02. RESPONSE: Approved. This is not clear. ACTIONS: Lines 631-632. Change wording to say "Rule uses the <Target> of its parent Policy element." ------------------------------------------------------------------------ 0032d. I think more attention needs to be paid to the order in which concepts are introduced. I would expect section 2 to deal with this, but it seems some important ideas are not being adequately explained. CATEGORY: Unclear. STATUS: Resolved 11/21/02. RESPONSE: Please submit any specific important ideas that are not being adequately explained or are in the wrong order in Section 2 in the XACML 1.0 specification. Note that Section 2 only covers key concepts, with full detail in later sections. ACTIONS: None. ------------------------------------------------------------------------ 0032f. I also think there's an over-dependence in the text on abbreviations that are introduced in the glossary. There are many special terms, and ordinary words used with special meaning, and it's not reasonable to assume that someone not familiar with them to absorb them on one pass through the glossary. CATEGORY: Unclear. STATUS: Resolved 11/21/02. RESPONSE: We believe this has been improved in XACML 1.0: terms from the glossary are bolded in XACML 1.0 to indicate they have special meaning. This is a specialist area, and we expect people to refer to the glossary until they are acquainted with the terms. Please submit any specific places that are not clear in the 1.0 version. ACTIONS: None. ========================================================================= 0033. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00061.html Subject: map function From: Seth Proctor <seth.proctor@sun.com> Date: Wed, 20 Nov 2002 16:22:32 -0500 I'm a little concerned with the definition of the map function. Every other function and attribute in the spec has a well defined type associated with it, but the map function does not. Even things like the bag functions are defined as type-* so that each of the bag functions returns a well defined type (ie, there is a uniquely named function for each bag function that returns each attribute type). The map function, however, is simply defined as returning a bag of some type. For consistency, and to make sure that the strong typing present in the rest of the spec exists here too, I would suggest that the map function be redefined as type-map, such that there is a named map function for each type in the spec. I think the functionality being provided by map makes sense, I just think it should be clear what types of bags the map function returns. CATEGORY: Alternative. STATUS: Discussed 11/21/02. RESPONSE: ACTIONS: DISCUSSION: [Daniel] I would second this motion - I suggested it some time ago, but somehow it got lost. It is indeed redundant to some extend, but for consistency it should be done I believe. Now that we allow function to be a parameter, having a top level funciton of undefined type really complicates proper extension API design. But nobody seems to care about extensions at this point. Well, eventually you will, but it would be too late to fix it. [Polar] The map function is polymorphic. The type of the map function is deduced by the function parameter and the other argument has to coincide. The type of map is ( ( a -> b ) -> [a] -> [b] ). That is, map takes a function that transforms an element of one type to another, a bag of the first type, and returns a bag of the resultant type. What would "integer-map" mean? Would that mean a transformation of a bag of integers to integers? Somehow, that would defeat the purpose of the brevity of the specification, especially if you wanted to convert doubles to integers, or dates to strings, etc. If you want to define explicit map functions you would have to use the cross product of types, i.e. *-*-map. You define an awful lot of functions. Any good type checker can handle this. Also that would limit the use of the function to just the primitive types. If you invent another type, you have to define a new type-*-map and *-type-map functions, (at least for every *type you you have transformation functions defined. That would defeat the beauty of higher order functions, reducing the specification by extracting common functionality. As far as extension APIs. I whole heartily disagree with Daniel. I do care about them. I dont have any problem in defining new types and applying the higher order functions to any well defined function. Maybe this is just an implemenation issue. [Seth Proctor] > The type of the map function is deduced by the function parameter and the > other argument has to coincide. This sounds similar to the argument for not including the DataType attribute in AttributeValues. The whole idea is that we should be able to look at an attribute, a function, a designator, etc., and know what type it will be returning. Without that, there is no strong type-system. > What would "integer-map" mean? Would that mean a transformation of a bag > of integers to integers? Somehow, that would defeat the purpose of the > brevity of the specification, especially if you wanted to convert doubles > to integers, or dates to strings, etc. No. The integer-map function would be a function that returns a bag of integers, and therefore expects a function that also returns integers. It would mean nothing more. You could still have a function that converts doubles, strings, etc to integers. The return type of a function does not limit what it accepts or works with internally. This would be consistent with the rest of the sepc, and would require a minimal number of additional functions. [Daniel] Let me elaborate a bit on why I agree with Seth. Since the function name (and therefore type) is a parameter for the map function, you do not now what type it will return until you now the value of this parameter. In the current, limited functionality system we do no the value at the "compile" time. To provide a uniform extensibility mechanism for these "higher" order functions, we may need to allow the value of each argument to be a parameter with a value determined at the runtime. In this case the functions that take this map output as an argument can not be verified to accept the correct data type in advance. In the case that the map type is declared and the function name is a runtime valued parameter - inappropriate name will result in an Indeterminate: a condition that we have a clear mechanism to deal with. For this reason - ALL XACML functions should have declared, not deduced, type. [Polar] Declaring a type of a map function by putting the return type in the name, such as "integer-map" doesn't mean much more than restricting the function name to primitive types. Furthermore, you are only "declaring" a partial type, because you are not "declaring" the type of the argument. Also, "integer-map" sounds like you are going to be "mapping a bunch of integers". Also, this forces you to "invent" a name for each type you may introduce into XACML for a map to all functions and have it work. For example, if you invent a type "http://www.xyz.com/datatype#heathrecord" and you have a function called "function:RecordID" that takes an element of type "http://www.xyz.com/Datatype@heathreaord" and returns a "http://www.xyz.com/datatype#RecordId". If you want to use a function then you have to define a function called "?????-map" so it will map a bag of "http://....healthrecord" to a bag of "http:///....RecordId". So, now you have to call it something. Let me say that giving a rose another name, doesn't make it something different than a rose. What we have here is the generic application of the SAME FUNCTIONALITY, so why give the same functionality different names? The type of the map function is: map :: (a -> b) -> [a] -> [b] The definition of the map function is: map f [] = [] map f (x:xs) = (f x) : (map f xs) Where f is a function from type a to type b, and the function is just applied to every element of the bag. So why give it different names? integer-map = map string-map = map date-map = map duration-map = map etc. [Seth] On Mon, Nov 25, 2002 at 10:29:03AM -0500, Polar Humenn wrote: > What we have here is the generic application of the SAME FUNCTIONALITY, so > why give the same functionality different names? Because this is how it is done with every other function in the spec. As a result, you need this for the map function too if you want consistency. Yes, I see the value of having a generic function that can map any type to any type, but it breaks the type system that the rest of the spec has defined. Both Daniel and I are speaking from an implementors point of view, and we both see the muddle that occurs when you have this special-case function. The clean definitions in the spec completely break when you allow the map function to not have its return type explicitly defined. Implementors will already need to define things like -equal, or -one-and-only, or -union for their new attribute types. Redefining the map function doesn't change this. A good implementation will let a programmer do this with a minimum of effort, but it is still necessary. To maintain consistency, and to keep the type system intact, the map function must become type-map. [Polar] Not true. "integer-equal" is fundementally different that "string-equal", etc. Map is generic, or polymorphic over "bags". And, "integer-equal" specifies a function that determines equality over integers (i.e. as arguments). If you took your approach to naming the map functions, e.g. "integer-map" naming the resultant type only, then to be "consistent" you would really have to name the "integer-equal" function as "boolean-equal", which doesn't make sense. [Anne] Maybe we should have asked for opinions from just one of {Polar, Daniel} :-) ========================================================================= 0034. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00062.html Subject: XCAML Spec version 1.0 - Example 2, Rule 1 From: Jahan Moreh <jmoreh@sigaba.com> Date: Wed, 20 Nov 2002 14:09:54 -0800 Section 4.2.3. Rule 1, line 1027 states that: "A person may read any record for which he or she is the designated patient". Section 4.2.4.1., Line 1036 starts the XACML rule instance for rule 1, which I assumed is the rule expressed in English in line 1027. Line 1095-1111 (the condition) defines a condition for matching the policy-number attribute from the <Subject> with the policy-number in the patient record. This condition does not match the English statement (A person may read any record for which he or she is the designated patient) stated earlier. Am I missing something or is this an inconsistency? CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: In Rule 1, "person" in the text descriptions is referred to by "policy-number" in the <Condition>. "policy-number" is used as the patient ID. We agree this is unclear, since "policy" has other meanings. ACTIONS: Use "patient-number" as the attribute name rather than "policy-number" in the examples. Also in 1027 Rule 1, say "A person, identified by patient number, may ....". Also, augment line 1166-1168 to describe that the person is being described by the person's patient-number. ========================================================================= 0035. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00063.html Subject: The identifiers are wrong in Appendix A.2 and B.4 From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Thu, 21 Nov 2002 11:46:26 +0900 In A.2 the separation char is #. E.g., http://www.w3.org/TR/xquery-operators#dayTimeDuration In B.4 the separation char is :. E.g., http://www.w3.org/TR/xquery-operators:dayTimeDuration Is this an inconsistency? CATEGORY: Inconsistent. STATUS: Resolved 11/25/02. RESPONSE: Use # as the separation char in both places. ACTIONS: B.4 replace : with # in datatypes. Search for similar problems throughout spec. ========================================================================= 0036. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00064.html Subject: Primitive type identifiers in B.4. From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Thu, 21 Nov 2002 12:49:14 +0900 Appendix B.4 says that several identifiers are defined in XML Schema and XQuery. I know that XML-schema identifiers (like http://www.w3.org/2001/XMLSchema#string) are explicitly defined in Section 3 of the XML-Schema specification: http://www.w3.org/TR/xmlschema-2/#built-in-datatypes How about the two XQuery-related identifiers? http://www.w3.org/TR/xquery-operators#dayTimeDuration http://www.w3.org/TR/xquery-operators#yearMonthDuration Are these URIs defined in the XQuery specification? http://www.w3.org/TR/xquery-operators/ If yes, tell me which part of which section defines them? If no, it should be explicitly said that the XACML specification defines these two identifiers by itself. CATEGORY: Incomplete. STATUS: Not yet discussed. RESPONSE: Define the two XQuery-related identifiers in XACML Specification. ACTIONS: In Appendix B.4, Change "The following data type identifiers are defined by XML Schema and XQuery" to "The following data type identifiers are defined by XML Schema. [follow this with the list of datatypes from #string to #base64Binary]. The following data type identifiers correspond to the dayTimeDuration and yearMonthDuration data types defined in the XQuery specification [XQO Sections 8.2.2 and 8.2.1, respectively]. http://www.w3.org/2002/08/xquery-function#dayTimeDuration http://www.w3.org/2002/08/xquery-function#yearMonthDuration ========================================================================= 0037. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00065.html Subject: About subject category attributes From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Thu, 21 Nov 2002 14:28:55 +0900 Section 6.2. says that: No more than one <Subject> element may contain an <Attribute> with the given value for AttributeId “urn:oasis:names:tc:xacml:1.0:subject:subject-category”. What does this mean? How is this related to the following description in Section 5.30??? If there are multiple subjects with the same subject category attribute, then they SHALL be treated as if they were one categorized subject. CATEGORY: Inconsistent. STATUS: Resolved 11/25/02. RESPONSE: Change 6.2 to agree with 5.30. ACTIONS: Section 5.30: "Multiple <Subject> elements may contain an <Attribute> with a given value for AttributeId "urn:oasis:names:tc:xacml:1.0:subject:subject-category". For a SubjectAttributeDesignator, all <Subject> elements with the same value for AttributeId "urn:oasis:names:tc:xacml:1.0:subject:subject-category" are treated as if they were a single <Subject> element. ========================================================================= 0038. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00066.html Subject: A wrong URI in Section 5.30 From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Thu, 21 Nov 2002 14:32:42 +0900 Replace http://www.w3.org/2001/XML-Schema-instance#string with http://www.w3.org/2001/XMLSchema#string CATEGORY: Inconsistent. STATUS: Resolved 11/25/02. RESPONSE: Accepted. Change to XMLSchema#string. ACTIONS: Change pdf:2362-2363 to use "http://www.w3.org/2001/XMLSchema#string" ========================================================================= 0039. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00067.html Subject: subject-category as attribute, rather than <Attribute> From: John Merrells <merrells@jiffysoftware.com> Date: Wed, 20 Nov 2002 22:24:12 -0800 I can see why the subject-category attribute has been modelled the way that it has, as an <Attribute> of the <Subject> element. But how about modelling it as an XML attribute of the <Subject> element instead? <Subject Category='...:access-subject'>...</Subject> This would enforce the constraint that there be only one subject- category attribute in the XML Schema. This would also make implementing a request processor a little simpler. And, I think would make understanding this feature of the standard simpler. CATEGORY: Alternative. STATUS: Discussed 11/25/02. Bring this up on the XACML list for more discussion. Would require a schema change, but would be more consistent and possibly more efficient to search. SEE ALSO: #40 RESPONSE: ACTIONS: ========================================================================= 0040. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00069.html Subject: Section 6.2 From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Thu, 21 Nov 2002 16:26:00 +0900 Section 6.2 says that every <Subject> element MUST contain one and only one <Attribute> with AttributeId "urn:oasis:names:tc:xacml:1.0:subject:subject-category". I'm wondering if this contradicts another sentence, which starts with "If this attribute is not present in a given <Subject> element" The former means that there must be a single attribute representing the subject category. On the other hand, the latter means that it's optional. Is this okay? CATEGORY: Inconsistent. STATUS: Discussed 11/25/02. Bring this to the XACML list for further discussion. SEE ALSO: #39 RESPONSE: DISCUSSION (11/25/02): Two options 1) Change "MUST contain one and only one" to "MUST contain no more than one" in Section 6.2 pdf:2553. 2) Make subject-category attribute required in the Request context schema (see f. below). Make following associated changes in the specification: a. 2.4 Multiple subjects, pdf:419-420 An XML attribute called "SubjectCategory" is used to differentiate between subjects acting in different capacities. Some standard values for this XML attribute are specified, and users may define additional ones. b. 4.2.2 Example request context, pdf:924: change [05] <Subject> to: [05] <Subject SubjectCategory="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"> c. 4.2.2 Example request context, delete lines pdf:929-937, [06]-[14] that currently specify the subject-category attribute. d. 4.2.2 Example request context, change pdf:1005-1009 from: 05]-[37] Subject attributes are placed in the Subject section of the Request. Each attribute consists of the attribute meta-data and the attribute value. [06]-[14] Each Subject section must have one and only one subject-category attribute. The value of this attribute describes the role that the subject plays in making the decision request. The value of "access-subject" denotes the identity for which the request was issued. to: 05]-[37] Subject attributes are placed in the Subject section of the Request. Each XACML attribute consists of the attribute meta-data and the attribute value. Each Subject element has an associated "SubjectCategory" XML attribute. The value of this attribute describes the role that the subject plays in making the decision request. The value of "access-subject" denotes the identity for which the request was issued. e. Change 5.30 Complex type SubjectAttributeDesignatorType, pdf:2354-2364, to: 5.30.Complex type SubjectAttributeDesignatorType The SubjectAttributeDesignatorType complex type extends the AttributeDesignatorType complex type. It is the base type for elements and extensions that refer to named categorized subject attributes. A named categorized subject attribute is defined as follows: A subject is represented by a <Subject> element of the <Subjects> element in the <xacml-context:Request> element. The <Subject> element contains a SubjectCategory XML attribute with a default value of "urn:oasis:tc:xacml:1.0:subject-category:access-subject". A categorized subject is a subject that is identified by its particular subject category XML attribute. f. Section 6.2 Element <Subject>. Insert following into schema fragment just before pdf:2549: <xs:attribute name="SubjectCategory" type="xs:anyURI" use="optional" default="urn:oasis:tc:xacml:1.0:subject-category:access-subject"/> g. Section 6.2 Element <Subject>. Insert following between pdf:2550 and pdf:2551: SubjectCategory [Optional] This attribute SHALL specify the subject category of the associated <Subject> element. This attribute indicates a role that the <Subject> entity plays in making the access request. If SubjectCategory is not supplied, then its default value SHALL be "urn:oasis:tc:xacml:1.0:subject-category:access-subject", indicating that the subject is the entity ultimately associated with initiating the access request. h. Section 6.2 Element <Subject>, delete pdf:2553-2558. Change pdf:2559 to: Typically, a <Subject> element will contain an i. Section 6.2 Element <Subject>, delete pdf:2562-2563 ("No more than one..." j. Delete Section 13.9.4 Subject Attributes k. Add "SubjectCategory" to Section 8.1 Extensible XML attribute types. Delete Section 8.2 Extensible XACML attribute types. l. Remove "Urn:oasis:names:tc:xacml:1.0:subject:subject-category M" line from 10.3.5 Attribute m. Remove the four ":subject-category:" attribute identifiers from the table in 10.3.6 Identifiers. n. Add new Section 10.3.7 XML Attribute Values The implementation MUST use the following identifiers as values for the <Subject> SubjectCategory XML attribute as specified by XACML. This requirement pertains primarily to implementations of a PAP or PEP that use XACML, since the semantics of this attribute are transparent to the PDP. urn:oasis:names:tc:xacml:1.0:subject-category:access-subject M urn:oasis:names:tc:xacml:1.0:subject-category:codebase O urn:oasis:names:tc:xacml:1.0:subject-category:intermediary-subject O urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject O urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine O o. Change B.2 Access subject categories, pdf:4388 from "If subject category is not specified, then this is the default value." to "If SubjectCategory is not specified, then this is the default value". p. B.5 Subject attributes, delete pdf:4390-4391: This identifier indicates the subject category. "access-subject" is the default. urn:oasis:names:tc:xacml:1.0:subject:subject-category ACTIONS: ========================================================================= 0041. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00077.html Subject: Schema file names are inconsistent From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Fri, 22 Nov 2002 14:49:19 +0900 At the home page http://www.oasis-open.org/committees/xacml/, the schema file names are: Policy Schema (cs-xacml-schema-policy-01.xsd) Context Schema (cs-xacml-schema-context-01.xsd) Note that the version number? is 01. However, in the context schema a different file name is used for the policy schema: cs-xacml-schema-policy-1.0.xsd This time, the version number is 1.0. They should be consistent. CATEGORY: Inconsistent. STATUS: Resolved 11/25/02. RESPONSE: Use "1.0". Michiharu has already made this change to the name of the file on the home page. ACTIONS: No further action needed. ========================================================================= 0042. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00078.html Subject: A schema bug? From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Fri, 22 Nov 2002 14:54:57 +0900 I got a schema validation error when I used Xerces 2.0.1 and 2.2.0. I can resolve this by adding mixed="true" to <xs:complexType name ="AttributeAssignmentType">. Is this a schema bug or Xerces's bug? org.xml.sax.SAXParseException: cos-ct-extends.1.4.2.2.2.2.1: Error for type 'AttributeAssignmentType'. The content type of a derived type and that of its base must both be mixed or element-only. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDAbstractTraverser.reportSchemaError(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.handleComplexTypeError(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseComplexTypeDecl(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseGlobal(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDHandler.getGlobalDecl(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseNamedElement(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseGlobal(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDHandler.traverseSchemas(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:134) CATEGORY: Inconsistent. STATUS: Resolved 11/25/02. RESPONSE: Accepted. Add mixed="true" in schema and spec. ACTIONS: Add mixed="true" to <xs:complexType name="AttributeAssignmentType">. Make this change in the XACML schema. Search specification for schema fragments that also need to be changed to be consistent: 5.35 at least needs to change. ========================================================================= 0043. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00080.html Subject: A comment on Section 7.3 From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Fri, 22 Nov 2002 15:47:49 +0900 Section 7.3 says that The target value SHALL be "Match" if the subjects, resource and action specified in the request context are all present in (i.e., within the scope of) the target. This sentence is unclear to me because the meaning of "present" is unclear to me. Why doesn't Section 7.3 mention MatchId? I think Section 7.3 should reference A.12, where I can find the detailed semantics of MatchId. It seems to me that the term "present" is used in three places (ignoring the "present" function), 1) Section 3.3.1.1 Rule target The meaning of "present" used here is also unclear to me, but I can accept this situation because Section 3 is non-normative. 2)Section 5.27, 5.28, 5.29 (Resource, Action, Environment Attr Designator) There is clear definitions of "present" from the attribute designator perspective. (I think these definitions have nothing to do with MatchId attributes used in <Target>) 3)Section 7.3 Is the term "present" used in Section 7.3 the same as the ones defined in Section 5.27, 5.28, 5.29??? CATEGORY: Unclear. STATUS: Discussed 11/25/02. Post proposed change below to the XACML list for further discussion. RESPONSE: ACTIONS: Change 7.3 Target Evaluation to say The target value SHALL be "Match" if the subject, resource and action elements specified in the target all match values in the request context. The target value SHALL be "No-match" if the subject, resource, and action elements specified in the target do not match values in the request context. The value of a Match element where a referenced attribute value can not be obtained depends on the value of the "MustBePresent" attribute of the AttributeDesignator. If the "MustBePresent" attribute is "true", then the result of the Match element is "Indeterminate" when the AttributeDesignator value can not be obtained. If the "MustBePresent" attribute is "false" or missing, then the result of the Match element is "False" when the AttributeDesignator value can not be obtained. ========================================================================= 0044. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00081.html Subject: There is no Section describing<SubjectAttributeDesignator> From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Fri, 22 Nov 2002 15:48:16 +0900 There is no section describing <SubjectAttributeDesignator>. As a result, although the term "present" is defined for other attribute designators (action, resource, environment), there is no definition of "present" for subject attribute designator. Is this okay? CATEGORY: Incomplete. SEE ALSO: #22 STATUS: Discussed 11/25/02. RESPONSE: Rename 5.30 "Complex type SubjectAttributeDesignatorType" to "Element <SubjectAttributeDesignator>". Re-word this section so that it provides information in a format consistent with the descriptions of ResourceAttributeDesignator, ActionAttributeDesignator, and EnvironmentAttributeDesignator. ACTION ITEM: #44. [Simon Godik] compare 5.30 with 5.27-29 and propose consistent wording. ACTIONS: ========================================================================= 0045. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00082.html Subject: "type" in Line 3503 in the pdf file is broken From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Fri, 22 Nov 2002 16:04:03 +0900 "type" in Line 3503 in the pdf file is broken: http://www.oasis-open.org/committees/xacml/repository/cs-xacml-core-01.pdf CATEGORY: Editorial. STATUS: Resolved 11/25/02. RESPONSE: Accepted. ACTIONS: Bill should fix pdf:3503 in the next release of the spec. ========================================================================= 0046. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00084.html Subject: "Not Match" or "No-match" (Tables 1, 2, and 3) From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Fri, 22 Nov 2002 18:21:35 +0900 "Not Match" should be "No-match" in Table 1, 2, and 3. CATEGORY: Inconsistent. STATUS: Resolved 11/25/02. RESPONSE: Accepted. Change "Not Match" to "No-match" in Tables 1, 2, and 3. ACTIONS: Change "not match" and 'not "match"' in Tables 1,2 and 3 of sections 7.5, 7.6, 7.7 to say "No-match" ========================================================================= 0047. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00085.html Subject: policy and rule ordering From: Paul Andrews <paandrew@cisco.com> Date: Fri, 22 Nov 2002 10:09:29 -0500 I have an observation to make regarding the order of evaluation of policies and rules within a policy set: The order is only defined for one rule combining algorithm, however if individual policies within a policy set had obligations associated with them it is possible (likely even) that the obligations should be executed in a specific order. CATEGORY: Incorrect. STATUS: Discussed 11/25/02. RESPONSE: This is as intended. There is a trade-off between consistency of obligations and efficiency of handling distributed policies. For example, you may have cached the 5th policy in the PolicySet, so it is faster to evaluate than the 2nd policy. An application that wishes to specify the order of evaluation is free to define a new combining algorithm using the XACML extensibility mechanisms. ACTIONS: No change. ========================================================================= 0048. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00086.html Subject: Resource types From: Paul Andrews <paandrew@cisco.com> Date: Fri, 22 Nov 2002 10:28:59 -0500 I note that the set of types allowed in a 'resource' element is restricted, as is the match criteria. Given the nature of my employers business I would like to be able to use types and match criteria that have not been defined. My reading of the spec. shows that the accepted answer to that is to move the resource specification to a 'condition' element instead, but that simply begs the question of why a 'resource' element exists in the first place if a 'condition' element can achieve the exact same thing (or conversely, if a condition element can be extended, then why not a 'resource' element). I understand the desire to facilitate indexing, however moving a resource match to a condition makes it difficult, i fnot impossible, to deduce the role played by the arguments to the condition. This in turn makes it hard to automatically translate the XACML representation of a policy into a different representation (as might be necessary if the actual access control were being performed by a legacy system). CATEGORY: Alternative. STATUS: Discussed 11/25/02. RESPONSE: Accepted in general. Change A.12 [again] to allow non-standard functions and datatypes, so long as they return boolean and accept AttributeDesignator as first arg and AttributeValue as second. ACTION ITEM: #48. [Anne Anderson] re-word Section A.12 again. Say functions used "should" be easily indexable. Complicated functions or non-indexable functions will inhibit efficiency of evaluation. ACTIONS: ========================================================================= 0049. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00093.html Subject: C.4 "Only-one-applicable" inconsistent with B.10"only-one-applicable-policy" From: Anne Anderson <Anne.Anderson@Sun.com> Date: Fri, 22 Nov 2002 13:57:45 -0500 (EST) Appendix C.4 describes the "Only-one-applicable" policy combining algorithm. Section B.10 uses the identifier "urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable-policy" This is confusing, if not inconsistent. I recommend that the identifier be changed to "urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable" since the "policy-combining-algorithm" portion of the name indicates that it applies to policies. CATEGORY: Inconsistent. STATUS: Resolved 11/25/02. RESPONSE: Accepted. ACTIONS: Change B.10 to use the identifier "urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable" ========================================================================= 0050. http://lists.oasis-open.org/archives/xacml/200211/msg00156.html Subject: error conditions From: bill parducci <bill.parducci@overxeer.com> Date: Fri, 22 Nov 2002 10:37:15 -0800 I think that there is some inconsistency with error condition responses of the PDP as communicated to the PEP. In some cases a decision of INDETERMINATE is returned without an accompanying status code (pdf:4502, 4605, 4664, 4799), while in others a status code is required (pdf:4715, 4755). I think that it is important that error conditions REQUIRE a status code in all circumstances so that the PEP is aware that the decision is a result of an error and not insufficient inputs. In practical terms this would allow the PEP to decide if retrying the request has merit, as well as provide important operational information. This requires that status codes be required in all cases (at least that seems like it would be the case). Under that assumption, here are the changes I think are necessary to accomplish this: Add the text from line pdf:4176, "...shall evaluate to "Indeterminate", with the appropriate error status," to lines pdf:4502, 4605, 4664 and 4799s. Change pdf:2696 (and schema) to read: "<xs:element ref="xacml-context:Status" minOccurs="1"/>" Change pdf:2696 (and schema) to read: "<xs:element ref="xacml-context:Status" minOccurs="0"/>" Change pdf:2709 to read: "<Status> [Required]" Change pdf:2760 to read: "<xs:element ref="xacml-context:StatusCode" minOccurs="1"/>" Change pdf:2760 to read: "xacml:Context:Status M" Change pdf:2760 to read: "xacml:Context:StatusCode M" I would like to propose that this be adopted by the spec. If the group doesn't agree then lines pdf:4715 and 4755 need to be updated to reflect this. CATEGORY: Inconsistent. STATUS: Resolved 11/25/02. RESPONSE: Accepted. ACTIONS: Make changes suggested except change pdf:2696 (and schema) to read: "<xs:element ref="xacml-context:Status" minOccurs="1"/>" ========================================================================= 0051. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00096.html Subject: C003 and matching in targets and conditions From: John Merrells <merrells@jiffysoftware.com> Date: Fri, 22 Nov 2002 18:35:34 -0800 It's suddenly dawned on me that the signature of the match functions is supposed to differ between targets and conditions. In a condition it's (primitive, primitive) and in a target it's (primitive, bag<primitive>). Is this intentional? It seems like a mistake to me. It'd be much simpler for everyone if the signature wasn't dependent upon the context... CATEGORY: Inconsistent. STATUS: Resolved 11/25/02. RESPONSE: This works as intended. A.12 specifies this behavior. The intention is to make Targets simpler. Actual function signatures do not differ: <Target> elements are not passed directly to the funtions. ACTIONS: None. Polar Humenn responded on 25 Nov 2002 to John Merrells and to xacml-comment as follows: It is not a mistake. The *Match constructs take the match function and apply it between each element in the bag and the explicit value. Currently, the equivalent expression to a Match element that would appear in the condition as: ( any-of matchId-function primitive bag<primitive> ). ========================================================================== 0052. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00097.html Subject: 5.31 Element <AttributeSelector> From: John Merrells <merrells@jiffysoftware.com> Date: Sun, 24 Nov 2002 17:54:08 -0800 ------------------------------------------------------------------------ 0052a. "The AttributeSelector element's RequestContextPath XML attribute SHALL contain a legal XPath expression over the <xacml-context:Request> element." The phrase 'over the' made me think for a while. This could be made clearer by using the 'context node' term from the XPath specification. XPath evaluation occurs with respect to a context node, the context node for this XPath expression is the <xacml-context:Request> element. CATEGORY: Unclear. STATUS: Discussed 11/25/02. RESPONSE: ACTION ITEM: 52a. [Michiharu Kudo] Need Michiharu's opinion as an XPath expert. ACTIONS: ------------------------------------------------------------------------ 0052b. "In the case where the XPath expression matches attributes in the request context by AttributeId, it must also match the attribute's data-type with the selector's DataType." Does the 'it' above mean the XPath expression? So, it's saying that if you write an xpath expression to select an attribute from the context, and the expression includes a predicate for matching with an AttributeID, then that expression MUST also include a predicate that matches the selectors data type with the data type of the selected attribute...? CATEGORY: Unclear. STATUS: Discussed 11/25/02. RESPONSE: ACTION ITEM: 52b. [Michiharu Kudo] Need Michiharu's opinion as an XPath expert. ACTIONS: ------------------------------------------------------------------------ 0052c. "In the case of using XPath 1.0, the value of the XPath expression is either a node-set, string value, numeric value, or boolean value." This may seem a quibble, and it probably is, but even though the XPath specification says that the result of an expression can be a primitive... I do not believe there's any way to form an expression that actually returns one. In my experience all XPath 1.0 expressions return a node-set. (I'd be very interested to be corrected on this point. I just looked in the o'reilly xpath book and it has some examples that are plain literal values like, 2002, or "hello", but if you follow the grammar of the language they're just not valid expressions.) CATEGORY: Unclear. STATUS: Discussed 11/25/02. RESPONSE: ACTION ITEM: 52c. [Michiharu Kudo] Need Michiharu's opinion as an XPath expert. ACTIONS: ------------------------------------------------------------------------ 0052d. "If the XPath 1.0 expression evaluates to a node-set, then each node may consist of a string, numeric or boolean value, or a child node (i.e. structured node). In this case, each node is logically converted to string data by applying the "string" function defined in the XPath 1.0 specification, resulting in a sequence of string data." This is correct in spirit, but not actually correct. In XPath 1.0 an expression evaluates to a node-set. There are seven kinds of node (root, element, text, attribute, namespace, processing instruction, and comment). The XPath specification describes a way of determining a <b>string-value</b> for each type of node. CATEGORY: Unclear. STATUS: Discussed 11/25/02. RESPONSE: ACTION ITEM: 52d. [Michiharu Kudo] Need Michiharu's opinion as an XPath expert. ACTIONS: ========================================================================== 0053. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00099.html Subject: XQO From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Mon, 25 Nov 2002 13:22:24 +0900 [XQO] is used in several places. E.g., see the description of "anyURI-equal" in Appendix A.14.1. I think this is a reference. If yes, it should be added to Section 11. CATEGORY: Incomplete. STATUS: Resolved 11/25/02. RESPONSE: Accepted. ACTIONS: Add to references in Section 11 the following: [XQO] XQuery 1.0 and XPath 2.0 Functions and Operators, W3C Working Draft 15 November 2002, http://www.w3.org/TR/2002/WD-xquery-operators-20021115/ ========================================================================== 0054. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00100.html Subject: The URI prefix for subject categories From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Mon, 25 Nov 2002 15:50:58 +0900 Two comments on the URI prefix for subject categories. ------------------------------------------------------------------------ 0054a. Section 4.2.2 uses a wrong prefix urn:oasis:names:tc:xacml:1.0:subject:category CATEGORY: Incorrect. STATUS: Resolved 11/25/02 RESPONSE: Accepted. ACTIONS: In Section 4.2.2, change "urn:oasis:names:tc:xacml:1.0:subject:category" to "urn:oasis:names:tc:xacml:1.0:subject:subject-category". This change may be moot if #39 is accepted, however. ------------------------------------------------------------------------ 0054b. I wonder if the URI prefix is added to Section 10.3.2. CATEGORY: Incomplete. STATUS: Resolved 11/25/02. RESPONSE: Accepted ACTIONS: Add "urn:oasis:names:tc:xacml:1.0:subject" to Identifier Prefixes defined in table in 10.3.2. This change may be moot if #39 is accepted, however. ========================================================================== 0055. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00101.html Subject: Conventional XML namespace prefixes From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Mon, 25 Nov 2002 16:26:29 +0900 Section 1.2 summarizes the conventional XML namespace prefixes. The two prefixes "xacml" and "xacml-context" should be added to the convention. These two prefixes are used many times, but it seems to me no definition is given in the specification document. Of course, they are defined in the (complete) schema files. However, it's better to add them to Section 1.2 for readability. Also, xmlns:xacml=... can be removed from the request context example in Section 4.2.2 because the "xacml" prefix is not used in it. CATEGORY: Unclear. STATUS: Resolved 11/25/02 RESPONSE: Accepted. ACTIONS: Add the following lines to the namespaces listed in 1.2 Notation: o The prefix "xacml" stands for the XACML policy namespace. o The prefix "xacml-context" stands for the XACML context namespace. Remove xmlns:xacml= line from Section 4.2.2 Example request context, example line [03], pdf:926. ========================================================================== 0056. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00102.html Subject: Section 10.3.1 From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Mon, 25 Nov 2002 16:28:15 +0900 A comment on the table in Sect. 10.3.1. The notational convention of element names is not standard (probably the syntax is not defined anywhere). How about using the qnames? For example, xacml:Context:Action can be xacml-context:Action. xacml:Policy:Policy can be xacml:Policy CATEGORY: Alternative. STATUS: Resolved 11/25/02. RESPONSE: Accepted. Use QNames in Section 10.3.1. ACTIONS: In the table in Section 10.3.1, change "xacml:Context:" to "xacml-context:". Change "xacml:Policy:" to "xacml:". ========================================================================== 0057. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00104.html Subject: Making MatchId and FunctionId argument order the same From: Anne Anderson <Anne.Anderson@Sun.com> Date: Mon, 25 Nov 2002 09:16:35 -0500 (EST) I have identified the exact changes required in order for us to make the arguments to a MatchId function appear in the same order as the arguments to a FunctionId function. I believe they are not nearly so extensive as we thought, and that we should make this change. Otherwise, we will have to live with this major, confusing inconsistency forever. In general: a. Redefine the -match functions such that the template is the second argument and the explicit value is the first argument. a. rfc822Name-match b. x500Name-match c. regexp-string-match [rename to string-regexp match] d. xpath-node-match b. Specify that Match element arguments are passed to the MatchId function in the same order in which they appear in the Match element. c. NO changes are required in the schema. d. NO changes are required in the examples, as -match functions appear only in example <Target> elements, where they are already in the new, correct order. Specific changes required: A.12.Matching elements 1. Change pdf:3538-3543 (but from new A.12 Matching elements version) from: The attribute value specified in the matching element SHALL be supplied to the MatchId function as its first argument. An element of the bag returned by the <AttributeDesignator> or <AttributeSelector> element SHALL be supplied to the MatchId function as its second argument1. The datatype of the <AttributeDesignator> or <AttributeSelector> element SHALL match the datatype of the second argument expected by the MatchId function. The datatype of the attribute value SHALL match the datatype of the first argument expected by the MatchId function. to: An element of the bag returned by the <AttributeDesignator> or <AttributeSelector> element SHALL be supplied to the MatchId function as its first argument1. The attribute value specified in the matching element SHALL be supplied to the MatchId function as its second argument. The datatype of the <AttributeDesignator> or <AttributeSelector> element SHALL match the datatype of the first argument expected by the MatchId function. The datatype of the attribute value SHALL match the datatype of the secondy argument expected by the MatchId function. 2. Change pdf:3508-3510 (but in new Appendix A.12 version) from: Otherwise, the MatchId function SHALL be applied between the explicit attribute value and each element of the bag returned from the <AttributeDesignator> or <AttributeSelector> element. to: Otherwise, the MatchId function SHALL be applied between each element of the bag returned yfrom the <AttributeDesignator> or <AttributeSelector> element and the explicit attribute value. 3. Remove footnote from new version of Appendix A.12 4. Replace pdf:3526-3529 (but in new Appendix A.12 version) from: <Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:regexp-string-match"/> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string";>John.*</AttributeValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> to: <Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:regexp-string-match"/> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string";>John.*</AttributeValue> A.14.12 Special match functions 5. Redefine regexp-string-match: Change pdf:4250-4253 from The first argument SHALL be a regular expression and the second argument SHALL be a general string. The function specification SHALL be that of the "xf:match" function with the arguments reversed [XF Section 6.3.15.1]. to: The first argument SHALL be a general string and the second argument SHALL be a regular expression. The function specification SHALL be that of the "xf:match" function [XF Section 6.3.15.1]. 6. Redefine x500Name-match: Change pdf:4256-4258 from: It shall return "True" if and only if some terminal sequence of RDNs from the first argument matches the second argument when compared using x500Name-equal. 7. Redefine rfc822Name-match: Change pdf:4260-4282 to: This function SHALL evaluate to "True" if the first argument matches the second argument according to the following specification. An RFC822 name consists of a local-part followed by "@" followed by domain-part. The local-part is case-sensitive, while the domain-part (which is usually a DNS name) is not case-sensitive.1 This function SHALL take two arguments, the first is of type "urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name" and the second is of type "http://www.w3.org/2001/XMLSchema#string"; and SHALL return an "http://www.w3.org/2001/XMLSchema#boolean";. The first argument contains a complete rfc822Name. The second argument is a complete or partial rfc822Name used to select appropriate values in the first argument as follows. In order to match a particular mailbox in the first argument, the second argument must specify the complete mail address to be matched. For example, if the second argument is "Anderson@sun.com", this matches a value in the first argument of "Anderson@sun.com" and "Anderson@SUN.COM", but not "Anne.Anderson@sun.com", "anderson@sun.com" or "Anderson@east.sun.com". In order to match any mail address at a particular domain in the first argument, the second argument must specify only a domain name (usually a DNS name). For example, if the second argument is "sun.com", this matches a value in the first argument of "Anderson@sun.com? or "Baxter@SUN.COM", but not "Anderson@east.sun.com". In order to match any mail address in a particular domain in the first argument, the second argument must specify the desired domain-part with a leading ".". For example, if the second argument is ".east.sun.com", this matches a value in the first argument of "Anderson@east.sun.com" and "anne.anderson@ISRG.EAST.SUN.COM" but not "Anderson@sun.com". 8. Change A.14.13 pdf:4303-4313 from: xpath-node-match This function SHALL take two "http://www.w3.org/2001/XMLSchema#string"; arguments, which SHALL be interpreted as XPath expressions and SHALL return an "http://www.w3.org/2001/XMLSchema#boolean";. This function SHALL first extend the first argument to match an XML document in a hierarchical fashion. If a is an XPath expression and it is specified as the first argument, it SHALL be interpreted to mean match the set of nodes specified by the enhanced XPath expression "a | a//* | a//@*". In other words, the expression a SHALL match all elements and attributes below the element specified by a. This function SHALL evaluate to "True" if any XML node that matches the enhanced XPath expression is equal according to "op:node-equal" [XQO] to any XML node from the node-set matched by the second argument. to: xpath-node-match This function SHALL take two "http://www.w3.org/2001/XMLSchema#string"; arguments, which SHALL be interpreted as XPath expressions and SHALL return an "http://www.w3.org/2001/XMLSchema#boolean";. This function SHALL first extend the second argument to match an XML document in a hierarchical fashion. If 'a' is an XPath expression and it is specified as the second argument, it SHALL be interpreted to mean match the set of nodes specified by the enhanced XPath expression "a | a//* | a//@*". In other words, the expression a SHALL match all elements and attributes below the element specified by 'a'. This function SHALL evaluate to "True" if any XML node that matches the enhanced XPath expression is equal according to "op:node-equal" [XQO] to any XML node from the node-set matched by the first argument. 9. Throughout the specification, change "regexp-string-match" to "string-regexp-match" 10. Many conformance tests will need to be changed, as they often use -match functions in Apply elements. I can make these in one day, however, and I believe the effort is justified. CATEGORY: Unclear. STATUS: Resolved 11/25/02. RESPONSE: Rejected. Please re-submit this comment with a proposal to change the order of the elements in a <Target> Match. ACTIONS: None. DISCUSSION: [Polar]If we change order of functions in match, then breaks any-of, all-of, etc. For example, any-of takes function value - explicit bag of values If instead of changing order of args for a -match function, we change Target element order so that explicit value comes first, then everything works. This also flows better: function is asking for a match of the explicit value against one of the bag values. With this approach, however, more examples will have to change. With this approach, schema change is required. The group agreed that this approach was better than Anne's suggested approached if a change is to be made. This needs a vote soon, since it affects implementations. ==========================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC