OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: Open 2.0 work items

Here are the XACML 2.0 work items that are still open as of today
(pre-TC meeting):

7. ConditionReference

   Allow a Rule to contain a ConditionReference element as an
   alternative to a Condition element.  The ConditionReference
   would identify a Condition element specified elsewhere.  This
   allows a single Condition to be re-used in Rules under
   different Targets.  An optional ConditionId attribute would be
   added to the Condition element to support this.

   TYPE: Simplicity of policy construction.
   STATUS: Accepted in general for 2.0 13 Nov 2003.  Michiharu,
    Polar, and Seth will develop final proposal via email.
    http://lists.oasis-open.org/archives/xacml/200304/msg00039.html [use cases]
    http://lists.oasis-open.org/archives/xacml/200312/msg00045.html [Michiharu:summary]
    http://lists.oasis-open.org/archives/xacml/200401/msg00022.html [Bill: summary]
    http://lists.oasis-open.org/archives/xacml/200401/msg00035.html [Michiharu:detailed]
   CHAMPION: Michiharu Kudo

11. XACML Extension Points

   Define schema extension points for XACML.  This work item
   might solve the requirements driving several other work

   TYPE: New functionality
   STATUS: Waiting proposal from Simon as of 8 Jan 2004  Used as solution for #10.
    for information that may be relevant.
   PROPOSAL: Waiting proposal from Simon.
   CHAMPION: Simon Godik and 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: No issues. In 2.0 draft.  Needs actual vote.
   CHAMPION: Hal Lockhart

18. Obligations in Rules

   Allow Rule to contain Obligations.

   TYPE: Simplicity of policy construction
   STATUS: Open issues.
   CHAMPION: Michiharu Kudo

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: Approved in general 30 Oct 2003.  8 Jan 2004: Seth to
     consult on new XML Schema time values.
    http://lists.oasis-open.org/archives/xacml/200312/msg00061.html [Status update]
   CHAMPION: Seth Proctor

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: Open issues.  Related: #1,29,31,35,38.
    http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #3
    http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #31
   CHAMPION: Frank Siebenlist

32. Standardize naming to specify rules for requestor's authz policy

   In a setting where a requester invokes certain operations of a
   service provider, the convention for the target of the service
   provider's policy is well defined: subject=requester,
   resource=service-provider, and action=operation.  However,
   when we consider the policy evaluation on the requester's side
   to check whether an invocation on the service provider is
   allowed according to the requester's policy, then is it less
   clear.  It is almost a mirror case, but if we take a
   convention where the "resource" is the one protected by the
   policy, the we should equate subject=service-provider and
   resource=requester with the same action=operation.
   Unfortunately, if we also have to consider the possibility
   that the service-provider can invoke an equivalent operation
   on the requester, then we need an additional way to
   discriminate between these cases.  Maybe we can label the
   action with a category of "out-bound" (?).

   TYPE: New functionality
   STATUS: Open issues.  Related: #1,29,31,35,38.
    http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #4
    http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #32
    http://lists.oasis-open.org/archives/xacml/200310/msg00042.html #32
   CHAMPION: Frank Siebenlist

36. Check for requester authorized to ask for authz decision

   Proposes that the PDP have a formally defined access control
   mechanism to "downstream PDPs".

   The PDP should check whether the upstream PDP 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: Open issues.  Related: #1,29,30,31,35,38.
    http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #36
    http://lists.oasis-open.org/archives/xacml/200310/msg00074.html #36 on 20 Oct 2003
   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: Open issues. Related: #1,29,31,35,38.
    http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #38
   CHAMPION: Hal Lockhart

42. Requests asking for access to multiple elements in a hierarchical resource

   How to express requests that ask for access to multiple
   elements in a hierarchical resource, i.e. "Does Frank have
   access to all elements under /X/Y?".

   XACML currently defines a standard Resource AttributeId
   "urn:oasis:names:tc:xacml:1.0:resource:scope" that can be used
   to express whether a request applies to "Immediate",
   "Children", or "Descendents".  XACML also currently defines a
   way to include an XML document in a <ResourceContent> element
   as part of a Request.  This is sufficient if all hierarchies
   are assumed to be XML documents and if the document itself is
   always included in <ResourceContent> when multiple decisions
   are requested.

   What is missing is a way of handling hierarchical resources
   that are not XML documents, such as file system directories.
   To handle other types of hierarchies, it will be necessary to
   identify what type of hierarchy the resource is and, in a
   related profile, what syntax is to be used in expressing and
   referring to nodes and elements in hierarchies of that type.

   Proposal 200310/msg00078.html proposes to solve this by
   requiring all hierarchical resources to be represented and
   referenced as XML instances using XPath expressions.  If this
   is accepted, then the specification needs to state this

   TYPE: New functionality.
   STATUS: Accepted in general for 2.0 30 Oct 2003.  Needs to 
     be explained in specification in non-normative Hierarchical
     Resources section.  Resolution is: supply resource hierarchy
     in XML representation in <ResourceContent>.
     Related: #9,25,42.
   CHAMPION: Simon Godik

43. Examine interactions between approved work items

   As part of the editorial process, a check is needed to ensure
   that there are no unexpected problematic interactions between
   approved work items.

   TYPE: Editorial
   STATUS: Open issues

46. Status detail for missing attributes

   In 6.15 there is an explanation for what detail to include
   with the missing-attribute status code: Attributes specify one
   or more missing values, and if an AttributeValue is included,
   then this specifies an acceptable value. If no AttributeValue
   is included, then the PDP is specifying the identifier and
   datatype only. Sounds good.

   The problem is that the Attribute type is

      <xs:element ref="xacml-context:AttributeValue"/>

   This means that it's not valid to have an Attribute with no
   AttributeValue. So, it's not possible for the PDP to specify a
   missing attribute without specifying at least one acceptable
   value (note that even an empty AttributeValue tag, which is
   still legal, is still technically a value).  PDPs need a way
   to specify missing attributes without providing acceptable

   TYPE: Erratum
   STATUS: Need to define a new "missing attribute" schema
     element that can return attribute meta-data (with or without
     Attribute Value information) for this.  Accepted in general
     30 Oct 2003.
   CHAMPION: Seth Proctor

51. Clarify obligations: "fulfill" vs. "understand"


   Intermixed uses of "fulfill" and "understand" with respect to
   obligations semantics is confusing.  For example, "what is the
   recommended action for an obligation that is understood yet is
   unable to be fulfilled?"

   TYPE: Erratum
   STATUS: Awaiting detailed proposal.
   PROPOSAL: http://lists.oasis-open.org/archives/xacml/200311/msg00059.html
   CHAMPION: Michiharu Kudo

52. New section explaining not backwards compatible and listing changes

   The XACML 2.0 specification should have a new section that
   explains 2.0 is not backwards compatible with 1.0 or 1.1, and
   listing the changes made between 1.0 (and/or 1.1) and 2.0.

   TYPE: Editorial
   STATUS: Awaiting detailed proposal.
   CHAMPION: Bill Parducci

55. Converge SAML and XACML Attribute schema definitions

   TYPE: Interoperability
   STATUS: Open.  Still under discussion.
    http://www.oasis-open.org/apps/org/workgroup/security/download.php/4884/draft-sstc-attribute-02.pdf [Rebekah SAML proposal]
    http://lists.oasis-open.org/archives/xacml/200401/msg00031.html [Anne]
    http://lists.oasis-open.org/archives/xacml/200401/msg00032.html [Anne]
    http://lists.oasis-open.org/archives/xacml/200401/msg00034.html [Scott Cantor]
    http://lists.oasis-open.org/archives/xacml/200401/msg00039.html [SAML/XACML]
   CHAMPION: Rebekah Lepro

58. Standard hierarchy schemas

   Given resolution to hierarchical resources in WI#9, there
   needs to be a standard schema for certain common hierarchies
   such as UFS.

   TYPE: Interoperability.  Could be separate profile.
   STATUS: Open
   CHAMPION: Anne Anderson (for UFS and WFS)

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


   TYPE: Interoperability.
   STATUS: Detailed proposal available
   CHAMPION: Anne Anderson 

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]