OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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

  Anne Anderson
  Hal Lockhart
  Ed Coyne
  Michiharu Kudo


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

   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

   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

   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 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]