[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Minutes of 12 Feb 2004 Focus Group
No, it took 1 and 1/2 hours :-) Anne On 12 February, Polar Humenn writes: Re: [xacml] Minutes of 12 Feb 2004 Focus Group > From: Polar Humenn <polar@syr.edu> > To: Anne Anderson <Anne.Anderson@Sun.COM> > Cc: XACML TC <xacml@lists.oasis-open.org> > Subject: Re: [xacml] Minutes of 12 Feb 2004 Focus Group > Date: Thu, 12 Feb 2004 15:28:15 -0500 (EST) > > > Wow! Did you three discuss all this stuff in a hour? > -Polar > > On Thu, 12 Feb 2004, Anne Anderson wrote: > > > 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 > > > > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php. > > -- 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]