[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of the XACML TC Focus Group 3 June 2004
Attendees: Anne Anderson Hal Lockhart Ed Coyne Michiharu Kudo Minutes: 1. NASA SEWP (engineering workstation something) Symposium on Identity Federation Hal Lockhart made a presentation on XACML. He mentioned the TC will be producing a Profile for Hierarchical Resources. 2. Hierarchical Resources -Anne is about to release a draft Profile for Hierarchical Resources. It makes support for all aspects of hierarchical resources optional. -Michiharu: Anne's example of why higher order bag functions are useful with "xpath-node-match" did not actually use "xpath-node-match". "xpath-node-match" already specifies that the second argument is a bag. "xpath-node-match" returns boolean. Anne: Michiharu is right. This was a poor example. RESOLUTION: The Profile will mention that the "xpath-node-match" function OR Bag functions OR Higher-order Bag functions may be useful in composing policies that refer to XML documents. -Michiharu: With XML documents, "resource-ancestor" does not deal with the order of ancestor elements. If you want to deal with that, you need to support XPath-type functions. -Anne: I just realized that only <AttributeSelector> may be used to extract portions of <AttributeValue> elemets that are XML schema instances. <AttributeDesignator> with DataType xpath-expression will not work here. -Michiharu: Anne proposed two resource-ids for XML document resources, one for node to be accessed, one for document identity itself. An XACML 1.0 example used an XPath expression concatenated with an XPointer expression. IBM's implementation actually does not use that. Michiharu has been looking for a better solution. Another solution would be to embed the XPath expression in an anyURI DataType as a query component following "?". But query component has many restrictions, so would have to translate the XPath expression into a funny, escaped character format. Anne: XPath expressions delving into <AttributeValue> elements probably would not want to include an "anyURI" portion - it would be meaningful only in the <ResourceContent> case. Michiharu: using "document-id" may be another way to solve this problem. Michiharu will consider further and respond. -Michiharu: With descendant "scope" Attribute, it makes sense when target is XML document AND you use xpath-expression to point to the target node. How can one do the same thing using resource-parent and resource-ancestor scheme. Anne: use of "scope" and use of "resource-parent/ancestor" are independent. Michiharu: Use case: Requester wants to retrieve entire XML document, but policy says certain elements should not be disclosed. PDP would have to make a separate evaluation for EVERY element in the XML document. If XML document is big, this will be difficult. This is typical. Anne: one problem discussed at F2F was how to represent the results of a decision where this is the case. If access is denied for one interior node in the document, is there one <Result> for the document as a whole indicating "Permit", but one more for the interior node indicating "Deny", and the PEP somehow knows that the interior "Deny" overrides the overall "Permit" for that one node? Michiharu: Request Context <ResourceContent> contains entire XML document. PDP can return responses node-by-node, so there would be <Result> for each node. This is how it is intended to work. Anne: but what if the <Result> for an interior node is "Deny", but <Result> for one of its children is "Permit"? Is the result for an interior node intended to apply to all its descendants? Michiharu: How to interpret decision returned by PDP may depend on the PEP. But in XML case, need to define specific semantics. Decision is applied only on the specific node associated with the decision, but in XML, that node will actually contain the descendant nodes. So the policy writer has to be careful about writing a policy that is consistent in denying access to a node and all its children. This is application specific. Michiharu will study the proposal further and respond. Adjourned at 11:am EDT. Anne -- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]