OASIS Open Mailing List Archives  ·  All Lists  ·  xacml  ·  2002-02

xacml — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

[xacml] Issues ready to CLOSE


I believe that the following issues from Issues List Version 2 are ready to be closed. If anyone disagrees with the Resolution listed for each, then the issue is not ready to close, and the listed Resolution should be included in the Issues List as yet another Potential Resolution . ================================================================== PM-2-05: Ensuring Completeness Resolution: 1. If a Base Policy is included in the Access Request, then that Base Policy is the only one that will be applied to the Access Request. Otherwise, 2. If a PDP has a single Base Policy, then the PDP's Base Policy specifies the complete <applicablePolicy> that will be used by that PDP in evaluating an Access Request. This <applicablePolicy> may actually be a tree of <applicablePolicy> statements, where additional statements are logically incorporated by the use of <referencedPolicy> predicates. In this case, there are no overlapping targets. If the PDP's Base Policy has an empty target element, then all Access Requests are evaluated against the <policy>. If the Base Policy has a non-empty target element, then any Access Request that does not match the target returns a result of NOT-APPLICABLE (=SAML INDETERMINATE). If the Access Request matches the target , then the result of the Access Request is the result of evaluating the <policy>. 3. If a PDP has multiple Base Policies, then the PDP must specify and publish its algorithm for deciding which Base Policies to evaluate, in which order, and how target overlaps are resolved. ================================================================== PM-4-02, PM-4-05: Policy names as URIs Resolution: Policy names should be URIs. ================================================================== PM-4-04: syntax extension Resolution: Close this issue. It is incompletely specified: which element? Extension issues are in a separate section. ================================================================== PM-4-06: Comment element Resolution: We should include a comment element. ================================================================== PM-4-07: policy element in a rule Resolution: Duplicate of PM-3-01. =================================================================== PM-4-09: required type in a policy PM-4-03: complex types Resolution: duplicates; close one. If not duplicates, please clarify what this only allows for simple types is and how the two issues are different. =============================================================== PM-5-02: Wildcards on Resource Hierarchies Resolution: Use ResourceToClassificationTransform . Register a URI with OASIS for the use of regular expressions in this context. Other transform algorithms may be specified by the use of other URIs to be registered with OASIS. ================================================================= PM-5-03: Roles and Group Hierarchies Resolution: XACML will not support role and group hierarchies in the policy language. Attribute authorities may support role and group hierarchies. ================================================================== PM-5-04: SAML Assertions URI This issue conflates two separate issues: 1. Are SAML assertions always URI? Resolution: Attributes in saml assertions are identified by a namespace, which is a URI, and a name, which is a string. 2. New, separate open issue PM-1-?: references to attributes in XACML predicates What information needs to be provided in order to refer to an attribute in an XACML policy predicate? Potential Resolution: References to attributes associated with the access request in XACML predicates consist of a URI to a document instance that contains the value of the attribute to be evaluated, a URI for the schema for the document, a schema-dependent path for locating a particular attribute instance in the document according to the schema, and an optional name for the Attribute Authority trusted to assign values for this attribute. The AA is located using the PKI with which the PDP is configured. ================================================================== -- Anne H. Anderson Email: [email protected] 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]  |  [Month Index]  |  [List Home]