Members of the OASIS Extensible Access Control Markup Language Technical Committee recently approved a version 1.0 Committee Specification for the XACML specification and voted to move the document forward for standardization. The motivation behind XACML is to express well-established ideas in the field of access-control policy using an extension language of XML. The XACML specification defines an XML schema consistent with this goal. The XACML 1.0 Committee Specification is now "undergoing a public review period in preparation for submission to OASIS for consideration as an OASIS Standard; the public review period will extend from Friday, November 8, 2002 until Sunday, December 8, 2002 (inclusive)."

Bibliographic information: OASIS eXtensible Access Control Markup Language (XACML). Committee Specification 1.0. 7-November-2002. 129 pages. Document identifier: 'cs-xacml-specification-1.0.doc'. Web location: http://www.oasis-open.org/committees/xacml/repository/. Edited by Simon Godik (Overxeer) and Tim Moses (Entrust). Contributions by Anne Anderson (Sun Microsystems), Bill Parducci (Overxeer), Carlisle Adams (Entrust), Daniel Engovatov (CrossLogix), Don Flinn (Quadrasis), Ernesto Damiani (University of Milan), James MacLean (Affinitex), Hal Lockhart (Entegrity), Ken Yagen (CrossLogix), Konstantin Beznosov (Quadrasis), Michiharu Kudo (IBM), Pierangela Samarati (University of Milan), Pirasenna Velandai Thiyagarajan (Sun Microsystems), Polar Humenn (Syracuse University), Sekhar Vajjhala (Sun Microsystems), Seth Proctor (Sun Microsystems), Steve Anderson (OpenNetworks), Steve Crocker (Pervasive Security Systems), Suresh Damodaran (Sterling Commerce), Gerald Brose (Xtradyne). Schema Definitions include: Policy Schema (cs-xacml-schema-policy-01.xsd) and Context Schema (cs-xacml-schema-context-01.xsd).

The XACML TC co-chairs are Carlisle Adams (Entrust) and Hal Lockhart (Entegrity).

Requirements informing the design of XACML as a "policy language for expressing information system security policy" are presented as follows:

• To provide a method for combining individual rules and policies into a single policy set that applies to a given action.
• To provide a method for flexible definition of the procedure by which rules and policies are combined.
• To provide a method for dealingwith multiple subjects acting in different capacities.
• To provide a method for basing an authorization decision on attributes of the subject and resource.
• To provide a method for dealing with multi-valued attributes.
• To provide a method for basing an authorization decision on the contents of an information resource.
• To provide a set of logical and mathematical operators on attributes of the subject, resource and environment.
• To provide a method for handling a distributed set of policy components, while abstracting the method for locating, retrieving and authenticating the policy components.
• To provide a method for rapidly identifying the policy that applies to a given action, based upon the values of attributes of the subjects, resource and action.
• To provide an abstraction-layer that insulates the policy-writer from the details of the application environment.
• To provide a method for specifying a set of actions that must be performed in conjunction with policy enforcement.

From the (non-normative) specification background statement:

The "economics of scale" have driven computing platform vendors to develop products with very generalized functionality, so that they can be used in the widest possible range of situations. "Out of the box", these products have the maximum possible privilege for accessing data and executing software, so that they can be used in as many application environments as possible, including those with the most permissive security policies. In the more common case of a relatively restrictive security policy, the platform's inherent privileges must be constrained, by configuration.

The security policy of a large enterprise has many elements and many points of enforcement. Elements of policy may be managed by the Information Systems department, by Human Resources, by the Legal department and by the Finance department. And the policy may be enforced by the extranet, mail, WAN and remote-access systems; platforms which inherently implement a permissive security policy. The current practice is to manage the configuration of each point of enforcement independently in order to implement the security policy as accurately as possible. Consequently, it is an expensive and unreliable proposition to modify the security policy. And, it is virtually impossible to obtain a consolidated view of the safeguards in effect throughout the enterprise to enforce the policy. At the same time, there is increasing pressure on corporate and government executives from consumers, shareholders and regulators to demonstrate "best practice" in the protection of the information assets of the enterprise and its customers.

For these reasons, there is a pressing need for a common language for expressing security policy. If implemented throughout an enterprise, a common policy language allows the enterprise to manage the enforcement of all the elements of its security policy in all the components of its information systems. Managing security policy may include some or all of the following steps: writing, reviewing, testing, approving, issuing, combining, analyzing, modifying, withdrawing, retrieving and enforcing policy.

XML is a natural choice as the basis for the common security-policy language, due to the ease with which its syntax and semantics can be extended to accommodate the unique requirements of this application, and the widespread support that it enjoys from all the main platform and tool vendors.