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: Updated XACML 2.0 Work Item Index, Version 1.46


Summary of items still open for 2.0.  Final text for open items
due 5 April 2004.

WI#7. ConditionReference
   Need to reach consensus

WI#9. Policies referring to hierarchical resources
   Action for Anne to develop better proposal

WI#18. Obligations in Rules
   Need to reach consensus: require eval of entire tree or close?

WI#23. Use XQuery comparison functions for date, time, dateTime
   Action for Seth

WI#29. Policy Authority Delegation
   Read Use Cases.  Discuss at F2F.

WI#31. Attribute Issuer as Subject
   Discuss at F2F.

WI#32. Standardize naming to specify rules for requestor's authz policy
   Action for Frank to explain use case in teleconference.

WI#36. Check for requester authorized to ask for authz decision
   Discuss at F2F.

WI#37. Multiple <AttributeValue> elements for single <Attribute> in Request
   Tim: additional edits included in Draft 7?

WI#43. Examine interactions between approved work items
   Has to wait for final draft.

WI#46. Status detail for missing attributes
   Action for Seth to define MissingAttribute element.

WI#52. New section explaining not backwards compatible and listing changes
   Has to wait for final draft.

WI#53. Drop <Function> element
   Tim: additional "clarifying text" added in Draft 7?

WI#55. Converge SAML and XACML Attribute schema definitions
   Discuss SSTC dropping ValueType.  Waiting for SAML 2.0
   decisions.

WI#58. Standard hierarchy schemas
   Action for Anne to develop better proposal.

WI#62. New string functions
   Action for anyone interested to find standard function
   definitions.

WI#63. Remove "IssueInstant" XML attribute
   Tim: removed in Draft 7?

WI#65. Add additional layer of aggregation to XACML attribute naming
   To be discussed in TC; also waiting for SAML decision.

WI#66. Add IP address match functions
   Action for Anne to provide proposal for functions.

WI#67. Add "IssuerNameFormat" XML attribute to Attribute[Designator]
   Not yet discussed in TC meetings.

WI#68.  Attribute assertion lifetime
   Not yet discussed in TC meetings.

WI#69.  AttributeAssignment clarification
   Not yet discussed in TC meetings.

WI#70.  Legal values for string DataType
   Not yet discussed in TC meetings.

Full index attached.

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.46
Updated: 04/03/31 (yy/mm/dd)

CURRENT 2.0 DRAFT:
  http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/6021/oasis-xacml-2.0-core-spec-wd-07.zip
THIS WORK ITEM INDEX INCLUDES E-MAILS UP THROUGH:
  http://lists.oasis-open.org/archives/xacml/200403/msg00139.html
--------------------------------------------------------------------
Open for 2.0:
WI#7. ConditionReference
   Need to reach consensus
WI#9. Policies referring to hierarchical resources
   Action for Anne to develop better proposal
WI#18. Obligations in Rules
   Need to reach consensus: require eval of entire tree or close?
WI#23. Use XQuery comparison functions for date, time, dateTime
   Action for Seth
WI#29. Policy Authority Delegation
   Read Use Cases.  Discuss at F2F.
WI#31. Attribute Issuer as Subject
   Discuss at F2F.
WI#32. Standardize naming to specify rules for requestor's authz policy
   Action for Frank to explain use case in teleconference.
WI#36. Check for requester authorized to ask for authz decision
   Discuss at F2F.
WI#37. Multiple <AttributeValue> elements for single <Attribute> in Request
   Tim: additional edits included in Draft 7?
WI#43. Examine interactions between approved work items
   Has to wait for final draft.
WI#46. Status detail for missing attributes
   Action for Seth to define MissingAttribute element.
WI#52. New section explaining not backwards compatible and listing changes
   Has to wait for final draft.
WI#53. Drop <Function> element
   Tim: additional "clarifying text" added in Draft 7?
WI#55. Converge SAML and XACML Attribute schema definitions
   Discuss SSTC dropping ValueType.  Waiting for SAML 2.0
   decisions.
WI#58. Standard hierarchy schemas
   Action for Anne to develop better proposal.
WI#62. New string functions
   Action for anyone interested to find standard function
   definitions.
WI#63. Remove "IssueInstant" XML attribute
   Tim: removed in Draft 7?
WI#65. Add additional layer of aggregation to XACML attribute naming
   To be discussed in TC; also waiting for SAML decision.
WI#66. Add IP address match functions
   Action for Anne to provide proposal for functions.
WI#67. Add "IssuerNameFormat" XML attribute to Attribute[Designator]
   Not yet discussed in TC meetings.
WI#68.  Attribute assertion lifetime
   Not yet discussed in TC meetings.
WI#69.  AttributeAssignment clarification
   Not yet discussed in TC meetings.
WI#70.  Legal values for string DataType
   Not yet discussed in TC meetings.

--------------------------------------------------------------------
WI#1. Grid Requirements

   Any XACML changes needed to satisfy Grid requirements

   STATUS: Abstract
   RELATED: #2,3,4,16,17,29,30,31,32,33,34,35,36,37
   CHAMPION: Frank Siebenlist

WI#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

   TARGET: Location Information Profile
   TYPE: New functionality
   STATUS: Open, but not for 2.0; issues; see ACTION.
   RELATED: #1,24.
   PROPOSAL:
     http://lists.oasis-open.org/archives/xacml/200310/msg00022.html
     http://lists.oasis-open.org/archives/xacml/200402/msg00084.html [TC discussion]
   CHAMPION: Seth Proctor

   ACTION [Seth]: need revised proposal.

WI#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 for 2.0: no proposal submitted by 20 Oct 2003
   RELATED: #1.
   CHAMPION: Frank Siebenlist

WI#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 for 2.0: no proposal submitted by 20 Oct 2003.
   RELATED: #1.
   CHAMPION: Frank Siebenlist

WI#5. Privacy Requirements

   Any XACML changes needed to satisfy Privacy requirements.

   TARGET: XACML Privacy Profile
   TYPE: New functionality
   STATUS: Abstract.
   RELATED: WI#60
   CHAMPION: Tim Moses, Anne Anderson

WI#6. Domain-specific identifiers

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

WI#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: Open for 2.0.  Need consensus on final proposal.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200304/msg00039.html [use cases]
    http://lists.oasis-open.org/archives/xacml/200403/msg00048.html [Text and schema-Polar]
    http://lists.oasis-open.org/archives/xacml/200403/msg00062.html [Text and schema-Simon]
    http://lists.oasis-open.org/archives/xacml/200403/msg00068.html [Tim: keep <Condition>]
    http://lists.oasis-open.org/archives/xacml/200403/msg00071.html [Simon: agrees]
    http://lists.oasis-open.org/archives/xacml/200403/msg00074.html [Polar: compromise]
    http://lists.oasis-open.org/archives/xacml/200403/msg00083.html [Polar agrees with Tim]
    http://lists.oasis-open.org/archives/xacml/200403/msg00084.html [Polar:type checking]
    http://lists.oasis-open.org/archives/xacml/200403/msg00101.html [Tim:alt. to Simon]
    http://lists.oasis-open.org/archives/xacml/200403/msg00107.html [Simon:var close to rule]
    http://lists.oasis-open.org/archives/xacml/200403/msg00110.html [Expression final]
    http://lists.oasis-open.org/archives/xacml/200403/msg00113.html [Expression not final]
    http://lists.oasis-open.org/archives/xacml/200403/msg00114.html [Placement:leave as is]
   CHAMPION: Michiharu Kudo

WI#8. RuleIdReference

   Define RuleIdReference analogous to PolicyIdReference and
   PolicySetIdReference.

   TYPE: Simplicity of policy construction
   STATUS: Closed for 2.0 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)

WI#9. Policies referring to hierarchical resources

   [This is different from WI#42.  WI#42 is about how a single
   request can ask for access to multiple nodes in a hierarchy,
   getting back multiple responses (which XACML already
   supports).  This item is about how a policy can protect all
   nodes in a subtree of a hierarchy without having to specify a
   separate policy condition for each.]

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

   TYPE: New functionality
   STATUS: Open for 2.0.  CURRENT proposal below accepted for 2.0
    8 Jan 2004, but see newer OPEN ISSUE below.  See ACTION.
   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
    http://lists.oasis-open.org/archives/xacml/200312/msg00050.html [need std hier. schema]
    http://lists.oasis-open.org/archives/xacml/200312/msg00059.html [Anne to Rob Grzywinski]
    http://lists.oasis-open.org/archives/xacml/200401/msg00070.html [Bob Daly]
    http://lists.oasis-open.org/archives/xacml/200402/msg00000.html [Bill to Bob]
   CHAMPION: Simon Godik

   OPEN ISSUE: how to handle cases like "read" in a file system
   requiring "execute" permission on all elements higher in the
   hierarchy.

   ACTION [Anne]: look at WS-ResourceFramework to see if it
    addresses hierarchical resources.  Otherwise, revise CURRENT.

WI#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.
   [This was discussed under WI#11 for a while, but was moved
   back to WI#10 12 Feb 2004 because proposed solution was
   specific to combining algorithm parameters].

   TYPE: New functionality
   STATUS: Open.  Need consensus on proposal.  See ACTIONs.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200402/msg00012.html [Simon]
    http://lists.oasis-open.org/archives/xacml/200402/msg00016.html [Michiharu/Simon]
    http://lists.oasis-open.org/archives/xacml/200402/msg00022.html [Polar/Michiharu]
    http://lists.oasis-open.org/archives/xacml/200402/msg00028.html [Michiharu/Polar]
    http://lists.oasis-open.org/archives/xacml/200402/msg00032.html [Polar/Michiharu]
    http://lists.oasis-open.org/archives/xacml/200402/msg00039.html [TC discuss]
    http://lists.oasis-open.org/archives/xacml/200402/msg00043.html [Michiharu/Polar]
    http://lists.oasis-open.org/archives/xacml/200403/msg00125.html [Michiharu:summary]
    http://lists.oasis-open.org/archives/xacml/200403/msg00133.html [Polar:mult.params?]
    http://lists.oasis-open.org/archives/xacml/200403/msg00137.html [Michiharu to Polar]
   CHAMPION: Michiharu Kudo

   ACTION [Tim]: see if enough information in current proposal to
    include in next draft.

   ACTION [Michiharu; 4 March 2004]: summarize discussion between
    Michiharu and Polar and post message within a week.  Will be
    discussed and approved at next TC meeting.

WI#11. XACML Extension Points

   Define schema extension points for XACML.  See
   http://lists.oasis-open.org/archives/xacml/200310/msg00098.html
   for information that may be relevant on extension points.
       
   TYPE: New functionality
   STATUS: Closed for 2.0 on 12 Feb 2004.  Any extension points
    should be for specific functionality, not general extensions
    that might become "kitchen sink" elements.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200402/msg00039.html [TC discuss]
   CHAMPION: Anne Anderson

WI#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: Included in 2.0 draft.  Accepted for 2.0 on 8 Jan 2004.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200305/msg00012.html
   CHAMPION: Michiharu Kudo

WI#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/>.  <Any...> dropped.  Environment elements to be
   treated same as Subject, Resource, Action as far as omitted
   elements are concerned.

   No need to add  "<Subjects></Subjects> = false" since schema
    makes an empty <Subjects> element invalid.

   TYPE: Simplicity of policy construction
   STATUS: Included in 2.0 draft 05 Section 5.5.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200310/msg00038.html
    http://lists.oasis-open.org/archives/xacml/200401/msg00062.html [FG accepts]
    http://lists.oasis-open.org/archives/xacml/200401/msg00064.html [Bill]
    http://lists.oasis-open.org/archives/xacml/200401/msg00065.html [Daniel]
    http://lists.oasis-open.org/archives/xacml/200401/msg00066.html [Daniel]
    http://lists.oasis-open.org/archives/xacml/200401/msg00067.html [Bill]
    http://lists.oasis-open.org/archives/xacml/200401/msg00068.html [Bill]
    http://lists.oasis-open.org/archives/xacml/200401/msg00069.html [Daniel]
    http://lists.oasis-open.org/archives/xacml/200402/msg00039.html [TC discuss]
   CHAMPION: Hal Lockhart

WI#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.
   RELATED: none
   
WI#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.
   RELATED: none

WI#16. XACML Policy in SAML Response Conditions

   Profile uses of XACML Policy instances as a syntax for
   specifying Conditions in a SAML Response.

   TARGET: SAML Profile
   STATUS: Closed for 2.0: no proposal by 20 Oct 2003.
   CHAMPION: Frank Siebenlist

WI#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.

   TARGET: SAML Profile
   STATUS: Closed for 2.0: no proposal by 20 Oct 2003.
   CHAMPION: Frank Siebenlist

WI#18. Obligations in Rules

   Allow Rule to contain Obligations.

   TYPE: Simplicity of policy construction
   STATUS: Open for 2.0.  Issues: requires retrieval and
    evaluation of all policies and rules in the policy tree,
    which does not work well in a distributed environment.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200305/msg00011.html
    http://lists.oasis-open.org/archives/xacml/200401/msg00062.html [Polar issues]
    http://lists.oasis-open.org/archives/xacml/200402/msg00013.html [Michiharu use case]
   CHAMPION: Michiharu Kudo

   ACTION: Either agree to require evaluation of entire policy
     tree or close this issue.

WI#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.
   CHAMPION: Michiharu Kudo

WI#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.

   TARGET: XACML Interpretation Guide
   STATUS: Open, but not for 2.0.  Needs proposal.
   PROPOSAL:
   CHAMPION: ?

WI#21. Non-normative XACML Primer

   Primer for XACML usage.

   TARGET: XACML Primer
   STATUS: Open, but not for 2.0.  Needs proposal.
   PROPOSAL:
   CHAMPION: ?

WI#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: Included in 2.0 draft.  Approved in general 30 Oct 2003.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200309/msg00005.html
   CHAMPION: Seth Proctor

WI#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: Open for 2.0.  Approved in general 30 Oct 2003.  Awaiting new functions.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200307/msg00044.html
    http://lists.oasis-open.org/archives/xacml/200312/msg00061.html [Status update]
   CHAMPION: Seth Proctor

   ACTION: Seth to provide specification for new comparison
     functions consistent with XML Schema.

WI#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.
   CHAMPION: Daniel Engovatov

WI#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 WI#9 proposal.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200309/msg00088.html
   CHAMPION: Anne Anderson

WI#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

WI#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: Included in 2.0 05 draft. Accepted for 2.0 8 Jan 2004.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200312/msg00062.html [Seth]
    http://lists.oasis-open.org/archives/xacml/200312/msg00067.html [Tim]
   CHAMPION: Seth Proctor

WI#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: Included in 2.0 draft.  Approved in general 30 Oct 2003.
   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

WI#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.

   TARGET: Administration Policy Profile
   STATUS: Open for 2.0, or maybe not.  No consensus yet on
    proposal. Need to review Use Cases Draft below.  Topic for
    F2F.  Use Cases Draft approved as TC Working Draft not
    intended for standardization at 4 March 2004 TC meeting.
   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
    http://lists.oasis-open.org/archives/xacml/200311/msg00022.html [Frank:Haskell model]
    http://lists.oasis-open.org/archives/xacml/200311/msg00030.html [schema changes]
    http://lists.oasis-open.org/archives/xacml/200311/msg00032.html [Tim:summary]
    http://lists.oasis-open.org/archives/xacml/200311/msg00034.html [Bill:weird case]
    http://lists.oasis-open.org/archives/xacml/200311/msg00036.html
    http://lists.oasis-open.org/archives/xacml/200312/msg00009.html [Polar:Abadi calculus]
    http://lists.oasis-open.org/archives/xacml/200312/msg00015.html [Use cases]
    http://lists.oasis-open.org/archives/xacml/200312/msg00019.html [Von Welch,resp]
    http://lists.oasis-open.org/archives/xacml/200312/msg00022.html [Polar to Frank]
    http://lists.oasis-open.org/archives/xacml/200312/msg00025.html [Frank to Polar]
    http://lists.oasis-open.org/archives/xacml/200402/msg00059.html [FG discuss]
    http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/5780/oasis_xacml_delegation_use-cases_wd_01.zip [Delegation Use Cases Working Draft]
   CHAMPION: Frank Siebenlist

WI#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.  Solve by making remote
    PAP accessible to the local PDP.
   RELATED: #17, possibly #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

WI#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 for 2.0.  No consensus; discuss at F2F.  See ACTION.
   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

   ACTION [All; 12 Feb 2004]: Depends on Admin Policy model.
    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.  Align with SAML:
    touched on in Tim's delegation use case document.

WI#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" (?).

   TARGET: Separate profile?
   TYPE: New functionality.
   STATUS: Open for 2.0.  No consensus.  See ACTION.
   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
    http://lists.oasis-open.org/archives/xacml/200402/msg00059.html [FG discuss]
   CHAMPION: Frank Siebenlist

   ACTION [Frank; 12 Feb 2004]: explain use case in a
    teleconference, not just in an e-mail.

WI#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.

   TARGET: WSDL Profile
   STATUS: Open, but not for 2.0.  Needs detailed proposal.
   RELATED: #1.
   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

WI#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.

   TARGET: WSDL Profile
   STATUS: Open, but not for 2.0.  Open issues.
   RELATED: #1.
   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

WI#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.  Can be solved using existing XACML policies.
   RELATED: #1,29,31,35,38.
   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

WI#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.

   TARGET: Administrative Policy Profile?
   TYPE: New functionality.
   STATUS: Open for 2.0.  Open issues for F2F. See ACTION.
   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
    http://lists.oasis-open.org/archives/xacml/200402/msg00059.html [FG discuss]
   CHAMPION: Frank Siebenlist

   ACTION [All; 12 Feb 2004]: 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.

WI#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: Open for 2.0.  Partially included in 2.0 draft 05.
    Additional edits to be made in response to Rebekah's
    questions in 06 draft.  See ACTION.
   RELATED: #55
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #37
    http://lists.oasis-open.org/archives/xacml/200401/msg00019.html [Rebekah - Q's]
    http://lists.oasis-open.org/archives/xacml/200402/msg00029.html [Rebekah]
    http://lists.oasis-open.org/archives/xacml/200402/msg00096.html [FG discussion]
    http://lists.oasis-open.org/archives/xacml/200403/msg00001.html [Tim's clarificatin]
    http://lists.oasis-open.org/archives/xacml/200403/msg00002.html [Seth to Tim]
    http://lists.oasis-open.org/archives/xacml/200403/msg00015.html [response to Rebekah Q's]
   CHAMPION: Rebekah Lepro

   ACTION [Tim]: include additional edits in response to
    Rebekah's questions.

WI#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.
   TARGET: Administration Policy Profile
   STATUS: Closed as duplicate of #19 on 12 Feb 2004.
   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
    http://lists.oasis-open.org/archives/xacml/200402/msg00059.html [FG discuss]
   CHAMPION: Hal Lockhart

WI#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: Included in 2.0 draft.  Accepted in general for 2.0 30
    Oct 2003.
   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

WI#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 SAML Profile
   STATUS: Open, but not for 2.0.
   RELATED: #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
    http://lists.oasis-open.org/archives/xacml/200402/msg00077.html [SAML F2F status]
    http://lists.oasis-open.org/archives/xacml/200402/msg00095.html [SAML Profile draft]
   CHAMPION: Hal Lockhart

WI#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: Closed for 2.0 8 Jan 2004, although could be
    considered for future version if proposal submitted.
   RELATED: #2,24.
   CHAMPION: Daniel Engovatov

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

   [This is different from WI#9.  This item is about how a single
   request can ask for access to multiple nodes in a hierarchy,
   getting back multiple responses (which XACML already
   supports).  XACML also already supports this when resource is
   an XML document using the "scope" = "Immediate", "Children",
   "Descendents" attribute. WI#9 is about how a policy can
   protect all nodes in a subtree of a hierarchy without having
   to specify a separate policy condition for each node.]

   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.  Resolution
    is: supply resource hierarchy in XML representation in
    <ResourceContent>.  Development of a standard XML
    representation for general or specific hierarchical resources
    is a separate WI#58.  Need owner for ACTION below.
   RELATED: #9,25,42,58.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200310/msg00078.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00082.html
    http://lists.oasis-open.org/archives/xacml/200401/msg00047.html [Simon add'l issues]
    http://lists.oasis-open.org/archives/xacml/200401/msg00048.html [Michiharu to Simon]
    http://lists.oasis-open.org/archives/xacml/200402/msg00059.html [FG discuss]
   CHAMPION: Simon Godik

   ACTION [?]: Needs to be explained in specification in
     non-normative Hierarchical Resources section.

WI#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 for 2.0.  Waiting for resolutions to all other open WI's.
   CHAMPION: ?

WI#44. Fix examples in the XACML Specification

   Review & correct all examples before the 2.0 release.

   TYPE: Editorial
   STATUS: Abstract.
   RELATED: #45.

WI#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: Included in 2.0 draft.  Accepted 12 Feb. 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 
    http://lists.oasis-open.org/archives/xacml/200311/msg00009.html
   CHAMPION: Michiharu Kudo

WI#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.

   Need to define a new "missing attribute" schema
   element that can return attribute meta-data (with or without
   Attribute Value information) for this.

   TYPE: Erratum
   STATUS: Open for 2.0.  Accepted in general 30 Oct 2003.  See ACTION.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200310/msg00076.html
    http://lists.oasis-open.org/archives/xacml/200310/msg00077.html
    http://lists.oasis-open.org/archives/xacml/200403/msg00104.html [Seth:no change OK]
   CHAMPION: Seth Proctor

   ACTION [Seth; 18 Mar 2004]: define new "MissingAttribute"
     element that is exactly like existing Attribute, except that
     AttributeValue is optional.

WI#47. New SAML Authorization Decision Query/Response using XACML

   TARGET: XACML SAML Profile
   STATUS: Open, but not for 2.0.  SAML accepts XACML/OGSA
    proposal in general, but says XACML should define a SAML
    extension using the XACMLnamespace.  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:
    http://lists.oasis-open.org/archives/xacml/200402/msg00077.html [SAML F2F status]
    http://lists.oasis-open.org/archives/xacml/200402/msg00095.html [SAML Profile draft]
    http://lists.oasis-open.org/archives/xacml/200403/msg00099.html [Polar]
   CHAMPION: Anne Anderson and Hal Lockhart

WI#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.

   TARGET: XACML Interface Definitions Specification
   STATUS: Open, but not for 2.0.  Requirements spec needed.
   RELATED: #38,40.
   PROPOSAL:
   CHAMPION: Tim Moses (expects to get to this soon 26 Feb 2004).

WI#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: Closed.  Same as #45.
   CHAMPION: Michiharu Kudo

WI#50. Fix obligations erratum: fulfilled by PDP

   Lines 2077-2078 in the 1.1 specification say "The
   <Obligations> element SHALL contain a set of obligations that
   MUST be fulfilled by the PDP in conjunction with the
   authorization decision."

   "PDP" should be "PEP".

   TYPE: Erratum
   STATUS: Included in 2.0 draft.  Accepted for 2.0 8 Jan 2004.
   PROPOSAL: http://lists.oasis-open.org/archives/xacml/200311/msg00060.html
   CHAMPION: Anne Anderson

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

   Lines:1768-1770,2731-2733,2756-2757,2859-2862,3060-3062

   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: Included in 2.0 draft 05.
   PROPOSAL: http://lists.oasis-open.org/archives/xacml/200311/msg00059.html
   CHAMPION: Michiharu Kudo

WI#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: Open for 2.0.  Awaiting resolution of other WI's.
   PROPOSAL:
   CHAMPION: Bill Parducci

   ACTION [Bill]: submit draft text to Tim by 17 April so can take into
    account changes in other proposals.

WI#53. Drop <Function> element

   I believe its purpose can be served by the <Apply> element
   when the FunctionId attribute identifies one of the bag
   functions.  We already allow a similar special case in the
   <Condition> element, which is an <Apply> element whose
   FunctionId attribute must identify a function whose return
   type is boolean.

   As currently structured, the bag function does not "enclose"
   the attributes or functions to which it applies.

   If we require the use of the <Apply> element instead, the bag
   function can enclose the attributes or functions to which it
   applies.  See lines [a477] to [a491] in draft 3.

   TYPE: Simplicity of policy construction.
   STATUS: Open for 2.0.  See ACTION below.  Will this change
    with the new reference proposals for WI#7?  No plans
    currently to change or eliminate <Function>.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200312/msg00063.html [Tim]
    http://lists.oasis-open.org/archives/xacml/200312/msg00064.html [Daniel]
    http://lists.oasis-open.org/archives/xacml/200312/msg00065.html [Polar to Tim]
   CHAMPION: Tim Moses

   ACTION [Tim]: add additional clarifying text to the
    description of <Function> explaining how and why it is used.

WI#54. Is resource-id required?

   First issue: V1.1 Section 6.3 schema fragment says resource
   must have 0 or more attributes, but text that follows says
   there must be one and only one instance of the "resource-id"
   attribute (implying one or more attributes, exactly one of
   which must be "resource-id").  These two should be made
   consistent. [Tim]

   Second issue: Why do we require "resource-id"?  Some policies
   may depend only on the security label of the resource, only on
   the host machine where the resource is located, or some other
   attribute of the resource, but may not care about the actual
   "resource-id" at all. [Anne]

   TYPE: Simplicity of policy construction and erratum fix
   STATUS: Included in 2.0 Draft ?.  Voted to make resource-id
    optional 8 Jan 2004.  See ACTION.
   PROPOSAL:
    http://lists.oasis-open.org/archives/xacml/200401/msg00000.html [Tim]
    http://lists.oasis-open.org/archives/xacml/200401/msg00001.html [Anne]
    http://lists.oasis-open.org/archives/xacml/200401/msg00002.html [Seth to Anne]
    http://lists.oasis-open.org/archives/xacml/200401/msg00003.html [Bill to Tim]
    http://lists.oasis-open.org/archives/xacml/200401/msg00004.html [Anne]
    http://lists.oasis-open.org/archives/xacml/200401/msg00005.html [Daniel to Anne]
    http://lists.oasis-open.org/archives/xacml/200401/msg00006.html [Satoshi to Anne]
    http://lists.oasis-open.org/archives/xacml/200401/msg00007.html [Daniel to Satoshi]
    http://lists.oasis-open.org/archives/xacml/200401/msg00008.html [Satoshi to Daniel]
    http://lists.oasis-open.org/archives/xacml/200401/msg00009.html [Daniel to Satoshi]
    http://lists.oasis-open.org/archives/xacml/200401/msg00010.html [Satoshi to Daniel]
    http://lists.oasis-open.org/archives/xacml/200401/msg00011.html [Daniel to Satoshi]
    http://lists.oasis-open.org/archives/xacml/200401/msg00012.html [Satoshi]
    http://lists.oasis-open.org/archives/xacml/200401/msg00013.html [Daniel to Satoshi]
    http://lists.oasis-open.org/archives/xacml/200401/msg00014.html [Satoshi to Daniel]
    http://lists.oasis-open.org/archives/xacml/200401/msg00015.html [Daniel to Satoshi]
    http://lists.oasis-open.org/archives/xacml/200401/msg00016.html [Satoshi to Seth]
    http://lists.oasis-open.org/archives/xacml/200401/msg00017.html [Tim]
   CHAMPION: Tim Moses and Anne Anderson

   ACTION [Tim]: make optional in next draft.

WI#55. Converge SAML and XACML Attribute schema definitions

   Need algorithmic 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.

   TYPE: Interoperability.
   TARGET: Some of this could go into an XACML SAML Profile, but
    not all.
   STATUS: Open for 2.0.  Still under discussion.  SAML has not
    frozen their 2.0 Attribute definition.  Should not hold up
    XACML 2.0 for SAML 2.0 [FG 11 Mar 2004]
   RELATED: #37
   PROPOSAL:
    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 - draft answer to SAML]
    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 mtg]
    http://lists.oasis-open.org/archives/xacml/200402/msg00077.html [SAML F2F status]
    http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/5854/wd-xacml-saml-profile-02.pdfy [SAML Profile draft]
    http://lists.oasis-open.org/archives/xacml/200403/msg00065.html [XACML options]
    http://lists.oasis-open.org/archives/xacml/200403/msg00112.html [Status, options]
    http://lists.oasis-open.org/archives/xacml/200403/msg00139.html [SSTC:drop ValueType]
   CHAMPION: Rebekah Lepro

WI#56. Should Request Context be optional (non-normative)

   Use of the Request Context should be non-normative, so long as
   policy evaluation is consistent with the behavior given a
   Request Context.

   TYPE: Erratum fix
   STATUS: Included in 2.0 Draft 06.  Accepted for 2.0 8 Jan
    2004.  Detailed text below accepted 22 Jan 2004.
   PROPOSAL:
     http://lists.oasis-open.org/archives/xacml/200401/msg00037.html [detailed text]
   CHAMPION: Hal Lockhart

WI#57. Make Environment element optional in Request Context

   TYPE: Simplicity of Request construction.
   STATUS: Closed for 2.0 8 Jan 2004.  Leave as is: minOccurs="1".

WI#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.
   TARGET: Could be separate profile, but if a single standard
    schema for hierarchies developed, it should be part of 2.0.
   STATUS: Open for 2.0 or maybe not.  See ACTION below.
   PROPOSAL:
     http://lists.oasis-open.org/archives/xacml/200401/msg00059.html [Anne]
     http://lists.oasis-open.org/archives/xacml/200401/msg00060.html [Rebekah to Anne]
     http://lists.oasis-open.org/archives/xacml/200401/msg00061.html [Anne to Rebekah]
     http://lists.oasis-open.org/archives/xacml/200401/msg00063.html [Frank]
     http://lists.oasis-open.org/archives/xacml/200402/msg00018.html [Anne]
   CHAMPION: Anne Anderson (for UFS and WFS, at least)

   ACTION [Anne]: need to be able to associate attributes such as owner
   with nodes.  Look at W3C ResourceDescriptionFramework, in case
   it offers anything.  We don't know if this applies, but the
   name sounds promising.

WI#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

   TARGET: XACML Profile for Role Based Access Control.
   STATUS: Open, but not for 2.0.  12 Feb 2004 FG recommended
    including in next RBAC draft.  Need vote to approve RBAC
    Version 02 as Committee Draft with this.
   PROPOSAL:
     http://lists.oasis-open.org/archives/xacml/200401/msg00038.html
   CHAMPION: Anne Anderson 
  
WI#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.

   TYPE: Privacy Profile
   STATUS: Open, but not for 2.0.  4 March 2004 approved Tim's
    proposal as a TC Working Draft.
   PROPOSAL:
     http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/5781/oasis_xacml_v2_0_privacy-profile_wd_01.zip
   CHAMPION: Tim Moses

   ACTION [Tony; 4 March 2004]: look at W3C work in the privacy
    area and provide XACML TC with a summary.

WI#61. Negating TargetMatch

   For Target Matching, ability to say things like "match any
   subject who doesn't have this name" or "match any access not
   for this server."   Having a flag (or something) that negates
   a TargetMatch.

   TYPE: New functionality
   STATUS: Closed for 2.0 on 18 Mar 2004.
   PROPOSAL:
     http://lists.oasis-open.org/archives/xacml/200402/msg00090.html
   CHAMPION: Seth Proctor (on behalf of an XACML users)

WI#62. New string functions

   Some of the standard string functions like concatenation,
   substring, etc.

   TYPE: New functionality
   STATUS: Open for 2.0.  18 March 2004: OK if specific proposals.  See ACTION.
   PROPOSAL:
     http://lists.oasis-open.org/archives/xacml/200402/msg00090.html
   CHAMPION: Seth Proctor

   ACTION [?; 18 March 2004]: find definitions of such functions
    from some other standard.  Provide use cases for each.

WI#63. Remove "IssueInstant" XML attribute

   TYPE: Remove unusable, vestigial attribute
   STATUS: Included in 2.0 Draft ?.  Approved removal 18 Mar 2004  See ACTION.
   PROPOSAL:
   CHAMPION:

   ACTION [Tim; 18 Mar 2004]: remove in next draft.

WI#64. Align XACML Attribute with SAML Attribute

   After SAML settles their Attribute format for 2.0, define
   mapping.

   TYPE: Interoperability
   STATUS: Closed 31 March 2004 as duplicate of WI#55.

WI#65. Add additional layer of aggregation to XACML attribute naming

   TYPE: Interoperability
   STATUS: Open for 2.0.  To be discussed in TC; also waiting for
    SAML decision.
   PROPOSAL: 
   CHAMPION: Daniel

WI#66. Add IP address match functions

   XACML defines a SubjectCategory for "requesting-machine" and
   users mention use of IP addresses as attributes, but XACML
   provides no functions for comparing two IP addresses.
   Comparisons should include address and optional port or port
   range, and should include DNS names as well as numeric IP
   addresses.  Comparisons should handle 64-bit names as well as
   32-bit names.  One use case is to provide functionality of the
   Java SocketPermission.

   TYPE: New functionality.
   STATUS: Open for 2.0.  Waiting specific proposal with
    functions.
   PROPOSAL: 
   CHAMPION: Anne Anderson

WI#67. Add "IssuerNameFormat" XML attribute to Attribute[Designator]

   TYPE: Interoperability with SAML
   STATUS: Not yet discussed in TC meetings.
   PROPOSAL:
     http://lists.oasis-open.org/archives/xacml/200403/msg00055.html [Anne-proposal]
     http://lists.oasis-open.org/archives/xacml/200403/msg00056.html [Seth to Anne]
     http://lists.oasis-open.org/archives/xacml/200403/msg00058.html [Anne to Seth]
   CHAMPION: Anne

WI#68.  Attribute assertion lifetime

   Need some way to indicate validity period for attributes
   included in a Request, and way to place constraints on
   acceptable validity in Policy.

   Alternative view says testing for validity is done by Context
   Handler, not by policy.  All attributes included in a Request
   Context are assumed to be valid at the time the PDP is asked
   to use the Request Context in making an authorization
   decision.

   TYPE: New functionality
   STATUS: Not discussed in TC meetings.
   PROPOSAL:
     http://lists.oasis-open.org/archives/xacml/200403/msg00067.html [Daniel to Frank]
     http://lists.oasis-open.org/archives/xacml/200403/msg00072.html [Polar: formal approach]
     http://lists.oasis-open.org/archives/xacml/200403/msg00073.html [Anne: use WSPL]
     http://lists.oasis-open.org/archives/xacml/200403/msg00078.html [Daniel:new datatype]
     http://lists.oasis-open.org/archives/xacml/200403/msg00079.html [Frank to Anne]
     http://lists.oasis-open.org/archives/xacml/200403/msg00082.html [Daniel:caching]
     http://lists.oasis-open.org/archives/xacml/200403/msg00086.html [Polar to Frank]
     http://lists.oasis-open.org/archives/xacml/200403/msg00088.html [Polar agrees with Daniel]
     http://lists.oasis-open.org/archives/xacml/200403/msg00089.html [Frank to Polar]
     http://lists.oasis-open.org/archives/xacml/200403/msg00092.html [Frank to Daniel]
     http://lists.oasis-open.org/archives/xacml/200403/msg00093.html [Daniel to Frank]
     http://lists.oasis-open.org/archives/xacml/200403/msg00095.html [Polar to Frank]
     http://lists.oasis-open.org/archives/xacml/200403/msg00096.html [Frank gives up]
     http://lists.oasis-open.org/archives/xacml/200403/msg00097.html [Anne to Frank]
   CHAMPION: Frank Siebenlist

WI#69.  AttributeAssignment clarification

   TYPE: Clarification
   STATUS: Not discussed in TC meetings.
   PROPOSAL:
     http://lists.oasis-open.org/archives/xacml/200403/msg00116.html
   CHAMPION: Seth Proctor

WI#70.  Legal values for string DataType

   is it legal in XACML to use string as the datatype for what
   may be interpreted as complex content? I would suggest the
   answer is no, unless we want to add explicit text to the XACML
   specification explaining why it's ok. Keep in mind that for
   people using DOM/SAX, the tree will be interpreted before they
   see the value, and this can cause the tags to change their
   representation (eg, namespacing, macro replacing, etc).

   TYPE: Clarification
   STATUS: Not discussed in TC meetings.
   PROPOSAL:
     http://lists.oasis-open.org/archives/xacml/200403/msg00117.html
     http://lists.oasis-open.org/archives/xacml/200403/msg00118.html [Rich Salz:agrees]
     http://lists.oasis-open.org/archives/xacml/200403/msg00119.html [Daniel:example invalid]
     http://lists.oasis-open.org/archives/xacml/200403/msg00122.html [Seth<->Daniel]
     http://lists.oasis-open.org/archives/xacml/200403/msg00123.html [Satoshi:change tests]
     http://lists.oasis-open.org/archives/xacml/200403/msg00130.html [Daniel:quote XML]
     http://lists.oasis-open.org/archives/xacml/200403/msg00131.html [Tim:alternative]
     http://lists.oasis-open.org/archives/xacml/200403/msg00134.html [Daniel<->Tim]
     http://lists.oasis-open.org/archives/xacml/200403/msg00135.html [Seth:no to alt]
   CHAMPION: Seth Proctor


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