[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Updated XACML 2.0 Work Item Index, v1.52
Attached is an updated Work Item Index for XACML 2.0. 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
Title: XACML 2.0 Work Items Version: 1.52 Updated: 04/04/22 (yy/mm/dd) CURRENT 2.0 DRAFT: http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/6433/oasis-xacml-2_0-core-spec-wd-09.zip THIS WORK ITEM INDEX INCLUDES E-MAILS UP THROUGH: http://lists.oasis-open.org/archives/xacml/200404/msg00144.html -------------------------------------------------------------------- SUMMARY: Following work items are still open. Hierarchical Resources WI#9. Policies referring to hierarchical resources WI#58. Standard hierarchy schemas WI#42. Requests asking for access to multiple elements in a hierarchical resource ACTION [TC]: Settle at F2F WI#18. Obligations in Rules ACTION [TC]: Settle at F2F. Delegation and administration of policies [not for XACML 2.0] WI#29. Policy Authority Delegation WI#31. Attribute Issuer as Subject WI#32. Standardize naming to specify rules for requestor's authz policy WI#36. Check for requester authorized to ask for authz decision ACTION [TC]: Discuss at F2F. Frank explain #32. WI#43. Examine interactions between approved work items ACTION [TC]: All to review spec with eye to this topic. WI#52. New section explaining not backwards compatible and listing changes ACTION [Bill]: Has to wait for final draft. May be separate document WI#55. Converge SAML and XACML Attribute schema definitions ACTION [TC]: Waiting for SAML 2.0 decisions. Then, update our SAML Profile and/or submit an "Attribute Metadata Profile" to SSTC. WI#65. Add additional layer of aggregation to XACML attribute naming ACTION [TC]: Need to reach consensus. WI#68. Attribute assertion lifetime ACTION [TC]: Settle at F2F or drop. Majority on list did not want. WI#69. AttributeAssignment clarification ACTION [Tim]: fix affected examples. Tim still needs to fix; will look into. WI#70. Legal values for string DataType ACTION [Bill]: verify XML Spy does not require enclosing string in <xs:string> in order to be valid in Section 4.2.4.4. ACTION [Tim]: fix affected examples. Maybe call out in Appendix A. WI#71. Make ordered-* versions of combining algorithms mandatory ACTION [TC]: Reach consensus. 8 Apr FG recommended approve. Done in v9. Specifying PDP and PEP behavior WI#73. Specifying PDP and PEP behavior WI#72. Remove concept of "base policy" ACTION [Polar]: propose wording that does not violate Polar's concerns. ACTION [TC]: resolve at F2F. WI#74. Include references for "PDP", "PEP", "ADF", "AEF" -------------------------------------------------------------------- WI#1. Grid Requirements Any XACML changes needed to satisfy Grid requirements STATUS: Abstract RELATED: #2,3,4,16,17,29,30,31,32,33,34,35,36,37 CHAMPION: Frank Siebenlist WI#2. Location Information Way to pass information needed to configure a PDP and its context and policy handlers/finders in order to evaluate a policy. Examples of such information are: o where to find various Attributes, and what they are keyed off o where Attribute Authorities to be used are located o where to find function, combining algorithm, data-type, Attribute parsing code Such information might be embedded in a. an XACML Request b. an XACML policy c. a third document type TARGET: Location Information Profile TYPE: New functionality STATUS: Open, but not for 2.0; issues; see ACTION. RELATED: #1,24. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00022.html http://lists.oasis-open.org/archives/xacml/200402/msg00084.html [TC discussion] CHAMPION: Seth Proctor ACTION [Seth]: need revised proposal. WI#3. Multiple Actions per Request Support Requests containing multiple Actions. Response could either say "All permitted/denied" or could include a separate decision for each. TYPE: New functionality STATUS: Closed for 2.0: no proposal submitted by 20 Oct 2003 RELATED: #1. CHAMPION: Frank Siebenlist WI#4. Multiple Resources per Request Support Requests containing multiple Resources. Response could either say "All permitted/denied" or could include a separate decision for each. TYPE: New functionality STATUS: Closed for 2.0: no proposal submitted by 20 Oct 2003. RELATED: #1. CHAMPION: Frank Siebenlist WI#5. Privacy Requirements Any XACML changes needed to satisfy Privacy requirements. TARGET: XACML Privacy Profile TYPE: New functionality STATUS: Abstract. RELATED: #60 CHAMPION: Tim Moses, Anne Anderson WI#6. Domain-specific identifiers Define a set of domain-specific identifiers based on application usage of XACML. TYPE: New functionality STATUS: Closed for 2.0: no proposal submitted by 20 Oct 2003. CHAMPION: Michiharu Kudo WI#7. ConditionReference Allow a Rule to contain a ConditionReference element as an alternative to a Condition element. The ConditionReference would identify a Condition element specified elsewhere. This allows a single Condition to be re-used in Rules under different Targets. An optional ConditionId attribute would be added to the Condition element to support this. TYPE: Simplicity of policy construction. STATUS: Included in XACML 2.0 Draft 0.7. Approved 1 April 2004. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200304/msg00039.html [use cases] http://lists.oasis-open.org/archives/xacml/200403/msg00048.html [Text and schema-Polar] http://lists.oasis-open.org/archives/xacml/200403/msg00062.html [Text and schema-Simon] http://lists.oasis-open.org/archives/xacml/200403/msg00068.html [Tim: keep <Condition>] http://lists.oasis-open.org/archives/xacml/200403/msg00071.html [Simon: agrees] http://lists.oasis-open.org/archives/xacml/200403/msg00074.html [Polar: compromise] http://lists.oasis-open.org/archives/xacml/200403/msg00083.html [Polar agrees with Tim] http://lists.oasis-open.org/archives/xacml/200403/msg00084.html [Polar:type checking] http://lists.oasis-open.org/archives/xacml/200403/msg00101.html [Tim:alt. to Simon] http://lists.oasis-open.org/archives/xacml/200403/msg00107.html [Simon:var close to rule] http://lists.oasis-open.org/archives/xacml/200403/msg00110.html [Expression final] http://lists.oasis-open.org/archives/xacml/200403/msg00113.html [Expression not final] http://lists.oasis-open.org/archives/xacml/200403/msg00114.html [Placement:leave as is] CHAMPION: Michiharu Kudo WI#8. RuleIdReference Define RuleIdReference analogous to PolicyIdReference and PolicySetIdReference. TYPE: Simplicity of policy construction STATUS: Closed for 2.0 20 Oct 2003. Can do this now with a Policy containing a single Rule. RELATED: #19. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200305/msg00004.html CHAMPION: Anne Anderson (on behalf of ebXML) WI#9. Policies referring to hierarchical resources [This is different from WI#42. WI#42 is about how a single request can ask for access to multiple nodes in a hierarchy, getting back multiple responses (which XACML already supports). This item is about how a policy can protect all nodes in a subtree of a hierarchy without having to specify a separate policy condition for each.] How to express policies that apply to a hierarchy of resources. E.g. "Frank can read any file under directory /X/Y". Or "permission to read any file requires permission to execute any directory above the file." TYPE: New functionality STATUS: Open for 2.0. P1 below accepted for 2.0 8 Jan 2004, but see newer OPEN ISSUE below. RELATED: #25, 42, 58 PROPOSALS: P1:http://lists.oasis-open.org/archives/xacml/200310/msg00078.html http://lists.oasis-open.org/archives/xacml/200404/msg00033.html [use cases;reqs] CURRENT: http://lists.oasis-open.org/archives/xacml/200404/msg00119.html 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. 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: Included in XACML 2.0 Draft 0.9. Approved 15 April 04. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200403/msg00125.html [Michiharu:summary] http://lists.oasis-open.org/archives/xacml/200403/msg00133.html [Polar:mult.params?] http://lists.oasis-open.org/archives/xacml/200403/msg00137.html [Michiharu to Polar] http://lists.oasis-open.org/archives/xacml/200404/msg00001.html [Anne:Summary] CHAMPION: Michiharu Kudo APPROVED: a) Schema will be as specified in http://lists.oasis-open.org/archives/xacml/200403/msg00125.html b) <CombinerParameter> <AttributeValue>/<Expression> elements will have a DataType so the PDP can completely evaluate the value before passing it to the CombiningAlgorithm. c) <CombinerParameters> are children of the <Policy>, not of the <Rule>; i.e. they are specified outside the <Rule> elements to which they apply. d) Each <CombinerParameter> includes RuleIdRef to bind it to its corresponding <Rule> element. WI#11. XACML Extension Points Define schema extension points for XACML. See http://lists.oasis-open.org/archives/xacml/200310/msg00098.html for information that may be relevant on extension points. TYPE: New functionality STATUS: Closed for 2.0 on 12 Feb 2004. Any extension points should be for specific functionality, not general extensions that might become "kitchen sink" elements. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200402/msg00039.html [TC discuss] CHAMPION: Anne Anderson WI#12. Environment Element in Target Allow the Target Element to include an Environment element, just as it now includes Subject, Resource, and Action elements. TYPE: New functionality STATUS: Included in 2.0 draft. Accepted for 2.0 on 8 Jan 2004. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200305/msg00012.html CHAMPION: Michiharu Kudo WI#13. Optional Target Elements Make Subjects, Resources, Actions elements optional in a Target. Missing element has same semantics as <Any.../> Make Target itself optional. Missing element has same semantics as a Target containing <AnySubject/>, <AnyResource/>, <AnyAction/>. <Any...> dropped. Environment elements to be treated same as Subject, Resource, Action as far as omitted elements are concerned. No need to add "<Subjects></Subjects> = false" since schema makes an empty <Subjects> element invalid. TYPE: Simplicity of policy construction STATUS: Included in 2.0 draft 05 Section 5.5. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00038.html http://lists.oasis-open.org/archives/xacml/200401/msg00062.html [FG accepts] http://lists.oasis-open.org/archives/xacml/200401/msg00064.html [Bill] http://lists.oasis-open.org/archives/xacml/200401/msg00065.html [Daniel] http://lists.oasis-open.org/archives/xacml/200401/msg00066.html [Daniel] http://lists.oasis-open.org/archives/xacml/200401/msg00067.html [Bill] http://lists.oasis-open.org/archives/xacml/200401/msg00068.html [Bill] http://lists.oasis-open.org/archives/xacml/200401/msg00069.html [Daniel] http://lists.oasis-open.org/archives/xacml/200402/msg00039.html [TC discuss] CHAMPION: Hal Lockhart WI#14. Signature envelope requirements Any new XACML work items to meet requirements for signature envelopes around an XACML schema instance, such as including an XACML Policy or Request in a signed SAML Assertion. TYPE: New functionality STATUS: Abstract. RELATED: none WI#15. Encrypted XACML schema instance requirements Any new XACML work items to meet requirements for encrypted XACML Policy or Context schema instances. TYPE: New functionality STATUS: Abstract. RELATED: none WI#16. XACML Policy in SAML Response Conditions Profile uses of XACML Policy instances as a syntax for specifying Conditions in a SAML Response. TARGET: SAML Profile STATUS: Closed for 2.0: no proposal by 20 Oct 2003. CHAMPION: Frank Siebenlist WI#17. XACML Policy in SAML Request Conditions Profile use of SAML Conditions element as a way for a PEP to pass an XACML Policy to be used by the PDP in evaluating the Request. TARGET: SAML Profile STATUS: Closed for 2.0: no proposal by 20 Oct 2003. CHAMPION: Frank Siebenlist WI#18. Obligations in Rules Allow Rule to contain Obligations. TYPE: Simplicity of policy construction STATUS: Open for 2.0. Settle at Apr 04 F2F. 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] http://lists.oasis-open.org/archives/xacml/200404/msg00091.html [Seth-summary] Conditionalized obligation: http://lists.oasis-open.org/archives/xacml/200404/msg00079.html [Polar] Example of obligation in rule: http://lists.oasis-open.org/archives/xacml/200404/msg00110.html [Michiharu] CHAMPION: Michiharu Kudo 15 Apr 04 discussion: 2 issues 1. How much do we specify PEP's required behavior? Separated from second issue 2. Discussion on different approaches to use case Polar: When does an Obligation apply? Really wants to conditionalize an obligation (Polar submitted proposal for this). If condition is true and if "fulfillon" is consistent with effect, then obligation would apply. Opposed to indeterministic evaluation of obligations. Michiharu: Remove "fulfillon" from an obligation that is in a Rule. Applies only if Rule returns its "Effect". Polar: more clear to specifically conditionalize obligations. Keep rules that supply access decisions separate from obligations. Rule combining algorithm more complex if put obligations in Rule. Michiharu: if want Obligation associated with conditions of a Rule, would have to state same condition twice, in two different ways: Rule (Target + Condition) and Conditionalized Obligation (Condition, including Target predicates) Polar: could include a Target in conditionalized obligations Simon: why can't we create single semantic that would apply to Obligations in Rule and in Policy No resolution. WI#19. Rule as lowest administrative unit Allow a Rule to be the lowest administrative unit for XACML. Probably required to support RuleIdReference. TYPE: New functionality STATUS: Closed for 2.0 20 Oct 2003. No proposal. RELATED: #8. CHAMPION: Michiharu Kudo WI#20. Non-normative XACML interpretation guide Rationale, examples, possible implementation models; general information that would help XACML users know the intent of the XACML TC for the use of XACML elements. TARGET: XACML Interpretation Guide STATUS: Open, but not for 2.0. Needs proposal. PROPOSAL: CHAMPION: ? WI#21. Non-normative XACML Primer Primer for XACML usage. TARGET: XACML Primer STATUS: Open, but not for 2.0. Needs proposal. PROPOSAL: CHAMPION: ? WI#22. time-in-range function Provide a function for comparing that a time of day is between two other times of day. TYPE: Erratum fix STATUS: Included in 2.0 draft. Approved in general 30 Oct 2003. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200309/msg00005.html CHAMPION: Seth Proctor WI#23. Use XQuery comparison functions for date, time, dateTime Allow date, time, and dateTime functions to handle comparing a value with no time zone with a value with a time zone. TYPE: Erratum fix STATUS: Included in XACML 2.0 Draft 0.9. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200404/msg00039.html 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. CHAMPION: Daniel Engovatov WI#25. Function for comparing file system pathnames. Define a function for specifying and comparing file system pathnames used in resource-id. Possibly new DataType also. TYPE: New functionality STATUS: Closed for 2.0: handle per WI#9 proposal. RELATED: #9, 42, 58 PROPOSAL: http://lists.oasis-open.org/archives/xacml/200309/msg00088.html CHAMPION: Anne Anderson WI#26. Define policy reduction (partial evaluation) of a policy Define a process for reducing a policy based on known information, leaving only the unresolved predicates. The reduced policy is returned along with the context with which the reduction was done. TYPE: New functionality STATUS: Closed for 2.0 20 Oct 2003. Use case requirement satisfied using a different model. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00080.html CHAMPION: Frank Siebenlist WI#27. Version number element or attribute in an XACML policy. Some way of indicating the version of a policy having a particular XACML policy id, and a way of placing version constraints on a policy reference. TYPE: New functionality STATUS: Included in 2.0 05 draft. Accepted for 2.0 8 Jan 2004. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200312/msg00062.html [Seth] http://lists.oasis-open.org/archives/xacml/200312/msg00067.html [Tim] CHAMPION: Seth Proctor WI#28. Define "current time/date/dateTime" during policy evaluation Specify whether time/date/dateTime are constant over a policy evaluation. Proposal is that it be constant. TYPE: Erratum fix STATUS: Included in 2.0 draft. Approved in general 30 Oct 2003. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00006.html http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #28 CHAMPION: Seth Proctor WI#29. Policy Authority Delegation The ability to express in a policy rule that a certain authorization authority is allowed to administer access control policy for a certain target: i.e. way to say "Frank is trusted to issue policies for resource X". If the PDP trusts the policy rule that states this, then the PDP would also trust policies issued by Frank for resource X. TARGET: Administration Policy Profile STATUS: Open for 2.0, or maybe not. No consensus yet on proposal. Need to review Use Cases Draft below. Topic for F2F. Use Cases Draft approved as TC Working Draft not intended for standardization at 4 March 2004 TC meeting. RELATED: #1,29,31,35,38. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #1 http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #29 http://lists.oasis-open.org/archives/xacml/200310/msg00042.html #29 http://lists.oasis-open.org/archives/xacml/200310/msg00046.html http://lists.oasis-open.org/archives/xacml/200310/msg00053.html http://lists.oasis-open.org/archives/xacml/200310/msg00054.html http://lists.oasis-open.org/archives/xacml/200310/msg00060.html http://lists.oasis-open.org/archives/xacml/200310/msg00061.html http://lists.oasis-open.org/archives/xacml/200310/msg00062.html http://lists.oasis-open.org/archives/xacml/200310/msg00063.html http://lists.oasis-open.org/archives/xacml/200311/msg00022.html [Frank:Haskell model] http://lists.oasis-open.org/archives/xacml/200311/msg00030.html [schema changes] http://lists.oasis-open.org/archives/xacml/200311/msg00032.html [Tim:summary] http://lists.oasis-open.org/archives/xacml/200311/msg00034.html [Bill:weird case] http://lists.oasis-open.org/archives/xacml/200311/msg00036.html http://lists.oasis-open.org/archives/xacml/200312/msg00009.html [Polar:Abadi calculus] http://lists.oasis-open.org/archives/xacml/200312/msg00015.html [Use cases] http://lists.oasis-open.org/archives/xacml/200312/msg00019.html [Von Welch,resp] http://lists.oasis-open.org/archives/xacml/200312/msg00022.html [Polar to Frank] http://lists.oasis-open.org/archives/xacml/200312/msg00025.html [Frank to Polar] http://lists.oasis-open.org/archives/xacml/200402/msg00059.html [FG discuss] http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/5780/oasis_xacml_delegation_use-cases_wd_01.zip [Delegation Use Cases Working Draft] CHAMPION: Frank Siebenlist WI#30. Passing of explicit policy in the Authorization Decision Query This is the same as #17, except that it is more general (i.e. policy from PEP not necessarily passed in SAML Conditions), and also explicitly states that the authority to specify the policy to use has been delegated to the PEP. TYPE: SAML Profile STATUS: Closed for 2.0 21 Oct 2003. Solve by making remote PAP accessible to the local PDP. RELATED: #17, possibly #29,38 PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #2 http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #30 CHAMPION: Frank Siebenlist WI#31. Attribute Issuer as Subject The current attribute issuer type is a string. This restriction doesn't allow one to easily point at an issuer as Subject, and it doesn't allow for any path validation that goes more than one level deep. By allowing an attribute issuer of type subject, one could cater for more complex use-cases that involve policy delegation. TYPE: New functionality STATUS: Open for 2.0. No consensus; discuss at F2F. See ACTION. RELATED: #1,29,31,35,38. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #3 http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #31 CHAMPION: Frank Siebenlist ACTION [All; 12 Feb 2004]: Depends on Admin Policy model. Request use cases from those interested in this item. Plan to agree on a model at the next F2F. This will require people to do homework ahead of time. Align with SAML: touched on in Tim's delegation use case document. WI#32. Standardize naming to specify rules for requestor's authz policy In a setting where a requester invokes certain operations of a service provider, the convention for the target of the service provider's policy is well defined: subject=requester, resource=service-provider, and action=operation. However, when we consider the policy evaluation on the requester's side to check whether an invocation on the service provider is allowed according to the requester's policy, then is it less clear. It is almost a mirror case, but if we take a convention where the "resource" is the one protected by the policy, the we should equate subject=service-provider and resource=requester with the same action=operation. Unfortunately, if we also have to consider the possibility that the service-provider can invoke an equivalent operation on the requester, then we need an additional way to discriminate between these cases. Maybe we can label the action with a category of "out-bound" (?). TARGET: Separate profile? TYPE: New functionality. STATUS: Open for 2.0. No consensus. See ACTION. RELATED: #1,29,31,35,38. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #4 http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #32 http://lists.oasis-open.org/archives/xacml/200310/msg00042.html #32 http://lists.oasis-open.org/archives/xacml/200402/msg00059.html [FG discuss] CHAMPION: Frank Siebenlist ACTION [Frank; 12 Feb 2004]: explain use case in a teleconference, not just in an e-mail. WI#33. XACML wsdl/porttype definition for <Req>/<Resp> exchange Abstract the decision request and response messages between the context handler and the PDP into a wsdl/porttype definition. TARGET: WSDL Profile STATUS: Open, but not for 2.0. Needs detailed proposal. RELATED: #1. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #5 http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #33 CHAMPION: Frank Siebenlist WI#34. porttype/operations to ask for required attributes Allow a requester to query the resource's authorization policy for the required attributes for a Target such that it "knows" which one are missing and would have to be retrieved and presented with any request. TARGET: WSDL Profile STATUS: Open, but not for 2.0. Open issues. RELATED: #1. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #6 http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #34 CHAMPION: Frank Siebenlist WI#35. Policy on revealing missing attributes The returning of the missing attribute info is sensitive information and should itself be subject to policy. TYPE: New functionality STATUS: Closed for 2.0 21 Oct 2003. Can be solved using existing XACML policies. RELATED: #1,29,31,35,38. PROPOSAL: OLD: http://lists.oasis-open.org/archives/xacml/200308/msg00008.html #7 CURRENT: http://lists.oasis-open.org/archives/xacml/200310/msg00081.html CHAMPION: Frank Siebenlist WI#36. Check for requester authorized to ask for authz decision Proposes that the PDP have a formally defined access control mechanism to "downstream PDPs". The PDP should check whether the upstream PDP requester, i.e. subject associated with the context handler, is allowed to ask for the authorization decision. We need to be able to state this in a policy statement, and describe the correct operating procedure. TARGET: Administrative Policy Profile? TYPE: New functionality. STATUS: Open for 2.0. Open issues for F2F. See ACTION. RELATED: #1,29,30,31,35,38. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00035.html #36 http://lists.oasis-open.org/archives/xacml/200310/msg00074.html #36 on 20 Oct 2003 http://lists.oasis-open.org/archives/xacml/200402/msg00059.html [FG discuss] CHAMPION: Frank Siebenlist ACTION [All; 12 Feb 2004]: This should be an aspect of our Administrative Policy, and should be resolved at the next F2F as part of the overall Administrative Policy framework. WI#37. Multiple <AttributeValue> elements for single <Attribute> in Request Allow <Attribute DataType="Y" ID=X> <AttributeValue DataType="Y">A</AttributeValue> <AttributeValue DataType="Y">B</AttributeValue> <AttributeValue DataType="Y">C</AttributeValue> </Attribute> as syntactic shorthand for <Attribute DataType="Y" ID=X> <AttributeValue DataType="Y">A</AttributeValue> </Attribute> <Attribute DataType="Y" ID=X> <AttributeValue DataType="Y">B</AttributeValue> </Attribute> <Attribute DataType="Y" ID=X> <AttributeValue DataType="Y">C</AttributeValue> </Attribute> This makes it easier to convert SAML Attributes into XACML Attributes, and is consistent with the way XPath treats the same set of AttributeValues. TYPE: Simplicity of Request construction STATUS: Included in 2.0 draft 0.7. RELATED: #55 PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #37 http://lists.oasis-open.org/archives/xacml/200401/msg00019.html [Rebekah - Q's] http://lists.oasis-open.org/archives/xacml/200402/msg00029.html [Rebekah] http://lists.oasis-open.org/archives/xacml/200402/msg00096.html [FG discussion] http://lists.oasis-open.org/archives/xacml/200403/msg00001.html [Tim's clarificatin] http://lists.oasis-open.org/archives/xacml/200403/msg00002.html [Seth to Tim] http://lists.oasis-open.org/archives/xacml/200403/msg00015.html [response to Rebekah Q's] CHAMPION: Rebekah Lepro WI#38. Policies for the Administration of XACML Policies XACML defines a language to express policies about access to resources. But it is also desirable to create policies about the creation, modification and deletion of XACML policies. In a sense XACML already allows this, since XACML policies are agnostic to the semantics of the resources being protected. However, it is very desirable for administrative policies to specify not the "name" of policies being administered, but their "content." TYPE: New functionality. TARGET: Administration Policy Profile STATUS: Closed as duplicate of #19 on 12 Feb 2004. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200308/msg00050.html http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #38 http://lists.oasis-open.org/archives/xacml/200310/msg00054.html http://lists.oasis-open.org/archives/xacml/200402/msg00059.html [FG discuss] CHAMPION: Hal Lockhart WI#39. Make Status in the XACML Response optional Makes it possible to allow Status for Indeterminate situations to be conveyed in the protocol envelope (such as SAML DecisionStatement) rather than in the XACML Response for cases where that is more appropriate. Avoids having redundant and possibly inconsistent Status fields when XACML Response is carried in some envelope that also has a Status. TYPE: New functionality STATUS: Included in 2.0 draft. Accepted in general for 2.0 30 Oct 2003. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #39 http://lists.oasis-open.org/archives/xacml/200310/msg00040.html CHAMPION: Hal Lockhart WI#40. Define a SAML PolicyQuery and PolicyStatement Define syntax for SAML that will allow a Query for one or more Policy or PolicySet instances with specified Policy[Set]Ids or with copy of a Request Context that need to be matched, and will return the requested instances in a PolicyStatement in a SAML Assertion. TYPE: XACML SAML Profile STATUS: Open, but not for 2.0. RELATED: #48. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00031.html http://lists.oasis-open.org/archives/xacml/200310/msg00032.html http://lists.oasis-open.org/archives/xacml/200310/msg00034.html http://lists.oasis-open.org/archives/xacml/200310/msg00036.html http://lists.oasis-open.org/archives/xacml/200310/msg00037.html #40 http://lists.oasis-open.org/archives/xacml/200402/msg00077.html [SAML F2F status] http://lists.oasis-open.org/archives/xacml/200402/msg00095.html [SAML Profile draft] CHAMPION: Hal Lockhart WI#41. General attribute classifications instead of Subject, Resource, ... Instead of using the fixed attribute classifications "Subject", "Resource", "Action", and "Environment", allow arbitrary attribute classifications to be used, each identified by a URN and associated with a profile that explains its use and semantics. TYPE: New functionality. STATUS: Closed for 2.0 8 Jan 2004, although could be considered for future version if proposal submitted. RELATED: #2,24. CHAMPION: Daniel Engovatov WI#42. Requests asking for access to multiple elements in a hierarchical resource [This is different from WI#9. This item is about how a single request can ask for access to multiple nodes in a hierarchy, getting back multiple responses (which XACML already supports). XACML also already supports this when resource is an XML document using the "scope" = "Immediate", "Children", "Descendents" attribute. WI#9 is about how a policy can protect all nodes in a subtree of a hierarchy without having to specify a separate policy condition for each node.] How to express requests that ask for access to multiple elements in a hierarchical resource, i.e. "Does Frank have access to all elements under /X/Y?". XACML currently defines a standard Resource AttributeId "urn:oasis:names:tc:xacml:1.0:resource:scope" that can be used to express whether a request applies to "Immediate", "Children", or "Descendents". XACML also currently defines a way to include an XML document in a <ResourceContent> element as part of a Request. This is sufficient if all hierarchies are assumed to be XML documents and if the document itself is always included in <ResourceContent> when multiple decisions are requested. What is missing is a way of handling hierarchical resources that are not XML documents, such as file system directories. To handle other types of hierarchies, it will be necessary to identify what type of hierarchy the resource is and, in a related profile, what syntax is to be used in expressing and referring to nodes and elements in hierarchies of that type. Proposal 200310/msg00078.html proposes to solve this by requiring all hierarchical resources to be represented and referenced as XML instances using XPath expressions. If this is accepted, then the specification needs to state this explicitly. TYPE: New functionality. STATUS: Open for 2.0. To be settled at Apr 04 F2F. 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,58. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200404/msg00119.html CHAMPION: Simon Godik WI#43. Examine interactions between approved work items As part of the editorial process, a check is needed to ensure that there are no unexpected problematic interactions between approved work items. TYPE: Editorial STATUS: Open for 2.0. Waiting for resolutions to all other open WI's. CHAMPION: ? WI#44. Fix examples in the XACML Specification Review & correct all examples before the 2.0 release. TYPE: Editorial STATUS: Abstract. RELATED: #45. WI#45. Fix AttributeAssignment example in Section 4.2.4.3 (Rule 3) In this example, AttributeAssignments contain AttributeSelectors and AttributeDesignators. While this isn't illegal, the example implies something about the specification that isn't true (ie, that the PDP will interpret the contents of assignments). TYPE: Editorial STATUS: Included in 2.0 draft. Accepted 12 Feb. Related #44. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200310/msg00064.html http://lists.oasis-open.org/archives/xacml/200310/msg00067.html http://lists.oasis-open.org/archives/xacml/200310/msg00068.html http://lists.oasis-open.org/archives/xacml/200310/msg00069.html http://lists.oasis-open.org/archives/xacml/200311/msg00009.html CHAMPION: Michiharu Kudo WI#46. Status detail for missing attributes In 6.15 there is an explanation for what detail to include with the missing-attribute status code: Attributes specify one or more missing values, and if an AttributeValue is included, then this specifies an acceptable value. If no AttributeValue is included, then the PDP is specifying the identifier and datatype only. Sounds good. The problem is that the Attribute type is <xs:element ref="xacml-context:AttributeValue"/> This means that it's not valid to have an Attribute with no AttributeValue. So, it's not possible for the PDP to specify a missing attribute without specifying at least one acceptable value (note that even an empty AttributeValue tag, which is still legal, is still technically a value). PDPs need a way to specify missing attributes without providing acceptable values. Need to define a new "missing attribute" schema element that can return attribute meta-data (with or without Attribute Value information) for this. TYPE: Erratum STATUS: Included in XACML 2.0 Draft 0.9. Accepted in general 30 Oct 2003. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200404/msg00009.html CHAMPION: Seth Proctor WI#47. New SAML Authorization Decision Query/Response using XACML TARGET: XACML SAML Profile STATUS: Open, but not for 2.0. SAML accepts XACML/OGSA proposal in general, but says XACML should define a SAML extension using the XACMLnamespace. We need to verify that SAML 2.0 changes do not invalidate our proposal. Only Sun(?), Oblix, and Entrust seem to use the SAML 1.0 version, so will be deprecated in SAML 2.0. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200402/msg00077.html [SAML F2F status] http://lists.oasis-open.org/archives/xacml/200402/msg00095.html [SAML Profile draft] http://lists.oasis-open.org/archives/xacml/200403/msg00099.html [Polar] CHAMPION: Anne Anderson and Hal Lockhart WI#48. PAP Interface to a PDP/PRP Define an interface to a PDP or PRP (Policy Repository Point) from a PAP for pushing and/or managing policies. TARGET: XACML Interface Definitions Specification STATUS: Open, but not for 2.0. Requirements spec needed. RELATED: #38,40. PROPOSAL: CHAMPION: Tim Moses (expects to get to this soon 26 Feb 2004). WI#49. Improve example showing how obligations work The example in Section 4.2.4.3 is somewhat misleading and has caused confusion among XACML users. See PROPOSAL for specific points. TYPE: Erratum STATUS: Closed. Same as #45. CHAMPION: Michiharu Kudo WI#50. Fix obligations erratum: fulfilled by PDP Lines 2077-2078 in the 1.1 specification say "The <Obligations> element SHALL contain a set of obligations that MUST be fulfilled by the PDP in conjunction with the authorization decision." "PDP" should be "PEP". TYPE: Erratum STATUS: Included in 2.0 draft. Accepted for 2.0 8 Jan 2004. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200311/msg00060.html CHAMPION: Anne Anderson WI#51. Clarify obligations: "fulfill" vs. "understand" Lines:1768-1770,2731-2733,2756-2757,2859-2862,3060-3062 Intermixed uses of "fulfill" and "understand" with respect to obligations semantics is confusing. For example, "what is the recommended action for an obligation that is understood yet is unable to be fulfilled?" TYPE: Erratum STATUS: Included in 2.0 draft 05. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200311/msg00059.html CHAMPION: Michiharu Kudo WI#52. New section explaining not backwards compatible and listing changes The XACML 2.0 specification should have a new section that explains 2.0 is not backwards compatible with 1.0 or 1.1, and listing the changes made between 1.0 (and/or 1.1) and 2.0. TYPE: Editorial STATUS: Open for 2.0. Awaiting resolution of other WI's. PROPOSAL: CHAMPION: Bill Parducci ACTION [Bill]: submit draft text to Tim by 17 April so can take into account changes in other proposals. WI#53. Drop <Function> element I believe its purpose can be served by the <Apply> element when the FunctionId attribute identifies one of the bag functions. We already allow a similar special case in the <Condition> element, which is an <Apply> element whose FunctionId attribute must identify a function whose return type is boolean. As currently structured, the bag function does not "enclose" the attributes or functions to which it applies. If we require the use of the <Apply> element instead, the bag function can enclose the attributes or functions to which it applies. See lines [a477] to [a491] in draft 3. TYPE: Simplicity of policy construction. STATUS: Included in XACML 2.0 Draft 7 Section 5.33. 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 WI#54. Is resource-id required? First issue: V1.1 Section 6.3 schema fragment says resource must have 0 or more attributes, but text that follows says there must be one and only one instance of the "resource-id" attribute (implying one or more attributes, exactly one of which must be "resource-id"). These two should be made consistent. [Tim] Second issue: Why do we require "resource-id"? Some policies may depend only on the security label of the resource, only on the host machine where the resource is located, or some other attribute of the resource, but may not care about the actual "resource-id" at all. [Anne] TYPE: Simplicity of policy construction and erratum fix STATUS: Open for 2.0. See ISSUE. Included in 2.0 Draft ?. Voted to make resource-id optional 8 Jan 2004. See ACTION. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200401/msg00000.html [Tim] http://lists.oasis-open.org/archives/xacml/200401/msg00001.html [Anne] http://lists.oasis-open.org/archives/xacml/200401/msg00002.html [Seth to Anne] http://lists.oasis-open.org/archives/xacml/200401/msg00003.html [Bill to Tim] http://lists.oasis-open.org/archives/xacml/200401/msg00004.html [Anne] http://lists.oasis-open.org/archives/xacml/200401/msg00005.html [Daniel to Anne] http://lists.oasis-open.org/archives/xacml/200401/msg00006.html [Satoshi to Anne] http://lists.oasis-open.org/archives/xacml/200401/msg00007.html [Daniel to Satoshi] http://lists.oasis-open.org/archives/xacml/200401/msg00008.html [Satoshi to Daniel] http://lists.oasis-open.org/archives/xacml/200401/msg00009.html [Daniel to Satoshi] http://lists.oasis-open.org/archives/xacml/200401/msg00010.html [Satoshi to Daniel] http://lists.oasis-open.org/archives/xacml/200401/msg00011.html [Daniel to Satoshi] http://lists.oasis-open.org/archives/xacml/200401/msg00012.html [Satoshi] http://lists.oasis-open.org/archives/xacml/200401/msg00013.html [Daniel to Satoshi] http://lists.oasis-open.org/archives/xacml/200401/msg00014.html [Satoshi to Daniel] http://lists.oasis-open.org/archives/xacml/200401/msg00015.html [Daniel to Satoshi] http://lists.oasis-open.org/archives/xacml/200401/msg00016.html [Satoshi to Seth] http://lists.oasis-open.org/archives/xacml/200401/msg00017.html [Tim] CHAMPION: Tim Moses and Anne Anderson ACTION [Tim]: make optional in next draft. ISSUE: 8 Apr 04 FG: Is some Attribute that can be supplied in the Request and returned in the Response necessary? Actual use case is what to return in the Status if resource-id is not available? WI#55. Converge SAML and XACML Attribute schema definitions Need algorithmic mapping between SAML Attribute and XACML Attribute. Some issues are keeping Issuer syntax compatible and handling two-part SAML Attribute names (domain plus id) and one-part XACML Attribute. Might be able to handle some of this using AttributeSelector, and inserting SAML Attribute Assertion as AttributeValue with DataType of saml:Assertion or saml:Attribute. TYPE: Interoperability. TARGET: Some of this could go into an XACML SAML Profile, but not all. STATUS: Open for 2.0. Still under discussion. SAML has not frozen their 2.0 Attribute definition. Should not hold up XACML 2.0 for SAML 2.0 [FG 11 Mar 2004] RELATED: #37 PROPOSAL: http://www.oasis-open.org/apps/org/workgroup/security/download.php/4884/draft-sstc-attribute-02.pdf [Rebekah SAML proposal] http://lists.oasis-open.org/archives/xacml/200401/msg00031.html [Anne - draft answer to SAML] http://lists.oasis-open.org/archives/xacml/200401/msg00032.html [Anne] http://lists.oasis-open.org/archives/xacml/200401/msg00034.html [Scott Cantor] http://lists.oasis-open.org/archives/xacml/200401/msg00039.html [SAML/XACML mtg] http://lists.oasis-open.org/archives/xacml/200402/msg00077.html [SAML F2F status] http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/5854/wd-xacml-saml-profile-02.pdfy [SAML Profile draft] http://lists.oasis-open.org/archives/xacml/200403/msg00065.html [XACML options] http://lists.oasis-open.org/archives/xacml/200403/msg00112.html [Status, options] http://lists.oasis-open.org/archives/xacml/200403/msg00139.html [SSTC:drop ValueType] http://lists.oasis-open.org/archives/xacml/200404/msg00053.html [XACML TC recs] http://lists.oasis-open.org/archives/xacml/200404/msg00090.html [Eve Maler] http://lists.oasis-open.org/archives/xacml/200404/msg00097.html [SSTC summary] CHAMPION: Rebekah Lepro WI#56. Should Request Context be optional (non-normative) Use of the Request Context should be non-normative, so long as policy evaluation is consistent with the behavior given a Request Context. TYPE: Erratum fix STATUS: Included in 2.0 Draft 06. Accepted for 2.0 8 Jan 2004. Detailed text below accepted 22 Jan 2004. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200401/msg00037.html [detailed text] CHAMPION: Hal Lockhart WI#57. Make Environment element optional in Request Context TYPE: Simplicity of Request construction. STATUS: Closed for 2.0 8 Jan 2004. Leave as is: minOccurs="1". WI#58. Standard hierarchy schemas Given resolution to hierarchical resources in WI#9, there needs to be a standard schema for certain common hierarchies such as UFS. TYPE: Interoperability. TARGET: Could be separate profile, but if a single standard schema for hierarchies developed, it should be part of 2.0. STATUS: Open for 2.0. To be settled at Apr 04 F2F. RELATED: #9,25,42 PROPOSAL: http://lists.oasis-open.org/archives/xacml/200404/msg00119.html CHAMPION: Anne Anderson (for UFS and WFS, at least) WI#59. Define standard "role" subject attribute Add following to Appendix B.5 "Subject attributes": This identifier indicates a role associated with the subject. Values of this attribute SHOULD be of type "http://www.w3.org/2001/XMLSchema#anyURI". urn:oasis:names:tc:xacml:2.0:subject:role TARGET: XACML Profile for Role Based Access Control. STATUS: Open, but not for 2.0. 12 Feb 2004 FG recommended including in next RBAC draft. Need vote to approve RBAC Version 02 as Committee Draft with this. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200401/msg00038.html CHAMPION: Anne Anderson WI#60. Define standard "purpose" attributes In order to deal with certain regulatory requirements, it would be useful to have a standard "purpose" attribute for resource and for action. urn:oasis:names:tc:xacml:2.0:resource:purpose urn:oasis:names:tc:xacml:2.0:action:purpose We could also define a standard rule that requires the resource purpose to include the action purpose. This would enforce the requirement that data resources only be used for the purposes for which they were collected. TYPE: Privacy Profile STATUS: Open, but not for 2.0. 4 March 2004 approved Tim's proposal as a TC Working Draft. PROPOSAL: http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/5781/oasis_xacml_v2_0_privacy-profile_wd_01.zip CHAMPION: Tim Moses ACTION [Tony; 4 March 2004]: look at W3C work in the privacy area and provide XACML TC with a summary. WI#61. Negating TargetMatch For Target Matching, ability to say things like "match any subject who doesn't have this name" or "match any access not for this server." Having a flag (or something) that negates a TargetMatch. TYPE: New functionality STATUS: Closed for 2.0 on 18 Mar 2004. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200402/msg00090.html CHAMPION: Seth Proctor (on behalf of an XACML users) WI#62. New string functions Some of the standard string functions like concatenation, substring, etc. TYPE: New functionality STATUS: Included in XACML 2.0 Draft 0.9. Approved "concatenation" at 15 Apr 04 TC meeting. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200404/msg00076.html CHAMPION: Seth Proctor WI#63. Remove "IssueInstant" XML attribute TYPE: Remove unusable, vestigial attribute STATUS: Included in XACML 2.0 Draft 0.9. Approved removal 18 Mar 2004. PROPOSAL: CHAMPION: WI#64. Align XACML Attribute with SAML Attribute After SAML settles their Attribute format for 2.0, define mapping. TYPE: Interoperability STATUS: Closed 31 March 2004 as duplicate of WI#55. WI#65. Add additional layer of aggregation to XACML attribute naming TYPE: Interoperability STATUS: Open for 2.0. To be discussed in TC. SAML not planning to add one. PROPOSAL: CHAMPION: Daniel WI#66. Add IP address match functions XACML defines a SubjectCategory for "requesting-machine" and users mention use of IP addresses as attributes, but XACML provides no functions for comparing two IP addresses. Comparisons should include address and optional port or port range, and should include DNS names as well as numeric IP addresses. Comparisons should handle 64-bit names as well as 32-bit names. One use case is to provide functionality of the Java SocketPermission. TYPE: New functionality. STATUS: Included in XACML 2.0 Draft 0.9. Approved at 12 Apr 04 TC meeting. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200404/msg00075.html CHAMPION: Anne Anderson WI#67. Add "IssuerNameFormat" XML attribute to Attribute[Designator] TYPE: Interoperability with SAML STATUS: Closed for 2.0. Consensus on list was not needed. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200403/msg00055.html [Anne-proposal] http://lists.oasis-open.org/archives/xacml/200403/msg00056.html [Seth to Anne] http://lists.oasis-open.org/archives/xacml/200403/msg00058.html [Anne to Seth] CHAMPION: Anne WI#68. Attribute assertion lifetime Need some way to indicate validity period for attributes included in a Request, and way to place constraints on acceptable validity in Policy. Alternative view says testing for validity is done by Context Handler, not by policy. All attributes included in a Request Context are assumed to be valid at the time the PDP is asked to use the Request Context in making an authorization decision. TYPE: New functionality STATUS: Open for 2.0. Settle at F2F or drop. Majority on list were not in favor of adding. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200403/msg00067.html [Daniel to Frank] http://lists.oasis-open.org/archives/xacml/200403/msg00072.html [Polar: formal approach] http://lists.oasis-open.org/archives/xacml/200403/msg00073.html [Anne: use WSPL] http://lists.oasis-open.org/archives/xacml/200403/msg00078.html [Daniel:new datatype] http://lists.oasis-open.org/archives/xacml/200403/msg00079.html [Frank to Anne] http://lists.oasis-open.org/archives/xacml/200403/msg00082.html [Daniel:caching] http://lists.oasis-open.org/archives/xacml/200403/msg00086.html [Polar to Frank] http://lists.oasis-open.org/archives/xacml/200403/msg00088.html [Polar agrees with Daniel] http://lists.oasis-open.org/archives/xacml/200403/msg00089.html [Frank to Polar] http://lists.oasis-open.org/archives/xacml/200403/msg00092.html [Frank to Daniel] http://lists.oasis-open.org/archives/xacml/200403/msg00093.html [Daniel to Frank] http://lists.oasis-open.org/archives/xacml/200403/msg00095.html [Polar to Frank] http://lists.oasis-open.org/archives/xacml/200403/msg00096.html [Frank gives up] http://lists.oasis-open.org/archives/xacml/200403/msg00097.html [Anne to Frank] CHAMPION: Frank Siebenlist WI#69. AttributeAssignment clarification TYPE: Clarification STATUS: Open for 2.0. Consensus reached on list. See ACTION. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200404/msg00005.html [Seth:resolution] CHAMPION: Seth Proctor ACTION [Tim]: fix affected examples. WI#70. Legal values for string DataType is it legal in XACML to use string as the datatype for what may be interpreted as complex content? I would suggest the answer is no, unless we want to add explicit text to the XACML specification explaining why it's ok. Keep in mind that for people using DOM/SAX, the tree will be interpreted before they see the value, and this can cause the tags to change their representation (eg, namespacing, macro replacing, etc). TYPE: Clarification STATUS: Open for 2.0. Consensus reached on list. See ACTION. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200404/msg00003.html [Seth:resolution] CHAMPION: Seth Proctor ACTION [Tim?]: fix affected examples. Optionally, call this out in Appendix A so it's clear how this is handled. WI#71. Make ordered-* versions of combining algorithms mandatory The ordered version of the combining algorithms are required to get deterministic results in all cases (no surprise there). I would like to suggest, therefore, that we make the ordered algorithms normative and required to implement. From an implementation point of view they are trivial to support, and I believe this will help with interoperability. TYPE: Interoperability STATUS: Included in XACML 2.0 Draft 0.9. 8 Apr 04 FG recommended making normative and mandatory to support deterministic policies. RELATED: #18 (Obligations in Rules) PROPOSAL: http://lists.oasis-open.org/archives/xacml/200404/msg00006.html CHAMPION: Seth Proctor WI#72. Remove concept of "base policy" TYPE: Simplicity, clarity of specification STATUS: Discussed 15 Apr 04. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200404/msg00072.html [Polar] http://lists.oasis-open.org/archives/xacml/200404/msg00089.html [Anne] http://lists.oasis-open.org/archives/xacml/200404/msg00133.html [Polar] http://lists.oasis-open.org/archives/xacml/200404/msg00134.html [Seth] CHAMPION: Polar Humenn 15 Apr 04 Discussion Simon: Anne's suggestion wording leaves open case where there might be more than one applicable policy - seems to say it is OK for PDP to just pick one. Hal: why should we say this is "default" behavior? It is just how a conformant PDP responds. Polar: objection is to second paragraph in Anne's proposal Simon: remove the second paragraph. Anne: How about removing second and changing first sentence of first paragraph to: "This specification defines only how to evaluate one Policy or PolicySet instance with respect to any given Request Context." Polar: I don't object to that. Hal: If you can't come up with one policy, the PDP SHOULD return "Indeterminate". ACTION [Polar; 15 Apr 04]: propose wording that does not violate your concerns. WI#73. Specifying PDP and PEP behavior To what extent should the XACML specification specify the behavior of the PDP (e.g. with base policies) and the PEP (e.g. with obligations)? Does XACML 2.0 specify a language or does it also specify operational semantics for use of the language in specific situations? TYPE: Clarification STATUS: Discussed on e-mail list. To be resolved at Apr 04 F2F. PROPOSAL: http://lists.oasis-open.org/archives/xacml/200404/msg00130.html [Bill] CHAMPIONS: Polar, Bill WI#74. Include references for "PDP", "PEP", "ADF", "AEF" It would be good for us to reference the IETF and DMTF/CIM standards ([RFC3198] IETF RFC 3198: Terminology for Policy-Based Management, November 2001. http://www.ietf.org/rfc/rfc3198.txt) from which the concepts and terminology for "PDP" and "PEP" come. Not only is this a common question ("did you guys define this term?"), but if would also be appropriate for us to acknowledge our source. I suggest we also relate these to the corresponding ISO/IEC terms ([ISO10181-3] ISO/IEC 10181-3:1996 Information technology -- Open Systems Interconnection -- Security frameworks for open systems: Access control framework), since another common question is "How do these fit with ADF and AEF?" TYPE: Editorial STATUS: PROPOSAL: http://lists.oasis-open.org/archives/xacml/200404/msg00140.html CHAMPION: Anne
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]