[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 Moses This represents quorum. 1. Minutes from May 29 TC meeting: http://lists.oasis-open.org/archives/xacml/200305/msg00054.html APPROVED. 2. Request to put links to TC Work Item docs on first page of web page. 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 http://csrc.nist.gov/rbac/rbac-std-ncits.pdf: o CheckAccess is the main API that would be handled by an XACML PDP. 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 http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/2405/wd-xacml-rbac-profile-01.doc Next meeting will depend on e-mail activity. Anne will schedule a meeting if things are slowing down. 5. Discussion of Errata Document http://lists.oasis-open.org/archives/xacml/200306/msg00001.html 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 attributes. APPROVED. -3.13 <Status> element MUST NOT list action or environment attributes. APPROVED. -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 http://lists.oasis-open.org/archives/xacml/200306/msg00016.html 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 "urn:oasis:names:tc:xacml:1.0:status:syntax-error". DISCUSSION: 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: http://lists.oasis-open.org/archives/xacml/200306/msg00035.html -3.9 <XPathVersion> element FOCUS GROUP: Simon will look for discussion of this on the list. No one can remember what the disposition was. STILL OPEN. -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 discussion. -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 Group. 6. 1.1 Work Item: Adding Environment to Target DISCUSSION: Simon: posted "Indexing hints" as an alternative to this in http://lists.oasis-open.org/archives/xacml/200306/msg00033.html: 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:choice> <xs:element ref="xacml:SubjectAttributeDesignator"/> <xs:element ref="xacml:ResourceAttributeDesignator"/> <xs:element ref="xacml:ActionAttributeDesignator"/> <xs:element ref="xacml:EnvironmentAttributeDesignator"/> </xs:choice> </xs:sequence> </xs:complexType> <Policy ...> <IndexingHints> <SubjectAttributeDesignator AttributeId="group" .../> <ActionAttributeDesignator AttributeId="read" .../> <EnvironmentAttributeDesignator AttributeId="purpose" .../> </IndexingHints> </Policy> 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 2003. 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 http://lists.oasis-open.org/archives/xacml/200306/msg00030.html (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 today. 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 header. 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 correctly) 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 example. 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 names. 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. NEXT MEETINGS: -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]