[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