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:
> 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.
>
