Editor: Anne Anderson Affiliation: Sun Microsystems, Inc. E-mail: Anne.Anderson@sun.com Date: 17-18 October 2006 Copyright © 2006 Sun Microsystems, Inc. All rights reserved.
This is the Sun Microsystems, Inc. position paper on the topic of Languages for Privacy Policy Negotiation and Semantics-Driven Enforcement, October 2006. It has two parts. The first part addresses general requirements, as we see them. The second part discusses three candidate technologies: XACML, WS-Policy augmented with WS-PolicyConstraints, and EPAL.
AVOID CONFLICTING STANDARDS: There already exists a standard language at the policy enforcement level for both access control and enforceable privacy policies: the OASIS eXtensible Access Control Markup Language (XACML) Version 2.0 [2] along with the Privacy policy profile of XACML v2.0 [3]. While it is not "semantics-driven", it is a widely adopted standard. Semantic standards efforts for now should focus on extending XACML with semantic information rather than inventing or standardizing a new language.
COMBINE ACCESS CONTROL AND PRIVACY POLICIES AT ENFORCEMENT LEVEL: At the enforcement level, the same language system must be used for both access control and for privacy, because the resources covered will often be the same, and unless the same system is used, the two sets of policies may conflict or be inconsistent.
If a new semantics-driven language for privacy policy enforcement is developed, it must be general enough for use as an access control/authorization policy language. Any such semantics-driven language must be proven in application to actual industrial access control and privacy policies before being considered for standardization.
USEFUL AREAS FOR SEMANTIC EXTENSIONS: these are some areas in which semantics-driven extensions to existing privacy policy languages would be useful.
CONNECT USER-LEVEL AND ENFORCEMENT-LEVEL POLICIES: semantic extensions might provide semantic connections between user-level policies and enforcement level policies; as an example, connecting a W3C P3P policy with the enforcement-level policy rules that express it. This might support easier auditing of user-level policy enforcement. There has been some research work in this area.
STANDARD PRIVACY TAXONOMIES: one of the main values of P3P has been the standardization of privacy terminology, making the specification and interpretation of privacy policies much simpler. Extensions to these taxonomies are needed to support not just user privacy, but also enterprise privacy.
SUPPORT MAPPINGS OF EQUIVALENT PRIVACY POLICY TERMS BETWEEN DOMAINS: semantic extensions might help two domains map their internal privacy policy terms to standard terms or to each other. While it is very important for standard terms to be developed for typical privacy policy vocabularies, in specific applications that cross organizational domains there may be a need to match non-standard, but equivalent terms used in the two domains. Semantics-driven extensions to existing languages might address this.
ENABLE MORE USABLE AND EXPRESSIVE USER PRIVACY PREFERENCE/REQUIREMENT MATCHING: Users need ways to indicate their privacy preferences and requirements that are simple enough to be used by ordinary users, yet are expressive enough to satisfy particular requirements. There may be roles for semantic extensions to play here, in mapping "user-level" terms to more specific terms used at the enforcement level. Some requirements not met by current mechanisms are:
APPEL was designed to address this problem, but has not been taken up, and the 2002 W3C P3P Workshop [1] concluded it was flawed in various ways.
HANDLE OBLIGATIONS: Obligations are an important component of many privacy policies. Any system for dealing with privacy must support expression and at least a link to enforcement of obligations associated with release of private information. It must also be recognized that both parties to an exchange of information may incur obligations, and this functionality must be supported. HANDLE TIME-BASED REASONING: Privacy policies often involve obligations that must occur in the future, such as Personal data will not be retained more than 30 days. In order to analyze and audit enforcement of such policies, the policy system may need to support time-based reasoning. Not all logics support this, but this appears to be at the research stage right now, and not suitable for standardization yet.
ADDRESS REQUIREMENTS OF IDENTITY FEDERATIONS, GRIDS, AND WEB SERVICES: Privacy policy standards need to address requirements of federated identity systems, various types of grid systems, and web services. Some of these are being presented in other position papers by the communities involved.
TAKE REGULATORY, CONTRACTUAL, ETHICAL/BEST-PRACTICE PRIVACY CONCERNS INTO ACCOUNT: Privacy requirements come from government regulations, contractual agreements between parties based on the business or personal interests, and ethical or best-practice concerns. No one set of privacy policy terms or conditions will satisfy the requirements of all these types of policy concerns. Systems must be flexible and extensible enough to support a broad range of privacy policy concerns.
ADDRESS CONSISTENT SUBSETS OF REGULATORY POLICIES: Attempts to express HIPAA, Sarbanes-Oxley, and other broad regulatory policies directly using semantic logic languages are doomed to failure because the regulatory policies themselves are too complex and internally inconsistent. Work in this area should focus on defining expressions for consistent subsets of the regulatory policies that are suitable for automated enforcement, and developing standard terminologies for these.
TAKE OUT-OF-BAND CONTRACTUAL AGREEMENTS INTO ACCOUNT: Not all privacy policies are enforced or expressed using automated digital information systems. Business-to-business contractual agreements, with legal remedies for violation, are an important part of any policy system. Automated policy languages should not try to solve problems that businesses would rather solve using existing contracts, due to better legal structures for dealing with violations.
This section discusses three candidate technologies: XACML, WS-Policy Augmented with the WS-PolicyConstraint Language, and EPAL.
As mentioned above, the OASIS eXtensible Access Control Markup Language (XACML) is a widely adopted standard language for access control, authorization, and privacy policies. A list of papers on and deployments of XACML is available [6]. To avoid conflicting standards, XACML should be the language of choice at the policy enforcement level. XACML satisfies many of the requirements stated above, and can be extended to satisfy most of those that depend on the policy language itself.
XACML uses a generic functional constraint language that depends only on the semantics of the generic data types of the various policy items, which are defined with unique identifiers. P3P policies be easily be translated into XACML. For example, to express that the P3P 1.1 retention options STP ("for stated purpose"), LEG ("for legal requirement"), and BUS ("for business practices") are acceptable, the constraint could be expressed as follows:
<!-- Returns true iff the first argument is a subset of the second argument -->
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-subset">
<!-- 1st argument: returns the values of all Attributes with DataType "string" and AttributeId "retention" -->
<AttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:example:p3p:retention"/>
<!-- 2nd argument: converts a collection of values into a "bag", which is handled as a set by "string-subset" -->
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<!-- The compact-retention values that are acceptable -->
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">STP</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">LEG</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">BUS</AttributeValue>
</Apply>
</Apply>
An XACML constraint can be evaluated over a supplied set of Attributes to determine whether the Attributes satisfy the constraint. For example, the constraint above will be satisfied if the values supplied for all the Attributes with identifier retention are a subset of the values {"STP", "LEG", "BUS"}. Besides rich sets of standard comparison operators and data types, XACML also contains Boolean operators for combining constraints into sets of alternatives, arithmetic functions for operating on Attribute values before they are compared (for example to compute age from date of birth), string manipulation functions (concatenate, convert to lower case), etc. Attributes can be identified using an XPath expression, where the values of the Attribute are the result of evaluating the XPath expression against some XML document, often the document for which access is requested. XACML has structures for grouping policy rules and sub-policies, referencing distributed policies, calling out indexable "target" values for specific rules or policies, associating obligations with policies, and many more. The result is a powerful language for expressing policies in a form that can be evaluated directly.
The Privacy policy profile of XACML v2.0 [3] defines standard XACML Attribute identifiers for expressing the purpose for which data is collected and the purpose for which data is being accessed. It also defines a standard rule for requiring that the purpose for which data is collected must be consistent with the purpose for which data is being accessed. There are other OASIS Standard XACML profiles for supporting integration with SAML, role based access control, hierarchical resources, etc. Another possibly useful extension to XACML would be the specification of standard Attribute Identifiers and Attribute values corresponding to the values used in P3P. XACML can be used to support extensions to P3P easily as new standard or application-specific Attributes are needed.
The XACML architecture includes a functional component called the Context Handler that mediates between the policy evaluation engine and the values that are supplied to it for evaluation. The Context Handler provides not only a mechanism for separating the standard policy language from specific policy data representations, but also provides an architectural locus for associating semantic information with XACML Attributes or Attribute values. For example, a policy function can request all ancestor classes from which a particular Attribute value subclass inherits, and compare that set of class values to a specified value. Defining a standard way for XACML's Context Handler to express this information would be a worthwhile extension, both for connecting user-level to enforcement-level policies and for supporting mappings of privacy policy terms.
While XACML is ideal as a language for expressing internal enterprise access control and privacy policies at the enforcement level, it is not suitable for negotiating policies between entities because the intersection of two general XACML policies is not defined. There is a subset of XACML, however, called the XACML profile for Web-services (WSPL) that fully supports efficient policy intersection down to the constraint/assertion level. This subset was originally developed by Tim Moses of Entrust, and is a Working Draft in the OASIS XACML Technical Committee [4]. Since WSPL conflicts with WS-Policy and WS-PolicyAttachment (both provide Boolean operators for associating sets of requirements and a mechanism for associating a policy with WSDL service descriptions), Sun developed a subset of WSPL called the WS-PolicyConstraint Language (WS-PolicyConstraints) [5] that retains only the XACML constraint syntax used in WSPL, along with its intersection semantics. This subset is designed to be a generic language for writing WS-Policy assertions in such a way that their intersections can be easily computed by generic policy processors or agents unaware of the specific semantics of the assertions themselves. It includes syntax for expressing multiple constraints on a single Attribute that is defined using XML Schema. It depends on WS-Policy (or similar language) for the Boolean operators used to express acceptable combinations of Assertions, and could use WS-PolicyAttachment as one way of specifying how a policy is associated with a service description.
WS-PolicyConstraints, along with WS-Policy, would be an excellent language for privacy policy negotiation that would support fine-grained policies that can be associated with different types of transactions or information. Further development and standardization of WS-PolicyConstraints would be a useful extension to XACML for privacy policies.
While these languages could serve as the basis for a logically solid mechanism for expressing and matching preferences and promises, a possibly larger problem is the development of good user interfaces for expressing privacy policy information.
IBM's Enterprise Privacy Authorization Language (EPAL) has languished as a W3C member submission since 2003; in the meantime, XACML has flourished, including the approval as an OASIS Standard of XACML's privacy policy profile. Two papers have shown that EPAL provides a subset of the functionality that can be provided by XACML [7][8]. In addition, other research has pointed out problems in EPAL, including a problem with its rule selection algorithm that makes it impossible to automatically combine two EPAL policies [9][10]. Since XACML and its privacy profile are already full OASIS Standards, efforts should go into extending, profiling, or augmenting XACML rather than toward standardizing a competing language that overlaps with it almost 100%; for this reason, we do not recommend any standardization work based on EPAL. If there are concepts in EPAL that are viewed as significant, but have not yet been implemented in XACML, they should be implemented as extensions to or profiles of XACML. IBM has active participants in the OASIS XACML Technical Committee, so is and has been in a position to work with the XACML TC on such extensions or profiles.
[1] W3C, Summary Report - W3C Workshop on the Future of P3P, November 12-13 2002. Available at http://www.w3.org/2002/12/18-p3p-workshop-report.html.
[2] Moses, T., ed., OASIS eXtensible Access Control Markup Language (XACML) Version 2.0, OASIS Standard 1 Feb 2005. Available at http://www.oasis-open.org/apps/org/workgroup/xacml/#XACML20.
[3] Moses, T., ed., OASIS Privacy policy profile of XACML v2.0, OASIS Standard 1 Feb 2005. Available at http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-privacy_profile-spec-os.pdf.
[4] Moses, T., ed., XACML profile for Web-services (WSPL), OASIS XACML Technical Committee Working Draft. Available at http://www.oasis-open.org/committees/download.php/3661/draft-xacml-wspl-04.pdf.
[5] Anderson, A., XACML-based Web Services Policy Constraint Language (WS-PolicyConstraints), Sun Microsystems, Inc. Specification, whitepapers, slides, proof-of-concept available at http://research.sun.com/projects/xacml.
[6] Anderson, A., ed., XACML References, OASIS XACML Technical Committee, updated regularly. Available at http://docs.oasis-open.org/xacml/xacmlRefs.html.
[7] Anderson, A., A Comparison of Two Privacy Policy Languages: EPAL and XACML, 3 November 2005; Sun Labs Technical Report. Available at http://research.sun.com/techrep/2005/abstract-147.html (abstract page has link to full report).
[8] Anderson, A., A Comparison of Two Privacy Policy Languages: EPAL and XACML, accepted for the ACM Workshop on Secure Web Services, Fairfax, VA, 03 November 2006. This paper revisits some of the key differences discussed in the Sun Labs Technical Report above.
[9] Barth, A., and Mitchell, J.C., Enterprise privacy promises and enforcement, ACM WITS'05, January 10, 2005, Long Beach, CA, USA.
[10] Barth A., Mitchell, J.C., and Rosenstein, J., Conflict and Combination in Privacy Policy Languages (Summary), Workshop on Privacy in the Electronic Society, 28 October 2004.
Sun and Sun Microsystems are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries.
Copyright © 2006 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A. All rights reserved.