[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] F2F XACML June 20, 2002 Minutes (morning)
Minutes XACML meeting Morning 20th June 2002 Present: Anne Anderson Tim Moses Daniel Engovatov Bill Parducci Simon Godik Michiharu Kudoh 1. Typing XACML will define some core predicates. Simon says these will be defined in an XML document, rather than in a schema. The core predicates will be required for conformance. Simon presents his proposal for the general "function" declaration type. It has two attributes: name and return value, both uris. Its contents is a sequence of arguments, each of which has a type attribute, which is a uri, and the contents is the argument value itself. A concrete function declaration is described by an instance of the function declaration. It defines the function name, return type and the type and number of arguments. The data type can be a reference to the XML schema data type, or a private data type. If we make the function declaration the head of a substitution group, then the concrete functions can be given meaningful tag names, and the attributes can have the "fixed" facet. Daniel still prefers that concrete functions be XML instances, not derived schema with fixed facets. Bill suggests we get concrete examples of the derivation approach on the list, in order to help people decide if this approach is acceptable. Daniel believes that the derivation approach implies that someone who defines a private function must declare it in the form of an extension schema that derives by restriction from the schema for function, rather than in the form of an xml instance, and this is much more difficult. Simon's approach eliminates the need for identifying type conversion functions. 2. Context AttributeDesignator (might need a different name) in policy is nothing but a urn holding an XPath into the context. The AttributeDesignator (might need a different name) in context holds the attribute meta-data. Michiharu provides an example of his requirement for fine-grained access-control. It involves a policy that denies access to a descendant element (e.g. salary) when the request is for the parent element (employee record). Simon makes the case that the request and context should be able to indicate whether the resource is hierarchical, or not, and whether a means is needed to indicate whether the request refers to the indicated level of the hierarchical or separately to all levels below the indicated level. It was agreed to support this: immediate element, the element and its immediate children and the element and its descendents. This semantic applies to all hierarchical resource types, not just xml documents. The editor will propose a specific solution. Decided to make action a uri. The whole question of whether an empty data item can be interpreted to be all entities of that type was discussed. Bill pointed out that it is difficult in a database setting to write a query on empty data sets. So, tentatively, we will use a reserved value, and use it in all places where this is required. We need reserved uris for all, implied and none.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC