MHonArc v2.5.2 -->
xacml message
[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