OASIS eXtensible Access Control Markup Language (XACML) TC

Agenda for XACML TC Meeting on Thursday Oct. 2; 2.0 WorkItems v1.19

  • 1.  Agenda for XACML TC Meeting on Thursday Oct. 2; 2.0 WorkItems v1.19

    Posted 10-01-2003 18:18
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

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


    Subject: Agenda for XACML TC Meeting on Thursday Oct. 2; 2.0 WorkItems v1.19


    The proposed agenda for tomorrow's XACML TC meeting follows.
    
    0. Volunteer to take minutes
    1. Roll call
    2. Agenda bashing
    3. Discussion of opening an on-line ballot for WSPL, possibly
       leading to a vote to open such an on-line ballot.
    4. Review of 2.0 Work Item status changes (current work item list
       attached).  Verbal updates on work in progress accepted :-)
    5. Face-to-Face planning: which 2.0 work items need intense
       discussion?  Start roughing out agenda.
    
    Anne Anderson, designated chair pro tem
    -- 
    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
    
    
    Title:   XACML 2.0 Work Items
    Version: 1.19
    Updated: 03/09/30 (yy/mm/dd)
    
    TEMPLATE FOR PROPOSALS:
      http://lists.oasis-open.org/archives/xacml/200308/msg00028.html
    
    PROPOSALS for non-Abstract work items must be submitted by
       October 20 (XACML F2F) in order for the work item to be
       considered for XACML 2.0.
    
    1. Grid Requirements
    
       Any XACML changes needed to satisfy Grid requirements
    
       TYPE: New functionality
       STATUS: Abstract Work Item.  As specific changes are
          identified, they will become individual work items with
          their own numbers, listed here.
          Current specific work items:
           #2,3,4,16,17,29,30,31,32,33,34,35
       PROPOSAL: Abstract
       CHAMPION: Frank Siebenlist
    
    2. Location Information
    
       Way to pass location information needed to evaluate a policy.
       Examples of such information are:
        o where to find various Attributes,
        o where Attribute Authorities to be used are located
        o where to find function, combining algorithm, data-type,
          Attribute parsing code
       Such information might be embedded in either of
       a. an XACML Request
       b. an XACML policy
    
       TYPE: New functionality
       STATUS: potential work item.  Related: #1,24.
       PROPOSAL:
       CHAMPION: Daniel Engovatov
    
    3. Multiple Actions per Request
    
       Support Requests containing multiple Actions.  Response could
       either say "All permitted/denied" or could include a separate
       decision for each.
    
       TYPE: New functionality
       STATUS: potential work item.  Related item#1
       PROPOSAL:
       CHAMPION: Frank Siebenlist
    
    4. Multiple Resources per Request   
    
       Support Requests containing multiple Resources.  Response
       could either say "All permitted/denied" or could include a
       separate decision for each.
    
       TYPE: New functionality
       STATUS: potential work item.  Related item#1
       PROPOSAL:
       CHAMPION: Frank Siebenlist
    
    5. Privacy Requirements
    
       Any XACML changes needed to satisfy Privacy requirements.
    
       TYPE: New functionality
       STATUS: Abstract Work Item.  As specific changes are
          identified, they will become individual work items with
          their own numbers, listed here.
       PROPOSAL: ABSTRACT
       CHAMPION: ?
    
    6. Domain-specific identifiers
    
       Define a set of domain-specific identifiers based on
       application usage of XACML.
     
       TYPE: New functionality
       STATUS: Postponed from 1.1.
       PROPOSAL:
       CHAMPION: Michiharu Kudo
    
    7. ConditionReference
    
       TYPE: Simplicity of policy construction
       Allow a Rule to contain a ConditionReference element as an
       alternative to a Condition element.  The ConditionReference
       would identify a Condition element specified elsewhere.  An
       optional ConditionId attribute would be added to the Condition
       element to support this.
    
       STATUS: Postponed from 1.1.  Proposal submitted.
       PROPOSAL:
        http://lists.oasis-open.org/archives/xacml/200304/msg00039.html
       CHAMPION: Michiharu Kudo
    
    8. RuleIdReference
    
       Define RuleIdReference analogous to PolicyIdReference and
       PolicySetIdReference.
    
       TYPE: Simplicity of policy construction
       STATUS: Postponed from 1.1.  Related item #19.  Proposal submitted.
       PROPOSAL:
        http://lists.oasis-open.org/archives/xacml/200305/msg00004.html  
       CHAMPION: Michiharu Kudo
    
    9. Hierarchical entities
    
       How to express policies and requests that apply to a hierarchy
       of subjects, resources, or actions.
    
       TYPE: New functionality
       STATUS: Postponed from 1.1. Related item#25.
       PROPOSALS:
        http://lists.oasis-open.org/archives/xacml/200304/msg00057.html
        http://lists.oasis-open.org/archives/xacml/200305/msg00009.html
       CHAMPION: Simon Godik
    
    10. Parameters for Combining Algorithms
    
       Support an element or attribute in a PolicySet, Policy, or Rule
       that provides parameters to be used by a Combining Algorithm
       that is combining the PolicySet, Policy, or Rule.
    
       TYPE: New functionality
       STATUS: Postponed from 1.1.  Proposal submitted.
       PROPOSAL:
         http://lists.oasis-open.org/archives/xacml/200305/msg00014.html
       CHAMPION: Michiharu Kudo
    
    11. XACML Extension Points
    
       Define schema extension points for XACML.  This work item
       might solve the requirements driving several other work
       items.
    
       TYPE: New functionality
       STATUS: potential work item.
       PROPOSAL:
       CHAMPION: Simon Godik
    
    12. Environment Element in Target
    
       Allow the Target Element to include an Environment element,
       just as it now includes Subject, Resource, and Action
       elements.
    
       TYPE: New functionality
       STATUS: Postponed from 1.1.  Proposal submitted.
       PROPOSAL:
        http://lists.oasis-open.org/archives/xacml/200305/msg00012.html
       CHAMPION: Michiharu Kudo
    
    13. Optional Target Elements
    
       Make Subjects, Resources, Actions elements optional in a
       Target.  Missing element has same semantics as <Any.../>
       Make Target itself optional.  Missing element has same
       semantics as a Target containing <AnySubject/>,
       <AnyResource/>, <AnyAction/>.
    
       TYPE: Simplicity of policy construction
       STATUS: potential work item.
       PROPOSAL:
       CHAMPION: ?
    
    14. Signature envelope requirements
    
       Any new XACML work items to meet requirements for signature
       envelopes around an XACML schema instance, such as including
       an XACML Policy or Request in a signed SAML Assertion.
        
       TYPE: New functionality
       STATUS: Abstract Work Item.  As specific changes are
          identified, they will become individual work items with
          their own numbers, listed here.
       PROPOSAL: ABSTRACT
       CHAMPION: ?
       
    15. Encrypted XACML schema instance requirements
    
       Any new XACML work items to meet requirements for encrypted
       XACML Policy or Context schema instances.
    
       TYPE: New functionality
       STATUS: Abstract Work Item.  As specific changes are
          identified, they will become individual work items with
          their own numbers, listed here.
       PROPOSAL: ABSTRACT
       CHAMPION: ?
    
    16. XACML Policy in SAML Response Conditions
    
       Profile uses of XACML Policy instances as a syntax for
       specifying Conditions in a SAML Response.
    
       TYPE: SAML Profile
       STATUS: potential work item.  Related to item#1.
       PROPOSAL:
       CHAMPION: Frank Siebenlist
    
    17. XACML Policy in SAML Request Conditions
    
       Profile use of SAML Conditions element as a way for a PEP to
       pass an XACML Policy to be used by the PDP in evaluating the
       Request.
    
       TYPE: SAML Profile
       STATUS: potential work item.  Related item#30,1.
       PROPOSAL:
       CHAMPION: Frank Siebenlist
    
    18. Obligations in Rules
    
       Allow Rule to contain Obligations.
    
       TYPE: Simplicity of policy construction
       STATUS: postponed from 1.1.  Proposal submitted.
       PROPOSAL:
        http://lists.oasis-open.org/archives/xacml/200305/msg00011.html
       CHAMPION: Michiharu Kudo
    
    19. Rule as lowest administrative unit
    
       Allow a Rule to be the lowest administrative unit for XACML.
       Probably required to support RuleIdReference.
    
       TYPE: New functionality
       STATUS: potential work item.  Related item #8.
       PROPOSAL:
       CHAMPION: Michiharu Kudo
    
    20. Non-normative XACML interpretation guide
    
       Rationale, examples, possible implementation models; general
       information that would help XACML users know the intent of the
       XACML TC for the use of XACML elements.
    
       TYPE: Simplicity of policy construction
       STATUS: potential work item.  Probably parallel to XACML 2.0.
       PROPOSAL:
       CHAMPION: ?
    
    21. Non-normative XACML Primer
    
       Primer for XACML usage.
    
       TYPE: Simplicity of policy construction
       STATUS: potential work item.  Probably parallel to XACML 2.0.
       PROPOSAL:
       CHAMPION: ?
    
    22. time-in-range function
    
       Provide a function for comparing that a time of day is between
       two other times of day.
    
       TYPE: Erratum fix
       STATUS: Proposal submitted.  No open issues.
       PROPOSAL:
        http://lists.oasis-open.org/archives/xacml/200309/msg00005.html
       CHAMPION: Seth Proctor
    
    23. Use XQuery comparison functions for date, time, dateTime
    
       Allow date, time, and dateTime functions to handle comparing a
       value with no time zone with a value with a time zone.
    
       TYPE: Erratum fix
       STATUS: Proposal submitted.
       PROPOSAL:
        http://lists.oasis-open.org/archives/xacml/200307/msg00044.html
       CHAMPION: Seth Proctor
    
    24. Define a schema for function declarations
    
       Define a schema for declaring the signature of a function.
       Probably needed with #2 if #2 includes finding parsing and
       evaluation code for new FunctionIds.
    
       TYPE: New functionality
       STATUS: potential work item.  Related: #2.
       PROPOSAL:
       CHAMPION: Daniel Engovatov
    
    25. Function for comparing file system pathnames.
    
       Define a function for specifying and comparing file system
       pathnames used in resource-id.  Possibly new DataType also.
    
       TYPE: New functionality
       STATUS: Related item#9.  Proposal submitted.  5 open issues.
       PROPOSAL:
        http://lists.oasis-open.org/archives/xacml/200309/msg00088.html
       CHAMPION: Anne Anderson
    
    26. Define policy reduction (partial evaluation) of a policy
    
       Define a process for reducing a policy based on known
       information, leaving only the unresolved predicates.
    
       TYPE: New functionality
       STATUS: potential work item.
       PROPOSAL:
       CHAMPION: Frank Siebenlist
    
    27. Version number element or attribute in an XACML policy.
    
       Some way of indicating the version of a policy having a
       particular XACML policy id, and a way of placing version
       constraints on a policy reference.
    
       TYPE: New functionality
       STATUS: potential work item.
       PROPOSAL:
       CHAMPION: Seth Proctor
    
    28. Define "current time/date/dateTime" during policy evaluation
    
       Specify whether time/date/dateTime are constant over a
       policy evaluation.
    
       TYPE: Erratum fix
       STATUS: Proposal submitted.
       PROPOSAL:
        http://lists.oasis-open.org/archives/xacml/200308/msg00006.html
       CHAMPION: Seth Proctor
    
    29. Policy Authority Delegation
    
       The ability to associate a PDP with a particular target
       domain, and not just with a particular target subject,
       resource, and action.
    
       TYPE: New functionality
       STATUS: Related item#1.  Proposal submitted.
       PROPOSAL: #1 in:
        http://lists.oasis-open.org/archives/xacml/200308/msg00008.html
       CHAMPION: Frank Siebenlist
    
    30. Passing of explicit policy in the Authorization Decision Query
    
       This is the same as #17, except that it is more general
       (i.e. policy from PEP not necessarily passed in SAML
       Conditions), and also explicitly states that the authority to
       specify the policy to use has been delegated to the PEP.
     
       TYPE: SAML Profile
       STATUS: Related item#17,1.  Proposal submitted.
       PROPOSAL: #2 in
        http://lists.oasis-open.org/archives/xacml/200308/msg00008.html
       CHAMPION: Frank Siebenlist
    
    31. Attribute Issuer as Subject
    
       The current attribute issuer type is a string. This
       restriction doesn't allow one to easily point at an issuer as
       Subject, and it doesn't allow for any path validation that
       goes more than one level deep. By allowing an attribute issuer
       of type subject, one could cater for more complex use-cases
       that involve policy delegation.
    
       TYPE: New functionality
       STATUS: Related item#1.  Proposal submitted.
       PROPOSAL: #3 in
        http://lists.oasis-open.org/archives/xacml/200308/msg00008.html
       CHAMPION: Frank Siebenlist
    
    32. Standardize naming to specify rules for requestor's authz policy
    
       Provide way to specify whether the requestor's policy allows the service 
       provider to service the request, possibly by defining
       "provider-subject" SubjectCategory.
    
       TYPE: New functionality
       STATUS: Related item#1.  Proposal submitted.
       PROPOSAL: #4 in
        http://lists.oasis-open.org/archives/xacml/200308/msg00008.html
       CHAMPION: Frank Siebenlist
    
    33. XACML wsdl/porttype definition for <Req>/<Resp> exchange
    
       Abstract the decision request and response messages between
       the context handler and the PDP into a wsdl/porttype
       definition.
    
       TYPE: WSDL Profile
       STATUS: Related item#1.  Proposal submitted.
       PROPOSAL: #5 in
        http://lists.oasis-open.org/archives/xacml/200308/msg00008.html
       CHAMPION: Frank Siebenlist
    
    34. porttype/operations to ask for required attributes
    
       Allow a requester to query the resource's authorization policy
       for the required attributes for a Target such that it "knows"
       which one are missing and would have to be retrieved and
       presented with any request.
    
       TYPE: WSDL Profile
       STATUS: Related item#1.  Proposal submitted.
       PROPOSAL: #6 in
        http://lists.oasis-open.org/archives/xacml/200308/msg00008.html
       CHAMPION: Frank Siebenlist
    
    35. Policy on revealing missing attributes
    
       The returning of the missing attribute info is sensitive
       information and should itself be subject to policy.
    
       TYPE: New functionality
       STATUS: Related item#1.  Proposal submitted.
       PROPOSAL: #7 in
        http://lists.oasis-open.org/archives/xacml/200308/msg00008.html
       CHAMPION: Frank Siebenlist
    
    36. Check for requester authorized to ask for authz decision
    
       The PDP should check whether the requester, i.e. subject associated
       with the context handler,  is allowed to ask for the authorization
       decision. We need to be able to state this in a policy statement,
       and describe the correct operating procedure.
    
       TYPE: New functionality
       STATUS: Related item#1.  Proposal submitted.
       PROPOSAL: 
       CHAMPION: Frank Siebenlist
    
    37. Multiple <AttributeValue> elements for single <Attribute> in Request
    
       Allow
          <Attribute ID=X>
            <AttributeValue>A</AttributeValue>
            <AttributeValue>B</AttributeValue>
            <AttributeValue>C</AttributeValue>
          </Attribute>
       as shorthand for
          <Attribute ID=X>
            <AttributeValue>A</AttributeValue>
          </Attribute>
          <Attribute ID=X>
            <AttributeValue>A</AttributeValue>
          </Attribute>
          <Attribute ID=X>
            <AttributeValue>A</AttributeValue>
          </Attribute>
    
       TYPE: Simplicity of Request construction
       STATUS: Potential work item.  Related item#1
       PROPOSAL:
       CHAMPION: Frank Siebenlist
    
    38. Policies for the Administration of XACML Policies
    
       XACML defines a language to express policies about access to
       resources. But it is also desirable to create policies about
       the creation, modification and deletion of XACML policies. In
       a sense XACML already allows this, since XACML policies are
       agnostic to the semantics of the resources being
       protected. However, it is very desirable for administrative
       policies to specify not the "name" of policies being
       administered, but their "content."
    
       TYPE: New functionality
       STATUS: Proposal submitted.  5 open issues.
       PROPOSAL:
        http://lists.oasis-open.org/archives/xacml/200308/msg00050.html
       CHAMPION: Hal Lockhart
    
    39. Make Status in the XACML Response optional
    
       Makes it possible to allow Status for Indeterminate situations
       to be conveyed in the protocol envelope (such as SAML
       DecisionStatement) rather than in the XACML Response for cases
       where that is more appropriate.  Avoids having redundant and
       possibly inconsistent Status fields when XACML Response is
       carried in some envelope that also has a Status.
    
       TYPE: New functionality
       STATUS: Potential work item.
       PROPOSAL:
       CHAMPION: Hal Lockhart
    
    40. Define a SAML PolicyQuery and PolicyStatement
    
       Define syntax for SAML that will allow a Query for one or more
       Policy or PolicySet instances with specified Policy[Set]Ids,
       and will return the requested instances in a PolicyStatement
       in a SAML Assertion.
    
       TYPE: New functionality.
       STATUS: Potential work item.  May be done in SSTC, and would
         either be in the SAML 2.0 spec or would be in a SAML Profile
         done by the XACML TC.
       PROPOSAL:
       CHAMPION: Hal Lockhart
    


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