[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of 12 Feb 2004 Focus Group
Minutes from the 12 February 2004 XACML Focus Group Present: Anne Anderson, Tim Moses, Simon Godik Agenda: Continuing discussing XACML 2.0 work items Note 1: Anne will miss the Feb. 19 TC meeting. On vacation. Note 2: Tim will put out a new draft once ConditionReference is settled. XACML 2.0 Work Items discussed 7. ConditionReference Wait for this item to receive more discussion on the list before trying to resolve this. 9. Policies referring to hierarchical resources RECOMMENDATION: Include items from #42 that actually refer to the policy side. 29. Policy Authority Delegation Should be on the open item list and should be a major topic to be resolved at the next F2F. 31. Attribute Issuer as Subject This really depends on the administrative policy model, which is not settled. This might get resolved at the next F2F. ACTION: request use cases from those interested in this item. Plan to agree on a model at the next F2F. This will require people to do homework ahead of time. 32. Standardize naming to specify rules for requestor's authz policy Why does the naming have to switch? Can't we just agree that the naming used on out-bound policies must be consistent with the naming used on the in-bound policies to which the out-bound policy would apply. This came up in WSPL, and was handled via profile description and specification. Might be like in RPC, where the two sides may have different names for parameters, but they are consistent so long as in same order and same data type. ACTION: need Frank to explain his use case in a teleconference, not just in an e-mail. 36. Check for requester authorized to ask for authz decision One use case here is where a PDP sees a policy reference in its policies, knows there is another PDP that can handle that policy, passes along the Request Context to that PDP and asks for a decision. Another use case is equivalent to passing a policy along with the request to a PDP, and asking for an evaluation based on that policy. We do not currently have a mechanism for passing a policy along with a Request Context. RECOMMENDATION: This should be an aspect of our Administrative Policy, and should be resolved at the next F2F as part of the overall Administrative Policy framework. 37. Multiple <AttributeValue> elements for single <Attribute> in Request Have we addressed all of Rebekah's questions? We think this item is now resolved/closed as in Draft 5, subject to re-opening if Rebekah has another issue. 38. Policies for the Administration of XACML Policies RECOMMENDATION: Close this as duplicate of #29: Policy Authority Delegation. 42. Requests asking for access to multiple elements in a hierarchical resource Note that we already have mechanism for asking for multiple things in a hierarchy from the requesters point of view. That is closed. Still issue on how to handle cases like "read" in a file system requiring "execute" permission on all elements higher in the hierarchy. This belongs under #9. RECOMMENDATION: Close this one. 45. Fix AttributeAssignment example in Section 4.2.4.3 (Rule 3) RECOMMENDATION: Close, since no objections to current draft. 46. Status detail for missing attributes Still awaiting "missing attribute" schema from Seth. Could solve by using AttributeDesignator? Can't use <Attribute>, since it requires a value. May just want to specify AttributeId, Issuer, DataType. RECOMMENDATION: Seth, get busy. 51. Clarify obligations: "fulfill" vs. "understand" Tim has already clarified this in the current draft. RECOMMENDATION: close as fixed in current draft. 52. New section explaining not backwards compatible and listing changes Full text requires resolution of other issues. Bill on the hook eventually. 55. Converge SAML and XACML Attribute schema definitions Need algorithm mapping between SAML Attribute and XACML Attribute. Some issues are keeping Issuer syntax compatible and handling two-part SAML Attribute names (domain plus id) and one-part XACML Attribute. Might be able to handle some of this using AttributeSelector, and inserting SAML Attribute Assertion as AttributeValue with DataType of saml:Assertion or saml:Attribute. 58. Standard hierarchy schemas We need say to associate attributes with each node in the hierarchy. Look at W3C ResourceDescriptionFramework: we don't know if this applies, but the name sounds promising. 59. Define standard "role" subject attribute Add following to Appendix B.5 "Subject attributes": This identifier indicates a role associated with the subject. Values of this attribute SHOULD be of type "http://www.w3.org/2001/XMLSchema#anyURI";. urn:oasis:names:tc:xacml:2.0:subject:role RECOMMENDATION: include in next draft. No objections. 60. Define standard "purpose" attributes In order to deal with certain regulatory requirements, it would be useful to have a standard "purpose" attribute for resource and for action. urn:oasis:names:tc:xacml:2.0:resource:purpose urn:oasis:names:tc:xacml:2.0:action:purpose We could also define a standard rule that requires the resource purpose to include the action purpose. This would enforce the requirement that data resources only be used for the purposes for which they were collected. Issue: purpose should be hierarchical. Policy might have rule saying action-purpose must be "within" resource-purpose. Request might say "action-purpose=legal/anti-discrimination/age-discrimination". Policy might say "action-purpose within legal". Example: provide shipping address to Amazon.com, but allow only for shipping to me. Insist tagged as resource-purpose "marketing/shipping only". Anyone coming to use this resource must have a purpose that Need "Standard Purpose Rule" that will say: action-purpose must be within resource-purpose. i.e. purpose for use must be within the purpose for which it was collected. Purpose for use may be more specific, but must not be more general. This rule would be standard. So should the action-purpose be just the leaf of the hierarchy, or should it be the entire hierarchy? Probably entire hierarchy, since leaf names along different branches of the hierarchy may conflict. Tim will proceed along these lines in developing a concrete proposal. Might want to run this by ISTPA, or get someone there to critique the proposal. Should it be in a privacy profile? Or in 2.0? For now, assume in 2.0 to give people an opportunity to view and critique. -- 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]