[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Updated XACML 2.0 Work Item Index, Version 1.41
Colleagues,
This list includes the open items from the XACML 2.0 Work Item
Index. Some of these are targetted for profiles that are not
tied to XACML 2.0. A full updated Work Item Index, showing open
and closed items, is attached.
WI#2. Location Information
PROFILE: Location Information Profile
STATUS: Open issues.
ACTION: Seth to produce revised proposal.
WI#7. ConditionReference
STATUS: Open issues.
ACTION: Need final consensus proposal from proponents.
WI#9. Policies referring to hierarchical resources
STATUS: Open issues.
ACTION: Anne to look at WS-ResourceDescriptionFramework to see
if it handles hierarchical resources appropriately, otherwise
revise CURRENT.
[NOTE:WI#9 "Policies referring to hierarchical resources" is
different from WI#42 "Requests asking for access to multiple
elements in a hierarchical resource".
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.
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). XACML already
supports this functionality for XML documents using the
urn:oasis:names:tc:xacml:1.0:resource:scope AttributeId
described in Section 7.8 (Immediate,Children, Descendants),
but not for hierarchical resources in general.]
WI#10. Parameters for Combining Algorithms
STATUS: Open. Re-opened with proposal from WI#11 on 12 Feb.
ACTION: are we ready to vote on this?
WI#13. Optional Target Elements
STATUS: Included in 2.0 draft 05 Section 5.5. Add note on
ACTION: Tim to add note on "<Subjects></Subjects> = false" to
Draft 06.
WI#18. Obligations in Rules
STATUS: Open issues.
ACTION: Polar wants to try to develop an alternative approach.
WI#23. Use XQuery comparison functions for date, time, dateTime
STATUS: Approved in general 30 Oct 2003. Waiting for new XML
Schema definitions of time, etc. How long are we willing to
wait?
ACTION: Seth to provide update.
WI#29. Policy Authority Delegation
PROFILE: Administration Policy Profile
STATUS: Open issues.
ACTION: Need to review Tim's new Use Cases document.
WI#31. Attribute Issuer as Subject
STATUS: Open issues.
ACTION 12 Feb: 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.
WI#32. Standardize naming to specify rules for requestor's authz policy
PROFILE?
STATUS: Open issues.
ACTION: need Frank to explain his use case in a
teleconference, not just by e-mail.
WI#33. XACML wsdl/porttype definition for <Req>/<Resp> exchange
PROFILE: WSDL Profile
STATUS: Needs detailed proposal.
WI#34. porttype/operations to ask for required attributes
PROFILE: WSDL Profile
STATUS: Open issues.
WI#36. Check for requester authorized to ask for authz decision
PROFILE?
STATUS: Open issues. For F2F.
ACTION: 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
STATUS: Open issues. Included in 2.0 draft 05. Additional
edits needed in response to Rebekah's questions. Current
discussion on e-mail ist.
ACTION: Tim to include additional edits in response to
Rebekah's questions.
WI#40. Define a SAML PolicyQuery and PolicyStatement
PROFILE: XACML SAML Profile
STATUS: Open.
ACTION: Anne updating SAML Profile.
WI#42. Requests asking for access to multiple elements in a hierarchical resource
STATUS: Accepted in general for 2.0 30 Oct 2003. Resolution
is a separate WI#58.
ACTION: Needs to be explained in specification in
non-normative Hierarchical Resources section.
WI#43. Examine interactions between approved work items
STATUS: Open. Waiting for resolutions to all WI's.
WI#46. Status detail for missing attributes
STATUS: Open. Need to define a new "missing attribute" schema
ACTION 12 Feb 2004: Seth to produce missing attribute schema.
WI#47. New SAML Authorization Decision Query/Response using XACML
PROFILE: XACML SAML Profile
STATUS: SAML accepted XACML/OGSA proposal in general.
ACTION: Anne updating SAML Profile.
WI#48. PAP Interface to a PDP/PRP
PROFILE: XACML Interface Definitions Specification
STATUS: Open. Related to #38,40. Requirements spec needed.
ACTION: Tim to produce requirements spec.
WI#52. New section explaining not backwards compatible and listing changes
STATUS: Awaiting detailed proposal once other WI's resolved.
ACTION: Bill Parducci has volunteered.
WI#53. Drop <Function> element
STATUS: Will this change with the new
reference proposals for WI#7? No plans currently to change
or eliminate <Function>.
ACTION: Tim will add additional clarifying text to the
description of <Function> explaining how and why it is used.
WI#54. Is resource-id required?
STATUS: Voted to make resource-id optional 8 Jan 2004.
ACTION: Tim to make optional in next draft.
WI#55. Converge SAML and XACML Attribute schema definitions
PROFILE: Some of this could go into XACML SAML Profile.
STATUS: Open. Still under discussion. SAML has not frozen
ACTION: continue discussion with SAML people; Anne updating
SAML Profile.
WI#58. Standard hierarchy schemas
TYPE: Interoperability. Could be separate profile, but if a
single standard schema for hierarchies developed, it should
be part of 2.0.
STATUS: Open.
ACTION: 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. Anne looking into this.
WI#59. Define standard "role" subject attribute
PROFILE: XACML Profile for Role Based Access Control.
STATUS: 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
ACTION: Vote.
WI#60. Define standard "purpose" attributes
PROFILE: Privacy Profile
STATUS: Open.
http://www.oasis-open.org/committees/download.php/5589/oasis_xacml_v2.0_privacy-profile_moses_01.zip [Draft profile]
CHAMPION: Tim Moses
ACTION: Study Tim's draft.
WI#61. Negating TargetMatch
STATUS: Not yet discussed.
CHAMPION: Seth Proctor
WI#62. New string functions
STATUS: Not yet discussed
CHAMPION: Seth Proctor
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.41
Updated: 04/03/02 (yy/mm/dd)
TEMPLATE FOR PROPOSALS:
http://lists.oasis-open.org/archives/xacml/200308/msg00028.html
CURRENT 2.0 DRAFT:
http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/5127/oasis-xacml-2_0-wd-05.zip
THIS WORK ITEM INDEX INCLUDES E-MAILS UP THROUGH:
http://lists.oasis-open.org/archives/xacml/200403/msg00002.html
and reflects recommendations from XACML FG meeting 26 Feb 2004.
WI#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
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
TYPE: Location Information Profile
STATUS: Open issues. Waiting for revised proposal from Seth. 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
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.
PROPOSAL:
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.
PROPOSAL:
CHAMPION: Frank Siebenlist
WI#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: ?
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.
PROPOSAL:
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 issues. Need final consensus proposal from proponents.
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200304/msg00039.html [use cases]
http://lists.oasis-open.org/archives/xacml/200402/msg00050.html [Simon-schema]
http://lists.oasis-open.org/archives/xacml/200402/msg00054.html [Polar agrees]
http://lists.oasis-open.org/archives/xacml/200402/msg00055.html [Daniel/Polar]
http://lists.oasis-open.org/archives/xacml/200402/msg00056.html [Polar-text]
http://lists.oasis-open.org/archives/xacml/200402/msg00082.html [Seth to Polar]
http://lists.oasis-open.org/archives/xacml/200402/msg00086.html [Polar to Seth]
http://lists.oasis-open.org/archives/xacml/200402/msg00087.html [Daniel to Polar]
http://lists.oasis-open.org/archives/xacml/200402/msg00089.html [Seth to Polar]
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 issues. CURRENT proposal below accepted for 2.0
8 Jan 2004, but OPEN ISSUE below.
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 to 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.
TYPE: New functionality
STATUS: Open. Re-opened with proposal from WI#11 on 12 Feb.
Close to consensus. Tim will see if enough information to
include in next draft.
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]
CHAMPION: Michiharu Kudo
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 XACML 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.
TYPE: Simplicity of policy construction
STATUS: Included in 2.0 draft 05 Section 5.5. Add note on
"<Subjects></Subjects> = false" to Draft 06.
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: Closed for XACML 2.0. Abstract. Related: <none>
PROPOSAL: ABSTRACT
CHAMPION: ?
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: Closed for XACML 2.0. Abstract. Related: <none>
PROPOSAL: ABSTRACT
CHAMPION: ?
WI#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
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.
TYPE: SAML Profile
STATUS: Closed for XACML 2.0: no proposal by 20 Oct 2003.
PROPOSAL:
CHAMPION: Frank Siebenlist
WI#18. Obligations in Rules
Allow Rule to contain Obligations.
TYPE: Simplicity of policy construction
STATUS: Open issues. Waiting for Polar's alternative.
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: Polar wants to try to develop an alternative approach.
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.
PROPOSAL:
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.
TYPE: New document not tied to XACML 2.0.
STATUS: Needs proposal. Not part of 2.0.
PROPOSAL:
CHAMPION: ?
WI#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: ?
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: Approved in general 30 Oct 2003. Waiting for new XML
Schema time values. Need to decide how long we wait.
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
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.
PROPOSAL:
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 #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.
TYPE: Administration Policy Profile
STATUS: Open issues. Related: #1,29,31,35,38. Need to review
Use Cases Draft below. Topic for F2F.
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/committees/download.php/5699/oasis_xacml_delegation_use-cases_moses_01.zip [Use Cases 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. 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
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 issues. Related: #1,29,31,35,38. For F2F. See ACTION.
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 12 Feb: 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.
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" (?).
TYPE: New functionality. Separate profile?
STATUS: Open issues. Related: #1,29,31,35,38. See ACTION.
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 12 Feb: need Frank to explain his 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.
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
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.
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
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. 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
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.
TYPE: New functionality. Separate profile?
STATUS: Open issues. Related: #1,29,30,31,35,38. For F2F. See ACTION.
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 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 issues. Included in 2.0 draft 05. Additional
edits to be made in response to Rebekah's questions in 06
draft.
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]
CHAMPION: Rebekah Lepro
ACTION: Tim to 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. 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. 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
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. Related: #2,24.
PROPOSAL:
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. Related: #9,25,42,58. See ACTION below.
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. Waiting for resolutions to all WI's.
PROPOSAL: ?
CHAMPION: ?
WI#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:
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.
TYPE: Erratum
STATUS: Open. 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
ACTION 12 Feb 2004: Seth to produce missing attribute schema.
WI#47. New SAML Authorization Decision Query/Response using XACML
TYPE: XACML SAML Profile
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)
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: 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.
TYPE: XACML Interface Definitions Specification
STATUS: Open. Related to #38,40. Requirements spec needed.
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: Awaiting detailed proposal once other WI's resolved.
PROPOSAL:
CHAMPION: Bill Parducci
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
STATUS: 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 will 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 and erratum fix
STATUS: 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 to 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. Some of this could go into an XACML SAML Profile.
STATUS: Open. Still under discussion. SAML has not frozen
their 2.0 Attribute definition.
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://lists.oasis-open.org/archives/xacml/200402/msg00095.html [SAML Profile draft]
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
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. Could be separate profile, but if a
single standard schema for hierarchies developed, it should
be part of 2.0.
STATUS: Open. 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: 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. Anne looking into this.
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
TYPE: XACML Profile for Role Based Access Control.
STATUS: 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. Study Tim's proposal.
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200402/msg00059.html [FG discuss]
http://lists.oasis-open.org/archives/xacml/200402/msg00067.html [Tim]
http://lists.oasis-open.org/archives/xacml/200402/msg00093.html [Tim intro to draft]
http://www.oasis-open.org/committees/download.php/5589/oasis_xacml_v2.0_privacy-profile_moses_01.zip [Draft profile]
CHAMPION: Tim Moses
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: Not yet discussed.
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200402/msg00090.html
CHAMPION: Seth Proctor
WI#62. New string functions
some of the standard string functions like concatination,
substring, etc.
TYPE: New functionality
STATUS: Not yet discussed
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200402/msg00090.html
CHAMPION: Seth Proctor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]