[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 2.0 Work Item List, v1.33
Colleagues, An updated XACML 2.0 Work Item Index is attached. This list indicates on the STATUS line those items that have been incorporated into the current XACML 2.0 specification draft. The items so marked are listed below, along with the champion. Those interested in the items, particularly the champion, should review the current XACML 2.0 specification draft carefully to ensure that the work item has been incorporated correctly. If they have been incorporated correctly, then no further "detailed proposal" is needed. 12. Environment Element in Target CHAMPION: Michiharu Kudo 13. Optional Target Elements CHAMPION: Hal Lockhart 22. time-in-range function CHAMPION: Seth Proctor 28. Define "current time/date/dateTime" during policy evaluation CHAMPION: Seth Proctor 37. Multiple <AttributeValue> elements for single <Attribute> in Request CHAMPION: Rebekah Lepro 39. Make Status in the XACML Response optional CHAMPION: Hal Lockhart 45. Fix AttributeAssignment example in Section 4.2.4.3 (Rule 3) CHAMPION: Michiharu Kudo Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
Title: XACML 2.0 Work Items Version: 1.33 Updated: 03/12/16 (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/4435/oasis-xacml-2.0-wd-02.zip THIS VERSION INCLUDES E-MAILS UP THROUGH: http://lists.oasis-open.org/archives/xacml/200312/msg00050.html STATUS CODES: Needs proposal. No proposal submitted. Will be dropped from 2.0 work item list unless proposal submitted by 20 October 2003. Needs detailed proposal. Proposal submitted, and no open issues. Proposal needs a detailed solution before a vote. Open issues. Proposal available, but there are open issues. Ready for vote. Detailed proposal available. No open issues. Closure candidate. May be closed, based on discussion to date. Abstract. Not a work item itself, but a category for specific items. 1. Grid Requirements Any XACML changes needed to satisfy Grid requirements TYPE: New functionality STATUS: Abstract. Related: #2,3,4,16,17,29,30,31,32,33,34,35,36,37 PROPOSAL: Abstract CHAMPION: Frank Siebenlist 2. Location Information Way to pass information needed to configure a PDP and its context and policy handlers/finders in order to evaluate a policy. Examples of such information are: o where to find various Attributes, and what they are keyed off o where Attribute Authorities to be used are located o where to find function, combining algorithm, data-type, Attribute parsing code Such information might be embedded in a. an XACML Request b. an XACML policy c. a third document type TYPE: New functionality STATUS: Open issues. Waiting for revised proposal from Seth. Related: #1,24. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00022.html CHAMPION: Seth Proctor 3. Multiple Actions per Request Support Requests containing multiple Actions. Response could either say "All permitted/denied" or could include a separate decision for each. TYPE: New functionality STATUS: Closed: no proposal submitted by 20 Oct 2003. Related: #1. PROPOSAL: CHAMPION: Frank Siebenlist 4. Multiple Resources per Request Support Requests containing multiple Resources. Response could either say "All permitted/denied" or could include a separate decision for each. TYPE: New functionality STATUS: Closed: no proposal submitted by 20 Oct 2003. Related: #1. PROPOSAL: CHAMPION: Frank Siebenlist 5. Privacy Requirements Any XACML changes needed to satisfy Privacy requirements. TYPE: New functionality STATUS: Closed for XACML 2.0. Abstract. Related: <none> PROPOSAL: ABSTRACT CHAMPION: ? 6. Domain-specific identifiers Define a set of domain-specific identifiers based on application usage of XACML. TYPE: New functionality STATUS: Closed: no proposal submitted by 20 Oct 2003. PROPOSAL: CHAMPION: Michiharu Kudo 7. ConditionReference Allow a Rule to contain a ConditionReference element as an alternative to a Condition element. The ConditionReference would identify a Condition element specified elsewhere. This allows a single Condition to be re-used in Rules under different Targets. An optional ConditionId attribute would be added to the Condition element to support this. TYPE: Simplicity of policy construction. STATUS: Accepted in general for 2.0 13 Nov 2003. Vote on A vs. B for 8 Jan 2004. 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] CHAMPION: Michiharu Kudo 8. RuleIdReference Define RuleIdReference analogous to PolicyIdReference and PolicySetIdReference. TYPE: Simplicity of policy construction STATUS: Closed 20 Oct 2003. Can do this now with a Policy containing a single Rule. Related #19. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200305/msg00004.html CHAMPION: Anne Anderson (on behalf of ebXML) 9. Policies referring to hierarchical resources How to express policies that apply to a hierarchy of resources. E.g. "Frank can read any file under directory /X/Y". TYPE: New functionality STATUS: Open issues. Related: #25,42. Some people want all mapped to XML; others want specific functions or something else for various specific types of hierarchies (e.g. ufs, urls). Direction seems to be all mapped to XML, but need standard hierarchy schema for UFS and any other common hierarchies. 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] CHAMPION: Simon Godik 10. Parameters for Combining Algorithms Support an element or attribute in a PolicySet, Policy, or Rule that provides parameters to be used by a Combining Algorithm that is combining the PolicySet, Policy, or Rule. TYPE: New functionality STATUS: Closed 21 Oct 2003. Will do this via extension points #11. PROPOSAL: OLD: http://lists.oasis-open.org/archives/xacml/200305/msg00014.html CURRENT: http://lists.oasis-open.org/archives/xacml/200310/msg00079.html CHAMPION: Michiharu Kudo 11. XACML Extension Points Define schema extension points for XACML. This work item might solve the requirements driving several other work items. TYPE: New functionality STATUS: Needs proposal by 20 Nov 2003. Used as solution for #10. See http://lists.oasis-open.org/archives/xacml/200310/msg00098.html for information that may be relevant. PROPOSAL: CHAMPION: Simon Godik and Michiharu Kudo. 12. Environment Element in Target Allow the Target Element to include an Environment element, just as it now includes Subject, Resource, and Action elements. TYPE: New functionality STATUS: Vote to accept for 2.0 on 21 Oct 2003. In 2.0 draft. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200305/msg00012.html CHAMPION: Michiharu Kudo 13. Optional Target Elements Make Subjects, Resources, Actions elements optional in a Target. Missing element has same semantics as <Any.../> Make Target itself optional. Missing element has same semantics as a Target containing <AnySubject/>, <AnyResource/>, <AnyAction/>. TYPE: Simplicity of policy construction STATUS: No issues. In 2.0 draft. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00038.html CHAMPION: Hal Lockhart 14. Signature envelope requirements Any new XACML work items to meet requirements for signature envelopes around an XACML schema instance, such as including an XACML Policy or Request in a signed SAML Assertion. TYPE: New functionality STATUS: Closed for XACML 2.0. Abstract. Related: <none> PROPOSAL: ABSTRACT CHAMPION: ? 15. Encrypted XACML schema instance requirements Any new XACML work items to meet requirements for encrypted XACML Policy or Context schema instances. TYPE: New functionality STATUS: Closed for XACML 2.0. Abstract. Related: <none> PROPOSAL: ABSTRACT CHAMPION: ? 16. XACML Policy in SAML Response Conditions Profile uses of XACML Policy instances as a syntax for specifying Conditions in a SAML Response. TYPE: SAML Profile STATUS: Closed for XACML 2.0: no proposal by 20 Oct 2003. PROPOSAL: CHAMPION: Frank Siebenlist 17. XACML Policy in SAML Request Conditions Profile use of SAML Conditions element as a way for a PEP to pass an XACML Policy to be used by the PDP in evaluating the Request. TYPE: SAML Profile STATUS: Closed for XACML 2.0: no proposal by 20 Oct 2003. PROPOSAL: CHAMPION: Frank Siebenlist 18. Obligations in Rules Allow Rule to contain Obligations. TYPE: Simplicity of policy construction STATUS: Open issues. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200305/msg00011.html CHAMPION: Michiharu Kudo 19. Rule as lowest administrative unit Allow a Rule to be the lowest administrative unit for XACML. Probably required to support RuleIdReference. TYPE: New functionality STATUS: Closed for 2.0 20 Oct 2003. No proposal. Related #8. PROPOSAL: CHAMPION: Michiharu Kudo 20. Non-normative XACML interpretation guide Rationale, examples, possible implementation models; general information that would help XACML users know the intent of the XACML TC for the use of XACML elements. TYPE: New document not tied to XACML 2.0. STATUS: Needs proposal. Not part of 2.0. PROPOSAL: CHAMPION: ? 21. Non-normative XACML Primer Primer for XACML usage. TYPE: New document not tied to XACML 2.0. STATUS: Needs proposal. Not part of 2.0. PROPOSAL: CHAMPION: ? 22. time-in-range function Provide a function for comparing that a time of day is between two other times of day. TYPE: Erratum fix STATUS: Approved in general 30 Oct 2003. In 2.0 draft. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200309/msg00005.html CHAMPION: Seth Proctor 23. Use XQuery comparison functions for date, time, dateTime Allow date, time, and dateTime functions to handle comparing a value with no time zone with a value with a time zone. TYPE: Erratum fix STATUS: Approved in general 30 Oct 2003. Needs detailed proposal. Need to have new names if these are not functionally backwards compatible and should be additional, with old functions deprecated in 2.0. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200307/msg00044.html CHAMPION: Seth Proctor 24. Define a schema for function declarations Define a schema for declaring the signature of a function. Probably needed with #2 if #2 includes finding parsing and evaluation code for new FunctionIds. TYPE: New functionality STATUS: Closed for 2.0: no proposal by 20 Oct 2003. Related: #2. PROPOSAL: CHAMPION: Daniel Engovatov 25. Function for comparing file system pathnames. Define a function for specifying and comparing file system pathnames used in resource-id. Possibly new DataType also. TYPE: New functionality STATUS: Closed for 2.0: handle per #9 proposal. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200309/msg00088.html CHAMPION: Anne Anderson 26. Define policy reduction (partial evaluation) of a policy Define a process for reducing a policy based on known information, leaving only the unresolved predicates. The reduced policy is returned along with the context with which the reduction was done. TYPE: New functionality STATUS: Closed for 2.0 20 Oct 2003. Use case requirement satisfied using a different model. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00080.html CHAMPION: Frank Siebenlist 27. Version number element or attribute in an XACML policy. Some way of indicating the version of a policy having a particular XACML policy id, and a way of placing version constraints on a policy reference. TYPE: New functionality STATUS: No open issues. Needs detailed proposal. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00058.html CHAMPION: Seth Proctor 28. Define "current time/date/dateTime" during policy evaluation Specify whether time/date/dateTime are constant over a policy evaluation. Proposal is that it be constant. TYPE: Erratum fix STATUS: Approved in general 30 Oct 2003. In 2.0 draft. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00006.html http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #28 CHAMPION: Seth Proctor 29. Policy Authority Delegation The ability to express in a policy rule that a certain authorization authority is allowed to administer access control policy for a certain target: i.e. way to say "Frank is trusted to issue policies for resource X". If the PDP trusts the policy rule that states this, then the PDP would also trust policies issued by Frank for resource X. TYPE: New functionality STATUS: Open issues. Related: #1,29,31,35,38. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #1 http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #29 http://lists.oasis-open.org/archives/xacml/200310/msg00042.html #29 http://lists.oasis-open.org/archives/xacml/200310/msg00046.html http://lists.oasis-open.org/archives/xacml/200310/msg00053.html http://lists.oasis-open.org/archives/xacml/200310/msg00054.html http://lists.oasis-open.org/archives/xacml/200310/msg00060.html http://lists.oasis-open.org/archives/xacml/200310/msg00061.html http://lists.oasis-open.org/archives/xacml/200310/msg00062.html http://lists.oasis-open.org/archives/xacml/200310/msg00063.html 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] CHAMPION: Frank Siebenlist 30. Passing of explicit policy in the Authorization Decision Query This is the same as #17, except that it is more general (i.e. policy from PEP not necessarily passed in SAML Conditions), and also explicitly states that the authority to specify the policy to use has been delegated to the PEP. TYPE: SAML Profile STATUS: Closed for 2.0 21 Oct 2003. See #17. Solve by making remote PAP accessible to the local PDP. Possibly related: #29,38. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #2 http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #30 CHAMPION: Frank Siebenlist 31. Attribute Issuer as Subject The current attribute issuer type is a string. This restriction doesn't allow one to easily point at an issuer as Subject, and it doesn't allow for any path validation that goes more than one level deep. By allowing an attribute issuer of type subject, one could cater for more complex use-cases that involve policy delegation. TYPE: New functionality STATUS: Open issues. Related: #1,29,31,35,38. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #3 http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #31 CHAMPION: Frank Siebenlist 32. Standardize naming to specify rules for requestor's authz policy In a setting where a requester invokes certain operations of a service provider, the convention for the target of the service provider's policy is well defined: subject=requester, resource=service-provider, and action=operation. However, when we consider the policy evaluation on the requester's side to check whether an invocation on the service provider is allowed according to the requester's policy, then is it less clear. It is almost a mirror case, but if we take a convention where the "resource" is the one protected by the policy, the we should equate subject=service-provider and resource=requester with the same action=operation. Unfortunately, if we also have to consider the possibility that the service-provider can invoke an equivalent operation on the requester, then we need an additional way to discriminate between these cases. Maybe we can label the action with a category of "out-bound" (?). TYPE: New functionality STATUS: Open issues. Related: #1,29,31,35,38. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #4 http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #32 http://lists.oasis-open.org/archives/xacml/200310/msg00042.html #32 CHAMPION: Frank Siebenlist 33. XACML wsdl/porttype definition for <Req>/<Resp> exchange Abstract the decision request and response messages between the context handler and the PDP into a wsdl/porttype definition. TYPE: WSDL Profile STATUS: Needs detailed proposal. Related: #1. Not part of 2.0. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #5 http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #33 CHAMPION: Frank Siebenlist 34. porttype/operations to ask for required attributes Allow a requester to query the resource's authorization policy for the required attributes for a Target such that it "knows" which one are missing and would have to be retrieved and presented with any request. TYPE: WSDL Profile STATUS: Open issues. Related: #1. Not part of 2.0. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #6 http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #34 CHAMPION: Frank Siebenlist 35. Policy on revealing missing attributes The returning of the missing attribute info is sensitive information and should itself be subject to policy. TYPE: New functionality STATUS: Closed for 2.0 21 Oct 2003. Related: #1,29,31,35,38. Can be solved using existing XACML policies. PROPOSAL: OLD: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #7 CURRENT: http://lists.oasis-open.org/archives/xacml/200310/msg00081.html CHAMPION: Frank Siebenlist 36. Check for requester authorized to ask for authz decision Proposes that the PDP have a formally defined access control mechanism to "downstream PDPs". The PDP should check whether the upstream PDP requester, i.e. subject associated with the context handler, is allowed to ask for the authorization decision. We need to be able to state this in a policy statement, and describe the correct operating procedure. TYPE: New functionality STATUS: Open issues. Related: #1,29,30,31,35,38. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #36 http://lists.oasis-open.org/archives/xacml/200310/msg00074.html #36 on 20 Oct 2003 CHAMPION: Frank Siebenlist 37. Multiple <AttributeValue> elements for single <Attribute> in Request Allow <Attribute DataType="Y" ID=X> <AttributeValue DataType="Y">A</AttributeValue> <AttributeValue DataType="Y">B</AttributeValue> <AttributeValue DataType="Y">C</AttributeValue> </Attribute> as syntactic shorthand for <Attribute DataType="Y" ID=X> <AttributeValue DataType="Y">A</AttributeValue> </Attribute> <Attribute DataType="Y" ID=X> <AttributeValue DataType="Y">B</AttributeValue> </Attribute> <Attribute DataType="Y" ID=X> <AttributeValue DataType="Y">C</AttributeValue> </Attribute> This makes it easier to convert SAML Attributes into XACML Attributes, and is consistent with the way XPath treats the same set of AttributeValues. TYPE: Simplicity of Request construction STATUS: Approved as "OK idea" at 21 Oct 2003 F2F. In 2.0 draft. Related: #1. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #37 CHAMPION: Rebekah Lepro 38. Policies for the Administration of XACML Policies XACML defines a language to express policies about access to resources. But it is also desirable to create policies about the creation, modification and deletion of XACML policies. In a sense XACML already allows this, since XACML policies are agnostic to the semantics of the resources being protected. However, it is very desirable for administrative policies to specify not the "name" of policies being administered, but their "content." TYPE: New functionality STATUS: Open issues. Related: #1,29,31,35,38. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00050.html http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #38 http://lists.oasis-open.org/archives/xacml/200310/msg00054.html CHAMPION: Hal Lockhart 39. Make Status in the XACML Response optional Makes it possible to allow Status for Indeterminate situations to be conveyed in the protocol envelope (such as SAML DecisionStatement) rather than in the XACML Response for cases where that is more appropriate. Avoids having redundant and possibly inconsistent Status fields when XACML Response is carried in some envelope that also has a Status. TYPE: New functionality STATUS: Accepted in general for 2.0 30 Oct 2003. In 2.0 draft. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #39 http://lists.oasis-open.org/archives/xacml/200310/msg00040.html CHAMPION: Hal Lockhart 40. Define a SAML PolicyQuery and PolicyStatement Define syntax for SAML that will allow a Query for one or more Policy or PolicySet instances with specified Policy[Set]Ids or with copy of a Request Context that need to be matched, and will return the requested instances in a PolicyStatement in a SAML Assertion. TYPE: XACML Profile for Using SAML STATUS: Related to #48. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00031.html http://lists.oasis-open.org/archives/xacml/200310/msg00032.html http://lists.oasis-open.org/archives/xacml/200310/msg00034.html http://lists.oasis-open.org/archives/xacml/200310/msg00036.html http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #40 CHAMPION: Hal Lockhart 41. General attribute classifications instead of Subject, Resource, ... Instead of using the fixed attribute classifications "Subject", "Resource", "Action", and "Environment", allow arbitrary attribute classifications to be used, each identified by a URN and associated with a profile that explains its use and semantics. TYPE: New functionality. STATUS: Needs proposal. Due by 3 Nov 2003. Related: #2,24. PROPOSAL: CHAMPION: Daniel Engovatov 42. Requests asking for access to multiple elements in a hierarchical resource How to express requests that ask for access to multiple elements in a hierarchical resource, i.e. "Does Frank have access to all elements under /X/Y?". XACML currently defines a standard Resource AttributeId "urn:oasis:names:tc:xacml:1.0:resource:scope" that can be used to express whether a request applies to "Immediate", "Children", or "Descendents". XACML also currently defines a way to include an XML document in a <ResourceContent> element as part of a Request. This is sufficient if all hierarchies are assumed to be XML documents and if the document itself is always included in <ResourceContent> when multiple decisions are requested. What is missing is a way of handling hierarchical resources that are not XML documents, such as file system directories. To handle other types of hierarchies, it will be necessary to identify what type of hierarchy the resource is and, in a related profile, what syntax is to be used in expressing and referring to nodes and elements in hierarchies of that type. Proposal 200310/msg00078.html proposes to solve this by requiring all hierarchical resources to be represented and referenced as XML instances using XPath expressions. If this is accepted, then the specification needs to state this explicitly. TYPE: New functionality. STATUS: Accepted in general for 2.0 30 Oct 2003. Needs to be explained in specification in non-normative Hierarchical Resources section. Resolution is: supply resource hierarchy in XML representation in <ResourceContent>. Related: #9,25,42. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00078.html http://lists.oasis-open.org/archives/xacml/200310/msg00082.html CHAMPION: Simon Godik 43. Examine interactions between approved work items As part of the editorial process, a check is needed to ensure that there are no unexpected problematic interactions between approved work items. TYPE: Editorial STATUS: Open issues PROPOSAL: ? CHAMPION: ? 44. Fix examples in the XACML Specification Review & correct all examples before the 2.0 release. TYPE: Editorial STATUS: Abstract. Related: #45. PROPOSAL: Abstract CHAMPION: 45. Fix AttributeAssignment example in Section 4.2.4.3 (Rule 3) In this example, AttributeAssignments contain AttributeSelectors and AttributeDesignators. While this isn't illegal, the example implies something about the specification that isn't true (ie, that the PDP will interpret the contents of assignments). TYPE: Editorial STATUS: In 2.0 draft. 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 46. Status detail for missing attributes In 6.15 there is an explanation for what detail to include with the missing-attribute status code: Attributes specify one or more missing values, and if an AttributeValue is included, then this specifies an acceptable value. If no AttributeValue is included, then the PDP is specifying the identifier and datatype only. Sounds good. The problem is that the Attribute type is <xs:element ref="xacml-context:AttributeValue"/> This means that it's not valid to have an Attribute with no AttributeValue. So, it's not possible for the PDP to specify a missing attribute without specifying at least one acceptable value (note that even an empty AttributeValue tag, which is still legal, is still technically a value). PDPs need a way to specify missing attributes without providing acceptable values. TYPE: Erratum STATUS: Need to define a new "missing attribute" schema element that can return attribute meta-data (with or without Attribute Value information) for this. Accepted in general 30 Oct 2003. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00076.html http://lists.oasis-open.org/archives/xacml/200310/msg00077.html CHAMPION: Seth Proctor 47. New SAML Authorization Decision Query/Response using XACML TYPE: XACML Profile for Using SAML STATUS: SAML accepts XACML/OGSA proposal in general (link), but says XACML should define a SAML extension using the SAML namespace. We need to verify that SAML 2.0 changes do not invalidate our proposal. Only Sun(?), Oblix, and Entrust seem to use the SAML 1.0 version, so will be deprecated in SAML 2.0. PROPOSAL: (find link) CHAMPION: Anne Anderson and Hal Lockhart 48. PAP Interface to a PDP/PRP Define an interface to a PDP or PRP (Policy Repository Point) from a PAP for pushing and/or managing policies. TYPE: XACML Interface Definitions Specification STATUS: Related to #38,40. Requirements spec needed. PROPOSAL: CHAMPION: Tim Moses 49. Improve example showing how obligations work The example in Section 4.2.4.3 is somewhat misleading and has caused confusion among XACML users. See PROPOSAL for specific points. TYPE: Erratum STATUS: Closed. Same as #45. CHAMPION: Michiharu Kudo 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: Detailed proposal available (above). Awaiting vote. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200311/msg00060.html CHAMPION: Anne Anderson 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]