Re: [xacml] Minutes of 12 Feb 2004 Focus Group

[Polar Humenn <polar@syr.edu>]

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