[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Open 2.0 work items
Here are the XACML 2.0 work items that are still open as of today
(pre-TC meeting):
7. ConditionReference
Allow a Rule to contain a ConditionReference element as an
alternative to a Condition element. The ConditionReference
would identify a Condition element specified elsewhere. This
allows a single Condition to be re-used in Rules under
different Targets. An optional ConditionId attribute would be
added to the Condition element to support this.
TYPE: Simplicity of policy construction.
STATUS: Accepted in general for 2.0 13 Nov 2003. Michiharu,
Polar, and Seth will develop final proposal via email.
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200304/msg00039.html [use cases]
http://lists.oasis-open.org/archives/xacml/200312/msg00045.html [Michiharu:summary]
http://lists.oasis-open.org/archives/xacml/200401/msg00022.html [Bill: summary]
http://lists.oasis-open.org/archives/xacml/200401/msg00035.html [Michiharu:detailed]
CHAMPION: Michiharu Kudo
11. XACML Extension Points
Define schema extension points for XACML. This work item
might solve the requirements driving several other work
items.
TYPE: New functionality
STATUS: Waiting proposal from Simon as of 8 Jan 2004 Used as solution for #10.
See
http://lists.oasis-open.org/archives/xacml/200310/msg00098.html
for information that may be relevant.
PROPOSAL: Waiting proposal from Simon.
CHAMPION: Simon Godik and Michiharu Kudo.
13. Optional Target Elements
Make Subjects, Resources, Actions elements optional in a
Target. Missing element has same semantics as <Any.../>
Make Target itself optional. Missing element has same
semantics as a Target containing <AnySubject/>,
<AnyResource/>, <AnyAction/>.
TYPE: Simplicity of policy construction
STATUS: No issues. In 2.0 draft. Needs actual vote.
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200310/msg00038.html
CHAMPION: Hal Lockhart
18. Obligations in Rules
Allow Rule to contain Obligations.
TYPE: Simplicity of policy construction
STATUS: Open issues.
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200305/msg00011.html
CHAMPION: Michiharu Kudo
23. Use XQuery comparison functions for date, time, dateTime
Allow date, time, and dateTime functions to handle comparing a
value with no time zone with a value with a time zone.
TYPE: Erratum fix
STATUS: Approved in general 30 Oct 2003. 8 Jan 2004: Seth to
consult on new XML Schema time values.
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
31. Attribute Issuer as Subject
The current attribute issuer type is a string. This
restriction doesn't allow one to easily point at an issuer as
Subject, and it doesn't allow for any path validation that
goes more than one level deep. By allowing an attribute issuer
of type subject, one could cater for more complex use-cases
that involve policy delegation.
TYPE: New functionality
STATUS: Open issues. Related: #1,29,31,35,38.
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #3
http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #31
CHAMPION: Frank Siebenlist
32. Standardize naming to specify rules for requestor's authz policy
In a setting where a requester invokes certain operations of a
service provider, the convention for the target of the service
provider's policy is well defined: subject=requester,
resource=service-provider, and action=operation. However,
when we consider the policy evaluation on the requester's side
to check whether an invocation on the service provider is
allowed according to the requester's policy, then is it less
clear. It is almost a mirror case, but if we take a
convention where the "resource" is the one protected by the
policy, the we should equate subject=service-provider and
resource=requester with the same action=operation.
Unfortunately, if we also have to consider the possibility
that the service-provider can invoke an equivalent operation
on the requester, then we need an additional way to
discriminate between these cases. Maybe we can label the
action with a category of "out-bound" (?).
TYPE: New functionality
STATUS: Open issues. Related: #1,29,31,35,38.
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #4
http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #32
http://lists.oasis-open.org/archives/xacml/200310/msg00042.html #32
CHAMPION: Frank Siebenlist
36. Check for requester authorized to ask for authz decision
Proposes that the PDP have a formally defined access control
mechanism to "downstream PDPs".
The PDP should check whether the upstream PDP requester,
i.e. subject associated with the context handler, is allowed
to ask for the authorization decision. We need to be able to
state this in a policy statement, and describe the correct
operating procedure.
TYPE: New functionality
STATUS: Open issues. Related: #1,29,30,31,35,38.
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #36
http://lists.oasis-open.org/archives/xacml/200310/msg00074.html #36 on 20 Oct 2003
CHAMPION: Frank Siebenlist
38. Policies for the Administration of XACML Policies
XACML defines a language to express policies about access to
resources. But it is also desirable to create policies about
the creation, modification and deletion of XACML policies. In
a sense XACML already allows this, since XACML policies are
agnostic to the semantics of the resources being
protected. However, it is very desirable for administrative
policies to specify not the "name" of policies being
administered, but their "content."
TYPE: New functionality
STATUS: Open issues. Related: #1,29,31,35,38.
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200308/msg00050.html
http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #38
http://lists.oasis-open.org/archives/xacml/200310/msg00054.html
CHAMPION: Hal Lockhart
42. Requests asking for access to multiple elements in a hierarchical resource
How to express requests that ask for access to multiple
elements in a hierarchical resource, i.e. "Does Frank have
access to all elements under /X/Y?".
XACML currently defines a standard Resource AttributeId
"urn:oasis:names:tc:xacml:1.0:resource:scope" that can be used
to express whether a request applies to "Immediate",
"Children", or "Descendents". XACML also currently defines a
way to include an XML document in a <ResourceContent> element
as part of a Request. This is sufficient if all hierarchies
are assumed to be XML documents and if the document itself is
always included in <ResourceContent> when multiple decisions
are requested.
What is missing is a way of handling hierarchical resources
that are not XML documents, such as file system directories.
To handle other types of hierarchies, it will be necessary to
identify what type of hierarchy the resource is and, in a
related profile, what syntax is to be used in expressing and
referring to nodes and elements in hierarchies of that type.
Proposal 200310/msg00078.html proposes to solve this by
requiring all hierarchical resources to be represented and
referenced as XML instances using XPath expressions. If this
is accepted, then the specification needs to state this
explicitly.
TYPE: New functionality.
STATUS: Accepted in general for 2.0 30 Oct 2003. Needs to
be explained in specification in non-normative Hierarchical
Resources section. Resolution is: supply resource hierarchy
in XML representation in <ResourceContent>.
Related: #9,25,42.
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200310/msg00078.html
http://lists.oasis-open.org/archives/xacml/200310/msg00082.html
CHAMPION: Simon Godik
43. Examine interactions between approved work items
As part of the editorial process, a check is needed to ensure
that there are no unexpected problematic interactions between
approved work items.
TYPE: Editorial
STATUS: Open issues
PROPOSAL: ?
CHAMPION: ?
46. Status detail for missing attributes
In 6.15 there is an explanation for what detail to include
with the missing-attribute status code: Attributes specify one
or more missing values, and if an AttributeValue is included,
then this specifies an acceptable value. If no AttributeValue
is included, then the PDP is specifying the identifier and
datatype only. Sounds good.
The problem is that the Attribute type is
<xs:element ref="xacml-context:AttributeValue"/>
This means that it's not valid to have an Attribute with no
AttributeValue. So, it's not possible for the PDP to specify a
missing attribute without specifying at least one acceptable
value (note that even an empty AttributeValue tag, which is
still legal, is still technically a value). PDPs need a way
to specify missing attributes without providing acceptable
values.
TYPE: Erratum
STATUS: Need to define a new "missing attribute" schema
element that can return attribute meta-data (with or without
Attribute Value information) for this. Accepted in general
30 Oct 2003.
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200310/msg00076.html
http://lists.oasis-open.org/archives/xacml/200310/msg00077.html
CHAMPION: Seth Proctor
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: Awaiting detailed proposal.
PROPOSAL: http://lists.oasis-open.org/archives/xacml/200311/msg00059.html
CHAMPION: Michiharu Kudo
52. New section explaining not backwards compatible and listing changes
The XACML 2.0 specification should have a new section that
explains 2.0 is not backwards compatible with 1.0 or 1.1, and
listing the changes made between 1.0 (and/or 1.1) and 2.0.
TYPE: Editorial
STATUS: Awaiting detailed proposal.
PROPOSAL:
CHAMPION: Bill Parducci
55. Converge SAML and XACML Attribute schema definitions
TYPE: Interoperability
STATUS: Open. Still under discussion.
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]
http://lists.oasis-open.org/archives/xacml/200401/msg00032.html [Anne]
http://lists.oasis-open.org/archives/xacml/200401/msg00034.html [Scott Cantor]
http://lists.oasis-open.org/archives/xacml/200401/msg00039.html [SAML/XACML]
CHAMPION: Rebekah Lepro
58. Standard hierarchy schemas
Given resolution to hierarchical resources in WI#9, there
needs to be a standard schema for certain common hierarchies
such as UFS.
TYPE: Interoperability. Could be separate profile.
STATUS: Open
PROPOSAL:
CHAMPION: Anne Anderson (for UFS and WFS)
59. Define standard "role" subject attribute
Add following to Appendix B.5 "Subject attributes":
This identifier indicates a role associated with the subject.
Values of this attribute SHOULD be of type
"http://www.w3.org/2001/XMLSchema#anyURI";;.
urn:oasis:names:tc:xacml:2.0:subject:role
TYPE: Interoperability.
STATUS: Detailed proposal available
PROPOSAL:
http://lists.oasis-open.org/archives/xacml/200401/msg00038.html
CHAMPION: Anne Anderson
--
Anne H. Anderson Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]