Conflict and combination in privacy policy languages
Proceedings of the 2004 ACM workshop on Privacy in the electronic society
Precomputation of privacy policy parameters for auditing SQL queries
Proceedings of the 2nd international conference on Ubiquitous information management and communication
Adaptive Solutions for Access Control within Pervasive Healthcare Systems
ICOST '08 Proceedings of the 6th international conference on Smart Homes and Health Telematics
Formal consistency verification between BPEL process and privacy policy
Proceedings of the 2006 International Conference on Privacy, Security and Trust: Bridge the Gap Between PST Technologies and Business Services
Towards personal privacy control
OTM'07 Proceedings of the 2007 OTM Confederated international conference on On the move to meaningful internet systems - Volume Part II
Cue: a framework for generating meaningful feedback in XACML
Proceedings of the 3rd ACM workshop on Assurable and usable security configuration
A privacy-aware localization service for healthcare environments
Proceedings of the 4th International Conference on PErvasive Technologies Related to Assistive Environments
Privacy enhanced trusted network connect
INTRUST'09 Proceedings of the First international conference on Trusted Systems
| Hi-index | 0.00 |
Current regulatory requirements such as Sarbanes-Oxley, HIPAA, and the European Union Directive on Data Privacy make it increasingly important for enterprises to be able to verify and audit their compliance with privacy policies. Two platform-independent languages that support directly-enforceable policies including "purposes" are IBM's Enterprise Privacy Authorization Language(EPAL) and the OASIS eXtensible Access Control Markup Language (XACML). This document gives a brief overview of directly-enforceable policy languages, and then compares EPAL and XACML to show where the two languages diiffer. The differences are used to compare the strengths and weaknesses of each language for expressing privacy policies and for authorization or access control policies. The main findings of this analysis are: - With two exceptions, EPAL 1.2 supports a small subset of the functionality offered by XACML 2.0. The two exceptions, a built-in policy "vocabulary" mechanism and "categories", could be supported in XACML 2.0 without changes to the language. Their implementation in EPAL 1.2 is problematic. - EPAL 1.2 lacks significant features required for complex enterprise policies, both for privacy and for access control in general. It adds no privacy-specific functionality not already supported by XACML 2.0. - XACML 2.0 is an approved OASIS Standard with an OASIS Standard profile for privacy policies. If EPAL were considered as an additional standard, it would be detrimental to industry functionality and interoperability.