[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Final comment resolutions
The attached document contains the resolutions to every comment on the XACML 1.0 Specification or schemas that was submitted to the xacml-comment@lists.oasis-open.org mailing list during the public review period from November 8, 2002 through December 8, 2002. At the XACML Comments Subcommittee meeting on 12/10/02, changes were made to the previous resolution to Comment#52b (Seth Proctor). Comment#71 (Anne Anderson), 72 (John Merrells), and 73 (Dipak Chopra) were resolved. These resolutions are reflected in this document. Attendees at the 12/10/02 Comments Subcommittee meeting were: Carlisle Adams, Tim Moses, Anne Anderson, Polar Humenn, and Michiharu Kudo Anne Anderson -- 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.33, 02/12/10 (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 or schemas 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/200212/msg00057.html and http://lists.oasis-open.org/archives/xacml/200212/msg00075.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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 (Primitive 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: #4 STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Remove border lines between urns in table following line 3291. --------------------------------------------------------------------------- 0003f. line 3385: '<AttributeValue' snippet font (should be 'courier') CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: "squooshing" confirmed. ACTIONS: Unsquoosh lines 2618, 2742, 2778 in PDF version of next specification release. ====================================================================== 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. SEE ALSO: #2 STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. SEE ALSO: #51,#57 RESPONSE: See #57. This was initially rejected, but #57 resolves the issue in this comment by changing the order of the elements in the Target to be (AttributeValue, AttributeDesignator/Selector). ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Rejected. The *AttributeIsPresent" elements were removed from the specification in XACML 1.0, which is the version being reviewed. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Rejected. The "QualifiedSubjectAttributeDesignator" element is named "SubjectAttributeDesignator" in the XACML 1.0 version of the specification, which is the version being reviewed. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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". ====================================================================== 0011a. 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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. ====================================================================== 0011b. 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 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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. Changed 12/02/02. SEE ALSO: #48,#57 RESPONSE: Approved. We agreed that this section is unclear and needs to be re-worded. On 12/02/02, we decided to change the argument order to make MatchId functions consistent with FunctionId functions after further comments came in from reviewers. See #57 ACTIONS IMPLEMENTED IN: draft sent Tue. 3 Dec 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200212/msg00007.html ACTIONS: Replace Appendix A.12 "Matching elements" with the revised text attached to e-mail message http://lists.oasis-open.org/archives/xacml-comment/200212/msg00000.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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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. ========================================================================= 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Replace Section A.12 with the text supplied in e-mail message http://lists.oasis-open.org/archives/xacml/200211/msg00157.html. Revised again in response to #48 and #57; attached to e-mail message http://lists.oasis-open.org/archives/xacml-comment/200212/msg00000.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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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. SEE ALSO: #44 STATUS: Resolved 11/21/02. RESPONSE: Approved adding a description of SubjectAttributeDesignator. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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: Resolved 12/05/02. RESPONSE: Needs to be clarified. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Use text that is in the draft attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ------------------------------------------------------------------------ 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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: This needs to be clarified. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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. ------------------------------------------------------------------------ 0032e - missing comment# in sequence ------------------------------------------------------------------------ 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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: Resolved 12/02/02. RESPONSE: Keep "map" function as is. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: None. DISCUSSION: [Polar Humenn] My vote is for "map". Rationale: The primitive functions, i.e. integer-equal, are named with their arguments' particular type, not their resultant type. If you named functions for their resultant type, as is suggested with "integer-map" returning a bag of integers regardless of what its argument type is, then to be consistent with that naming convention would mean the "equals" function between integers would be called really be called "boolean-equal" because equal returns a boolean. And that would lead to inconsistent, not to mention, nonsensical naming. The functionality of "map" is independent of the primitive type of the its arguments, where as "integer-equal" is not, "integer-equals" requires two integers as arguments. The function "map" only requires the supplied function and the supplied bag to agree on types, no matter what the type happens to be. It is truly polymorphic. I think naming "integer-map" is really confusing as it only states half the type story, the rest is left in the air. If you were to fully specify the type in the name, you'd have to say something like "integer-float-map" for functions that map bags of integers to floats (or visa versa depending on how you want it". That would cause an explosion of type names, which is unnecessary, because the <Function> argument really specifies the type. Also, for extension types, the function "map" can easily and with formal integrity, be used for any extension type and any other extension functions that do conversions or selections of that type. Furthermore, this "map" function didn't come out of nowhere, it is the most popular polymorphic function on the planet. :) [Daniel Engovatov] My vote is for <type>-map. I have explained some of my rational for this in a previous e-mail. Most important are - consistency and ease of expandability - for the cases when the function name is supplied as an argument that has its value determined during the evaluation time. Not specifying the return type of the enclosing "higher" order function would make it extremely cumbersome to define a consistent and optimized interface. [Seth Proctor] I think there's been too much emphasis in this conversation on comparing map and type-equal. The better comparison is between map and things like type-one-and-only. The one-and-only functions could have been defined like the map function, operating on any type and returning a single value of the same type, just like map is now defined [1]. Instead, it works on pre-defined types [2]. This is useful because we know specifically what type is being returned by the function, and what type we expect to work with inside the function. There are other type-* functions that are in the same position (think Bag and Set functions), which is why Daniel and I are talking about consistency. Arguably, it could be useful to change all of the type-* functions to be defined like map, so that the generic functionality could be used by any type, but it would require an overhaul of the entire spec, and therefore is inappropriate for now (maybe a 1.1 or 2.0 version) [1] In the map function the type it operates on is the return type of the function, and that is indeed the same type it returns. [2] It is relatively easy for an implementation to let new types be used in this system, so it's not hard to extend. [Polar Humenn, responding to Daniel Engovatov] > My vote is for <type>-map. > I have explained some of my rational for this in a previous e-mail. > > Most important are - consistency The proposed naming convention is NOT consistent with the other functions. The current function names contain the type of their arguments, whereas the proposed <type>-map names the resultant type. > and ease of expandability I really don't know what you mean by "expandability". > - for the cases when the function name is supplied as an argument that > has its value determined during the evaluation time. The function name is supplied EXPLICITLY in the FunctionId attribute of the <Function> element. It's value is already determined at compile time. That was the specific reason for the <Function> element. Now, of course, you can take any IMPLEMENTATION route you chose, such as using the "interpreter" approach where you might not know its value until evaluation time, but that is certainly not FORCED by the specification. [Polar Humenn, responding to Seth Proctor] > I think there's been too much emphasis in this conversation on > comparing map and type-equal. The better comparison is between > map and things like type-one-and-only. The one-and-only > functions could have been defined like the map function, > operating on any type and returning a single value of the same > type, just like map is now defined [1]. That is true. One-and-only can be polymorphic, and I certainly would NOT complain if it were. However, the name is consistent with the other naming convention is that the <type> in the name, names its argument. It is only coincidence that it also names its return type as well. > Instead, it works on pre-defined types [2]. This is useful because we > know specifically what type is being returned by the function, and what > type we expect to work with inside the function. There are other type-* > functions that are in the same position (think Bag and Set functions), > which is why Daniel and I are talking about consistency. The other functions, especially the set functions use an implicit "type-equal" function in the reduction of the set. That is why the set functions contain the type name. As for the "type-bag", "type-one-and-only", "type-bag-size" functions, I would be very happy if they were polymorphic as well. The type is pretty meaningless to their functionality. However, the function "type-is-in" calls an implicit function "type-equal" to handle the membership determination. So, it can be said that it is needed. > Arguably, it could be useful to change all of the type-* > functions to be defined like map, so that the generic > functionality could be used by any type, but it would require > an overhaul of the entire spec, and therefore is inappropriate > for now (maybe a 1.1 or 2.0 version) Arguably, we could eliminate most of the "typing" information because it could be deduced by the type system, especially since every attribute value and designator has a required DataType XML attribute, but we've already been down that route. > [1] In the map function the type it operates on is the return type of the > function, and that is indeed the same type it returns. Not so. In the map function, the "type" it "operates on" is the argument type of the given function not the resultant type. The given function takes an arguement of type "a" and returns an item of type "b". The map function converts every memeber of a bag of type "a" to a bag of type "b". It is only a coincidence if the resultant type is the same type as the argument type, i.e. a = b. > [2] It is relatively easy for an implementation to let new types be used in > this system, so it's not hard to extend. That is an implementation issue. I have a system for which "map" can operate on any type, old or newly introduced. I don't have to create a new map function for the new type. [Polar Humenn, responding to Daniel Engovatov] > >As for the "type-bag", "type-one-and-only", "type-bag-size" functions, I > >would be very happy if they were polymorphic as well. The type is pretty > >meaningless to their functionality. However, the function "type-is-in" > >calls an implicit function "type-equal" to handle the membership > >determination. So, it can be said that it is needed. > > Why would you be happy? Would it make for a simpler, faster and more > efficient implementation for a variety of languages and architectures? That depends on the capability of the implementors, and the languages and architectures chosen. > What is the reason for introducing polymorphic functions beyond it being a > "cool" feature? Use case? Sample implementation that we can see, how it > useful? I don't know what "cool" is. Use case: If I introduce a new type, say "FingerPrint", and I use an AttributeDesignator to retrieve attributes of that type, I don't have to create a new function "FingerPrint-bag-size" to find out how many I have when I do retrieve them, I can just use the same old function "bag-size". Likewise, if I create a function called "FignerPrint-to-Characteristic" I don't have to create a new function "FignerPrint-map" (or would it be "Characteristic-map"?) to convert a bag of FingerPrint values to a bag of Characteristic values. I would just use the same old "map". Now, how you implement it, is up to you. You certainly wouldn't be precluded from creating "FingerPrint-bag-size". or FingerPrint-map (or Characteristic-map?). Sample implementation: I've already gone over how you can do most of this with Java interfaces, of which you can do the analogous thing with C++. [Polar Humenn, responding to Seth Proctor, after resolution was posted] > > 33. Subject: map function > > RESOLUTION: keep "map" as is (un-typed) > > After all the discussion on this point, can we at least get an explination > of how this was decided? I'd like to hear the justification for making one > function different than all the others. I think it was decided to keep "map" the way it is for the following reasons: 1. First and foremost, it has been determined that the specification is not broken because "map" is polymorphic. 2. No change needs to be made to the spec, i.e. we do not have to introduce "integer-map", "string-map", etc., which further implies that we must make restrictions on the functions that can be applied to each <type>-map function. 3. Accepting <type>-map would enlarge our conformance test space. [Seth Proctor, responding to Polar Humenn] Thanks. That was what I was looking for. I would suggest that if anyone is keeping a list of next-generation XACML features, they add to it that someone should revisit this issue, not to change map, but to consider changing some of the other functions to act the same way. My issue with the map function is not how it works, merely that it's different than the other functions that should have the same kind of (useful) functionality. [Anne Anderson, responding to Seth Proctor] There was no consensus on the list, and it was not moving toward consensus. The default is to make no change to the existing specification unless it is actually broken and could not work. ========================================================================= 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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: Resolved 11/25/02. 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 $B!H(Burn:oasis:names:tc:xacml:1.0:subject:subject-category$B!I(B. 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. Will change as a result of #39. RESPONSE: Change 6.2 to agree with 5.30. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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: Resolved 12/02/02. SEE ALSO: #40 RESPONSE: Approved. Make SubjectCategory an xml attribute in the Context rather than an XACML Attribute. ACTIONS IMPLEMENTED IN: draft sent Tue. 3 Dec 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200212/msg00007.html ACTIONS: Change schema, specification, and conformance tests to have SubjectCategory be an XML attribute of the <Subject> element in the Request, rather than an XACML Attribute. DISCUSSION: [Seth Proctor] I think that having the category as an XML attribute makes some sense, and since it's a required element (albeit with a default value) it wouldn't really impact anything. On the other hand, if you want to treat the subject-category as just another attribute that you can look for and manipulate like all attribute values, then it makes sense to leave it as it is. Ultimately, I feel that it makes things a little clearer to have it as an XML attribute, but I'm easy on this one. ========================================================================= 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: Resolved 12/02/02. SEE ALSO: #39 RESPONSE: See #39. Make SubjectCategory an optional XML attribute with Default="urn:....:access-subject". This removes the possibility of having more than one subject-category attribute per <Subject>, while still forcing each <Subject> to have one value (specified or default). ACTIONS IMPLEMENTED IN: draft sent Tue. 3 Dec 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200212/msg00007.html ACTIONS: Change schema, change spec, change Conformance Tests. 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 ========================================================================= 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 "01". Michiharu has already made this change to the name of the file on the home page. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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: We will add mixed="true" in schema and spec. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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: Resolved 12/02/02. RESPONSE: This needs to be clarified. Reword as in ACTIONS. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html [isn't Tim amazing! fixed this even before it was approved!] ACTIONS: 1) Change 7.3 Target Evaluation to say The target value SHALL be "Match" if the subject, resource and action elements specified in the target result in "true". The target value SHALL be "No-match" if one of the subject, resource, or action elements specified in the target results in "false". The target value SHALL be "Indeterminate" if any of the subject, resource, or action elements results in "Indeterminate." See Section 7.9.2 Attribute Retrieval and the specifications of match functions for more description of "Indeterminate" results. 2) Remove If any attribute value referenced in the condition cannot be obtained, then the condition SHALL evaluate to "Indeterminate". from the end of Section 7.4. DISCUSSION: [Polar Humenn] I think we should just stop at your re-wording at > 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. Here, as you did catch the mix-up between the target and the request context in the spec. However, the evaluation to Indeterminate is based upon the evaluation of the contained Match Elements of which they all contain their own Indeterminate semantics. So, I think let's leave it there. I think we are describing the evaluation of the Target expression with respect to its elements, not about what its elements do. That functionality is defined elsewhere, so we don't need to redefine it here. How about: The target value SHALL be "Match" if the subject, resource and action elements specified in the target result in "true". The target value SHALL be "No-match" if one of the subject, resource, or action elements specified in the target results in "false". The target value ShALL be "Indeterminate" if any of the subject, resource, or action elements results in "Indeterminate." Simiarly I think the sentence at the end of Section 7.4 Conditons, If any attribute value referenced in the condition cannot be obtained, then the condition SHALL evaluate to "Indeterminate". should be removed, as this semantics and how it is handled is defined for every element that retrieves attribute values. [Anne Anderson, responding to Polar] [approve, agreed] ========================================================================= 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: Resolved 12/05/02. Response resolved 12/02/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. ACTIONS: Use the text attached to http://lists.oasis-open.org/archives/xacml-editors/200212/msg00007.html In addition, remove xml attribute descriptions from Sections 5.28, 5.29, and 5.30 since already described in 5.27. ========================================================================= 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: This should be fixed in the next release of the specification. 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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: Resolved 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 that specifies order by using the XACML extensibility mechanisms. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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, if not 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. SEE ALSO: #12 STATUS: Resolved 12/02/02. RESPONSE: Change the specification to allow any function that matches the criteria of returning Boolean result and taking arguments of AttributeValue first and AttributeDesignator or AttributeSelector second. Reword Section A.12 Matching elements to clarify this. ACTIONS: Replace Section A.12 Matching elements with text appended to the comment reply in archived message http://lists.oasis-open.org/archives/xacml-comment/200212/msg00000.html ========================================================================= 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Change B.10 to use the identifier "urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable" Change Conformance Tests also. ========================================================================= 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: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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Make changes suggested except change pdf:2696 (and schema) to read: "<xs:element ref="xacml-context:Status"/>" [remembering that the default is 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 and thus easier to index. Actual function signatures do not differ: <Target> elements are not passed directly to the functions. Note that this comment regards the difference in apparent datatype of the arguments, not the difference in specification order. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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: Resolved 12/05/02. RESPONSE: Approved. Use the "context node" term. ACTIONS: In Section 5.31 Element <AttributeSelector>, pdf:2400, change "over" to "whose context node is" ------------------------------------------------------------------------ 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: Resolved 12/10/02. Previously resolved 12/09/02. RESPONSE: "it" means the XACML context handler. XPath writers SHOULD include DataType filtering; this is not in scope for the XACML specification. DataType will depend solely on the DataType specified in the AttributeSelector. The DataType in the Request Context Attribute will be ignored in the case of evaluating an AttributeSelector. If the returned nodes can not be converted to the specified DataType by the PDP, then that is a type error. ACTIONS: Use the wording in the XACML draft dated 12/6/02 (attached to http://lists.oasis-open.org/archives/xacml-editors/200212/msg00024.html) plus the following edits: 1) Section 5.32: eliminate references to "primitive" type. 2) In Section 5.32, pdf:2373-2387: replace section starting with following sentence In the case that the XPath expression matches attributes in the request context by their Attribute Id, the PDP MUST additionally verify that the attribute's DataType is the same as the element's DataType. and ending with "Otherwise, each node SHALL be converted to a string using the http://www.w3.org/TR/xquery-operators#string accessor function, resulting in a sequence of string-data. with If the DataType specified in the AttributeSelector is a primitive data type defined in [XQO] or [XS], then the value returned by the XPath expression SHALL be converted to the DataType specified in the AttributeSelector using the constructor function below [from XQO] that corresponds to the DataType. If an error results from using the constructor function, then the value of the AttributeSelector SHALL be "Indeterminate". xs:string() xs:boolean() xs:integer() xs:double() xs:dateTime() xs:date() xs:time() xs:hexBinary() xs:base64Binary() xf:anyURI() fn:yearMonthDuration() fn:dayTimeDuration() If the DataType specified in the AttributeSelector is not one of the preceding primitive DataTypes, then the AttributeSelector SHALL return a bag of instances of the specified DataType. If there are errors encountered in converting the values returned by the XPath expression to the specified DataType, then the result of the AttributeSelector SHALL be "Indeterminate". If the policy writer intends to select the string value of an element's contents rather than the node representing the element itself, then the XPath expression MUST terminate in "/text()". 2b) Update the AttributeSelector examples to include /text() at the end of the XPath expressions. pdf:1105 use: DataType=".../patent-number/text()" pdf:1275 use: DataType="...md:parentGuardianId/text()" pdf:1294 use: DataType="...md:patentDoB/text()" pdf:1463 use: DataType="...md:registrationID/text()" 3) In Section 6.7 Element <Attribute>, pdf:2633, change the description of the DataType xml attribute from: Attribute data type to: The data type of the contents of the <AttributeValue> element. This SHALL be either a primitive type defined by the XACML 1.0 Specification or a type defined in a namespace declared in the XACML Context element. 4) In Section 5.32 Element <AttributeSelector>, pdf:2403: change the description of the DataType xml attribute from: The data-type of the attribute. to The bag of values returned by the AttributeSelector SHALL be of this data-type. DISCUSSION: 12/9/02: There are several cases (I may not have the XPath syntax quite right -aha) 1. An XPath expression may select nodes that are parents of the contents of an <AttributeValue>. The selected nodes may contain 1a. A primitive value. Example: "/Request/Subject/Attribute@IssueInstant" selects primitive values of type xs:dataTime from the IssueInstant xml attribute of all Subject Attributes. 1b. A structured value. Example: "/Request/Subject/Attribute" selects structured values whose structure is defined in the XACML schema. Type is xacml:AttributeType In this case, the XACML schema itself specifies the type of the resulting node value(s). 2. An XPath expression may select the full contents of one or more <AttributeValue> nodes themselves. The selected nodes may contain 1a. A primitive value. Example: "/Request/Subject/Attribute[@AttributeId="urn:...:subject-id" and @DataType="xacml:x500Name"]" might select one or more primitive values like "cn=Anne, ou=Labs, o=Sun, c=US", with a DataType of xacml:x500Name. 1b. A structured value. Example: "/Request/Subject/Attribute[@AttributeId="urn:...:key-info and @DataType=ds:keyInfo" would select structured elements with values like: <ds:KeyName>anne's public key</ds:KeyName> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus>BQADgY0AMIGJAoGBAK/yHi+g4n</ds:Modulus> <ds:Exponent>CZGRYY2feUmVrM0QKOzAdr</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> In this case, the <Attribute> element's DataType xml attribute specifies the type of the resulting node value(s). 3. An XPath expression may select nodes that are sub-elements of the contents of an <AttributeValue>. The selected nodes may contain 3a. A primitive value. Example:"/Request/Subject/Attribute[@AttributeId="urn:...:key-info and @DataType=ds:keyInfo/KeyName" would select elements of xs:string DataType with values like: "anne's public key" 3b. A structured value. Example:"/Request/Subject/Attribute[@AttributeId="urn:...:key-info and @DataType=ds:keyInfo/KeyValue" would select elements with values like: <ds:RSAKeyValue> <ds:Modulus>BQADgY0AMIGJAoGBAK/yHi+g4n</ds:Modulus> <ds:Exponent>CZGRYY2feUmVrM0QKOzAdr</ds:Exponent> </ds:RSAKeyValue> In this case, the schema associated with the "ds" namespace (which must be referenced in an xmlns attribute in the Context header) will specify the type of the resulting node value(s). 4. An XPath expression may select the ResourceContent or a sub-element of the ResourceContent. In this case the schema associated with the ResourceContent will specify the type of the resulting node value(s). Where the values selected are of primitive types defined by XACML, then standard XACML functions can deal with them. Where the values selected are of primitive or structured types not defined by XACML, then extended functions must be supplied to deal with them. [Michiharu, responding to resolution of 12/9/02] http://lists.oasis-open.org/archives/xacml/200212/msg00072.html I did not follow the yesterday's discussion on 0052b. By looking at the resolution below, I have to admit that I have a little different view. In my opinion, DataType argument specified in a request context should not be used by PDP. Data should be cast using DataType information specified in the AttributeSelector element. In other words, A. DataType argument specified in a request context is no longer used. Instead, policy writer is encouraged to filter target nodes by adding a predicate expression on DataType information of the request context. No further filtering based on the DataType specified in the request context is not performed by PDP (or XACML context handler). B. AttributeSelector tries to cast the retrieved bag of values into the DataType specified in the policy if that DataType is one of XACML primitive data types (string etc.). If that DataType is NOT XACML primitive data types (e.g. ds:keyinfo), then AttributeSelector does not cast the retrieved bag of values but just returns the bag of DOM nodes. The rationale is the following: A. We cannot resolve DataType argument in the request context at every case (as described in the Anne's message). Some case we can retrieve it (.e.g case 1a) but not in other cases (e.g. case 3b, 4). In particular, it is not possible to get schema type information from a specific node information because no API for doing that has been defined. Then 1b, 2b, 3b is not implementable. Moreover, it seems difficult to reason DataType by just looking inside the XPath expression (case 1a, 2a, 3a). So my suggestion is to give up to utilize DataType argument specified in the request context to know the data type of the retrieved nodes. B. Since AttributeSelector element has a DataType attribute, it is possible to cast the retrieved nodes into the data of the specified DataType. This enables flexible data handling: if the DataType is XACML primitive data, then the cast operation is performed. If not XACML primitive data, the retrieved data is handled as a DOM data type and handed to XACML external function that deals with the DOM nodes. The following is examples: =============== Example 1) <Request> <Subject> <Attribute AttributeId="serial-no" DataType="..string" IssueInstant ="12/10"> <AttributeValue>1234</AttributeValue> </Attribute> <Attribute AttributeId="keyinfo" DataType="..ds:keyinfo" IssueInstant ="12/10"> <AttributeValue> <ds:KeyInfo> <ds:KeyName>Alice</ds:KeyName> <ds:KeyValue> <ds:RSAKeyValue> ... </ds:RSAKeyValue> </ds:KeyName> </ds:KeyInfo> </AttributeValue> </Attribute> </Subject> </Request> ================ Case 1) <AttributeSelector RequestContextPath="//Attribute[@AttributeId='serial-no' and @DataType='..string']/AttributeValue/text()" DataType="..string"/> The above AttributeSelector retrieves a text node "1234" in the request. This value is cast into XACML string type specified in the AttributeSelector element. ================ Case 2) <AttributeSelector RequestContextPath="//Attribute[@AttributeId='serial-no' and @DataType='..string']/AttributeValue/text()" DataType="..integer"/> The above AttributeSelector is still valid. The value "1234" is cast into an integer type and it succeeds. The caller of the AttributeSelector receives a bag of one integer. ================ Case 3) <AttributeSelector RequestContextPath="//Attribute/@IssueInstant" DataType="..DateTime"/> The above AttributeSelector retrieves "12/10" and the caller of the AttributeSelector receives a bag of one DateTime. ================ Case 4) <AttributeSelector RequestContextPath="//Attribute[@AttributeId='keyinfo' and @DataType='..ds:keyinfo']/AttributeValue" DataType="..ds:KeyInfo"/> The above AttributeSelector retrieves ds:KeyInfo node as a aggregated DOM node. Since data type specified in the policy is not XACML primitive data type, then no cast operation is performed and a DOM structure (it should be a XACML primitive type) is returned (as one element bag structure). The policy writer is expected to specify an external function that handles such DOM node. The returned bag may include more than one DOM node. [Anne Anderson, responding to Michiharu] But schema type information could be obtained. It is defined in the schema that defines the node. [Michiharu] There is no API for obtaining node DataType information in existing XPath processors. This is needed, but not yet available. XACML implementors would have to implement it themselves. So better to ignore DataType attribute in RequestContext (unless used inside the XPath expression in the policy). [Polar Humenn, responding to Michiharu] > ================ > Case 1) > <AttributeSelector > RequestContextPath="//Attribute[@AttributeId='serial-no' and > @DataType='..string']/AttributeValue/text()" DataType="..string"/> > > The above AttributeSelector retrieves a text node "1234" in the request. > This value is cast into XACML string type specified in the > AttributeSelector element. And returns a bag of "...#string". I agree with this approach. The DataType names the resultant type. > ================ > Case 2) > <AttributeSelector > RequestContextPath="//Attribute[@AttributeId='serial-no' and > @DataType='..string']/AttributeValue/text()" DataType="..integer"/> > > The above AttributeSelector is still valid. The value "1234" is cast into > an integer type and it succeeds. The caller of the AttributeSelector > receives a bag of one integer. Correct. Provided the Context Handler/PDP can convert the data to an integer. What should happen if it cannot? Indeterminate? Or leave it out, i.e. empty bag? > ================ > Case 3) > <AttributeSelector > RequestContextPath="//Attribute/@IssueInstant" DataType="..DateTime"/> > > The above AttributeSelector retrieves "12/10" and the caller of the > AttributeSelector receives a bag of one DateTime. I agree. But the same question, what if the pointed at nodes are not of the correct type. > ================ > Case 4) > <AttributeSelector > RequestContextPath="//Attribute[@AttributeId='keyinfo' and > @DataType='..ds:keyinfo']/AttributeValue" DataType="..ds:KeyInfo"/> > > The above AttributeSelector retrieves ds:KeyInfo node as a aggregated DOM > node. Since data type specified in the policy is not XACML primitive data > type, then no cast operation is performed and a DOM structure (it should be > a XACML primitive type) is returned (as one element bag structure). The > policy writer is expected to specify an external function that handles such > DOM node. The returned bag may include more than one DOM node. I would say not a DOM node, because we don't have functions do deal with DOM nodes. The PDP must understand the type to a point. That is it has been given a set of extension functions that work on that type. The higher order functions like map and such can deal with them using the extension functions. For example, you load the PDP with external functions, such as "external:keyinfo-get-key-name", which takes a "ds:keyinfo" and returns a "string", which is the <KeyName> element of the KeyInfo. The following is a condition which is true if "Alice" is a key name of any key info selected by the AttributeSelector. <Condition FunctionId="any-of"> <Function "function:string-equal"/> <AttributeValue DataType="....#string">Alice</AttibuteValue> <Apply FunctionId="function:map"> <Function FunctionId="external:keyinfo-get-key-name"> <AttributeSelector ....... DataType="ds:keyInfo"> </Apply> </Condition> ------------------------------------------------------------------------ 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 This." value 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: Resolved 12/05/02. RESPONSE: Section 5.31 correctly explains what to do with whatever type is returned: either node-set or primitive values are converted to a bag of values. The Introduction to the XPath 1.0 specification says that an XPath expression can return the stated four things, so we believe this is correct. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: None. ------------------------------------------------------------------------ 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: Resolved 12/05/02. RESPONSE: Make the recommended change. ACTIONS: 1) In Section 5.31, change pdf:2404-2407 from 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). to If the XPath 1.0 expression evaluates to a node-set, then each node may consist of seven kinds of nodes as defined in XPath 1.0 specification." 2) In Section 5.31, change pdf:2407 In this case, each element is logically converted... to In this case, each element SHALL be converted... ========================================================================== 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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. SEE ALSO: #39 STATUS: Resolved 11/25/02. RESPONSE: Accepted ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Add "urn:oasis:names:tc:xacml:1.0:subject" to Identifier Prefixes defined in table in 10.3.2. [This change became moot with the acceptance of #39.] ========================================================================== 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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 IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html 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) It is confusing to have Target MatchId arguments be (AttributeDesignator/Selector, AttributeValue) yet Condition FunctionId arguments for the same function are (AttributeValue, AttributeDesignator). The only reason for this discrepancy is that we originally allowed only equality functions in the Target, so the order did not matter. Once we allowed for any Boolean function, the order should have been made consistent. While it is a fairly large change, and affects the schema, this is ugly and confusing. If we do not change it now, we will have to live with it forever. CATEGORY: Unclear. SEE ALSO: #5, #51 STATUS: Resolved 12/02/02. Partially resolved 11/25/02 by rejecting proposal to change argument order of -match functions, but requesting re-submittal of a proposal to change order of elements in the <Target> Match instead. RESPONSE: Target element order will be: AttributeValue, then AttributeDesignator or AttributeSelector. This will make MatchId argument order the same as FunctionId argument order. ACTIONS IMPLEMENTED IN: draft sent Tue. 3 Dec 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200212/msg00007.html ACTIONS: Update specification, policy schema, and Conformance Tests accordingly. 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. [John Merrells] Firstly, this [current differing order] needs to be very clearly pointed ont in the specification. I've read the spec maybe six times in the past three months and I only just noticed that the signatures differed in the specifications. [I was probably blinded by the natural assumption that the signature would not depend upon the context of the expression. I can't think of another language that does this.] Secondly, this is definitely going to catch users out who have to write this stuff. They'll happily cut an expression from a condition and paste it into a target, or vis-versa, and get upset. They'll be screwed unless they hack out, or in, the calls to 'only-one-of'. Wouldn't it be simpler for everyone to just make the signature the same in both places? You've got polymorphism based on the context of the call. How about adopting the more usual approach of basing the polymorphism on the type of the arguments? If I pass a primitive and a bag it does the match thing, if I pass a primitive and a primitive it compares them. Or, how about using two different names to reflect the fact there are two different behaviours... string-equal, string-match, double-match, double-equal, ... I think that polymorphism on argument type is the best approach, then changing the condition signature to be the same as the target signature, and then finally having different names for the behaviours. [Polar Humenn] I agree that in Section A.12 Match Elements we can put a _non-normative_ statement that says that the equivalent expression of a match element in the terms of higher order functions and reference that section. I say _non-normative because I want to preclude this definition as being the implemenation of the particular match element. For example, when the match element appears in the target it may be a specification of some complicated indexing function over possibly predetermined values of a specific attribute type. > I've read the spec maybe six times in the past three months and I only > just noticed that the signatures differed in the specifications. [I was > probably blinded by the natural assumption that the signature would not > depend upon the context of the expression. I can't think of another > language that does this.] I don't know what you mean here. The signature of the Match element is not the same as the signature of the function USED WITHIN the element. As for the signature depending on the type of the context of the expression, is standard type theory. Lots of languages as far back as C, Fortran, take advantage of such things. For example, the function, "+" in almost any language can be "integer-add" or "double-add", or even "boolean-or", depending on the type of the variables or constants used in the expression. > Secondly, this is definitely going to catch users out who have > to write this stuff. They'll happily cut an expression from a > condition and paste it into a target, or vis-versa, and get > upset. They'll be screwed unless they hack out, or in, the > calls to 'only-one-of'. > > Wouldn't it be simpler for everyone to just make the signature > the same in both places? True, and I think we are going to rearrange the schema so that the explicit value comes first and the designator second. That will give some consistency between "any-of" and the match elements. However, it is not an easy cut-paste job, as "any-of" appears in a <Apply> statement with <Function> and the Match element almost stands on its owwn. Also, you can use the Match Elements in both the Condition and the Target. > You've got polymorphism based on the context of the call. How > about adopting the more usual approach of basing the > polymorphism on the type of the arguments? If I pass a > primitive and a bag it does the match thing, if I pass a > primitive and a primitive it compares them. That is not true. The polymorphism is based on the types of the arguments, not the context of the call. The Designator or arguments all have explicit data types, and that instantiates the type signature of the Match element or the application of the "any-of" function. What you are asking for is a type generalization in an ad-hoc manner, which requires a runtime check to see what the type of the argument is at evaluation time. Having it the way we have it, you force the expression to be type correct, which precludes the need for a runtime check of the argument's type. That it one of the major benefits of type checking. > Or, how about using two different names to reflect the fact > there are two different behaviours... string-equal, > string-match, double-match, double-equal, ... I'm missing something in this comment. Two different names for different behaviors? You mean for the match elements? > I think that polymorphism on argument type is the best > approach, then changing the condition signature to be the same > as the target signature, and then finally having different > names for the behaviours. Forgive me, I am definitely missing something here. The Match element signature should be the same in both the Target and the Condition. We just make a statement that if the Match element ends up in the Target that it was restricted to those functions that are easily used for indexing, (but I think we are going to relax that condition). [John Merrells] I think I must have missed something basic here then. This is my reading of the spec... A12 says that type-equal is a match function, and that the arguments of a match function are <T,bag<T>> : Boolean. A14.1 then says that the arguments for the type-equal functions are <T,T> : Boolean. I took this to mean that within a <XxxxMatch> element that the signature was to be enforced as the former type, and everywhere else, ie within a condition, that it was to be enforced as the later. Is this a correct interpretation. >As for the signature depending on the type of the context of the >expression, is standard type theory. Lots of languages as far >back as C, Fortran, take advantage of such things. For example, >the function, "+" in almost any language can be "integer-add" or >"double-add", or even "boolean-or", depending on the type of the >variables or constants used in the expression. > I'm saying the same thing. This is how I'd like xacml to work. My reading suggests that the signature is not based on the types passed but on the identity of the call site. In C, or whatever, this would be like saying there's a function foo that can be called from either functions bar or baz, but when calling from baz you have to pass an int and when calling from baz you have to pass a double, and if you try to call the wrong one that's a compile time type error. >What you are asking for is a type generalization in an ad-hoc >manner, which requires a runtime check to see what the type of >the argument is at evaluation time. Having it the way we have >it, you force the expression to be type correct, which precludes >the need for a runtime check of the argument's type. That it one >of the major benefits of type checking. > Nope, I'm glad xacml expressions are strongly typed. ========================================================================== 0058. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00122.html Subject: syntactic errors in XACML schemas From: "DuCharme, Bob (LNG-EWR)" <bob.ducharme@lexisnexis.com> Date: Tue, 26 Nov 2002 13:54:28 -0500 Each of the two schemas available on http://www.oasis-open.org/committees/xacml/ has an error that prevents it being parsed. cs-xacml-schema-policy-01.xsd: the Xerces Java error message shows that because the AttributeAssignmentType complex type is a derived type, it must be declared as mixed or element-only, depending on whether its base type is mixed or element-only. Because AttributeValueType, the base type, has mixed="true" in its declaration, I added this to the declaration for AttributeAssignmentType and Xerces now parses it without a problem. Is this the fix that people should assume is in place when actually using XACML? cs-xacml-schema-context-01.xsd just has a typo: the "-1.0" in the import statement near the beginning should read "-01" if it's going to read the cs-xacml-schema-policy-01.xsd file mentioned above, which it needs to do. CATEGORY: Incorrect. STATUS: Resolved 12/02/02. Duplicates of #41 and #42 SEE ALSO: #41,#42 RESPONSE: We will use "mixed" in schema; use -01 in xsi import statement. ACTIONS: See #41 and #42 ========================================================================== 0059. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00129.html Subject: XACML questions ... From: Gene Thurston [mailto:gthurston@amberpoint.com] Sent: Wednesday, November 20, 2002 8:21 PM I was working with the latest XACML draft, and I had a few questions, mostly around the optional XPath capability outlined in it: ------------------------------------------------------------------------ 0059a. Why is there no <EnvironmentMatch>, similar to <SubjectMatch>, <ResourceMatch>, and <ActionMatch>? CATEGORY: Inconsistent STATUS: Resolved 12/02/02. RESPONSE: Not needed, since not useful for indexing. No use case. ACTIONS IMPLEMENTED IN: draft sent Tue. 3 Dec 2002 attached to http://lists.oasis-open.org/archives/xacml-editors/200212/msg00007.html ACTIONS: None. ------------------------------------------------------------------------ 0059b. When used inside a <SubjectMatch> element, is the XPath expression found in the <AttributeSelector> evaluated over the entire context document, or just over the <Subjects> sub-tree? Same question for <ResourceMatch> and <ActionMatch>? If the answer to the above is that the XPath expressions are always evaluated over the entire context document, then what are the semantics if such an expression inside, say, a <SubjectMatch> element evaluates to something outside the <Subjects> sub-tree? Is this just, "OK" (as I suspect), or is there supposed to be something special about the fact that it was inside a <SubjectMatch> so we shouldn't match anything outside the subject's attributes? If it is "OK", then there is no difference between <SubjectMatch>, <ResourceMatch>, or <ActionMatch>, and perhaps there should be a generic <AttributeSelectorMatch> or something similar? CATEGORY: Unclear. STATUS: Resolved 12/05/02. SEE ALSO: #52 RESPONSE: <AttributeSelector> SHALL have as its Context the XACML Request. This is already stated in the first sentence of "5.31 Element <AttributeSelector>". When the <AttributeSelector> occurs in a Target, it SHOULD point into the corresponding portion of the Request. ACTIONS: In Section 5.9 <SubjectMatch>, add text saying "The XPath expression in the AttributeSelector SHOULD resolve to a node that is in the Subject element of the Request." Make corresponding changes to Sections 5.13 (<ResourceMatch) and 5.17 (<ActionMatch>). Tim has freedom to do editorial re-wording. DISCUSSION FOR ALL: [Tim Moses, responding to Gene directly] I'll pass your questions on to the XACML comment list, in order to ensure that they get recorded and addressed, and that any lack of clarity is corrected. Basically, attributes of subjects, resources and actions (but not environment) may appear in a policy's target. A policy is applicable to a request if at least one of its subject matches is true AND at least one of its resource matches is true AND at least on of its action matches is true. AttributeSelector may be used in any of these match types. In the case of a subject match, for instance, the "context" node for the XPath expression is xacml-context/Subject. And similarly for the other types. On the other hand, AttributeSelector may also be used in an Apply element to define an argument to an expression. In this case, the "context" node for the XPath expression is the whole xacml:context. So, it can select any attribute of any entity (subject, resource, action or environment), but it has to explicitly indicate which type of entity is intended. [John Merrells, responding to Tim Moses] > AttributeSelector may be used in any of these match types. In the > case of a subject match, for instance, the "context" node for the > XPath expression is xacml-context/Subject. And similarly for the > other types. Whoa... the spec doesn't say that. The spec says that for an AttributeSelector the context node for the evaluation of the XPath expression is the Request element... !?! [Very long discussion ensued on the xacml@lists.oasis-open.org list; discussion not included here] ========================================================================== 0060. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00138.html Subject: A002 From: John Merrells <merrells@jiffysoftware.com> Date: Tue, 26 Nov 2002 19:58:52 -0800 Which part of the specification is this test testing? I read 7.9.2, but it says that if the PDP can't find an attribute in the context then it's to return Indeterminate. Also, in Figure 1 the PDP is shown reading policies from a PAP and returning responces to the context handler, but not retrieving attributes from anywhere. CATEGORY: Unclear. STATUS: Resolved 12/02/02. RESPONSE: The intent of the specification is that XACML PDPs will be able to obtain attributes that are not included in the request as received from the PEP, and that the Context Handler is responsible for retrieving attributes, whether from the initial context or from external sources. Clarify Figure 1 and its explanation and Section 7.9 to indicate that the PDP passes AttributeDesignators or AttributeSelectors to the ContextHandler and receives AttributeValues in return. ContextHandler also passes the PDP the initial request context for purposes of locating policies whose Targets match the request context. ACTIONS: 1) In Figure 1, change #8. to "Target, Attributes, Resource" and #9. to "Decision". In text description of #8., explain that Context Handler invokes the PDP and passes the initial request context for Target matching. The PDP requests the required attributes from the Context Handler. In text description of #9., change to "The PDP returns its decision." 2) Change Section 7.9 to say "Attributes are specified in the request context, regardless of whether they appeared in the original request or not, and are referred to in the policy ..." 3) Change Section 7.9.2 from "The PDP SHALL reference the attributes as if they were in a physical request context document, but the context handler is responsible for obtaining and supplying the requested values." to: The "signature" of the interface between the PDP and the Context Handler module has two inputs: an AttributeDescriptor or AttributeSelector, and a Boolean "MustBePresent" value. The output from the Context Handler to the PDP is either a bag of values or "Indeterminate" (in the case where an empty bag resulted, but "MustBePresent" is true). The Context Handler is responsible for retrieving the referenced attribute value regardless of whether the attribute was supplied in the original Request context or whether the attribute is available elsewhere in the system. DISCUSSION: [Anne Anderson] [For those not running the Conformance Tests, test A002 requires the system to retrieve an attribute value that is not supplied in the original XACML Request from the PEP. The instructions for the test are deliberately places no requirements on which attribute it is, where it is retrieved from, how it is retrieved, etc.] The intent of test A002 is to exercise one of the primary advantages of XACML: the ability to have the PDP side of the system obtain attributes that are not necessarily supplied by the PEP. Section 7.9.2 covers this, although we were so careful not to specify a particular implementation that perhaps we were not specific enough. It is the "context handler" that is responsible for supplying attribute values, and it is the existence of a context handler that is independent of any physical XML Request document that is being tested in A002. If we do not have a test of this kind, implementors can limit their capabilities to parsing an XML Request document using standard XML tools and retrieving attributes from that. We have specifically stated that the Context is NOT to be considered as a physical XML document (although it is certainly based on some sort of document received from the PDP), and that attribute values are obtained from the context handler. I am posting this to the XACML list for discussion. Do we want to require the functionality required by Conformance Test A002? [John Merrells, responding to Anne Anderson] The test special instructions state that it is the PDP that is responsible for fetching the attribute, but your comments above suggests that it is the responsibiliy of the context handler to fetch the attribute and supply it to the PDP. But, how does a context handler know which attributes are going to be needed by the PDP... it'd have to either send everything it has access to in the PIP... or do what the PDP would do in order to find out what the PDP is going to need. So, therefore only the PDP knows which attributes are not available to it within the request context, so it must issue the request for the attribute, but the spec (7.9.2) specifically says that in this case the PDP returns Indeterminate. Does anyone have a PDP that passes A002? [Anne Anderson, responding to John Merrells] >The test special instructions state that it is the PDP that is >responsible for fetching the attribute, but your comments above >suggests that it is the responsibiliy of the context handler to >fetch the attribute and supply it to the PDP. I should be more precise in my test special instructions. I was treating the "PDP" as the entire "PDP side" of the access control system, including the Context Handler. In 7.9.2, the PDP is the XACML Evaluation Engine. The "PDP side" of an access control system will necessarily have other functional components: o for receiving, possibly translating, and parsing requests from the PEP, o for fetching policies from repositories, o for fetching attributes from the Request Context and from repositories, o for constructing and possibly translating a Response into the PEP's format, o for transmitting the Response back to the PEP o for logging actions o ... We have not named the functional component that retrieves policies from external repositories or on-line PAPs, but such a component is implied by the semantics of the PolicyIdReference and PolicySetIdReference elements. In our model, the Context Handler is the functional component that handles any translation between the PEP's request format and an internal representation consistent with a Request Context, fetches attributes from the Request Context (or from an internal representation consistent with a Request Context) and from repositories, and handles any translation of the Response into the PEP's expected format. The "signature" of the interface between the PDP and the Context Handler module has two inputs: an AttributeDescriptor or AttributeSelector, and a Boolean "MustBePresent" value. The output from the Context Handler to the PDP is either a bag of values or "Indeterminate" (in the case where an empty bag resulted, but "MustBePresent" is true). "Indeterminate" would also be returned if there were a network error in attempting to contact a configured repository, or some other system error. As the XACML PDP evaluates a policy, it will encounter various AttributeDescriptors and AttributeSelectors. Each time the PDP encounters one, it passes the information in that descriptor or selector to the Context Handler. The Context Handler searches for a match among the attribute objects it has parsed out of the Request Context received from the PEP. If the requested attribute is not there, then the Context Handler queries its configured attribute sources (LDAP directory, SAML attribute assertion repository, file of attributes, on-line AA, etc.) for a matching attribute, passing the AttributeId, Issuer, etc., and the values of any corresponding subject-id, resource-id, or action-id attributes (as appropriate to the type of descriptor). If there is no attribute available from the configured attribute sources, then the Context Handler returns either an empty bag or "Indeterminate" to the XACML PDP, depending on the value of the "MustBePresent" input. If the "MustBePresent" value is true, then the Context Handler returns "Indeterminate". If the "MustBePresent" attribute is false, then the Context Handler returns an empty bag. In the context of a Condition, the XACML PDP passes the returned value to the enclosing function. Most, if not all, standard XACML functions return "Indeterminate" if one of the inputs is "Indeterminate", but extension functions might not. It is up to the definition of the function. Similarly, if the resulting function does not take a bag as its input, but a bag is passed to it, then standard functions return "Indeterminate", but extension functions might not. In the context of a Target, the XACML PDP either passes the "Indeterminate" result to the enclosing function, or else passes one element at a time from the bag result to the enclosing function. Again, the result depends on the definition of the enclosing MatchId function. >But, how does a context handler know which attributes are going >to be needed by the PDP... it'd have to either send everything >it has access to in the PIP... or do what the PDP would do in >order to find out what the PDP is going to need. The XACML PDP queries the Context Handler for an attribute each time it needs one in the process of evaluating a policy. >So, therefore only the PDP knows which attributes are not >available to it within the request context, so it must issue the >request for the attribute, but the spec (7.9.2) specifically >says that in this case the PDP returns Indeterminate. It does not say this. It says the value of the "MustBePresent" attribute determines whether the result of not finding a requested attribute is an empty bag of "Indeterminate". The default is to return an empty bag. >Does anyone have a PDP that passes A002? I expect that A002 and the two E tests (which require fetching policies and policy sets from external sources) will probably be the most difficult to implement, but the functionality is very important to achieving the goals of XACML. We wanted Policy writers to be able to write policies without worrying about who supplies which attributes, when, and from where. Some attributes may be supplied by the PEP, but others may need to be retrieved from external sources by the PDP side of the access control system. In some systems, attributes will be stored as X.509 Attribute Certificates; in other systems, attributes will be stored as SAML attribute assertions. In some systems, attributes will be stored in an LDAP directory; in other systems, attributes may be stored in a database. In some systems, a PEP is capable of retrieving attributes, but in others the PEP is a relatively dumb beast. A given policy should work with all these types of systems, assuming the Context Handler has been configured appropriately. [John Merrells, responding to Anne Anderson] Thanks for the detailed explanation Anne. This is much clearer to me now. I'll try to describe below why I was unable to glean this meaning from the specification. Anne Anderson - Sun Microsystems wrote: >In our model, the Context Handler is the functional component >that handles any translation between the PEP's request format >and an internal representation consistent with a Request >Context, fetches attributes from the Request Context (or from an >internal representation consistent with a Request Context) and >from repositories, and handles any translation of the Response >into the PEP's expected format. This was clear to me. Figure 1 and its description show this well. >The "signature" of the interface between the PDP and the Context >Handler module has two inputs: an AttributeDescriptor or >AttributeSelector, This was not clear to me. Firstly, figure 1, which I admit is non-normative, does not show this. It shows the request context going in (arrow 8) and the response context coming out (arrow 9). It does not show a bunch of calls from the PDP to the CH requesting attributes. Reading 7.9.2 again I see that it is actually saying this, I just didn't get it: "The PDP SHALL request the values of attributes in the request context from the context handler." I took 'request context' to mean the thing that is passed from the CH to the PDP... in other words the Request element. Perhaps 'request context' should be explictly defined in the document to be all attributes within the system, whether within or outside the Request? 'context handler' could also be capitalized. eg. "The PDP SHALL request attribute values from the Context Handler." The following assertion in 7.9.2 also caused me problems... "The PDP SHALL reference the attributes as if they were in a physical request context document, but the context handler is responsible for obtaining and supplying the requested values." What does that mean? The phrase 'the attributes' should probably be 'attributes', and the 'but' clause is a repeat of the previous assertion, so we're left with... "The PDP SHALL reference attributes as if they were in a physical request context document." I don't get it. Why 'as if''? Does 'reference' mean request? So the PDP will request all attribute values in the same way, and not have different ways of requesting different attributes? >As the XACML PDP evaluates a policy, it will encounter various >AttributeDescriptors and AttributeSelectors. Each time the PDP >encounters one, it passes the information in that descriptor or >selector to the Context Handler. The Context Handler searches >for a match among the attribute objects it has parsed out of the >Request Context received from the PEP. If the requested >attribute is not there, then the Context Handler queries its >configured attribute sources (LDAP directory, SAML attribute >assertion repository, file of attributes, on-line AA, etc.) for >a matching attribute, passing the AttributeId, Issuer, etc., and >the values of any corresponding subject-id, resource-id, or >action-id attributes (as appropriate to the type of descriptor). >If there is no attribute available from the configured attribute >sources, then the Context Handler returns either an empty bag or >"Indeterminate" to the XACML PDP, depending on the value of the >"MustBePresent" input. If the "MustBePresent" value is true, >then the Context Handler returns "Indeterminate". If the >"MustBePresent" attribute is false, then the Context Handler >returns an empty bag. > >In the context of a Condition, the XACML PDP passes the returned >value to the enclosing function. Most, if not all, standard >XACML functions return "Indeterminate" if one of the inputs is >"Indeterminate", but extension functions might not. It is up to >the definition of the function. Similarly, if the resulting >function does not take a bag as its input, but a bag is passed >to it, then standard functions return "Indeterminate", but >extension functions might not. > >In the context of a Target, the XACML PDP either passes the >"Indeterminate" result to the enclosing function, or else passes >one element at a time from the bag result to the enclosing >function. Again, the result depends on the definition of the >enclosing MatchId function. Yeah, I'm fine with all this, thanks for walking through the processing, I just didn't see that the PDP was supposed to ask the CH for the value of attributes that were referenced in a policy, but didn't exist with the request document. >I expect that A002 and the two E tests (which require fetching >policies and policy sets from external sources) will probably be >the most difficult to implement, I didn't actually have any problem with policy references... 5.18 and 5.19 are clear enough. [Seth Proctor, after Comment was resolved] Hrm. I think the new language is more confusing than the old language, since it's just defining an AD/AS, but it doesn't say that that's what it's doing. Still, it makes it clearer that a PDP should be able to look outside the physcial document for attribute values. One thing this still doesn't address is the issue of when it has to look elsewhere: if values are found in the physical document, does it still have to do a search? If a value is found at one location, must the CH continue on, doing an exhaustive search? If this is left undefined, then different implementations can produce different results from the same request. Also, "AttributeDescriptor" should be "AttributeDesignator." ========================================================================== 0061. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00139.html Subject: no rules or policies From: Seth Proctor <seth.proctor@sun.com> Date: Wed, 27 Nov 2002 11:13:57 -0500 Sections 7.6 and 7.7 contain, respectively, the only text in the spec that says what to do when a Policy has no Rules or a PolicySet has no policies. Unfortunately, the language is a little muddled (and looks like it might be left over from a previous version). Section 7.6 says "A Rules value of 'At-least-one-applicable' SHALL be used if the <Rule> element is absent..." Section 7.7 says "A policies value of 'At-least-one-applicable' SHALL be used if there are no contained or referenced policies or policy sets..." Is this supposed to imply that if the rule/policy[set] is missing, then the result should always be the result of the at-least-one-applicable combining algorithm, ie NotApplicable? If that's the case, I'd like to request that the text be clarified so that it's more obvious (since the above text doesn't really mean anything). If that's not the case, these sections need to be expanded to explain what to return in these conditions. As a side note, I don't really understand what the value is of having a Policy with no Rule, since it will always return the same thing (probably N/A), so why bother going through the effort of evaluating it? In other words, what is the reason for the schema defining PolicyType to have <xs:element ref="xacml:Rule" minOccurs="0" ... CATEGORY: Incomplete. STATUS: Resolved 12/02/02. RESPONSE: Reword Sections 7.6 and 7.7 as in ACTIONS. ACTIONS: 1) Change Section 7.6 Policy Evaluation to: The value of a policy SHALL be determined only by its contents against the request context. A policy's value SHALL be determined by the evaluation of the policy's target and the evaluation of its rules according to the specified rule combining algorithm. The policy's target is evaluated to determine the applicability of the policy. If the target evaluates to "Match" then the value of the policy SHALL be determined by evaluation of the policy's rules according to the specified rule combining algorithm. If the target evaluates to "No-Match", then the value of the policy shall be "NotApplicable". If evaluation of the target raises an "Indeterminate", then the value of the policy SHALL be "Indeterminate". 2) Change Section 7.7 Policy Set Evaluation to: The value of a policy set SHALL be determined by its contents against the request context. A policy set's value SHALL be determined by the evaluation of the policy set's target and the evaluation of its policies and policy sets according to the specified policy combining algorithm. The policy set's target is evaluated to determine the applicability of the policy set. If the target evaluates to "Match" then value of the policy set SHALL be determined by evaluation of the policy set's policies and policy sets according to the specified policy combining algorithm. If the target evaluates to "Not-Match", then the value of the policy set shall be "NotApplicable". If evaluation of the target raises an "Indeterminate", then the value of the policy set SHALL be "Indeterminate". DISCUSSION: [Polar Humenn] I agree on this. But this whole section doesn't really make sense to me at all. Neither do the tables. What is trying to be said here? Furthermore, these sections are riddled with mistakes like Not "Match" instead of "No-match" and "None-applicable" instead of "Not-applicable". These sections should say nothing more than the policy body is evaluated according to its rule combining algorithm and the evaluation of its rules, which is specified elsewhere. The "truth" tables are wrong according to any kind of policy combining algorithm. All of the combining algorithms handle the case when there are no rules or policies. So, I suggest the following rewording of both sections and remove the tables. [Rewording as in ACTIONS above, modulo editorial corrections] > As a side note, I don't really understand what the value is of > having a Policy with no Rule, since it will always return the > same thing (probably N/A), so why bother going through the > effort of evaluating it? In other words, what is the reason for > the schema defining PolicyType to have > > <xs:element ref="xacml:Rule" minOccurs="0" ... The reason is that XACML (in the long run) will most likely be generated by tools. I can't see anybody that would want to really write such copious verbage at the keyboard. When generating from other laguages or GUIs it is quite easy to end up with policies with no rules, conjunctives or disjunctives with no elements, etc. For logical completeness, these cases should be allowed and handled in a logically sound manner. Also, if the minimum administrative element for a PDP is the policy. One use case, Let's say that you will dynamically add rules, so to start you have no rules, but you still have to configure your PDP with a policy there. So you shouldn't force people to have rules where they don't have any. ========================================================================== 0062. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00151.html Subject: Two different URIs for access-subject From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Thu, 28 Nov 2002 16:30:42 +0900 INCONSISTENT In the specification document, Two different URIs for access-subject are used. urn:oasis:names:tc:xacml:1.0:subject-category:access-subject urn:oasis:names:tc:xacml:1.0:subject:subject-category:access-subject FYI: Testcases are inconsitent, too, for the same reason. In the schema, urn:oasis:names:tc:xacml:1.0:subject-category:access-subject is used. In the test policies, urn:oasis:names:tc:xacml:1.0:subject:subject-category:access-subject is used. CATEGORY: Inconsistent. STATUS: Resolved 12/02/02. RESPONSE: Use "urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" ACTIONS: Update specification to use "urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" consistently. Update Conformance Tests also. DISCUSSION: [Seth Proctor, after resolution was posted] Is there a reason this was decided? All the other attributes are nested in a namespace (like subject: or resource:), and since this is a subject attribute, it seems like it should also be in the :subject: namespace if it's going to look like all the other attributes. Otherwise, it isn't a subject attribute...is that the intent? [Anne Anderson, responding to Seth Proctor] The urn:...:subject-category:access-subject, etc. values are not Attribute Identifiers. They are attribute values. Yes, all our defined Subject Attribute Identifiers use :subject:<identifier>, and all Resource Attribute Identifiers use :resource:<identifier>, etc., but that is not true for Attribute values. ========================================================================== 0063a. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00152.html Subject: Environment attributes From: tony wilson <tony.wilson@inmezzo.com> Date: Thu, 28 Nov 2002 15:07:23 +0000 I'm unclear about the use of the time based context attributes, namely Urn:oasis:names:tc:xacml:1.0:environment:current-time Urn:oasis:names:tc:xacml:1.0:environment:current-date, and Urn:oasis:names:tc:xacml:1.0:environment:current-dateTime Section 10.3.5 of the specification states that 'The value for these attributes MUST be provided by the PDP', wheras Appendix B8 states that 'When used, they SHALL appear within the <Resource> element of the request context.' Looking at tests AAA016-IIA021, it appears that the expected usage is that the values may or may not be present in the request context, but if they are not present then values must be supplied by the PDP. Also, when values are being provided in the context requests of these tests, they are appearing in the <Environment> element, not the <Resource> element. Which, if any, of these is correct? CATEGORY: Unclear. STATUS: Resolved 12/02/02. RESPONSE: Clarify that intent is 'When supplied as part of the request, they SHALL appear within the <Environment> element of the request context.' ACTIONS: 1) In Section B.8, use 'When supplied as part of the request, they SHALL appear within the <Environment> element of the request context.' 2) In Section 10.3.5, use "If values for these attributes are not provided in the request, then values for these attributes MUST be provided by the PDP." DISCUSSION: >Appendix B8 states that >'When used, they SHALL appear within the <Resource> element of the >request context.' Sounds like a bug in the spec. >Which, if any, of these is correct? My interpretation is... If provided within a Request these attributes shall appear within the Environment. If not provided within a Request the PDP shall provide them within the Environment. ========================================================================== 0063b. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00008.html Subject: SubjectCategory XML attribute:string or URI? From: Anne Anderson <Anne.Anderson@Sun.com> Date: Tue, 03 Dec 2002 11:20:45 -0500 (EST) I recommend we change the type of the SubjectCategory XML attribute in both the Policy and, based on the 12/02/02 change, in the Context. RATIONALE: All the values we have defined for SubjectCategory are URIs. It is very important that custom SubjectCategory values not collide with each other. When subject-category was an XACML attribute, it probably made sense for the Policy SubjectCategory XML attribute to be a string since we specified that string-equals comparison was to be done. But the actual syntax of the SubjectCategory value should be something that is likely to be unique, and can be made not to collide with other values, and now that we are specifying that syntax, I believe it should be a URI. CATEGORY: Alternative. SEE ALSO: #70 STATUS: Resolved 12/05/02. RESPONSE: SubjectCategory XML attribute type will be xs:anyURI everywhere. ACTIONS: Make SubjectCategory XML attribute type be xs:anyURI everywhere, both in the Specification and in the schemas. ========================================================================== 0064. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00014.html Subject: <StatusCode Value= type> From: Anne Anderson <Anne.Anderson@Sun.com> Date: Tue, 03 Dec 2002 15:30:59 -0500 (EST) In the current schema, the type of the StatusCode Value XML attribute is specified as xs:QName. I believe it should be xs:anyURI to agree with our previous decisions about avoiding use of QNames except within schemas to refer to other schema elements. CATEGORY: Inconsistent. STATUS: Resolved 12/05/02. RESPONSE: Type of StatusCode Value will be xs:anyURI ACTIONS: Change schema and specification to indicate that the type of the <StatusCode> Value XML attribute is xs:anyURI. This affects the schema and Section 6.13 StatusCode in the specification. ========================================================================== 0065. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00015.html Subject: resource question & comment From: Seth Proctor <seth.proctor@sun.com> Date: Tue, 03 Dec 2002 17:43:31 -0500 ------------------------------------------------------------------------------- 0065a. Comment: In section 7.8, the urns for the scope types are called out, but the resource id is referred to simply as 'ResourceId' and not by its complete urn. This should reference the urn for resource-id (I suspect this is left over from when the Resource section of a Request actually had a ResourceId). CATEGORY: Inconsistent. STATUS: Resolved 12/05/02. RESPONSE: Use full urn:...:resource:resource-id instead of "ResourceId". ACTIONS: In Section 7.8, pdf:2898, change "ResourceId" to "urn:oasis:names:tc:xacml:1.0:resource:resource-id" ------------------------------------------------------------------------- 0065b. Question: In the ResultType, there is a ResourceId XML attribute, but it's of type anyURI. Should this be a string instead? Many systems allow things like spaces in path names, which is illegal in a URI. I realize that these can be escaped in URIs, but that may be extra processing for the application to do. I don't care either way, but I thought I'd bring it up. CATEGORY: Alternative. STATUS: Resolved 12/05/02. RESPONSE: Make ResourceId XML attribute type xs:string. This allows Request resource-id values of various types to be expressed here. ACTIONS: Change Type= of the <ResultType> ResourceID XML attribute from "xs:anyURI" to "xs:string" in the specification. The schema is already correct. ========================================================================== 0066. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00016.html Subject: another resource question From: Seth Proctor <seth.proctor@sun.com> Date: Tue, 03 Dec 2002 18:08:04 -0500 Section 7.8 doesn't say anything about error conditions, and I'm wondering if it should. I know that some things are out of scope and shouldn't be considered (eg, if only some Descendants could be resolved, the app-specific code should decide whether or not this is an error). But what should happen if there is some unrecoverable error in the process of discovering the resource list? Should the PDP return an error, or should it evaluate with the single resource that was provided in the Request? I would hope it could return an error, but 7.8 doesn't say anything about this. CATEGORY: Incomplete. STATUS: Resolved 12/09/02. RESPONSE: Allow for <Decision>s to be returned about resources that could not be discovered. Do this by returning a <Decision> with the ResourceId of the hierarchical element that could not be resolved or completely resolved, with an error <Status> on that <Decision>. Other <Decision>s on hierarchical elements, even if they are descendants of the element that has the error, may have non-error <Status> in the same Response. ACTIONS: Use wording from 12/6/02 draft (attached to http://lists.oasis-open.org/archives/xacml-editors/200212/msg00024.html) with the following additional edit: pdf:2918: 1) eliminate "related" 2) insert between element and SHALL the words "associated with the parent element". DISCUSSION: [Bill Parducci] i believe that the behavior is a return of INDETERMINATE with a status code of '[...]processing-error' (now that status codes are no longer optional). ========================================================================== 0067. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00018.html Subject:Section 8.2 "Extensible XACML attribute types" needsrevision From: Anne Anderson <Anne.Anderson@Sun.com> Date: Wed, 04 Dec 2002 08:15:42 -0500 (EST) Section 8.2 is a bit garbled, and now that we have SubjectCategory as an XML attribute instead of an XACML Attribute, it needs re-wording anyway. Here is my proposal: 1. Eliminate Section 8.2. Now that subject-category is not an XACML attribute, there are no longer any XACML-defined AttributeIds that have pre-defined, but extensible, values. 2. Add "SubjectCategory" to the list of "Extensible XML attribute types" in Section 8.1. CATEGORY: Incorrect. STATUS: Resolved 12/05/02. RESPONSE: Approved. ACTIONS: 1) Remove Section 8.2. 2) Add SubjectCategory to the list of "Extensible XML attribute types" in Section 8.1. 3) Delete Section 7.9.4 Subject Attributes. ========================================================================== 0068. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00134.html Subject: D002 From: John Merrells <merrells@jiffysoftware.com> Date: Tue, 26 Nov 2002 17:35:05 -0800 [Same comment submitted for D024] The policy uses string-equal as if the args were (bag<string>,string), this should probably be using the any-of method... <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:conformance-tests:bogus" DataType="http://www.w3.org/2001/XMLSchema#string"/> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string";>Zaphod Beeblebrox</AttributeValue> CATEGORY: Incorrect. SEE ALSO: #69 STATUS: Resolved 12/09/02. RESPONSE: Use wording specified in ACTIONS below. Say nothing in the specification about policies that are rejected before ever being presented to a PDP for evaluation: XACML specifies only the behavior of the PDP in evaluating a policy that is presented to it. Conformance Tests will not require systems that reject policies asynchronously with Request evaluations to return a given Response that depends on the rejected policy. ACTIONS: 1) Add to Section 7 a new sub-section: 7.x Syntax and Type Errors If a policy with invalid syntax is evaluated by the XACML PDP at the time a Request is received, then the result of that policy SHALL be "Indeterminate" with a StatusCode value of "urn:oasis:names:tc:xacml:1.0:status:syntax-error". If a policy with invalid static types is evaluated by the XACML PDP at the time a Request is received, then the result of that policy SHALL be "Indeterminate" with a StatusCode value of "urn:oasis:names:tc:xacml:1.0:status:processing-error". 2) Add following "Special Instructions" to every Conformance Test that uses an initial policy that has a syntax or static type error: The policy for this test contains [schema|static type] errors. If an initial policy with invalid [syntax|static types] MAY EVER be evaluated by the implementation's XACML PDP at the time a Request is received, then this test MUST be passed. In this case, the resulting Decision MUST be "Indeterminate" with a StatusCode value of ["urn:oasis:names:tc:xacml:1.0:status:syntax-error" - if syntax error | "urn:oasis:names:tc:xacml:1.0:status:processing-error" - if static type error ] If the implementation's XACML PDP CAN NEVER attempt to evaluate an initial policy with invalid [syntax|static types], then the implementation MUST demonstrate that the policy in *Policy.xml will be rejected by whatever entity is responsible for validating policy syntax in the system in which the XACML PDP will be used. In this case, the supplied Request and Response files are not relevant and may be ignored. DISCUSSION: Summary: some implementations perform validity checking on policies at the time they are configured into the PDP. The PDP will never see such policies. These PDPs may, however, see invalid policies that are referenced via a PolicyIdReference or PolicySetIdReference. Other implementations may look for and evaluate policies only at the time a Request is received. In this case, one or more of the initial policies may have validity errors. The XACML specification should not force an implementation to perform policy validity checking (syntax or type) at the time a Request is received, so the Conformance tests should not require this. ========================================================================== 0069. http://lists.oasis-open.org/archives/xacml/200212/msg00027.html Subject: IIC012: syntax-error or processing-error? From: Anne Anderson <Anne.Anderson@Sun.com> Date: Wed, 04 Dec 2002 08:58:43 -0500 (EST) Conformance Test IIC012 is intended to test for the error case in which a Condition FunctionId uses a function that does not return a Boolean result. The <Condition is: <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-subtract"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-one-and-only"> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:conformance-test:age" DataType="http://www.w3.org/2001/XMLSchema#integer"/> </Apply> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-one-and-only"> <EnvironmentAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:conformance-test:bart-simpson-age" DataType="http://www.w3.org/2001/XMLSchema#integer"/> </Apply> </Condition> Question: should the StatusCode Value from evaluating this Policy be "urn:...:status:syntax-error" (since it is a type error), or "urn:...:status:processing-error"? I'm leaning toward syntax-error. What do others think? CATEGORY: Unclear. SEE ALSO: #68 STATUS: Resolved 12/09/92 (same as #68). RESPONSE: See #68 ACTIONS: See #68 DISCUSSION: Long discussion on xacml@lists.oasis-open.org See #68. ========================================================================== 0070. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00028.html Subject: The data type of the SubjectCategory attribute From: Satoshi Hada <SATOSHIH@jp.ibm.com> Date: Thu, 05 Dec 2002 15:17:59 +0900 should be xs:anyURI in the two schemas. Currently, it is xs:string. CATEGORY: Incorrect. SEE ALSO: #63b STATUS: Resolved 12/05/02. RESPONSE: This is a duplicate of #63b. ACTIONS: See #63b. ========================================================================== 0071. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00035.html Subject: Element <Description> From: Anne Anderson <Anne.Anderson@Sun.com> Date: Thu, 05 Dec 2002 14:02:39 -0500 (EST) -------------------------------------------------------------------------- 0071a. In Section 5.20 "Element <Policy>" under the description of the <Description> sub-element, add "See 5.2 Element <Description>." CATEGORY: Unclear. STATUS: Resolved 12/10/02. RESPONSE: Add specified text. (Already in 12/6/02 draft) ACTIONS: Add "See 5.2 Element <Description>" -------------------------------------------------------------------------- 0071b. In Section 5.2 "Element <Description>", change first sentence from: The <Description> element is used for a free-form description of the <PolicySet> element and <Policy> element. to: The <Description> element is used for a free-form description of the <PolicySet>, <Policy>, and <Rule> elements. CATEGORY: Incomplete. STATUS: Resolved 12/10/02. RESPONSE: Add specified text. (Already in 12/6/02 draft) ACTIONS: Change as specified. =========================================================================== 0072. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00039.html Subject: 5.31 Element <AttributeSelector> From: John Merrells <merrells@jiffysoftware.com> Date: Thu, 05 Dec 2002 12:16:38 -0800 ------------------------------------------------------------------------ 0072a. If you want to enforce type correctness between the selector and the values then you have these choices... 1) The author of the XPath expression must write the expression so that it matches both the AttributeId and the DataType. Subject/Attribute[AttributeId= '...subject-id' and DataType"..."]/AttributeValue or, 2) the processor must enforce the type correctness. Option 1 is clearly error prone as people just won't bother, option 2 could be quite hard. [Although using the AttributeValue as the context node you could say "../@DataType"] CATEGORY: Incomplete. STATUS: Resolved 12/10/02. RESPONSE: See 52b. ACTIONS: See 52b. DISCUSSION: [Anne Anderson] I think we specified option 2 in the resolution to 0052b: The XACML context handler must filter the values returned by the XPath expression based on matching the DataType, returning only those that match the DataType to the PDP. [John Merrells, responding to Michiharu Kudo] >For the type correctness, I don't expect that option 1 always >occurs. So each implementation should enforce the type >correctness. I mean that the processor just calls some XPath >processor to retrieve the requested node set irrespective of the >datatype specified in the selector. After some string >conversions are performed, the processor checks whether each >string value can be converted to the datatype specified in the >selector. Either way, this kind of run-time type checking should >be implemented for the case of ResourceContent. Good. The specification text needs to be changed. Currently it states: "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. " >If XPath expression does not include a predicate expression to >satisfy data type requirement (Subject/Attribute[AttributeId= >'...subject-id' and DataType"..."]/AttributeValue), it can >select a node that has different data type. But I think this is >the problem of the policy specification and not the problem of >the AttributeSelector specification. Certainly, it would be >better to add some note about this in the specification. Yes. If the expression author writes an XPath that selects multiple attribute values with different DataTypes, then that is their problem. It would be good for the specification to point this out for expression writers. -------------------------------------------------------------------------- 0072b. How is the selected node converted into a value? You can convert a node into a string-value, as defined in the XPath spec. You then have a choice of using the string to value conversions that are defined in XPath, or use the conversions as defined in XACML. I would specify as the later, as XPath has some oddities in this area. (ie. The string 'false' has the boolen value true.) CATEGORY: Incomplete. STATUS: Resolved 12/10/02. RESPONSE: See 52b. ACTIONS: See 52b. DISCUSSION: [Anne Anderson] I believe this is clearly specified in Section 5.33, pdf:2404-2415: XPath 1.0: apply "string" function XPath 2.0: use xf:string accessor function. [John Merrells, responding to Michiharu Kudo] >I think that the semantics of the AttributeSelector should >conform to the specified version of the XPath. So the conversion >functions would be ones specified in the corresponding XPath >specification. In the case of XPath 1.0, each conversion (node >set to string value and string value to each data type) would be >the conversion specified in XPath 1.0 even if it may have some >oddities in it. I'd suggest that Implementors of XACML will find it easier to convert a string into an XACML type, than to convert a string into an XPath type and then into an XACML type. Fisrtly the XPath conversion functions would have to be exposed through the XPath processor API. The XPath interface specification does not mandate this. Also, the string to XACML type constructors should be readily available. [As the implementor will almost certainly have implemented these for expression processing.] Secondly, the specification will have to provide a table that maps the XPath type system onto the XACML type system. [Michiharu Kudo, responding to John Merrells] For the string type, I think there is no need to specify which string type to be implemented in the specification. It is up to the implementors. In turn, that string must be converted into the target XACML data type (e.g. XMLSchema#boolean) specified in the AttributeSelector element. This conversion is not clearly specified in the specification. We may borrow conversion semantics from XPath 2.0 function and operator draft document e.g. xf:boolean-from-string. -------------------------------------------------------------------------- 0072c. The next problem is working out which type to convert the string-value into. If we assume that the author or processor has checked that the selector and value types match then we can use the DataType specified in the selector. CATEGORY: Incomplete. STATUS: Resolved 12/10/02. RESPONSE: The type is converted into the type specified in the DataType of the AttributeSelector element. The DataType in the Request Attribute is ignored. ACTIONS: See 52b. DISCUSSION: [Anne Anderson] I believe this is specified in the response to #52b: The XACML context handler must filter the values returned by the XPath expression based on matching the DataType, returning only those that match the DataType to the PDP. [John Merrells, responding to Michiharu Kudo] >And I could not find any XACML function definition that converts >"false" string value to False boolean value in the committee >specification. Which function are you talking about? Section '4.3 Boolean Functions': "Function: boolean boolean(object) ... a string is true if and only if its length is non-zero" >If the conversion failed, then "Indeterminate" should be >returned (optionally with some status code such as >syntax-error). This statement should be added to the specification. -------------------------------------------------------------------------- 0072d. Another example that should be explored is an XPath expression executed over the ResourceContent. In this case there are no DataTypes provided with the values, so there's no type checking that can be performed. We can only assume that the value provided is a valid representation for a an instance of the value of DataType specified in the selector. If the value can not be coerced into that DataType then what should the processor return? CATEGORY: Incomplete. STATUS: Resolved 12/10/02. RESPONSE: The value will be the type specified in the DataType of the AttributeSelector. If the conversion of any value fails, then the AttributeSelector returns Indeterminate. ACTIONS: See 52b. DISCUSSION: [Michiharu Kudo] In the case of ResourceContent, the selected node set and resultant string value(s) must be checked against the data type specified in the selector. If the conversion failed, then "Indeterminate" should be returned (optionally with some status code such as syntax-error). =========================================================================== 0073. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00047.html Subject: XACML 1.0 Committee Specification Comments From: "Chopra, Dipak" <dipak.chopra@sap.com> Date: Mon, 09 Dec 2002 05:44:55 +0100 I reviewed the XACML 1.0 Committee Spec and here is the list of questions/comments. ---------------------------------------------------------------------------------- 0073a. Can PAP and PDP exchange Policy Set? Based on the Section 3.1 Data Flow Model, it seems like only Policy can be exchanged. If that is the case, how can PDP evaluate Policy Set as mentioned in Section 7.7 Policy Set Evaluation? CATEGORY: Unclear. STATUS: Resolved 12/10/02. RESPONSE: Needs clarification. ACTIONS: 1) In Section 3.1, Figure 1 - Data-flow diagram, change "1.policy" to "1.policy or policy set" 2) In Section 3.1, step 1 following Figure 1 - Data-flow diagram, change 1. PAPs write policies and make them available to the PDP. Its policies represent the complete policy for a specified target. to: 1. PAPs write policies and policy sets and make them available to the PDP. Its policies and policies sets represent the complete policy for a specified target. ---------------------------------------------------------------------------------- 0073b. What is the commonality between different Policy elements in the same Policy Set? The requirement on line #354 seems to indicate that the merging of different Policy elements into Policy Set is governed by "a given action". Does it mean that the cardinality between Policy Set and Action is 1 to 1? It seems confusing as schema does not suggest that. CATEGORY: Unclear. STATUS: Resolved 12/10/02. RESPONSE: Needs to be clarified. ACTIONS: In first requirement in Section 2.1 Requirements, change "given action" to "particular decision request." ---------------------------------------------------------------------------------- 0073c. As Target can have multiple Resource and Action elements, not every Action is valid for each Resource. But the current schema allows to provide more non-existent access to resources. CATEGORY: Unclear. STATUS: Resolved 12/10/02 RESPONSE: Yes, it is true that not every Action will apply to every Resource in a Target. The Target is designed to facilitate indexing based on either Subject, Resource, or Action, and not on combinations of Subject, Resource, and Action. The "Condition" element may be used to express relationships between particular Resource attributes and particular Action attributes. ACTIONS: No change. ---------------------------------------------------------------------------------- 0073d. What is the significance of an Obligation with FulfillOn="Deny"? Which use case needs this feature? CATEGORY: Unclear. STATUS: Resolved 12/10/02. RESPONSE: A use case is where the PEP has an obligation to "Log denied access attempt" in the case of a Deny. ACTIONS: No change. ---------------------------------------------------------------------------------- 0073e. Line #2675, scope can be "Descendants" or "Children" as mentioned on lines #2907, 2908 in the case of multiple results. CATEGORY: Unclear. STATUS: Resolved 12/10/02 RESPONSE: Needs to be corrected. ACTIONS: Change line 2675 from in the request context is "Descendants" to in the request context is "Descendants" or "Children" ---------------------------------------------------------------------------------- 0073f. Section 7.6 Policy Evaluation. The table should be Policy truth table. CATEGORY: Unclear. STATUS: Resolved 12/10/02. RESPONSE: Needs to be corrected. ACTIONS: Change title of table from "Rule truth table" to "Policy truth table" ---------------------------------------------------------------------------------- 0073g. Section 7.7 Policy Set Evaluation. The table should be Policy Set truth table. CATEGORY: Unclear. STATUS: Resolved 12/10/02. RESPONSE: Needs to be corrected. ACTIONS: Change title of table from "Rule truth table" to "Policy Set truth table" ---------------------------------------------------------------------------------- 0073h. In this table, what is the meaning of "Effect" of Policy. As far as schema is concerned, Policy does not have this attribute. Only Rule has Effect element. Probably the right statement "At least one policy value has the calculated effect value". CATEGORY: Unclear. STATUS: Resolved 12/10/02. RESPONSE: Change "effect" to "decision" ACTIONS: Change first entry in 7.7 Policy Set evaluation truth table from At least one policy value is its Effect to At least one policy value is its Decision. ---------------------------------------------------------------------------------- 0073i. Line #2907, 2908. It seems like authorization decision MAY include multiple results based on the structure of resource sub-tree. I think this mechanism provides more information than requested. PEP is requesting if this subject(s) has the specified access (actions(s)) on the specified resource and its child nodes. The response should be one result. Why would PEP want to get detailed result information for each sub-node under resource? PEP must know about the structure (if there is any) of the requested resource and accordingly request for authorization decision from PDP. Based on that response, PEP should be able to allow or disallow the request. On line #2968, it says only one Decision element, which is not right based on lines #2907, 2908. CATEGORY: Unclear. STATUS: Resolved 12/10/02. RESPONSE: Use case: the resource is a patient record. Administrative requesters are allowed to see the sub-elements of the resource that contain patient name, date-of-birth, social security number, etc., but are not allowed to see elements pertaining to diagnosis, prognosis, or medical history. This is the intent of providing multiple decisions pertaining to various sub-elements of a resource. ACTIONS: No change. ---------------------------------------------------------------------------------- 0073j. There are two different types of resources. Functionality resource and data-instance resource. For example, ManagePO resource can be used to create/delete/modify an instance of PO. So ManagePO is a type of functionality type resource and instance of PO is a data-instance type resource. If we need to mandate that this action of this data-instance type resource can only be permitted by this functionality-type resource, how do we enforce that? CATEGORY: Unclear. STATUS: Resolved 12/10/02. RESPONSE: If we are understanding you correctly, this could be enforced by expressing ManagePO as the Subject of the Request, and the PO as the Resource of the Request. ACTIONS: No change. =====================================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC