[xacml] Issues ready to CLOSE

[Anne Anderson <Anne.Anderson@Sun.com>]

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: 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