[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]