Re: [xacml] proposal for identifying optional features

[Anthony Nadalin <drsecure@us.ibm.com>]

Why wouldn't we use just use a URI ?

Minor changes on your proposal:

All compliant XACML implementations MUST declare which profiles they support this can an optional element that can be included in a policy to list the required URIs. For a request, we could just define an environment variable to hold the list of required URIs. The format of the variable could be the same as the format of the optional element. A context handler could be aware of
that variable. We also need to define error codes or other behavior if a PDP does not support required options.

Anthony Nadalin | work 512.838.0085 | cell 512.289.4122
Anne Anderson <Anne.Anderson@Sun.COM>

Anne Anderson <Anne.Anderson@Sun.COM>

06/22/2004 09:55 AM

Please respond to
Anne.Anderson

To	XACML TC <xacml@lists.oasis-open.org>
cc	Anne.Anderson@Sun.COM
Subject	[xacml] proposal for identifying optional features

Tony suggested we have some way of identifying which optional
features or profiles a given implementation supports, or that a given
request or policy requires.

We have survived without this through XACML 1.0 and 1.1, but if
we decide it is worth doing, here is a proposal.

create a urn for each profile or separate optional feature
(e.g. obligations, xpath).  Create an optional element that can be
included in a policy to list the required urn's.  For a request, I think
we could just define an environment variable to hold the list of
required urn's.  The format of the variable could be the same as the
format of the optional element.  A context handler could be aware of
that variable.  We also need to define error codes or other behavior if
a PDP does not support required options.  We need to decide whether
supporting the "optional support" feature is itself optional!

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


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.