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: 2.0 Work Item List, v1.26


Updated 2.0 Work Item list is attached.  This reflects 13 Nov
2003 TC meeting and e-mail submissions up to then.

Summary of changes since previous list:

7. ConditionReference

  General proposal now accepted.  Waiting for the specific
  line-by-line specification changes.
  
11. XACML Extension Points

  Now includes link to W3C document that may be relevant to
  developing a proposal for this item.  
  46. Status detail for missing attributes
  
NEW ITEM (should Seth be champion, or Michiharu?):

49. Improve example showing how obligations work

   The example in Section 4.2.4.3 is somewhat misleading and has
   caused confusion among XACML users.  See PROPOSAL for specific
   points.

   TYPE: Erratum
   STATUS: Waiting for more specific proposal.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200311/msg00009.html
   CHAMPION: Michiharu Kudo

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

Title:   XACML 2.0 Work Items
Version: 1.26
Updated: 03/11/13 (yy/mm/dd)

TEMPLATE FOR PROPOSALS:
  http://lists.oasis-open.org/archives/xacml/200308/msg00028.html

STATUS CODES:
 Needs proposal.
   No proposal submitted.  Will be dropped from 2.0 work item
   list unless proposal submitted by 20 October 2003.
 Needs detailed proposal.
   Proposal submitted, and no open issues.  Proposal needs a
   detailed solution before a vote.
 Open issues.
   Proposal available, but there are open issues.
 Ready for vote.
   Detailed proposal available.  No open issues.
 Closure candidate.
   May be closed, based on discussion to date.
 Abstract.
   Not a work item itself, but a category for specific items.

1. Grid Requirements

   Any XACML changes needed to satisfy Grid requirements

   TYPE: New functionality
   STATUS: Abstract. Related: #2,3,4,16,17,29,30,31,32,33,34,35,36,37
   PROPOSAL: Abstract
   CHAMPION: Frank Siebenlist

2. Location Information

   Way to pass information needed to configure a PDP and its
   context and policy handlers/finders in order to evaluate a
   policy.

   Examples of such information are:
    o where to find various Attributes, and what they are keyed off
    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
   a. an XACML Request
   b. an XACML policy
   c. a third document type

   TYPE: New functionality
   STATUS: Open issues. Waiting for revised proposal from Seth. Related: #1,24.
   PROPOSAL:
     http://lists.oasis-open.org/archives/xacml/200310/msg00022.html
   CHAMPION: Seth Proctor

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: Closed: no proposal submitted by 20 Oct 2003.  Related: #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: Closed: no proposal submitted by 20 Oct 2003.  Related: #1.
   PROPOSAL:
   CHAMPION: Frank Siebenlist

5. Privacy Requirements

   Any XACML changes needed to satisfy Privacy requirements.

   TYPE: New functionality
   STATUS: Closed for XACML 2.0.  Abstract.  Related: <none>
   PROPOSAL: ABSTRACT
   CHAMPION: ?

6. Domain-specific identifiers

   Define a set of domain-specific identifiers based on
   application usage of XACML.
 
   TYPE: New functionality
   STATUS: Closed: no proposal submitted by 20 Oct 2003.
   PROPOSAL:
   CHAMPION: Michiharu Kudo

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.  Waiting for 
    detailed changes.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200304/msg00039.html
    http://lists.oasis-open.org/archives/xacml/200311/msg00010.html
   CHAMPION: Michiharu Kudo

8. RuleIdReference

   Define RuleIdReference analogous to PolicyIdReference and
   PolicySetIdReference.

   TYPE: Simplicity of policy construction
   STATUS: Closed 20 Oct 2003.  Can do this now with a Policy
    containing a single Rule.  Related #19.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200305/msg00004.html  
   CHAMPION: Anne Anderson (on behalf of ebXML)

9. Policies referring to hierarchical resources

   How to express policies that apply to a hierarchy of
   resources.  E.g. "Frank can read any file under directory
   /X/Y".

   TYPE: New functionality
   STATUS: Open issues.  Related: #25,42.  Some people want all
     mapped to XML; others want specific functions or something
     else for various specific types of hierarchies (e.g. ufs, 
     urls).
   PROPOSALS:
    OLD: http://lists.oasis-open.org/archives/xacml/200304/msg00057.html
    OLD: http://lists.oasis-open.org/archives/xacml/200305/msg00009.html
    CURRENT: http://lists.oasis-open.org/archives/xacml/200310/msg00078.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: Closed 21 Oct 2003.  Will do this via extension points #11.
   PROPOSAL:
     OLD: http://lists.oasis-open.org/archives/xacml/200305/msg00014.html
     CURRENT: http://lists.oasis-open.org/archives/xacml/200310/msg00079.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: Needs proposal by 20 Nov 2003.  Used as solution for #10.
    See
    http://lists.oasis-open.org/archives/xacml/200310/msg00098.html
    for information that may be relevant.
   PROPOSAL:
   CHAMPION: Simon Godik and Michiharu Kudo.

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: Vote to accept for 2.0 on 21 Oct 2003.
   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: No issues. Needs detailed proposal.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200310/msg00038.html
   CHAMPION: Hal Lockhart

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: Closed for XACML 2.0.  Abstract.  Related: <none>
   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: Closed for XACML 2.0.  Abstract.  Related: <none>
   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: Closed for XACML 2.0: no proposal by 20 Oct 2003.
   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: Closed for XACML 2.0: no proposal by 20 Oct 2003.
   PROPOSAL:
   CHAMPION: Frank Siebenlist

18. Obligations in Rules

   Allow Rule to contain Obligations.

   TYPE: Simplicity of policy construction
   STATUS: Open issues.
   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: Closed for 2.0 20 Oct 2003.  No proposal.  Related #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: New document not tied to XACML 2.0.
   STATUS: Needs proposal.  Not part of 2.0.
   PROPOSAL:
   CHAMPION: ?

21. Non-normative XACML Primer

   Primer for XACML usage.

   TYPE: New document not tied to XACML 2.0.
   STATUS: Needs proposal.  Not part of 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: Approved in general 30 Oct 2003.  Needs detailed proposal.
   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: Approved in general 30 Oct 2003.  Needs detailed
     proposal.  Need to have new names if these are not
     functionally backwards compatible and should be additional,
     with old functions deprecated in 2.0.
   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: Closed for 2.0: no proposal by 20 Oct 2003.  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: Closed for 2.0: handle per #9 proposal.
   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.  The
   reduced policy is returned along with the context with which
   the reduction was done.

   TYPE: New functionality
   STATUS: Closed for 2.0 20 Oct 2003.  Use case requirement
    satisfied using a different model.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200310/msg00080.html
   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: No open issues.  Needs detailed proposal.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200310/msg00058.html
   CHAMPION: Seth Proctor

28. Define "current time/date/dateTime" during policy evaluation

   Specify whether time/date/dateTime are constant over a
   policy evaluation.  Proposal is that it be constant.

   TYPE: Erratum fix
   STATUS: Approved in general 30 Oct 2003.  Needs detailed proposal.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200308/msg00006.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #28
   CHAMPION: Seth Proctor

29. Policy Authority Delegation

   The ability to express in a policy rule that a certain
   authorization authority is allowed to administer access
   control policy for a certain target: i.e. way to say "Frank is
   trusted to issue policies for resource X".  If the PDP trusts
   the policy rule that states this, then the PDP would also
   trust policies issued by Frank for resource X.

   TYPE: New functionality
   STATUS: Open issues.  Related: #1,29,31,35,38.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #1
    http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #29
    http://lists.oasis-open.org/archives/xacml/200310/msg00042.html #29
    http://lists.oasis-open.org/archives/xacml/200310/msg00046.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00053.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00054.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00060.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00061.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00062.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00063.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: Closed for 2.0 21 Oct 2003.  See #17.  Solve by making
     remote PAP accessible to the local PDP.  Possibly related: #29,38.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #2
    http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #30
   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: Open issues.  Related: #1,29,31,35,38.
   PROPOSAL:
    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.
   PROPOSAL:
    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

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: Needs detailed proposal.  Related: #1.  Not part of 2.0.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #5
    http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #33
   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: Open issues.  Related: #1.  Not part of 2.0.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #6
    http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #34 
   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: Closed for 2.0 21 Oct 2003.  Related: #1,29,31,35,38.
    Can be solved using existing XACML policies.
   PROPOSAL:
    OLD: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #7
    CURRENT: http://lists.oasis-open.org/archives/xacml/200310/msg00081.html
   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.
   PROPOSAL: 
    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

37. Multiple <AttributeValue> elements for single <Attribute> in Request

   Allow

      <Attribute DataType="Y" ID=X>
        <AttributeValue DataType="Y">A</AttributeValue>
        <AttributeValue DataType="Y">B</AttributeValue>
        <AttributeValue DataType="Y">C</AttributeValue>
      </Attribute>

   as syntactic shorthand for

      <Attribute DataType="Y" ID=X>
        <AttributeValue DataType="Y">A</AttributeValue>
      </Attribute>
      <Attribute  DataType="Y" ID=X>
        <AttributeValue DataType="Y">B</AttributeValue>
      </Attribute>
      <Attribute DataType="Y" ID=X>
        <AttributeValue DataType="Y">C</AttributeValue>
      </Attribute>

   This makes it easier to convert SAML Attributes into XACML
   Attributes, and is consistent with the way XPath treats the
   same set of AttributeValues.

   TYPE: Simplicity of Request construction
   STATUS: Approved as "OK idea" at 21 Oct 2003 F2F.  Needs detailed proposal.  Related: #1.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #37
   CHAMPION: Rebekah Lepro

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.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200308/msg00050.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #38
    http://lists.oasis-open.org/archives/xacml/200310/msg00054.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: Accepted in general for 2.0 30 Oct 2003.  Needs 
     detailed proposal.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #39
    http://lists.oasis-open.org/archives/xacml/200310/msg00040.html
   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 or
   with copy of a Request Context that need to be matched, and
   will return the requested instances in a PolicyStatement in a
   SAML Assertion.

   TYPE: XACML Profile for Using SAML
   STATUS: Related to #48.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200310/msg00031.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00032.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00034.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00036.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #40
   CHAMPION: Hal Lockhart

41. General attribute classifications instead of Subject, Resource, ...

   Instead of using the fixed attribute classifications
   "Subject", "Resource", "Action", and "Environment", allow
   arbitrary attribute classifications to be used, each
   identified by a URN and associated with a profile that
   explains its use and semantics.

   TYPE: New functionality.
   STATUS: Needs proposal.  Due by 3 Nov 2003.  Related: #2,24.
   PROPOSAL:
   CHAMPION: Daniel Engovatov

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

   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.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200310/msg00078.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00082.html
   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
   PROPOSAL: ?
   CHAMPION: ?

44. Fix examples in the XACML Specification

   Review & correct all examples before the 2.0 release.

   TYPE: Editorial
   STATUS: Abstract.  Related: #45.
   PROPOSAL:  Abstract
   CHAMPION:

45. Fix AttributeAssignment example in Section 4.2.4.3 (Rule 3)

   In this example, AttributeAssignments contain
   AttributeSelectors and AttributeDesignators. While this isn't
   illegal, the example implies something about the specification
   that isn't true (ie, that the PDP will interpret the contents
   of assignments).

   TYPE: Editorial
   STATUS: Needs detailed proposal.  Related: #44.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200310/msg00064.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00067.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00068.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00069.html 
   CHAMPION: Michiharu Kudo

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

   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.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200310/msg00076.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00077.html
   CHAMPION: Seth Proctor

47. New SAML Authorization Decision Query/Response using XACML

   TYPE: XACML Profile for Using SAML
   STATUS: SAML accepts XACML/OGSA proposal in general (link),
    but says XACML should define a SAML extension using the
    SAML namespace.  We need to verify that SAML 2.0 changes
    do not invalidate our proposal.  Only Sun(?), Oblix, and 
    Entrust seem to use the SAML 1.0 version, so will be 
    deprecated in SAML 2.0.
   PROPOSAL: (find link)
   CHAMPION: Anne Anderson and Hal Lockhart

48. PAP Interface to a PDP/PRP

   Define an interface to a PDP or PRP (Policy Repository Point)
   from a PAP for pushing and/or managing policies.

   TYPE: XACML Interface Definitions Specification
   STATUS: Related to #38,40.  Requirements spec needed.
   PROPOSAL:
   CHAMPION: Tim Moses

49. Improve example showing how obligations work

   The example in Section 4.2.4.3 is somewhat misleading and has
   caused confusion among XACML users.  See PROPOSAL for specific
   points.

   TYPE: Erratum
   STATUS: Waiting for more specific proposal.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200311/msg00009.html
   CHAMPION: Michiharu Kudo


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