Minutes of 12 Feb 2004 Focus Group

[Anne Anderson <Anne.Anderson@Sun.COM>]

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