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 XACML TC Meeting 12 June 2003

Minutes of XACML TC Meeting 12 June 2003

Present: Anne Anderson (scribe), Michiharu Kudo, Polar Humenn,
Hal Lockhart, Carlisle Adams, Simon Godik, Daniel Engovatov, Tim

This represents quorum.

1. Minutes from May 29 TC meeting:


2. Request to put links to TC Work Item docs on first page of web

   o DSIG
   o RBAC
   o WSPL Use Cases
   o XACML Webservices
   o Errata

   APPROVED.  Web site maintainer to see what works best.  For
   example, may be able to have a link to "working drafts".
   Current repository is a mish-mash of all types of documents,
   so it is not serving the purpose.

3. New web site maintainer

   Michiharu Kudo would like to be replaced.  Anne volunteered,
   subject to her manager's approval.  Michiharu will communicate
   with Anne about how to work with the web site.

4. Update on RBAC discussion from Focus Group 9 June 2003

   Main points in reviewing APIs in the proposed ANSI standard at

   o CheckAccess is the main API that would be handled by an
   o Issue with APIs that retrieve all permissions associated
     with a User, Role, or Session.  XACML does not define how to
     do this now.  WSPL work shows it is hard.  Need not be an
     interface to the XACML PDP.  Could be done by a separate
     service, such as a "policy analysis service".
   o Proposed ANSI std RBAC APIs too narrow: "AddUser",
     etc. would not be implemented in this form by most systems.
   o "Permission" too narrow

   Mouli (NIST) has action item to describe simpler proposal for
   supporting hierarchical RBAC than is in current draft XACML
   RBAC Profile at

   Next meeting will depend on e-mail activity.  Anne will
   schedule a meeting if things are slowing down.

5. Discussion of Errata Document

   Focus Group 5 June 2003 reviewed document and made
   recommendations.  These recommendations were reviewed and
   voted on by the TC as follows.

  -3.12 <Status> element MAY: include action and environment


  -3.13 <Status> element MUST NOT list action or environment


  -3.14 <AttributeValue> occurrence is inconsistent.

   APPROVED, along with recommendation to also remove
   minOccurs="0" from line 2644 in spec to agree with schema.

  -3.15 Semantics of the <AttributeDesignator> with MustBePresent
   attribute set to "true" is unclear when <Attribute> does not
   contain <AttributeValue>

   VOTED TO DROP AS ERRATUM.  Close reading of specification and
   schema is consistent and as intended: every <Attribute> MUST
   contain an <AttributeValue> since it is not optional, although
   the <AttributeValue> may contain no data (empty value).  An
   empty <AttributeValue> where DataType is inconsistent with an
   empty value is schema invalid.  Where an empty
   <AttributeValue> is consistent with the specified DataType,
   then the bag will contain one member for each such "empty"
   value (it will NOT be an "empty bag"), and there is no
   conflict with "MustBePresent", since the Attribute is present,
   even if the values are "empty values".

  -3.16 MustBePresent attribute semantics for the
   <AttributeSelector> element.

   APPROVED, using status of "processing-error", not
   "missing-attribute" in the place where a question mark occurs.

  -3.17 Unclear how to convert nodes from XPath expression into
   bag of attributes.

   APPROVED Michiharu's proposed solution posted in

   Solution follows:

   This is the draft resolution for errata 3.17: Unclear how to
   convert nodes from XPath expression into bag of
   attributes. The following resolution explicitly states that we
   deals with only simpler cases such as a text node and an
   attribute value which are obvious how to convert those values
   to literals. It does not deal with a node or a set of nodes
   which is much harder to handle.

   Lines 2409--2413 should be replaced with the following:

   Each selected node by the specified XPath expression MUST be
   either a text node, an attribute node, a processing
   instruction node, or a comment node. The string representation
   of the value of each selected node MUST be converted to an
   attribute value of the specified data type, and the result of
   the AttributeSelector is the bag of the attribute values
   generated from all the selected nodes.

   If the selected node is different from the node types listed
   above, then the result of that policy SHALL be "Indeterminate"
   with a StatusCode value of

   Hal: can this error be detected at policy creation time?
   Michiharu: no, this will be a runtime error.

  -3.7 Obligations for the policy.

   VOTED TO DROP AS ERRATUM: Satoshi decided 7.11 was clear on
   closer reading:

  -3.9 <XPathVersion> element

   FOCUS GROUP: Simon will look for discussion of this on the
   list.  No one can remember what the disposition was.


  -Several new errata reported to Michiharu by Jim Fuller, but not
   put on xacml-comment.  Michiharu will forward to xacml-comment.

   ACTION ITEM [Simon]: add these to the errata list as potential errata for

  -Other items in the errata list have probably already been
   disposed, but Simon has not yet found the relevant e-mails.

   ACTION ITEM [ALL]: find any e-mails or minutes that contained
   resolutions to remaining errata.

  -Remaining errata to be subject of discussion at next Focus

6. 1.1 Work Item: Adding Environment to Target

   Simon: posted "Indexing hints" as an alternative to this in

     A simple alternative would be to provide indexing hints in the
     Policy element.  We can define IndexingHints element as a child
     of the Policy element.  It would contain a sequence of attribute
     designators for indexing.

     <xs:complexType name="IndexingHintsType">
     <xs:sequence minOccurs="0" maxOccurs="unbounded">
             <xs:element ref="xacml:SubjectAttributeDesignator"/>
             <xs:element ref="xacml:ResourceAttributeDesignator"/>
             <xs:element ref="xacml:ActionAttributeDesignator"/>
             <xs:element ref="xacml:EnvironmentAttributeDesignator"/>

     <Policy ...>
             <SubjectAttributeDesignator AttributeId="group" .../>
             <ActionAttributeDesignator AttributeId="read" .../>
             <EnvironmentAttributeDesignator AttributeId="purpose" .../>

     If rule contains indexable expression on an attribute specified
     in the indexing hints, rule MAY be indexed.  Indexing rules is
     not a MUST, ie if xacml processor does not index rules it is
     still compliant (but not very fast) processor.

   Michiharu: privacy policy has "purpose" axis, which is
     different from Subject, Resource, or Action.  Would use this
     in Environment, and would like to index on it.  This is a
     specific use case for indexing on environmental attributes.

   Michiharu: Environment in Target would be optional element
     for backwards compatibility.

   Anne: Nice if other elements in Target were also made optional!

   This item to be discussed further at Focus Group on 19 June

7. Election of new co-chair and secretary

   Carlisle leaving Entrust for academic career: joining U. of
   Ottawa 1 August 2003.  Will probably take out individual
   membership and continue contact with XACML, but will be gone
   all summer.

   Hal wants another co-chair.

   Plan: Accept nominations by e-mail (including self-nominations),
   hold vote at 26 June 2003 TC Meeting.

   Secretary's main job is membership.  Minutes have been handled
   on a rotating basis.  Hal says he can do the membership duties
   if no other volunteer arises.

8. WSPL update from Tim.

   Discussion of document attached to
   (WSDL and SOAP bindings for WSPL).

   3 problems to solve in WSPL
   1. How to combine policies: good proposal exists.
   2. How to convey policies via WSDL, SOAP, etc.  Topic for
   3. How to convert a combined policy into instructions for
      creating a conformant message.  Future topic.

   SOAP: consumer might have policy associated with response to
   its request, so might want to include this policy in a SOAP

   WSDL is a description of a service, so policy information
   belongs here.  Relevant objects:
   - Port: equivalent to an object.  Concrete instance of a
     class.  Has name, class.  Equivalent of class is "portType":
     not a specific instance, but a description of a class to
     which ports can conform.
   - portTypes have operations (like OO methods)
   - Message: parameters of a method invocation
     o Input (msg that calls service)
     o Output (msg response from service)
     o Fault (msg you get if method you invoke did not implement

   Different types of policies seem to apply most closely to
   different objects: some to ports, some to operations, or
   portType message.  Trust policies might apply to portType, for

   Frank Siebenlist originally suggested policy to be targetted
   at a portType, rather than at a port.  "I need instance of
   this portType.  Have located an instance.  Need to configure
   myself to use that port: do DNS lookup to get name, etc., get
   policies."  Policy may include subpolicies targetted to
   particular messages or operations.

   Frank Siebenlist now says better to associate policies with
   concrete ports instead of portType.  Polar says CORBA also
   decided to attach policies to object instance, not interface.
   CORBA also has concept of "domains", which are like WSDL
   "service".  No current proposal to attach policies to
   "services": collection of ports that define a service.  Not
   grouped just because they have a common policy.

   Tim wants feedback on proposal to associate policies with
   concrete ports rather than with portType.

   Next topic: names assigned by a consumer may be different from
   names assigned by a provider.  Consequence is that consumer
   must use names chosen by service provider and published in
   WSDL.  If use same service from multiple providers, then
   client policy must be modified for each to use appropriate

   Next point: PolicySet targetted at portType should identify
   portType in its Target.  Issuer of SAML assertion should be
   controller of namespace for portType.

   Auditing: Two types: who created the request (Tim not
   concerned about), and confirming that request was processed
   under appropriate policy (take time, portType submitted to,
   find policy appropriate for portType at that time; should see
   link to policy available from issuer of SAML assertion).

   Tim really wants feedback on everything.  No choices
   completely obvious.

   Anne: Would be helpful if Tim posted an e-mail containing
   outstanding issues.

9. Simon has submitted proposal to use XML Ids instead of
   Condition references, etc.

Adjourned at 11:33am.

 -Focus Group on 19th: Errata list.
 -TC Call on 26th.

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]