Re: Inquiries into XACML design requests to SAML

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

Here are answers to your inquiries, probably addressing more
aspects of the issue than your original inquiry intended.  These
were discussed at the XACML TC meeting this morning, and a draft
version was posted to the XACML TC list shortly after your
original inquiry, but I should be held responsible for any
omissions or errors.  -Anne

1. Why didn't XACML just use the XSI-defined primitive types?
   Why did XACML extend the list of types?

The XSI set was not rich enough, even as a set of primitives.
For example, we felt X500 Names and RFC822 names had syntactic
and semantic aspects that could not be handled via any of the XSI
types, and were very important for access control policies.

In addition, not all attributes can be expressed using primitive
types.  In some cases, a structured element is needed to tie
together multiple related data items.  As an example, a security
label needs not just the "secret", "confidential",
etc. classification value, but also the entity whose
classification is being used (Army, Sun corporate, etc.).  For
these, a schema-defined attribute type is needed.

2. Why does XACML use URIs to identify Attributes and their DataTypes?

QNames cause trouble for digital signatures, since the names must
be resolved to identical values by multiple parties, each of whom
may have different resolution chains.

Note that WSS recently had to backtrack on their use of QNames
and are now using URIs.  I am not familiar with all the reasons,
but I believe their reasons are probably related to ours.

3. Why not allow the Attribute DataType to be specified by the
type of the schema element that is used as the attribute value?
Why have an explicit "Datatype" attribute?

XACML actualy does allow a policy to use types defined by
schemas.  For example, "X" in the example below could be an
XML-schema defined type, resulting in

    <AttributeValue DataType="X"><X>xxxx</X></AttributeValue>

[Note that functions on such types are not supported by XACML's
basic AttributeDesignator mechanism]

But evaluation of a policy requires comparisons and operations on
data.  If the policy engine is to support standard functions for
doing these comparisons and operations, then standard data types
are required.  XACML, by supporting a rich set of standard data
types and associated functions, allows most policies to be
supported by standard policy engines, rather than by requiring
pluggable code for each new data type.

An alternative is to support XPath query operators, where the
arguments to a function are XPath expressions that resolve to
values of primitive data types that the functions understand.
XACML did not want to require use of XPath, so did not want to
force this solution.  But XACML does support this alternative by
optionally allowing attributes to be specified using XPath
expressions.  These expressions can be used to extract primitive
data elements from an Attribute whose data type is defined via an
XML schema-instance.

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