OASIS eXtensible Access Control Markup Language (XACML) TC

Revised Minutes of 09 Oct 2003 Focus Group

  • 1.  Revised Minutes of 09 Oct 2003 Focus Group

    Posted 10-15-2003 16:38
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: Revised Minutes of 09 Oct 2003 Focus Group


    [Thanks to Hal for correction]
    
    Minutes from the 9 October 2003 XACML Focus Group
    Revised 15 Oct 2003
    
    ACTION ITEM: [Champions] please re-issue your proposals with any
    issues raised below listed as open issues against your work
    items.
    
    Present: Anne Anderson, Hal Lockhart, Tim Moses
    
    Agenda: Continuing reviewing XACML 2.0 work items to determine
    which ones should be on the agenda for discussion at the XACML
    F2F
    
    Tim mentioned that he is working again on the XACML LDAP
    Profile.  If anyone has comments or suggestions, now would be a
    good time to submit them to the list.
    
    XACML 2.0 Work Item Review
    
    26. Define policy reduction (partial evaluation) of a policy
    
      This was assigned to Frank as a Grid requirement, but at the
      SAML F2F, the working group determined there were existing ways
      to meet the Grid requirement.
    
      This is a candidate for closure unless someone wants to pick it
      up as useful for policy analysis, debugging, etc.
    
      Any takers?  If not, this should not be on the agenda for the
      F2F.
    
      F2F: probably not.
    
    27. Version number element or attribute in an XACML policy
    
      This seems like a reasonable and useful feature.  We did not
      review the actual proposal, but observed that "latest version"
      should be the default.
    
      F2F: no.  Resolve by e-mail
    
    28. Define "current time/date/dateTime" during policy evaluation
    
      The attendees agreed that, assuming no time/date/dateTime
      attribute was included in the PEP's input Request Context, then
      the context handler should retrieve the local
      time/date/dateTime when first needed, use it to populate the
      Request Context, and from then on that same value should be
      used.
    
      This discussion agrees with the proposal.
    
      F2F: no.  Resolve by e-mail
    
    29. Policy Authority Delegation
    
      We had a number of questions about this.  It needs
      clarification.  Issues:
    
      a. Define "domain".  What does it correspond to?
      b. Could this be solved using a subject-domain or
         resource-domain attribute that the PEP should include in its
         Request, and that policies could match on?
    
      Wait for Frank to provide clarification before putting on F2F
      agenda.
    
      F2F: not until/unless Frank clarifies, but then possibly
    
    30. Passing of explicit policy in the Authorization Decision Query
    
      This was discussed at the SAML F2F, and the working group
      decided the Grid requirement could be satisfied using other
      models.  Therefore, this is a candidate for closure.
    
      F2F: no
    
    31. Attribute Issuer as Subject
    
      The attendees had a number of issues with this and feel the
      work item needs a more precise definition.
    
      a. Can this be solved using an XACML policy used by the PDP's
         context handler: Something like 'subject A is allowed to
         perform the "issue" certificate action on resource "subject
         B" or resources with attribute "name-domain" = B'
      b. Is this mainly an issue of aligning SAML and XACML syntax?
      c. Does an authentication chain really belong in the resource
         policy?  Isn't it a separate policy?
    
      F2F: not unless clarified, then possibly
    
    32. Standardize naming to specify rules for requestor's authz policy
    
      Again, clarification is needed.
    
      a. What entity is the "requestor"?  The PEP?  We don't usually
         think of a "requestor" having its own policy...
      b. Would this perhaps be a Grid Profile for Use of XACML?
      c. XACML already allows new SubjectCategory values to be
         defined simply by defining a new urn.  Grid could define
         such a urn.
    
      F2F: not unless clarified, then possibly
    
    33. XACML wsdl/porttype definition for <Req>/<Resp> exchange.
    
      This should probably be in a profile for use of WSDL with
      XACML, which could be independent of XACML 2.0.  It is a
      reasonable and useful thing to do.
    
      F2F: no.
    
    34. porttype/operations to ask for required attributes
    
      This requires a new, undefined interface to XACML and the
      functionality of that interface is not in the scope of the
      existing XACML specs.  WSPL covers it, but not XACML 1.0/1.1.
      It would be possible to return the Distributive Normal Form for
      a policy (which specifies sets of attribute name/value pairs
      that are sufficient to satisfy a given policy) as described in
      one of Anne's early WSPL submissions.
    
      The XACML Response Context area designed for returning
      Attributes that are missing might be used with this.
    
      This operation is not satisfied by a SAML AttributeQuery, since
      an AttributeQuery is designed to return a set of Attributes
      that have actually been issued to a given Subject.  #34 wants a
      list of Attributes that would be needed.
    
      F2F: no.
    
    35. Policy on revealing missing attributes
    
      We discussed this superficially, but discussion not conclusive.
    
    35. Check for requester authorized to ask for authz decision
    
      Comment that XACML may be used already for this as a policy
      used by the context handler or entity that handles the
      authentication layer around an XACML Request/Response
      transaction.  Discussion not concluded.
    
    That is as far as we got.
    
    Anne
    -- 
    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]