[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] XACML Face to Face 19-20th June 2002 Concatenated Minutes
|
Minutes XACML Face to Face meeting 19-20th June 2002 Manhattan Beach, CA Concatenated from: http://lists.oasis-open.org/archives/xacml/200206/msg00056.html http://lists.oasis-open.org/archives/xacml/200206/msg00059.html http://lists.oasis-open.org/archives/xacml/200206/msg00063.html http://lists.oasis-open.org/archives/xacml/200206/msg00065.html http://lists.oasis-open.org/archives/xacml/200206/msg00068.html
Present: Anne Anderson Tim Moses Daniel Engovatov Bill Parducci Simon Godik Michiharu Kudoh
Agenda: Wednesday June 19th 2002 9:00am - 9:05am Appoint chair (pro-tem) Bill and secretary Tim 9:05am - 10:00am Agenda 10:00am - 12:00am: Typing 12:00am - 12:30pm: Send minutes 12:30pm - 2:00pm: Lunch 2:00pm - 5:00pm: Context 5:00pm - 5:30pm Send minutes
Thursday June 20th 2002 8:30am - 9:30am Teleconference (formal TC meeting) 9:30am - 11:30am: Typing 11:30am - 12:00pm: Send minutes 12:00pm - 1:30pm: Lunch 1:30pm - 2:30pm Teleconference 2:30pm - 4:30pm: Context 4:30pm - 5:30pm Wrap-up
Agenda discussion
Typing Daniel recommends having extensibility points for types in predicates and functions. Proposing a binding to a general-purpose language implementation (e.g. LISP). Suggest including an XML attribute for "predicate" that conveys the type of the arguments. Simon suggests that LDAP will be a common solution for retrieving attributes. So, we need an LDAP profile for retrieving them. i.e. sitting LDAP between the PDP and the PIP, as well as sitting it between the PDP and the PRP. We decided to address LDAP at the next face-toface.
Context Decided to wait for Michiharu to arrive, later in the morning.
Typing Daniel wants a way to define a way of binding to programming languages. Simon argues for keeping things simple. Anne describes how mapping to Java is taking place. They simply need a common policy that is understood by all users (e.g. OS, DBS, etc.) independent of programming language. Bill makes the point that we define some parts (but not all) of a programming language. Everyone will have to extend, so why even include the basic operations? Anne suggesting that we define "predicate" in the core, but not the actual predicates. Daniel suggests cutting the spec into two parts: the first has the framework, the second has the general predicates and functions. Daniel says that date comparisons (for instance) are not the same for all customers. We could make operations on dates illegal for the spec-defined predicates and functions. Simon suggests that we can confine the predicates and functions to the types defined in XML schema. It was suggested that we have a vote in the Thursday teleconference on splitting the spec into a "framework" and "constraint language". 3 External functions Simon presented his proposal (of 3 May) on external functions. We may or may not want to use the same approach for internal functions. Types are defined by uri, which may be built-in XML schema types or private types. Simon talks about the "conversion" function. Daniel says that Simon's proposal is fine, except, he would like to be able to place another function where currently only an argument is allowed. Also, he would like to be able to specify a default value for the case where the attribute value cannot be retrieved. Daniel says that if a function can substitute for an argument, then the "outer" function could be the conversion function. In version 14, the extensibility of attribute functions is achieved by an empty abstract type (AttributeFunctionAbstractType). This does not recognize that functions share common characteristics (e.g. a return value and a list of arguments). Consensus seems to be that Simon's basic proposal is fine. But, there were some uncertainties: do we need the conversion function (for instance)? We seem to need the policy to specify types that go beyond those defined in XML schema. For instance, "xs:duration" may not be adequate, you may need "days in custody". Is the conversion function determined by the input and output type definitions? Summary: We want to define a general function-structure. The operation performed by a particular function is associated with its "name" attribute. The name is a urn. The same function on different types have different names. We may provide another (optional) attribute for a locator of the function. And we will provide an attribute for its return value type. We will define "some" functions and their urns. Others may define other functions and urns. Functions contain arguments and other functions. The type of an argument will be explicitly included in the argument's schema. If the raw attribute is only available as a different type, then a type conversion must be performed. The type conversion operation for each possible input type is optionally identified in the function's schema.
Minutes Present:
1. Context Version 14 contains a schema for Context with two top-level elements: request and response. Discussion of the <subject> element and whether it is permissible for it to be empty. Decided to allow it to be empty. Daniel wants to be sure that we can write policies that explicitly deny access if the subject is unknown. Michiharu points out that an XPath expression for a missing element is the empty set and this translates to false, if the result is converted to boolean. The subjectId should allow for ds:keyInfo to address the case where the subject has proved knowledge of a key, but not supplied a name. Simon asks how we could write a policy that depends upon the method used to authenticate the subject. SubjectId should be a choice of xacml:NameIdentifier or ds:keyInfo. Discussion of <holder>. Decided to take <holder> out of the context. The AttributeDesignator in a policy is simply an XPath expression of type xs:anyURI. Discussion of importing saml schema definitions (DecisionType and AttributeValue). The meeting preferred to eliminate any definitions imported from saml. Decided we need an <xacml AuthenticationInfo> (method and instant) element descendant to Subject. Resource: there is one and only one in a context instance. Decided to remove the xacmlContext:ResourceContentType definition, and redefine the type of <xacml:ResourceContent> to be xa:any. Then the XPath expression in the policy <Attribute> proceeds down into the resource, if it is an XML document. In Section 7, we need to define an identifier for ResourceDigest. The Resource <Attribute> will have the same type definition as the Subject <Attribute>. Decided to use name SubjectCategory instead of SubjectFunction. The meeting discussed the fact that the <ResourceContent> can be greater than the resource identified by the ResourceURI. i.e. conditions may reference parts of the resource other than those to which access is being requested. Michiharu wants to allow a PDP to return multiple decisions in a single response for each separate descendant element and attribute of the resource defined in context. Can this be indicated in the request using the facilities of XPath? Simon will modify the schema for "function", and table it for discussion tomorrow morning. And he will provide examples. We may not resolve Michiharu's issue during this face-to-face. But, resolution may have to await discussion on the list.
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 ANY.
Minutes
Present:
V 15 section 6 should be of the same style as section 5. We intend to have updated schema available by 28 June. Because the specification contains examples, it seems unlikely that we can update those to be consistent with the new schema by 28th June.
1. Context response Simon wants to schedule a discussion on the use of AttributeDesignator
in policy. Discussed the context response. Discussed "advice". Advice might be used for identifying missing attributes to the PEP by the PDP. In the saml world, the samlp:response is an assertion and it has to be built from the response context. The assertion may contain validity information. Where does this come from? Should we support a decision-caching model? Validity is optional in the saml schema. The identifier of the rule that was used to determine the decision is another attribute that may be returned in the response. Advice will be an optional element. It will not be mandatory to implement by either the PDP or PEP. However, we will define one kind of advice: missing attributes. We decided to leave out conditions in v 1.0. Multiple responses - Response is unbounded. Then resource is a sequence of decision, resource, obligations and advice. Response is singular, sequence of decision. Decision is a sequence of effect, resource (optional), obligations (optional) and advice (optional). Discussion of attribute designators in policy. Simon describes the current solution: a free-form XPath into the context. The alternative is to provide a designator that contains elements or attributes for the attribute meta-data. The first alternative is powerful and flexible. The second is straightforward and tuned to the application. Simon advocates the first approach for resource and the second for everything else, particularly subject. Tim suggests that the specification could define some constants whose values are the XPath expressions into the context to retrieve particular attributes. There was confusion over the ability of the "selector" profile of XPath to support the ".." operator. Daniel suggests that the attribute designator may have to contain a SQL expression. Maybe this should be considered after v 1.0. In v1.0 we'll use the first approach with the "selector"
subset of XPath.
Actions:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC