[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Inquiries into XACML design requests to SAML
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]