Draft response to SSTC on XACML Attribute definition

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

At the SAML F2F, I was asked why XACML had chosen to use a
different Attribute definition from SAML.  The XACML TC
participants present at the SAML F2F were not able to respond
off-the-cuff, so here is a draft response.  Does anyone have more
information, history, opinion, correction, etc?

-Anne

First of all, here are the two schema definitions:

SAML 1.1:

	<element name="AttributeDesignator" type="saml:AttributeDesignatorType"/>
	<complexType name="AttributeDesignatorType">
		<attribute name="AttributeName" type="string" use="required"/>
		<attribute name="AttributeNamespace" type="anyURI" use="required"/>
	</complexType>
	<element name="Attribute" type="saml:AttributeType"/>
	<complexType name="AttributeType">
		<complexContent>
			<extension base="saml:AttributeDesignatorType">
				<sequence>
					<element ref="saml:AttributeValue" maxOccurs="unbounded"/>
				</sequence>
			</extension>
		</complexContent>
	</complexType>
	<element name="AttributeValue" type="anyType"/>

XACML 1.1:

	<xs:element name="Attribute" type="xacml-context:AttributeType"/>
	<xs:complexType name="AttributeType">
		<xs:sequence>
			<xs:element ref="xacml-context:AttributeValue"/>
		</xs:sequence>
		<xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>
		<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
		<xs:attribute name="Issuer" type="xs:string" use="optional"/>
		<xs:attribute name="IssueInstant" type="xs:dateTime" use="optional"/>
	</xs:complexType>
	<!-- -->
	<xs:element name="AttributeValue" type="xacml-context:AttributeValueType"/>
	<xs:complexType name="AttributeValueType" mixed="true">
		<xs:sequence>
			<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
		</xs:sequence>
		<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:complexType>

The XACML TC started out with the SAML Attribute schema
definition.  We diverged as we found difficulties in using the
SAML Attribute schema in policies.

1. XACML AttributeId vs. SAML AttributeName plus AttributeNamespace

   In policies, using the SAML definition requires two predicates
   to match a single Attribute, e.g. AttributeName="X" AND
   AttributeNamespace="Y".  We could not find instances where a
   policy writer would want to reference "an Attribute from any
   AttributeNamespace with the AttributeName X", or "an Attribute
   with any AttributeName from AttributeNamespace Y".

   Since a URI can be composite, containing a prefix that
   indicates the namespace and a suffix that indicates the name,
   and since a single predicate can then be used to select the
   Attribute, the XACML TC changed the schema to use a single
   AttributeID URI.  This also is consistent with the naming and
   retrieval of Attributes in LDAP.

   For example, rather than defining
   AttributeNamespace="permisRole" and AttributeName="manager",
   XACML would have you define something like
   AttributeId="http://www.permis.org/2002/names/roles#manager";
   or AttributeId="urn:permis:names:role:manager"

2. Explicit XACML DataType

   SAML depends on each AttributeValue having a schema, such that
   the schema instance contains tags identifying the type of the
   Attribute.

   XACML wanted to define a set of standard functions that could
   be used with most AttributeValues.  By defining a set of
   standard DataTypes, with associated semantics and functions
   for manipulating those types, most XACML policies can be
   defined without recourse to additional schemas, and strict
   type checking for the functions can be performed.

   Note that is it possible in XACML to define the type of an
   AttributeValue by using a schema, since the set of DataTypes
   is extensible.  A policy writer can set
   DataType="urn:myAttributeSchema:attrX", and have the
   AttributeValue then be an instance of this schema element.
   The policy writer will not be able to use standard functions
   with such an Attribute however.

3. SAML sequence of AttributeValue vs XACML AttributeValue that
   may contain a sequence

   In SAML, an Attribute may contain one or more AttributeValue
   elements.  In XACML, an Attribute contains a single
   AttributeValue element, although that element may contain a
   sequence.

   Again, this difference rose from XACML's need to apply
   functions to AttributeValues.  It was difficult to define
   standard functions that would apply to multiple
   AttributeValues in a single Attribute, especially since SAML
   has no requirement that each of the AttributeValues be
   instances of the same schema.

   XACML does permit a subject to have multiple values associated
   with a single Attribute Identifier.  This can be done by
   specifying multiple Attribute instances, each having the same
   Attribute Identifier.

   There is a proposed work item for XACML 2.0 that would allow a
   single Attribute having multiple AttributeValues (all of which
   MUST be of the same DataType) to serve as a shorthand for
   specifying a set of Attributes with the same Attribute
   Identifier and DataType, but this would be only a shorthand
   for existing semantics.

4. XACML inclusion of Issuer and IssueInstant

   XACML was designed to accept attributes from multiple
   sources, such as X.509 Attribute Certificates, database
   entries, SAML Attribute Assertions, etc.  Rather than force
   each format to be converted into a SAML AttributeStatement,
   XACML chose to extract the information considered necessary
   for matching attribute values to policy requirements and
   include all that information in a single, simple Attribute
   definition.

   The XACML TC maintained the SAML "string" type for Issuer,
   although the XACML TC considers this inadequate and has
   requested that SAML 2.0 contain a better definition for
   Issuer.  The Issuer should be a type/value pair, so that, for
   example, Issuer X.500 names can be distinguished from company
   identifiers or RFC822 names.

   The XACML TC includes IssueInstant, but has no way of using
   this value in a policy other than to require an exact match.
   For example, there is no way in an XACML policy to say that a
   particular Attribute is acceptable so long as it was issued
   after a given dateTime.  This reduces the value of
   IssueInstant considerably, but this is an XACML issue and not
   a SAML problem.

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