The 12/9/02 Comments Subcommittee meeting and the 12/12/02 TC meeting are VERY important. - At the Subcommittee meeting, we MUST resolve all remaining comments (including any that come in between now and Sunday). - At the TC meeting, we MUST have at least 2/3 of the TC members present in order to vote to approve the 1.0 Specification. Please make arrangements to call in: the vote will be held at the beginning of the 2-hour scheduled time (after the roll call). Appended are the unresolved comments up to this time. Remember to check for any additional ones that come in over the weekend! 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 SUMMARY ======= This version of the file contains e-mail up through
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00044.html and
http://lists.oasis-open.org/archives/xacml/200212/msg00065.html ACTION ITEMS: 52b. [Tim] develop text changes to implement the response. [Michiharu] review Tim's text changes for correct use of XPath terminology. DUE: 12/09/02 The unresolved comments are: - 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." Status: resolved in intent; waiting for wording. - 0066.
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00016.html Subject: another resource question From: Seth Proctor Status: resolved in intent; waiting for wording to be developed and approved. - 0068.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00134.html Subject: D002 Status: Issue is policy type checking, whether it is relevant to a Request evaluation, and if so, what the Result should be. - 0069.
http://lists.oasis-open.org/archives/xacml/200212/msg00027.html Subject: IIC012: syntax-error or processing-error? Status: same as #68 - 0071.
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00035.html Subject: Element <Description> Status: not yet discussed - 0072.
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00039.html Subject: 5.31 Element <AttributeSelector> Status: not yet discussed. I believe most of the sub-comments have been resolved, but 72d may require some discussion. UNRESOLVED COMMENTS =================== 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: Response resolved 12/05/02. RESPONSE: "it" means the XACML context handler. 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. ACTION ITEM: #52b [Tim] come up with wording; [Michiharu] approve terminology. DUE 12/9/02. ACTIONS: ========================================================================== 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: Response resolved 12/05/02. Implementation of the ACTION to be reviewed and approved 12/9/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: In Section 7.8, add wording to effect the above. In the next to last paragraph of Section 7.8, pdf:2909-2911, remove the sentence starting with "In this case, the <Status> element SHOULD be..." 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). ========================================================================== 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: Not yet discussed. RESPONSE: ACTIONS: DISCUSSION: [long discussion on
xacml@lists.oasis-open.org not included here.] Issue is whether type checking in a policy is done by the XACML PDP at the time a policy is evaluated or before the policy is ever passed to the XACML PDP. If policy type checking is done by the XACML PDP, then D002 (as originally formed) should return a syntax-error. If type checking is done before a policy is ever made available to the XACML PDP, then Conformance Test D002 (as originally formed) is meaningless, because the policy above would fail type checking and thus never be passed to the XACML PDP and would never be available for evaluation at the time a Request is received. If type checking is done before a policy is ever presented to a PDP, then how are errors detected? How does the PEP know, for example, that NotApplicable was returned because the policy that was supposed to apply had a syntax error? Or must these types of errors be detected and handled by another part of the access control system, such as the PAP interface to the XACML PDP? [Anne Anderson] Are there any objections to the following resolution to the type and syntax checking debate, at least with respect to the Conformance Tests? This may not resolve the issue completely, but I feel we need to decide as soon as possible what the Conformance Tests will do so that implementations can attest to "successfully using" this coming week. 1) I have added the following "Special Instructions" to the two tests that test that an invalid policy will never be used to return a Permit, Deny, or NotApplicable result. - Special Instructions for Test Case II.A.4 The policy for this test is not schema-compliant: it contains a syntax error. If a policy with invalid syntax 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 result MUST be consistent with the supplied IIA004Response.xml file: it returns a Decision of Indeterminate with a StatusCode value of "urn:oasis:names:tc:xacml:1.0:status:syntax-error". If the implementation's XACML PDP CAN NEVER attempt to evaluate a policy with invalid syntax, then the implementation MUST demonstrate that the policy in IIA004Policy.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. - Special Instructions for Test Case II.C.3 The policy for this test contains a static type error. If a policy with static type errors 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 result MUST be consistent with the supplied IIC003Response.xml file: it returns a Decision of Indeterminate with a StatusCode value of "urn:oasis:names:tc:xacml:1.0:status:processing-error". If the implementation's XACML PDP CAN NEVER attempt to evaluate a policy with static type errors at the time a Request is received, then the implementation MUST demonstrate that the policy in IIA004Policy.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. ========================================================================== 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: Not yet discussed. RESPONSE: ACTIONS: DISCUSSION: Long discussion on
xacml@lists.oasis-open.org See #68. ========================================================================== 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: Not yet discussed. RESPONSE: ACTIONS: -------------------------------------------------------------------------- 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: Not yet discussed. RESPONSE: ACTIONS: =========================================================================== 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: Not yet discussed. RESPONSE: ACTIONS: 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. -------------------------------------------------------------------------- 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: Not yet discussed. RESPONSE: ACTIONS: 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. -------------------------------------------------------------------------- 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: Not yet discussed. RESPONSE: ACTIONS: 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. -------------------------------------------------------------------------- 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: Not yet discussed. RESPONSE: ACTIONS: 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). ===========================================================================