[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] [schema] New list of schema issues
We plan to meet again on Friday 26 July 2002 to continue trying to close issues on the list. I propose that we start on Friday where we left off today (#38), then cycle back to action items and items we were unable to close today. Attached is the new list of open schema issues, including several action items, which are duplicated here: - [Anne] Specify semantics for multiple subjects in a request. Due: 25 July 02 - [Simon] Specify proposal for Error schema. Due: 25 July 02 - [All] Make concrete proposals for simpler AttributeDesignator syntax. Proposals should include both AttributeDesignator syntax and corresponding Request context syntax. Due: 25 July 02 - [Tim] Update schema with CLOSED items and Error schema. Due: 26 July 02 - [Anne] Respecify the Or and Ordered Or function semantics for Issue #36 such that only TRUE or FALSE is returned. Due: 25 July 02 - [Daniel] Specify alternate solution to handling of INDETERMINATE and ERROR results in evaluating functions such as in Issue#36. Due: 25 July 02 -- 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: XACML schema issues Author: Anne Anderson Version: 1.16, 02/07/22 (yy/mm/dd) Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.SchemaIssues.txt Next schema subcommittee meeting: Friday 26 July 2002, usual time (10am-12 EDT). ACTION ITEMS: - [Anne] Specify semantics for multiple subjects in a request. Due: 25 July 02 - [Simon] Specify proposal for Error schema. Due: 25 July 02 - [All] Make concrete proposals for simpler AttributeDesignator syntax. Proposals should include both AttributeDesignator syntax and corresponding Request context syntax. Due: 25 July 02 - [Tim] Update schema with CLOSED items and Error schema. Due: 26 July 02 - [Anne] Respecify the Or and Ordered Or function semantics for Issue #36 such that only TRUE or FALSE is returned. Due: 25 July 02 - [Daniel] Specify alternate solution to handling of INDETERMINATE and ERROR results in evaluating functions such as in Issue#36. Due: 25 July 02 ISSUES: 34. [Michiharu] XPath Subset http://lists.oasis-open.org/archives/xacml/200207/msg00066.html OPEN: Complexity, especially when namespace must be specified. For simple XPATH, context schema must be flattened. How to limit XPATH if using a general-purpose library. Check in policy authoring tool. Context can use any XPATH expression, but policy is limited. Could XPATH evaluation be done on the requester side, with just the extracted elements be handed to the PDP? Should context be designed without any attributes, in order to make XPATH simpler (just element /)? 36. [Anne] attribute references and indeterminate results http://lists.oasis-open.org/archives/xacml/200207/msg00069.html http://lists.oasis-open.org/archives/xacml/200207/msg00071.html On further reflection, I think the definition of the semantics of the function being used for OR should determine whether all attribute references must be resolved or not. Since retrieving attributes can be very expensive, I propose the following semantics for the two "standard" OR functions: urn:oasis:names:tc:XACML:0.15g:operators:or Operands may be evaluated in any order. Evaluation continues until either one operand returns TRUE, or until all operands have been evaluated. Once any operand has been evaluated TRUE, no additional operands are evaluated. If any evaluated operand returns TRUE, then the result of the function is TRUE. If all operands are evaluated, and none of them evaluates to TRUE, then, if ANY operand evaluated to INDETERMINATE, the function returns INDETERMINATE. If ALL operands evaluated to FALSE, then the function returns FALSE. urn:oasis:names:tc:XACML:0.15g:operators:orderedOr Operands must be evaluated in the order specified. As long as evaluated operands return a result of FALSE, evaluation continues. If an evaluated operand returns TRUE, then the function returns TRUE and no additional operand evaluations are done. If an evaluated operand returns INDETERMINATE, then the function returns INDETERMINATE. In this case, additional operands MAY be evaluated in order to provide information for inclusion in Advice, but such additional evaluations do not affect the result of the function. Similarly, combining algorithms must specify any requirements regarding the order in which rules/policies/sets are evaluated, whether all rules/policies/sets MUST be evaluated, and the semantics of any evaluated rule/policy/set returning INDETERMINATE. OPEN: Anne to respecify the OR semantics such that only TRUE or FALSE is returned. Daniel will also propose a solution. 37. [Michiharu] Use of XPath with namespaces. http://lists.oasis-open.org/archives/xacml/200207/msg00056.html Namespace URI functions and Global Name functions. Another option: namespace prefix in the XPATH expression, but this needs some assumptions on the target document. OPEN: 38. [Daniel] Split non-null-set-intersection function http://lists.oasis-open.org/archives/xacml/200207/msg00076.html [1)] [Tim] http://lists.oasis-open.org/archives/xacml/200207/msg00077.html Split non-null-set-intersection into intersection(list, list) - returning xs:list and non_null(list), returning boolean. OPEN: 39. [Daniel] Add floor(decimal) http://lists.oasis-open.org/archives/xacml/200207/msg00076.html [2)] [Tim] http://lists.oasis-open.org/archives/xacml/200207/msg00077.html In addition to round(decimal), floor(decimal) is probably necessary [Tim] "function:integer" was intended to serve as floor(decimal). OPEN: 40. [Anne] Change XACML "Request" to "Query"? http://lists.oasis-open.org/archives/xacml/200207/msg00078.html [1.] [Tim] http://lists.oasis-open.org/archives/xacml/200207/msg00079.html [Daniel] http://lists.oasis-open.org/archives/xacml/200207/msg00080.html Eve Maler suggests we change the name of "Request" to "Query" to conform to SAML usage. OPEN: 41. [Anne] Is a "notional" XML document for Request a good idea? http://lists.oasis-open.org/archives/xacml/200207/msg00078.html [2.] [Daniel] http://lists.oasis-open.org/archives/xacml/200207/msg00080.html OPEN: 42. [Anne] ConditionType and ConditionIdType http://lists.oasis-open.org/archives/xacml/200207/msg00081.html What should we use for ConditionIdType when the ConditionType is an Attribute or AttributeDesignator? Should we define a new ConditionIdType that is "function:boolean-attribute-value"? Tim proposes "function:true" as wrapper for an Attribute or AttributeDesignator. This conflicts with use of "function:true" to ALWAYS return TRUE for "any" matches in Target. OPEN:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC