Privacy and Identity Management in Europe for Life
First Report on Standardisation and Interoperability
Overview and Analysis of Open Source Initiatives
Combined deliverable: Merger of D 3.3.1 and D 3.4.1.
Editors: Carine Bournez (W3C/ERCIM) Patrik Bichsel (IBM) Reviewers: Maren Raguse (ULD) Immanuel Scholz (TUD) Identifier: D3.3.1 / D3.4.1 Type: Deliverable Class: Public Date: 30 May 2008
Copyright © 2008 by the PrimeLife Consortiun The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement no 216483. Members of the PrimeLife Consortium
1. IBM Research GmbH IBM Switzerland
2. Unabhängiges Landeszentrum für Datenschutz ULD Germany
3. Technische Universität Dresden TUD Germany
4. Karlstads Universitet KAU Sweden
5. Università degli Studi di Milano UNIMI Italy
6. Johann Wolfgang Goethe - Universität Frankfurt am Main GUF Germany
7. Stichting Katholieke Universiteit Brabant TILT Netherlands
8. GEIE ERCIM W3C France
9. Katholieke Universiteit Leuven K.U.Leuven Belgium
10. Università degli Studi di Bergamo UNIBG Italy
11. Giesecke & Devrient GmbH GD Germany
12. Center for Usability Research & Engineering CURE Austria
13. Europäisches Microsoft Innovations Center GmbH EMIC Germany
14. SAP AG SAP Germany
15. Brown University UBR USA
Disclaimer: The information in this document is provided "as is", and no guarantee or warranty is given that the information is fit for any particular purpose. The below referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any liability which is mandatory due to applicable law. Copyright 2008 by IBM Research GmbH, Technische Universität Dresden, Università degli Studi di Milano, Johann Wolfgang Goethe - Universität Frankfurt am Main, GEIE ERCIM, Katholieke Universiteit Leuven, Giesecke & Devrient GmbH, Europäisches Microsoft Innovations Center GmbH, SAP AG.
2 Abstract
This document is a merged deliverable, covering items D3.3.1 (Overview and Analysis of Open Source Initiatives) and D3.4.1 (First Report on Standardisation and Interoperability). PrimeLife values open source and open standards and plans to share its results as open source software, public educational material and contributions to open standardisation bodies.
The first chapter will introduce the scope of this report and its importance in the PrimeLife project. The second chapter essentially describes the target technology platforms, the Web and then more specifically SOAs, and associated technologies.
The next chapters report the state of standards and open technologies, organised in 5 classes: standard identity management and privacy frameworks, policy and rules languages, authentication, user control, identity systems. When applicable, references to open source implementations are mentioned. A brief description of the organisations which coordinate standardisation of the previously described specifications follows. The last part of the document reviews in detail a number of selected open source projects which relate to the scope of the PrimeLife project.
The conclusion summarises results from the PRIME project and expectations for the PrimeLife work, so as to contribute to the definition of the project's next steps.
3 List of Contributors
Contributions from several PrimeLife partners are contained in this document. The following list presents the contributors for the chapters of this deliverable.
Chapter Author(s) Abstract Carine Bournez (W3C) Introduction Patrik Bichsel (IBM), Jan Camenisch (IBM) Target Technology Platforms Carine Bournez (W3C), Ulrich Pinsdorf (EMIC), Thomas Roessler (W3C), Rigo Wenning (W3C) Architectures and Frameworks Kai Rannenberg (GUF) Policy and Rule Languages Ulrich Pinsdorf (EMIC), Thomas Roessler (W3C), Pierangela Samarati (UNIMI), Mario Verdicchio (IBM), Rigo Wenning (W3C) Authentication Infrastructure Jan Camenisch (IBM), Markulf Kohlweiss (KU Leuven), Thomas Roessler (W3C), Stuart Short (SAP), Karel Wouters (KU Leuven) User Control Infrastructure Eduard de Jong (GD), Robert Mueller (GD) Identity Systems Michele Bezzi (SAP), Patrik Bichsel (IBM), Jan Camenisch (IBM), Ulrich Pinsdorf (EMIC), Thomas Roessler (W3C) Specification Developing Michele Bezzi (SAP), Carine Bournez (W3C), Eduard de Jong Organisations (GD), Robert Mueller (GD), Ulrich Pinsdorf (EMIC), Kai Rannenberg (GUF), Thomas Roessler (W3C), Rigo Wenning (W3C) Selected Open Source Projects Patrik Bichsel (IBM), Carine Bournez (W3C), Thomas Roessler (W3C), Immanuel Scholz (TUD), Rigo Wenning (W3C) Conclusion Claudio d'Ardagna (UNIMI), Jan Camenisch (IBM), Benjamin Kellermann (TUD), Immanuel Scholz (TUD), Rigo Wenning (W3C)
This deliverable was rendered from HTML pages using Prince XML from YesLogic Pty Ltd. YesLogic has donated a license of Prince XML to W3C.
4 Table Of Contents
1 Introduction 9 1.1 Scope of this Document ...... 9 1.2 Historic Background ...... 9 1.3 PrimeLife Aims and Activities ...... 10 1.4 PrimeLife Project Overview ...... 10 1.5 PrimeLife's Approach to Privacy ...... 11 2 Target Technology Platforms 13 2.1 The Web ...... 13 2.1.1 Architecture ...... 13 2.1.2 Standards ...... 14 2.1.3 Evolving Web Application Development Paradigms - Web 2.0 ...... 16 2.1.4 Semantic Web ...... 17 2.1.5 Privacy technologies for the Web ...... 17 2.2 Service Oriented Architectures ...... 18 2.2.1 OASIS WS-Security ...... 19 2.2.2 OASIS WS-SecureConversation ...... 20 2.2.3 OASIS WS-Trust ...... 20 2.2.4 W3C WS-Policy...... 21 2.2.5 OASIS WS-SecurityPolicy ...... 22 2.2.6 Primelife Perspective ...... 22 3 Architectures and Frameworks 23 3.1 Identity Management ...... 23 3.1.1 IdM Framework (24760) ...... 23 3.1.2 A Framework for Access Management (29146) ...... 24 3.1.3 Entity authentication assurance (29115) ...... 25 3.2 Privacy ...... 25 3.2.1 A Privacy Framework (29100) ...... 25 3.2.2 A Privacy Reference Architecture (29101) ...... 26 4 Policy and rule languages 27 4.1 Extensible Access Control Markup Language (XACML) ...... 27 4.1.1 An XACML scenario...... 27 4.1.2 An example of XACML policy ...... 28 4.1.3 Relations to other proposals and to the PrimeLife project...... 30 4.1.4 Current status of the XACML proposal...... 30 4.2 The Rule Interchange Format (RIF) ...... 30 4.2.1 RIF Dialects ...... 31 4.2.2 Use Cases...... 31 4.3 P3P ...... 32 4.3.1 Status ...... 33 4.3.2 Conclusion ...... 33 4.4 APPEL ...... 34 4.4.1 Shortcomings ...... 34 4.4.2 Conclusion ...... 34 4.5 Enterprise Privacy Authorisation Language (EPAL) ...... 35 4.5.1 Structure of an EPAL policy ...... 35 4.5.2 An EPAL policy example ...... 35 4.5.3 An EPAL query example...... 36 4.5.4 A typical EPAL scenario ...... 37 4.5.5 Relations to other standards and to the PrimeLife project...... 37
5 4.5.6 Status of the EPAL proposal ...... 37 4.6 CARML ...... 37 4.6.1 Elements of the CARML language ...... 38 4.6.2 Status of the CARML proposal ...... 39 4.6.3 AAPML ...... 39 4.7 Identity Governance Framework ...... 39 4.8 PRIME Policy Languages...... 40 4.8.1 Rough use cases ...... 40 4.8.2 Distinctive features of PRIME languages ...... 41 4.8.3 Relation to standards ...... 42 4.9 WS-Policy...... 43 4.9.1 Structure of a policy...... 43 4.9.2 Normal form of a policy ...... 44 4.9.3 Compact form of a policy ...... 44 4.9.4 Nested policies...... 45 4.9.5 References to other policies...... 45 4.9.6 Intersection of policies...... 46 4.9.7 Relations to other proposals and to the PrimeLife project...... 48 4.9.8 Status of the WS-Policy proposal ...... 48 4.10 OASIS WS-XACML ...... 48 4.11 Security Policy Assertion Language (SecPAL) ...... 49 5 Authentication Infrastructure 50 5.1 The ITU-T X.509 Standard...... 50 5.1.1 X.509 Certificate and Certification Process...... 51 5.1.2 Evolution of the X509 standard ...... 52 5.2 PKIX ...... 53 5.2.1 X.509 Attribute Certificate and Privilege Management Infrastructure ...... 53 5.2.2 Relationship to PrimeLife ...... 54 5.3 XML Signature ...... 55 5.3.1 Specification Overview ...... 55 5.3.2 Status ...... 56 5.3.3 PrimeLife Impact ...... 56 6 User Control Infrastructure 58 6.1 Smart Cards: User-controlled Token for Privacy Protection ...... 58 6.1.1 Introduction ...... 58 6.1.2 Standardisation...... 60 6.1.3 Architectures ...... 60 6.1.4 Strategy and Actions ...... 61 6.2 Biometrics Standardisation and Privacy ...... 61 6.2.1 Biometrics Standardisation ...... 62 6.2.2 Architectures ...... 62 6.2.3 Strategy and Actions ...... 62 7 Identity Systems 64 7.1 OpenID ...... 64 7.1.1 Background ...... 64 7.1.2 Protocol Flow...... 64 7.1.3 Message Formats ...... 65 7.1.4 Trust and Privacy Properties ...... 65 7.1.5 Specification Development ...... 66 7.1.6 Open Source Implementations...... 66 7.1.7 PrimeLife Perspective on OpenID...... 66 7.2 Higgins ...... 67
6 7.3 CardSpace ...... 68 7.4 WS-Federation ...... 70 7.5 SAML ...... 70 7.5.1 Background ...... 71 7.5.2 Architecture ...... 71 7.5.3 Protocol Flow...... 71 7.5.4 Open Source Implementations...... 72 7.6 Liberty Identity Federation ...... 72 7.6.1 History and relationship with SAML...... 72 7.6.2 Liberty profiles...... 73 7.6.3 Profiles of the Single Sign-On and Federation Protocol ...... 73 7.6.4 Single Sign-On Protocol Flow Example: Liberty Artifact Profile...... 73 7.6.5 Liberty and CardSpace...... 74 7.6.6 PrimeLife and Liberty ...... 74 7.6.7 Open Source Implementations...... 74 7.7 Yadis ...... 75 7.7.1 Protocol flow ...... 75 7.7.2 The Yadis document ...... 75 7.7.3 Trust and privacy properties ...... 76 7.7.4 Opportunities for PrimeLife...... 76 7.7.5 Specification development...... 76 7.7.6 Open Source Implementations...... 76 8 Specification Developing Organisations 77 8.1 W3C ...... 77 8.2 IETF ...... 78 8.3 OASIS...... 78 8.4 Liberty Alliance ...... 79 8.5 TCG...... 80 8.6 ISO/IEC JTC 1 ...... 82 8.6.1 ISO/IEC JTC 1/SC 27/WG 5 ...... 82 8.6.2 ISO/IEC JTC 1/SC 17/WG 4 ...... 83 8.6.3 ISO/IEC JTC 1/SC 17/WG 11 ...... 83 8.6.4 ISO/IEC JTC 1/SC 37 ...... 84 9 Selected Open Source Projects 85 9.1 MozPETs: Mozilla Privacy Enhancement Technologies ...... 85 9.2 Firefox Plugins ...... 86 9.2.1 Formfiller and Identity Management Enhancement ...... 86 9.2.2 Privacy Enhancement...... 87 9.2.3 Trust Enhancement ...... 88 9.2.4 Other Firefox Plugins...... 89 9.2.5 Opportunities for PrimeLife...... 89 9.3 TOR...... 89 9.4 Privoxy ...... 90 9.5 Invisible Internet Project (I2P) ...... 91 9.6 Bandit ...... 91 9.6.1 Development Framework...... 92 9.7 Concordia Project ...... 92 9.8 Open-Source Identity System (OSIS)...... 93 9.8.1 Specification development...... 93 9.8.2 Open Source Interoperability Workshops ...... 93 9.9 Pamela Project ...... 93 9.10 OpenSSO ...... 94
7 9.10.1 Architectural Overview ...... 94 9.10.2 Opportunities for PrimeLife...... 94 9.10.3 Open Source Implementations...... 95 9.11 OAuth ...... 95 9.11.1 Protocol flow ...... 95 9.11.2 Trust and privacy properties ...... 96 9.11.3 Specification development...... 97 9.11.4 Open Source Implementations...... 97 9.12 Noserub...... 97 10 Conclusion 98 10.1 Results Available From PRIME ...... 98 10.1.1 Privacy Ontologies...... 98 10.1.2 The JRC Policy Workbench...... 99 10.1.3 Policy Language...... 100 10.1.4 SendPersonalData dialog ...... 100 10.1.5 Firefox plugins...... 101 10.1.6 DataTrack...... 103 10.1.7 Privacy Policy Decision Engine...... 104 10.1.8 BluES'n ...... 107 10.1.9 PRIME Policy Manager...... 107 10.1.10 Obligation Manager ...... 108 10.1.11 Identity Mixer ...... 109 10.2 Results Expected from PrimeLife...... 109 10.2.1 Activity 1 - Privacy Life ...... 109 10.2.2 Activity 2 - Mechanisms ...... 110 10.2.3 Activity 4 - User Interfaces ...... 110 10.2.4 Activity 5 - Policies ...... 111 10.2.5 Activity 6 - Infrastructures...... 112 10.3 Perspectives...... 112 10.4 Recommended next steps for standardisation & open source ...... 113
8 Chapter 1 Introduction
1.1 Scope of this Document
This deliverable aims at giving an overview of standardisation and open source initiatives that are relevant for PrimeLife. It decribes the state of work there as well as possible and actual cooperations. 1.2 Historic Background
Hidden data collection and the slow erosion of people’s privacy led to the start of the P3P work by W3C in 1997. Using P3P, a service can make statements about its privacy practises in both human and machine readable form to support the individual using the service in making informed decisions. Informed decisions by indivduals and procurers were also the aim of ISO/IEC's work on IS 15408 "Evaluation Criterial for IT Security", that started in 1991 and was enhanced by a "Privacy" Class covering Anonymity, Pseudonymity, Unlinkability, and Unobservability, before it was for the first time published in 1999.
With the advent of “Web 2.0”, the Web has become more interactive. Interactive services are built around online communities or offer personalised services. Exchanges of values, ideas and information require a certain level of trust or reputation. In some cases, access to the information is regulated. Currently, a number of initiatives in open source and standardisation exist: OpenID, CardSpace, Higgins, Liberty Alliance, OSIS, as well as language driven ones like FOAF, XACML or SAML. Mostly, the goal is to provide the notion of “Identity” across several completely decentralised services and add the necessary hooks for services to manage the relationship to its users. Often, the frameworks and languages are limited to a specific technology or service. Privacy or security are ignored or only minimally addressed.
As a consequence, identity management today consists of isolated initiatives. Industrial solutions provide control schemes without privacy support. The current standardisation efforts try to federate several solutions. Such federation, in turn, makes the application of Privacy- Enhancing Technologies (PET) even harder as the semantics must participate in the interoperability in order to survive the federation. The PRIME project demonstrated the use of
9 “sticky policies” to transport data protection information with the personal information itself. PRIME also demonstrated how the user may influence or even control the data processing after the transmission of personal data (user-centric approach). The MIT based projects TAMI and PAW showed that data found on the Web can be used to create hooks for data protection decisions, access control and other constraints on the use of data. This work allows opening up the constraint of data use from a strict user-input driven scheme to larger community considerations and enhancing the machine-processing capabilities at users’ hands. Transparency of data processing is the preferred approach.
Already the PRIME project influenced standardisation efforts in W3C and ISO/IEC. At W3C’s Privacy Workshop in October 2006, researchers and practitioners explored new directions in privacy policy languages and enforcement mechanisms. There was significant interest in exploring the interfaces between different, possibly domain-specific, policy languages. In May 2006, ISO/IEC JTC 1/SC 27 "IT Security techniques" has established Working Group (WG) 5 on “Identity Management and Privacy Technologies”. This initiative followed two SC 27 Study Periods on "Identity Management" and "Privacy". The new WG started work with projects such as “A framework for identity management” (24760), “A privacy framework” (29100) and “A privacy reference architecture” (29101). 1.3 PrimeLife Aims and Activities
PrimeLife will explore how current identity management schemes can be influenced to include privacy-enhancing tools and hooks. This necessarily means also influencing current standardisation efforts and creating new initiatives where needed. Within this context, PrimeLife will significantly advance the state of the art in standardisation. PrimeLife will work with selected bodies such as ITU, ISO/IEC JTC 1/SC 27/WG 5, OASIS, and W3C to influence the relevant standards activities to encourage them to incorporate advanced privacy- enhancing concepts and technologies. For example 7 privacy related projects are being worked on in SC 27/WG 5, and PrimeLife is establishing a liaison to this group due to its global outreach and its topical portfolio, overlapping significantly with that of PrimeLife.
PrimeLife also aims at bringing the technologies and concepts into the open source initiatives, in particular in the areas of anonymous credentials (where Partner IBM has made first contributions to Higgins), user interfaces, various kinds of policies (where so far only little, isolated efforts have been made), and also infrastructure components. The most prominent open source initiatives on identity management are OpenID, Higgins, and OSIS. However, they are only a first step in the right direction and do not yet provide end-to-end privacy, identity, and trust management. With such open source code available, it is expected that the currently developed global solutions will integrate PrimeLife solutions, thus, leading to a global impact of the project's results and thus to better privacy protection in the next generation services. Success will be measured by the (success of the) workshop for standardisation of the projects’ technologies and for the cooperation with other projects, by the contributions to standardisation bodies and (existing) open source communities, and by the extent to which these contributions get taken up. 1.4 PrimeLife Project Overview
Individuals in the Information Society want to protect their autonomy and retain control over personal information, irrespective of their activities. Information technologies hardly consider those requirements, thereby putting the privacy of the citizen at risk. Today, the increasingly collaborative character of the Internet enables anyone to compose services and to contribute
10 and distribute information. Individuals will contribute throughout their life leaving a life-long trail of personal data.
This raises substantial new privacy challenges: A first challenge is how to protect privacy in emerging Internet applications such as collaborative scenarios and virtual communities. A second challenge is how to maintain life-long privacy.
PrimeLife will resolve the core privacy and trust issues pertaining to these challenges. Its long-term vision is to counter the trend to life-long personal data trails without compromising on functionality. We will build upon and expand the sound foundation of the FP6 project PRIME that has shown how privacy technologies can enable citizens to execute their legal rights to control personal information in on-line transactions.
Resolving these issues requires substantial progress in many underlying technologies. PrimeLife will substantially advance the state of the art in the areas of human computer interfaces, configurable policy languages, Web service federations, infrastructures and privacy-enhancing cryptography.
PrimeLife will ensure that the community at large adopts privacy technologies. As one of the activities to this effect PrimeLife will work with the relevant open source communities and standardisation bodies. This document summaries these communities and bodies and relates them to the technologies and mechanisms PRIME has produced and PrimeLife aims to produce. 1.5 PrimeLife's Approach to Privacy
We envision that users will be able to act and interact electronically in an easy and intuitive fashion while retaining control of their personal data throughout their life. Users might use a multitude of different means to communicate with several partners employing a variety of platforms. For instance, a user Alice might authenticate to an on-line service created by a mash-up. She automatically logs on using her laptop and later confirms a payment transaction for an electronic article using her mobile phone. In all those transactions, despite many potentially untrusted services collaborate in the mash-up, Alice is able to reveal only the minimally necessary information to establish mutual trust and conduct the transaction. For instance, no service will learn any personal information about Alice. Nevertheless, a merchant is guaranteed payment for the services.
In other words, privacy needs to be addressed in a user centric way, i.e., in a way where the users are given control over their data. This requires that
1. the users be informed what data about them is requested (it might be that the data needs to be certified by a third party) and how that data is going to be used; and that 2. the users be provided with technologies that allow them to conduct transactions in such a way that only the necessary information needs to be revealed.
The first item requires that access control is done in an attribute-based way. Other than an ACL that lists which users are allowed to access, the attribute-based access control defines for each item what attributes (requirements, credentials) a requester needs to satisfy to get access to a resource. Next, access control needs to be done such that the user is not authenticated with respect to a user ID (and then checking whether that user has the required attributes) but rather by allowing access to any user who can provide proof that the attributes are satisfied. For this to work, various languages for policies, ontologies, and credential and
11 attribute formats are needed to communicate all these data. Moreover, the users need to be given intuitive user interfaces that guide them through such authorisation procedures. It should be able to investigate which data will be sent to which partners at what time and thereby maintain a profile (or partial identity) with the communication partners.
Let us discuss the second item. Some of the technologies we have already mentioned: access control mechanisms, various languages and components to work with them (e.g., editors, evaluation engines, ...), and user interfaces. In addition, we require anonymous (or private) credentials. These are essentially public key certificates that certify also attributes about the users (e.g., an electronic version of a driver's license) that allow users to control what information contained in the certificate shall be revealed at what time. So for instance, using an anonymous driver's license credential, user Alice could convince a bar tender that she is old enough to order a beer without disclosing any other information attributed to her in the license (in fact, she does not even have to reveal her birth date but only the fact that she was born a sufficient time ago to be old enough for that beer). This aspect of PrimeLife's approach is taken over from the PRIME project and hence can draw on the these results many of which are quite mature already. Therefore we deem this offers many opportunities for standardization and open source contributions.
However, the approach to reveal only the minimally necessary information does not address all the privacy problems arising. In many cases, e.g., social networks or wiki pages, the users indeed want to reveal personal information about them and also exchange these information. Moreover, as information is provided by many different parties, it becomes much harder to judge whether the information is trustworthy. The establish the latter, users will potentially have to reveal even more information about themselves in order for their communication partners to assess to what extent and with respect to what they can be trusted. PrimeLife aims to address these challenges as well. In this area, PrimeLife is to a large extend conducting basic research and therefore we here expect fewer opportunities for standardization and maybe just a few isolated contributions to open source communities.
12 Chapter 2 Target Technology Platforms
Data is exchanged between various kinds of computer systems connected to Internet. The target platform for PrimeLife work is generally the Web. This section reviews the architecture of the Web and its essential technology components. Although few standards are available for privacy and security on the Web in general, the deployment of Web services has led to dedicated work for Service-Oriented Architectures. 2.1 The Web
2.1.1 Architecture
The World Wide Web (see WEBARCH [WEBARCH]) is a global information space built on top of a set of relatively simple technologies which, in combination, have enabled its world wide deployment, and have catalysed the Internet's growth and use over the last 15 years.
Key design elements of the World Wide Web include:
Identification Uniform Resource Identifiers [URI] serve to identify resources on the Web. They provide an abstraction layer for resource identification across protocols and across document formats. New URI schemes can be introduced without having to change the surrounding format (e.g., HTML, SVG, MathML). Extension by URI scheme enables deployment of new protocols without having to change surrounding document formats. However, it is not true that dereferencing the same URI will always result in the same protocol interaction. Further, different URI schemes expose different methods -- the HTTP protocol, e.g., supports both retrieval and information posting methods (GET and POST).
Interaction While URIs provide the means for extensibility in protocol space, a social agreement (codified in the set of supported protocols in user agents) leads to the choice of HTTP as the primary protocol for the Web. Key properties of HTTP include safe information retrieval (the simple retrieval of a Web page is by convention free of side effects; side
13 effect bearing interactions can be distinguished) and negotiation of resource representations (depending on, e.g., language preferences and supported data formats).
Formats For data formats (as for protocols) the practically unlimited extensibility of the protocol and addressing layers is complemented by social conventions (codified in deployment) about the formats in use: Various variants of HTML, style and scripting languages, and a few graphics formats effectively form the backbone of today's Web.
2.1.2 Standards
This section summarises the specifications that are at the core of today's instantiation of the Web: HTTP as the primary retrieval protocol, HTML and CSS as the primary formats used for documents and their style, and the Document Object Model's application programming interfaces as used by the ECMAScript scripting language (more commonly referred to as JavaScript).
HTTP and TLS
The Hypertext Transfer Protocol (RFC 2616 [RFC 2616]) is a fundamentally stateless request/response protocol that is used to interact with Web resources. Methods that can be used in this interaction include both simple retrieval (GET; a so-called safe method, as it must not cause side effects), submission of information (using POST or PUT), and other manipulations (using, e.g., DELETE). HTTP further supports content and language negotiation, redirection functionality, and advanced mechanisms for caching and proxying of requests.
Browser cookies -- while broadly deployed -- are a notoriously underspecified aspect of HTTP; yet, they serve a critical function on today's Web, by adding session management to an otherwise stateless protocol.
Authentication within HTTP is limited to simple username and password based approaches, even though the protocol's framework can be extended to different authentication protocols. In practice, even these features go largely unused. Deployments mostly rely on HTML forms to solicit user names and passwords, and on cookie-based session management to tie a prior authentication transaction to a session. Identity systems for the Web take a similar approach: The basic identity transaction is either conducted on top of HTTP, or through a separate protocol, and the result of that transaction is then tied to a session.
Similarly, confidentiality and signature services are out of scope for HTTP. These functionalities are instead provided by the TLS protocol (formerly known as SSL). TLS, too, provides a framework for transporting user credentials (RFC 2818 [RFC 2818]).
Deployment of HTTP is virtually ubiquitous: HTTP servers can be found in about any network enabled device (often as configuration and control interface of choice); HTTP clients are found on mobile phones, gaming consoles, and of course personal computers.
The broad deployment of HTTP causes significant inertia: Changes to the HTTP protocol (e.g., a new version) can only be deployed mid-term. The ongoing standards effort at the IETF [HTTP bis] is at this time (April 2008) focused on specification maintenance and errata work; it is expected that this work will produce a higher-quality version of the HTTP/1.1 specification.
14 As far as security and identity mechanisms for HTTP are concerned, the currently active IETF working group is specifically chartered to only document the protocol's properties. Yet, there is a certain amount of momentum to further investigate security mechanisms for HTTP, and it is expected that this momentum will further materialise during the lifetime of Prime Life (see HTTP bis Security Properties [HTTPbis-security]).
HTML, CSS
The Hypertext Markup Language, HTML, is (like HTTP) at the root of the Web's stack of specifications. It gives authors the means to:
• Publish online documents with headings, text, tables, lists, photos, etc. • Retrieve online information via hypertext links, at the click of a button. • Design forms for conducting transactions with remote services, for use in searching for information, making reservations, ordering products, etc. • Include spread-sheets, video clips, sound clips, and other applications directly in their documents.
The object tag in HTML enables embedding of arbitrary objects, and subsumes the functionality of the deprecated applet tag. Extensions to HTML can also be based on using class names as an indicator for content's semantics. The microformat community [Microformats] is advocating this approach to embed semantic data with HTML documents.
Current versions of HTML are HTML 4.01 [HTML 4.01], the last SGML version of HTML, and XHTML 1.0 [XHTML 1.0], a reformulation of that language in XML.
Ongoing development is focusing on HTML5 [HTML5], an effort to provide an interoperable specification for HTML and associated APIs, and XHTML 2 [XHTML 2], the next generation of the XML-based XHTML.
Layout information for HTML (and other structured document formats, including XML applications) can be specified using Cascading Style Sheets [CSS 2].
Document Object Model, ECMAScript, XMLHttpRequest
The W3C Document Object Model (DOM [DOM Level 3 Core]) is an API that manipulates HTML and XML documents. It relies on a structure model of the document and defines accessors to the various components of this structure. It is platform-neutral and language neutral. It is organised in levels which specify required and optional features: Level 1 defines a core model and a basic API for HTML, Level 2 enhances the core model and adds views, events, style and traversal APIs. Level 3 has a more complete core model (including more DOM types) and provides load-and-save and validation APIs. All the W3C DOM Levels recommendations include bindings to Java and to ECMAScript. DOM is the preferred API to manipulate HTML and XML documents on the Web when accessing elements in non- sequential order is required.
ECMAScript, standardised by ECMA International (see ECMAScript [ECMAScript]) in 1999 is mostly used as a language to manipulate Document Object Models on the Web. It is the major language for client-side scripting, implemented in all common clients for all kinds of platforms. ECMA TC39 [ECMA TC39] is actively working on the ECMAScript 4 language.
15 The XMLHttpRequest [XMLHttpRequest] object is another neutral API that allows scripts to perform HTTP client requests without reloading the Web pages. It builds on some parts of the DOM model and constitutes the core of the Ajax technique. The goal of such a specification is to unify the techniques used for dynamicity of content and achieve the necessary interoperability that proprietary technologies (ActiveX, inline frames, proprietary applets, Flash...) prevent. It is currently a W3C Working Draft.
2.1.3 Evolving Web Application Development Paradigms - Web 2.0
The power of Web applications often comes from the easy combination of data and services across multiple sources: In the easiest case, a meeting description might include a map service inline, highlighting the meeting location. More complex mash-ups might combine any number of data sources, factor in personal information (e.g., travel plans) to answer the user's questions, and trigger activities on multiple possible services.
As application programming interfaces and client-side scripting have matured in recent browser generations, they have enabled an increasing shift of complexity toward the client side: Where much of the complexity of "Web 1.0" applications resided on the server side, "Web 2.0" and "AJAX" programming puts complexity on the client, and thinks of the server side as generic APIs that can be invoked by complex applications running on the client.
These choices have a profound impact on the security and privacy structure of the Web: On the one hand, there is increased susceptibility of services to abuse, as careless use of Web 2.0 design patterns might put security (and privacy) critical aspects of business logic on the client, and thereby in the hands of an attacker. More dangerously, mash-ups will often run scripts from different trust domains within a single domain of control (or within several, insufficiently isolated domains of control). As a result, the technical environment's enforcement of social and business agreements between different data processing parties becomes difficult in actually deployed mash-up environments.
Some recent research and development into JavaScript security models has the potential to help change this environment to improve the client-side Web programming environment's ability to enforce security and privacy policies. We specifically mention the open source Caja [Caja] project that extends JavaScript to include a capability based security model. This security model is deployable now, through a JavaScript-to-JavaScript compiler.
On the other hand, modern Web application development techniques improve the abilities of collaborating actors to share user data and track behaviour, beyond what is possible with simple cookies, HTML pages, and forms. Classical privacy-enhancing techniques that might, e.g., impose controls on cookies or warn before form submissions are losing their usefulness, as new technologies enable storage of client-side state (e.g. to enable offline Web applications), tracking of users, and exchange of information between different sites.
It is an open research question what leverage points are best suited to build the enforcement of privacy policies into Web applications, and to create business and technical incentives for Web application developers to disclose privacy intents.
Additional approaches to data sharing in Web 2.0 scenarios involve the passing of personal information and authorisations between different sites through (mostly) redirect patterns. Relevant developments include OAuth (see chapter 9) and OpenID (see chapter 7).
16 Primelife Perspective
Overall, mash-ups and the use of Web 2.0 programming patterns to process personal information are going to stay with us. In the context of Activity 1, PrimeLife will analyse these use cases in more detail.
Standardisation Efforts
Specifications relevant to Web 2.0 programming patterns are under development in a number of places: The W3C HTML Working Group [HTML WG] is developing the HTML5 [HTML 5] specification, which includes numerous APIs (including APIs for local storage of data, cross-domain communications, and relevant security models); additional related work is done by the W3C Web Application Formats [WAF WG] and Web API Working Groups [Web API]; a proposal to merge these groups is currently (May 2008) under consideration by the W3C membership. Some work on Caja [Caja] has found its way into the ECMAScript standardisation work at ECMA TC39 [ECMA TC39]. Other relevant work is either being done under the umbrella of open source projects or ad-hoc initiatives, and may make its way into more formal standardisation during the lifetime of the project.
2.1.4 Semantic Web
The Semantic Web provides a common framework that allows data and metadata to be shared and reused across application, enterprise, and community boundaries. Key ingredients of this framework include the simple, yet powerful data model of the Resource Description Framework [RDF-PRIMER]; a standardised query language [SPARQL]; and an ontology language [OWL] that enables machine-readable expression of the relationships between different concepts.
The usage of URI references as identifiers enables different parties to coin new terms without the risk of clashing with others, thereby enabling easier integration and mixing of data.
From a privacy perspective, Semantic Web technology will enable ever easier and ever more powerful aggregation of personal information. Where a lack of integration might in the past have helped individual privacy, the Semantic Web promise of overcoming that gap.
The power of Semantic Web technologies cuts both ways, however: It also eases the tasks of identity management by providing a framework that can be used to express not just personal information, but also privacy practices, policies, and preferences. As broader and more effective data integration becomes possible, distributed and scalable compliance monitoring becomes possible, leading to improved accountability of those who process personal information.
2.1.5 Privacy technologies for the Web
Very few Privacy-Enhancing Technologies (PET) are standardised today. There is a large variety of tools (see chapter 8) that do not interoperate. Wisdom put into one tool can't be used in another tool. This way it is also very hard for E-Commerce sites to obtain predictable results when designing their portals. P3P is the only major exception to this rule. It is discussed together with other relevant standards in more detail separately in this document, specifically P3P (see chapter 4) and APPEL (see chapter 4). APPEL as opposed to P3P, has never reached the status of Recommendation.
17 2.2 Service Oriented Architectures
The basis for this text is an updated version of Geuer-Pollmann/Claessens [Geuer-Pollmann/ Claessens]. The term ‘Web services’ is found nearly anywhere in the enterprise platforms and networking domains. Generally speaking, ‘Web service’ refers to the transfer of XML via internet protocols, such as HTTP or SMTP. The ‘Simple Object Access Protocol’ (SOAP Version 1.2, 2007 [SOAP12]) is an XML based protocol, which provides a definition how structured and typed information can be exchanged between peers in a distributed and decentralised environment.
In order to provide security, reliability, transaction abilities and rich meta-data support for Web services, additional specifications exist on top of the XML/SOAP stack. Figure 1 provides an overview of important Web service specifications and how they relate to each other. XML lays the basis for all the standards. Other basis technologies in this group are SOAP encoding service invocations, its transport protocols HTTP/UDP, and basic XML cryptography schemas. The next layer, called 'Messaging', groups standards that provide advanced communication features such as flow control, transactions, establishing of secure communication channels, and trust establishment. The layer 'Infrastructure and Profiles' layer contains standards which typically affect the interaction between multiple services, such as interoperability, trust establish between services/parties across organizational borders, and distributed management. The 'Metadata' group is somehow orthogonal to the latter three layers. It groups standards that deliver information how to find and invoke a service, e.g. address lookup, specific meta-data, security policy, and service interface.
The standards in Figure 1 are color coded, indicating the defining organization and the status of the specification. The core technologies in the XML space are all defined by the World Wide Web Consortium (W3C). Many of the higher-layer specifications are driven by multiple industry players, including Microsoft, IBM, BEA Systems, SAP and others. These specifications help to make progress in the interoperability between the different industry platforms, most notably Microsoft’s .NET [MS .NET] platform and IBM’s WebSphere [IBM WebSphere] software. The results are often donated to standards organisations like OASIS [OASIS], which will care for their future evolution.
18 'Figure 1: Overview of existing Web service specifications and their relations.'
2.2.1 OASIS WS-Security
The WS-Security [WS-Security] specification defines mechanisms for integrity and confidentiality protection, and data origin authentication for SOAP messages and selected parts thereof. The cryptographic mechanisms are utilised by describing how XML Signature and XML Encryption are applied to parts of a SOAP message. That includes processing rules so that a SOAP node (intermediaries and ultimate receivers) can determine the order in which parts of the message have to be validated or decrypted. These cryptographic properties are described using a specific header field, the
19 a container for arbitrary binary tokens (base64 encoded), a container for XML-formatted tokens, and an encrypted data token.
Additional specifications define various ‘token profiles’ that introduce special token formats. For instance, the X.509 Certificate Token Profile 1.1 [X.509 Certificate TP 1.1] defines how X.509 certificates, certificate chains or PKCS#7 certificate revocation lists may be used in conjunction with WS-Security. The ‘Username Token Profile 1.1’ extends the existing username token by adding literal plaintext passwords, hashed passwords, time variant parameters (nonce) and creation time stamps. The Rights Expression Language (REL) Token Profile 1.1 [REL TP 1.1] links WS-Security to ISO/IEC 21000-5. The Kerberos Token Profile 1.1 [Kerberos TP 1.1] defines how Kerberos tickets are embedded into SOAP messages and the SAML Token Profile 1.1 [SAML TP 1.1] defines how SAML 1.1 and 2.0 assertions (see also SAML 2.0 Bindings [SAML 2.0 Bindings]) can be included.
WS-Security is one of the basic security specifications in the Web service world. Therefore it is definitively relevant for PrimeLife.
2.2.2 OASIS WS-SecureConversation
The WS-Security specification introduced the concept of message level security. By utilising only WS-Security to encrypt and sign Web service messages, a lot of overhead related to key management is necessary. For instance, if a Web service requires each message being encrypted using a 2048-bit RSA operation and given the fact that 1000 service invocations may happen during the next 3 minutes, it becomes obvious that this concept does not scale very well. In the transport layer, HTTP 1.1 permits to keep an existing SSL/ TLS connection open so that subsequent requests to a Web server may be sent via the already established secured connection. WS-SecureConversation [WS-SecureConversation] brings this concept into the Web services world. This is done by introducing mechanisms to establish and share so-called ‘security contexts’. Based on established security contexts or arbitrary already existing shared secret keys, WS-SecureConversation provides mechanisms to derive shared key material (read: session keys). Security contexts can be established in three different ways. First, a security context token (SCT) may be retrieved using the mechanisms of WS-Trust. In that case, the requestor retrieves the SCT from some security token service that is trusted by the Web service. The second way is that the requestor creates an own SCT and sends that SCT to the Web service. The problem may be that the Web service may not trust the requestor to create an appropriate SCT and may reject that self-created SCT. A third option is that both the requestor and the Web service mutually agree on a security context using a challenge-and-response process. An established SCT is afterwards used to derive session keys. These session keys may then be used for subsequent message encryption and message authentication codes (symmetric ‘signatures’) with WS-Security.
In the scope of PrimeLife, as in most other Web service based solutions, WS- SecureConversation is a reasonable addition to WS-Security.
2.2.3 OASIS WS-Trust
The WS-Trust [WS-Trust 1.3] specification introduces the concept of ‘security token services’ (STS). A security token service is a Web service that can issue and validate security tokens. For instance, a Kerberos ticket granting server would be an STS in the non-XML world. A security token service offers functionality to issue new security tokens, to re-new existing tokens that are expiring and to check the validity of existing tokens. Additionally, a security token service can convert one security token into a different security token, thus
20 brokering trust between two trust domains. For example, a Web service describes required security tokens for Web service calls using WS-SecurityPolicy/PolicyAttachment. A requestor may want to call that specific Web service but may not have the right security tokens indicated by the policy. The Web service may require SAML credentials from a particular trust domain whereas the requestor only has an X.509 certificate from its own domain. By requesting the ‘right’ matching token (credential) from the security token service, the requestor may get back a token from the STS that can be included when calling the Web service in question. The decision what exactly the ‘right’ token is can be made either by the requestor or by the STS. The requestor may inspect the Web service’s policy and specifically ask the STS: "I have the attached X.509 certificate and need a SAML token". The other option is that the requestor includes its possessed tokens and states what Web service it intends to call: "I possess the following tokens and I would like to call the Web service http://foo/bar. Please give me whatever token may be appropriate." WS-Trust provides a rich interface that permits the implementation of various use cases. For instance, the requestor may include time variant parameters as entropy for a token generation process. The token service may return secret key material to the requestor (so-called proof-of-possession tokens) along with the requested security token, so that the requestor can prove that it possessed the security token. For instance, the requested security token may be a certificate whereas the proof-of-possession token is the associated private key. The security token service may also return multiple keys like a certificate along with its validation chain or it may create key exchange tokens with which the requestor can encrypt key material for the intended Web service. A requestor can also express requirements on algorithms and key strengths for required tokens. WS-Trust defines protocols including challenge-and-response protocols to obtain the requested security tokens, thus enabling the mitigation of man-in-the-middle and message replay attacks. The WS-Trust specification also permits that a requestor may need a security token to implement some delegation of rights to a third party. For instance, a requestor could request an authorisation token for a colleague that may be valid for a given time interval. WS-Trust utilises WS-Security for signing and encrypting parts of SOAP messages as well as WS-Policy/SecurityPolicy to express and determine what particular security tokens may be consumed by a given Web service.
WS-Trust is a basic building block that can be used to rebuild many of the already existing security protocols and make them fit directly in the Web services world by using Web service protocols and data structures. It is thus essential for service composition in PrimeLife.
2.2.4 W3C WS-Policy
The Web Services Policy Framework (WS-Policy) [WS-Policy 1.5] provides a general- purpose model to describe Web service related policies. A policy can describe properties, requirements and capabilities. For example, a policy may mandate that a particular Web service only provides services between 8:00 AM and 5:00 PM or that service requests must be signed using an X.509 certificate (of course not by the certificate but by its associated key). Policies also allow to define different available options, so that machines can figure out based on their own policy and a service’s policy what requests may be accepted and what requests may be not. WS-Policy by itself only provides a framework to describe logical relationships between policy assertions, without specifying any assertion. WS-PolicyAttachment [WS- PolicyAttachment 1.2] attaches policies to different subjects. ‘Web service related’ means policies apply to service endpoints or to XML data. A policy can be attached to an XML element (by embedding the policy itself or a link to the policy inside the element) or by linking from the policy to the subject that is described by the policy. WS-PolicyAttachment also defines how policies can be referenced from WSDL documents and how policies can be attached to UDDI entities and stored inside a UDDI repository. WS-MetadataExchange [WS-
21 MetadataExchange 1.1] defines protocols to retrieve metadata associated with a particular Web services endpoint. For example, a WS-Policy document can be retrieved from a SOAP node using WS-Metadata.
2.2.5 OASIS WS-SecurityPolicy
WS-SecurityPolicy [WS-SecurityPolicy 1.3] defines certain security-related assertions that fit into the WS-Policy framework. These assertions are utilised by WS-Security, WS-Trust and WS-SecureConversation. The ‘SecurityToken’ assertion tells a requestor what security tokens are required to call a given Web service (‘security tokens’ are described in the sections WS- Security and WS-Trust). Integrity and confidentiality assertions identify the message parts that have to be protected and it defines what algorithms are permitted. Visibility assertions identify what particular message parts have to remain unencrypted in order to allow SOAP nodes along the message path to operate on these parts. The ‘MessageAge’ assertion enables entities to constrain after what time a message is to be treated as expired.
2.2.6 Primelife Perspective
Web services are an important building block to realize web-based business processes. Hence, their implications in terms of security and privacy have to be considered to meet the project goals. In PrimeLife, Activity 6 will analyze this area in more detail and will investigate new approaches to address the main privacy issues.
22 Chapter 3 Architectures and Frameworks
This section presents work of the Working Group (WG) 5 "Identity Management and Privacy Technologies" of ISO/IEC JTC 1/SC 27 "IT Security techniques" which is described in more detail in the section about the Specification Developing Organisations (see chapter 8). PrimeLife is establishing a liaison with WG 5 due to its global outreach and its topical portfolio overlapping significantly with that of PrimeLife. The terminology in this section follows that of the respective standards. 3.1 Identity Management
3.1.1 IdM Framework (24760)
This standard aims to provide a framework for the definition of identity and the secure, reliable, and private management of identity information. This framework should be applicable to individuals as well as organisations of all types and sizes, in any environment and regardless of the nature of the activities they are involved in.
Identity Management (IdM) is the secure management of identities, the identification process during which an entity may be authenticated, and the information associated with the identification of an entity within some context. The entity might be anything that can be uniquely recognised, a person, an animal, a device, an object, a group, an organisation, an information object, etc. Entities may have multiple identities that may be used in different contexts, often called Partial Identities.
The context for the identification process might be within an organisation’s boundaries, or federated across organisations. This standard will cover the life cycle of identities and identity information as they are established, modified, suspended, terminated or archived. Information associated with identities may change over time and must therefore be carefully managed. Some associations of an entity might be informal and change frequently. Other associations might be formal, specific relationships, such as people, policy-based organisational roles, and financial accounts that remain stable over time. Identity attributes are often securely stored within tokens, directories, access devices, or database management systems.
23 Identities may be associated with policy-based roles, and these roles may be associated with duties and responsibilities, and privileges and permissions to access resources. An Identity Management System (IdMS) also needs to interact with other information systems that require or generate identity information.
This project is in the "Working Draft" stage.
3.1.2 A Framework for Access Management (29146)
This standard aims to provide a framework for the definition of Access Management and the secure management of the process to access information. This framework is applicable to any kind of users, individuals as well as organisations of all types and sizes, and should be useful to organisations at any location and regardless of the nature of the activities they are involved in.
Access Management (AcM) is the secure management of the processes to access information and the information associated with the accountability of an entity within some context. The entity might be anything that can be uniquely recognised, a person, an animal, a device, an object, a group, an organisation, a piece of information, etc. Entities may have multiple identities that may be used in different contexts. Identities may be federated or not. The processes include, without limitation, the identification, the authorisation, the entitlement and privilege management; the authentication, and the review of information usage. The intent is not to define in details the technical aspects of each of these processes but to identify the overall process of the access to the information. The different services composing an Access Management framework are typically
• an Identity Management service • an Entitlement, Privilege and Authorisation Management service • an Authentication Management service, and • a Usage Control and Monitoring service.
Other services may be identified during the development of the standard. A typical model for an Access Management framework is composed of several services that could be decoupled or integrated in a solution suite. The standard must clarify the relation between the framework and to the services mentioned and their interactions. The context for access might be within an organisation's boundaries or federated across organisations. This standard describes the life cycle of access and security services associated to that access as they are established, modified, suspended and terminated. Information associated with accesses may change over time and must therefore be carefully managed. The framework must provide the means to administrate the access definitions of all users and to publish the definitions to the information systems that it may serve. Access definitions may be associated with policy- based rules and roles, and these roles may be associated with duties, responsibilities, privileges and permissions to access resources. An Access Management System ensures the secure management of access definitions that also include the delivery of credentials to users entitled to roles and the secure maintenance thereof.
This project is in the "New Project" stage and a first Working Draft is expected for Summer 2008.
24 3.1.3 Entity authentication assurance (29115)
This project aims at describing the guidelines or principles that must be considered in entity authentication, assurance and the rationale for why it is important to an authentication decision, especially: a framework for assessing "how close" an entity is to the claimed one throughout an identity's life cycle;
• guidelines for how the strength of the authentication can be measured; and • the basis for a set of entity authentication assurance measures that are general and applicable to the entire life cycle of an identity including a wide range of authentication mechanisms.
This project is to take into account the following requirements:
• authentication metrics • authentication mechanisms • authentication protocols • characteristics of the device used to authenticate • location of the individual being authenticated • communications paths • relative ease of authentication manipulation by malicious behaviour • corrections and modification of errors • identifier types • identity proofing • privacy
This project is in the "Working Draft" stage. 3.2 Privacy
3.2.1 A Privacy Framework (29100)
This Project aims at providing a framework for defining privacy safeguarding requirements as they relate to PII (Personally Identifiable Information) processed by any information and communication system in any jurisdiction. The framework is to be applicable on an international level and addresses system specific issues on a high-level. It is general in nature and puts organisational, technical, procedural and regulatory aspects in perspective. It is the purpose of this international standard to provide guidance concerning information and communication system requirements for processing PII by setting a common privacy terminology, defining privacy principles when processing PII, categorising privacy features and relating all described information privacy aspects to existing security guidelines. The framework can serve as a basis for desirable additional privacy standardisation initiatives, for example for a technical reference architecture, for the implementation and use of specific privacy technologies, for an overall privacy management, for the assurance of privacy compliance for outsourced data processes, for privacy impact assessments or for specific engineering specifications.
The Privacy Framework is being developed for those individuals with an interest in the standardisation of privacy safeguarding controls as they relate to PII processed by enterprise ICT systems. This may include individuals involved in specifying, procuring, architecting, designing, developing, testing, administering and operating ICT systems. Recognising the
25 growing need to incorporate privacy requirements and privacy safeguarding controls in system development life cycles or, more specifically, in security development life cycles this International Standard addresses the target audience of ICT system developers in a separate section, providing a framework and guidelines for an approach to built-in privacy-enhancing functionalities already during the system development.
This project is in the "Working Draft" stage.
3.2.2 A Privacy Reference Architecture (29101)
This project aims at providing a privacy reference architecture model that describes best practices for a consistent, technical implementation of privacy safeguarding requirements as they relate to the processing of personally identifiable information in information and communication systems. It is to cover the various stages in data life cycle management and the required privacy functionalities for PII in each data life cycle, as well as positioning the roles and responsibilities of all involved parties. The privacy reference architecture aims at presenting a best practice, privacy-enhanced architecture model and provides guidance for planning and building system architectures that facilitate the proper handling of PII across system platforms. It sets out the necessary prerequisites to allow the categorisation of data and control over specific sets of data within various data life cycles. It is the purpose of this project to provide guidance concerning a consistent and effective technical implementation of privacy safeguarding requirements within information and communication systems. Therefore it establishes a privacy reference architecture that enables system architects to build necessary privacy safeguarding measures into the system in a cohesive way across system platforms and to combine them with existing security measures, all to improve the proper handling of PII overall. Additionally, the privacy reference architecture gives best practices in advancing the use of privacy-enhancing technologies.
Interested parties that would benefit from using the concepts of the privacy reference architecture include representatives from organisations designing, developing, implementing, and operating information and communication systems. Most likely, these are representatives from various IT organisation departments such as from development, support, and operations or business units or quality assurance and data protection units that have a specific interest in applying consistent architectural decisions to accomplish compliance with specific privacy requirements, rules and regulations.
This project is in the "Working Draft" stage.
26 Chapter 4 Policy and rule languages
This chapter provides an initial, descriptive review of a number of policy and rule languages, both established standards and research languages. This review will be further refined as the PrimeLife project's research work on policy languages proceeds. Based on that review, and on the project's research results, suitable avenues for standardisation of such results will be proposed. 4.1 Extensible Access Control Markup Language (XACML)
XACML is a general-purpose access control policy language. It provides an XML syntax both for a policy language and an access control decision language.
The policy language allows for descriptions of general access control requirements, while the decision language enables users to create queries about whether a given action on a certain resource should be allowed or not, and also to interpret the result. The response is always comprised of one of the following answers: Permit, Deny, Indeterminate (an error occurred or a decision cannot be made because some required information is missing) or Not Applicable (the request cannot be answered by this service because no applicable policy has been found).
4.1.1 An XACML scenario
In a typical XACML scenario, a user wants to perform some action on a resource. In this context, a resource is anything to which access can be controlled, such as an XQuery module or a Java method, and the requested action may be a query execution and a method invocation, respectively.
The user issues a request to the device protecting the resource (e.g.: filesystem or a Web server), which is called a Policy Enforcement Point (PEP). The PEP creates a request which consists of four collections of attributes, describing the Subjects (or users) making the request, the Resource being accessed, the Action to be performed on the resource, and the
27 Environment, comprised of additional information related to the request but not specifically linked to the previous three entities. The Environment attribute collection is optional.
The PEP sends this request to a Policy Decision Point (PDP), which processes it by looking for some policy that applies to it.
An XACML Policy consists of a single access control policy, in the form of a collection of rules. A policy specifies the conditions under which access to the requested resource can be allowed or must be denied. Each policy and each rule within the policy contain a set of applicability predicates used to determine whether the policy (or the rule) applies to a given decision request.
The applicability predicates are organised in an item called Target. A Target is a set of conditions for the Subject, the Resource, the Action, and the Environment that must be satisfied for a policy or rule to apply to a given request. Boolean functions are used to compare values found in a request with those included in the Target. If all the conditions of a Target are met, then the relevant policy or rule applies to the request. Target information not only is useful to check applicability, but also provides a policy indexing service, in that policies may be searched through by a PDP on the basis on their Target constraints. If a policy has no Target, it means that it is always applicable. If a particular type is missing (for example, there are no Subjects) the policy applies to all instances of that type (i.e. to all subjects). If there is more than one group of predicates of a given type, all predicates in at least one group for each type must be true.
A Target element may be followed by at most one Condition, comprised of a single predicate or a Boolean combination of predicates. XACML does not make any distinction among attributes in specifying whether they should appear in the Target or in the Condition predicates. If the Condition is missing, then the Condition is treated as implicitly true. If either the Target predicates or the Condition predicates evaluate to false, the policy or rule is considered not applicable to the request, and a Not Applicable value is returned. When a rule applies to a request, the value of its Effect attribute (Permit, or Deny) is returned as a result of the evaluation. As a policy typically contains multiple rules, XACML specifies a set of Combining Algorithms to compose possibly contradictory multiple results into a unique response. For instance, when a policy relies on the Deny Overrides Algorithm, if any evaluation returns Deny, or no evaluation permits, then the final combined result is also Deny. On the contrary, with a Permit Overrides Algorithm only one Permit sub-result is needed to yield a Permit final result.
The PDP is thus able to produce an answer on whether access should be granted (that is, a decision is taken). Such answer is returned to the PEP, which can then allow or deny access to the requester (that is, the decision is enforced).
PEP and PDP are here treated as two logically distinct units, but they might both be included in a single application, or be distributed across several servers.
Here follows a simplified example that illustrates the concepts above.
4.1.2 An example of XACML policy
A Request element generated to meet the request from Seth of the developers' group to read a document on the server would look like this:
28
A Policy that applies to such request follows:
This policy, called ExamplePolicy, targets all requests of actions on a resource whose URI is http://server.example.com/docs/guide.html. It is comprised of a single rule (ReadRule) targeting all requests of actions whose action-id attribute is string read. If the requesting subject satisfies the condition of having a group attribute whose value is a developers string, then the Permit effect is returned as a result of the evaluation of the rule, and also of the policy. The PDP then sends to the PEP the following Response item:
29
XACML does not provide any description of the vocabularies used in the policies, whose definition lies outside the scope of this specification. Policies must include all the information needed to identify and evaluate each attribute used in the policy.
4.1.3 Relations to other proposals and to the PrimeLife project
XACML has raised some criticism regarding its low performance because of the overhead (processing time and memory) of the XML format and the lack of an easy integration into existing entitlement engines. Still, detailed comparisons in the literature [TREPALXACML] show that XACML provides a more comprehensive access control policy language than its most significant competitor EPAL (see chapter 4), and also a fully-featured privacy policy language.
4.1.4 Current status of the XACML proposal
The latest XACML version 2.0 was ratified by OASIS standards organisation on 1 February 2005. Version 3.0 is currently in preparation.
There is a number of open source implementations of the XACML standard:
• Sun's Implementation, version 1.2 (14/02/2006) [Sun XACML] ◦ Full support of XACML 2.0, no support for SAML ◦ Java 2.0 Platform, Standard Edition version 1.4.0 ◦ License: BSD License (old?? copyright years 2003-2004) • Enterprise-Java-XACML from Google Code, (beta) version 0.0.14 (08/02/2008) [Enterprise-Java-XACML] ◦ It is not based upon the Sun Microsystems' implementation ◦ Full support of XACML 2.0, intended support of XACML 3.0 ◦ License: Apache License 2.0 • SICSACML: XACML 3.0 [SICSACML] ◦ It is based upon the Sun Microsystems' implementation ◦ Java implementation of XACML 3.0 draft, released as patch for (1). It implements a PDP for XACML 3.0. ◦ License: BSD License
Further information about the state of XACML is available from the OASIS XACML Technical Committee's home page [OASIS XACML]. 4.2 The Rule Interchange Format (RIF)
The Rule Interchange Format is a family of XML languages being developed by the Rule Interchange Format (RIF [RIF]) Working Group at W3C to allow computer-processable rules to be transferred between rule systems. RIF is a work-in-progress, and what is described here is a vision for how RIF is expected to materialise over the coming months and years, with
30 basic features completed first. All the features described here are subject to change as the Working Group proceeds.
4.2.1 RIF Dialects
The RIF family of languages (each called a "dialect") is organised to match the different kinds of technologies used to work with rules. It starts with a common language, RIF Core, which corresponds to the shared subset (the intersection) of major rule languages. Rules written in this XML language can be translated with relative ease to nearly all other major rule languages. Simple rules can be be written in RIF Core, or translated to RIF Core, but many practical rule bases will only be transferable using some other dialect. Expressively, RIF Core is datalog (the language of positive Horn clauses without function terms), along with some primitive datatypes (such as integers and strings), and the common operations on those datatypes (such as addition and string concatenation). The syntax of RIF is designed to be quite general, and to be straightforward to parse and generate, so it is naturally verbose. A part of an example rule about the perishability of items, from one of the RIF working drafts, is given here:
...
Above RIF Core, RIF splits into two main branches, "production rules" and "logic rules". Production rules take the form "if (some condition) becomes true then do (something)", or if- condition-then-action. This is the style of rule handled by the major business rules products. Logic rules take the form "if (some condition is true) then (some other condition must be true)", or if-condition-then-condition. This is the style of rule handled by pure Prolog, by FOL logic theorem provers, and by many systems with varying degrees of acceptance over the past 40+ years. Along the logic branch, the RIF Basic Logic Dialect, or RIF BLD provides a common subset language. It extends RIF Core by adding function terms and equality, along with argument naming and membership/subclass structures. It does not, however, include any form of negation, since logic languages diverge sharply around the types of negation they implement, primarily (monotonic) classical negation as opposed to some form of (non- monotonic) negation-as-failure. In the future, the Working Group expects to provide some dialects aligned with some of these branches.
4.2.2 Use Cases
The use cases [RIF Use Cases] and applications for RIF cover much of the space of distributed information systems. Wherever there is information processing, the option of using a rule system (instead of imperative programs) arises, and for some application areas
31 rule systems have become widely adopted. High-profile areas include credit scoring (Fair Isaac, the company behind FICO credit scores, is a major rule system vendor and a founding participant in the RIF Working Group), regulatory compliance in banking, and health care delivery. To date, most major rule systems have been closed-architecture, single-provider systems. With RIF, we begin to see the possibility of rules being developed on one system and then easily moved to another, allowing customers to avoid vendor lock-in, developing a stronger market, and encouraging more investment in long-term rule bases. Rule interoperability enables many more applications, though, when distributed systems can exchange rules. For example, vendors can publish complex, dynamic pricing structures (as rules), and then customers can (computationally) determine the most efficient purchases to initiate. Complex negotiations, with ensuing efficiencies become possible all along the supply chain, as trading partners are able to selectively expose their business logic (their rule bases) and search for synergies. In the life sciences, rule interchange can be pivotal in both research and health care delivery. In research, data integration is an enormous problem because of the vast variety of medical research; effectively mining that data, to find the relevant bits of a particular task, is essential. Rule systems (and related Semantic Web technologies, like the OWL Web Ontology Language) can greatly ease the integration effort. On the clinical side, rule systems can help physicians make diagnoses and orchestrate treatments (including detecting likely errors). Since many of these benefits increase with the scale of the market for rules (more users of rulebases, more providers of rulebases), a common interchange format should significantly improve the end benefits for research and to patients. 4.3 P3P
The Platform for Privacy Preferences Project [P3P] enables Web sites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by user agents. P3P user agents will allow users to be informed of site practices (in both machine- and human-readable formats) and to automate decision-making based on these practices when appropriate. Thus users need not read the privacy policies at every site they visit.
Although P3P provides a technical mechanism for ensuring that users can be informed about privacy policies before they release personal information, it does not provide a technical mechanism for making sure sites act according to their policies. Products implementing this P3P may provide some assistance in that regard, but that was left to specific implementations. However, P3P provides the basis for tools capable of alerting and advising the user. Wherever notices are required in laws or self-regulatory programmes, P3P can provide a very user- friendly way to provide them. In addition, P3P does not include mechanisms for transferring data or for securing personal data in transit or storage, but it can be used by tools that decide on data flow.
P3P has 3 components:
• a protocol: The P3P protocol allows user agents to discover privacy metadata about a given Web site. This is done either via a well-known location, a HTTP header, or a link-tag inside the
- element of an HTML page. • a vocabulary: The P3P vocabulary allows to express data handling practices like identification of the party making the statement, retention period, secondary uses, disclosure to third parties, dispute resolution mechanisms and more. • a data schema language: The base data schema is an internationalised schema to express personal data. It is used to express the object of the statement element. This32 allows to have a level of detail that can go down to one policy per data item, e.g. to treat the given name different than the family name.
4.3.1 Status
The P3P 1.0 Specification [P3P 1.0 Spec] became a W3C Recommendation on 16 April 2002 after 5 years of intense development with numerous obstacles. The initial idea of a wallet service and a negotiation protocol [Removing Data Transfer from P3P] proved to be too ambitious and P3P was toned down to a pure policy language able to express data collection and usage services in a machine readable syntax.
The first rather rudimentary implementation was Microsoft's Internet Explorer 6.0. It only analysed the HTTP headers that contained tokens called Compact Policy [Compact Policy] in the P3P Specification. Based on the privacy practices expressed in the tokens, cookies were blocked or allowed. Many Web sites reacted quickly and installed P3P Policies. Privacy Bird [Privacy Bird] is a plug-in that uses P3P Policies to match against preferences and has a good reporting tool. Whenever there is a mismatch, the bird turns into angry red and the policy report shows exactly where the mismatch between the user's preferences and the site's policy is. The most complete tool implemented was the P3P Implementation [JRC P3P Resource Centre] of JRC [JRC]. This is a Java based proxy implementation, but development has stopped.
After experiences with P3P, feedback triggered two further Workshops: One on incremental improvements [Future of P3P Workshop 2002] and another on the long term vision [Future of P3P Workshop 2003]. The first workshop triggered further work on P3P 1.1 [P3P 1.1 Spec] that added user agent guidelines and improved the protocol allowing sites to identify related sites. P3P 1.0 did not say anything about the user agent. After testing, it appeared that people wanted to have a standard answer to a standard situation. The user agent guidelines reflected this. Even today, the challenge of an efficient privacy dashboard is still open, let alone the integration into the Web browsers.
But in the aftermath of 9/11 governments started massively to increase data collection. The privacy debate shifted back where it came from, notably privacy as a right against the government. This debate took near to all interest away from privacy in private services and development slowed down. P3P 1.1 [P3P 1.1 Spec] was published as a Working Group Note.
4.3.2 Conclusion
P3P work remains very important for PrimeLife as it was the first attempt to express data handling in a structured machine readable way. It shows the way forward and resulted not only in a lot of Web site implementations, but also in a flood of research publications that tried to further the approach taken by P3P. Despite the fact that it was not addressed in the P3P Specification, the use of policies for data governance was always one aspect of the work and IBM realised this approach with the Tivoli Privacy manager handling data in the backend using a P3P engine. Today, the level of P3P implementations on Web servers remains high.
PrimeLife can take advantage of the existing large scale implementation of P3P on Web sites to acquire metadata and draw conclusions. Many of the P3P challenges are still unresolved and can be further advanced by the research done in PrimeLife.
33 4.4 APPEL
APPEL [APPEL] specifies a language for describing collections of preferences regarding P3P policies between P3P agents. Using this language, a user can express preferences in a set of preference-rules (called a ruleset), which can then be used by the user agent to make automated or semi-automated decisions regarding the acceptability of machine-readable privacy policies from P3P enabled Web sites.
At some point in time, the P3P Specification Working Group thought that a common interchange language for specifying user preferences which is understood by all P3P implementations is a condition for user acceptance and adoption of this technology. Several other efforts have addressed a similar problem for other communities, PICS Rules, and Profiles 0.94 for example. An interchangeable format for preference rules would allow data protection professionals to disseminate minimum guidelines and default privacy protection levels to users who have neither the time nor the knowledge to create it themselves.
4.4.1 Shortcomings
In matching P3P policies, there is a huge range of options, which an agent can try to look for. APPEL gives a suggested specification for a matching algorithm and interchangeable XML rule format, which is in fact the only existing interoperable format for preference files. However, to implement a user interface to the full range of possibilities within APPEL results in an extremely complex interface. Only one utility was ever built, designed as part of the JRC P3P project [JRC P3P Resource Centre] tried to come up with an interface. This interface proved to be even too complex for experts.
Additionally, APPEL had some unpredictable behaviour as a P3P policy could be written in two different ways but having the same meaning and the APPEL rule would lead to the same unexpected results. This was due to the fact that APPEL was the first trial to construct a rule language based on RDF technologies. There were suggestions to improve the user interface by a move of P3P to a formalised ontology, but this was not taken up by the P3P Specification Working Group due to a lack of support from the community and the implementers. As an endpoint APPEL was published as a Working Group Note on 15 April 2002. It is used in most P3P implementations (e.g. PrivacyBird [Privacy Bird]) as an import format and subsequently translated into the internal format of the application.
The world moved on. There was a lot of interest in APPEL and rules in general as part of the Semantic Web [Semantic Web] technology. The engineers realised that they needed a new clean approach that is not tight to privacy only. After long scientific discussions, W3C chartered the Rule Interchange Format (RIF) Working Group [RIF] that is still running. A privacy ontology was developed by the PRIME Project [PRIME]. RIF is only a framework for rulesets. There is the option for PrimeLife to combine the privacy ontology developed by PRIME with the framework set by RIF in order to develop a new RIF-compliant rule language. The PRIME obligation language is an obvious candidate to learn more and to refine the approach to rules.
4.4.2 Conclusion
APPEL is a very important historical step towards rule languages and was slightly premature. APPEL helps to understand the very fundamental issues concerning semantics and syntax raised by a privacy preference language. But it is of no use to take up APPEL as is as there
34 are new languages and technologies out there to be used to have a much cleaner approach to privacy rules. 4.5 Enterprise Privacy Authorisation Language (EPAL)
Enterprise Privacy Authorisation Language [EPAL] is a framework for managing collected personal data that aims at enabling enterprises to formalise and enforce privacy practices.
Privacy practice prescriptions are embodied in the form of a policy.
4.5.1 Structure of an EPAL policy
An EPAL policy is given in the form of a XML data structure and includes three main sections.
• The Policy Information identifies the policy providing information about the Issuer, the Version Number, the Start Date, the End Date, the Replacement Policy Name, the Replacement Policy Version. • A Vocabulary Reference provides a pointer in the form of an URI to an EPAL vocabulary that describes all the components that can be used in the rules in the following section. These components deal with the entities typically involved in a transaction: Data Users, Data Categories, Actions, Purposes, Conditions, Obligations, Context Models. • The Ruling Set includes the rules that define whether a Data User is allowed or denied to perform an Action on a Data Category for a certain Purpose under specific Conditions. The rules are ordered with descending precedence, that is, if a rule applies (i.e. allows or denies a request), subsequent rules are ignored. To be applicable to a request, a rule must include the same elements (such as Data Users, Actions...) as in the request and all of its Conditions must be met.
Every EPAL policy is characterised by an optional Global Condition and by a mandatory Default Ruling. The Default Ruling ("allow", "deny, or "not-applicable") is returned as a result of the policy evaluation if the Global Condition is false or no rule within the policy is applicable.
4.5.2 An EPAL policy example
A simplified example of an EPAL policy follows:
35
The policy above allows to collect children's data and store it provided parent consent has been given. All elements whose definition is not provided in this epal-policy element are defined in vocabularies to which references are provided in the policy itself.
4.5.3 An EPAL query example
A typical EPAL authorisation query looks like follows. This is an example to which the policy above applies.
36
The refid attribute of the Container element refers to the container of the policy that is instantiated for the authorisation evaluation. Moreover, it contains one or more attribute elements with the actual attribute values to be used to evaluate the relevant conditions. Some policies with an Obligation element, may also state that when a certain access is allowed, some specific additional steps must be taken by the requestor.
4.5.4 A typical EPAL scenario
In a typical EPAL scenario, a customer of the enterprise views the privacy policy statement (specified e.g. with P3P (see chapter 4)), accepts it and sends in personal identifiable information data. The consent and the relevant policy are logged, and the privacy management enforcement monitors ensure that only data accesses by the enterprise's employees are allowed that conform to the privacy policy.
4.5.5 Relations to other standards and to the PrimeLife project
As illustrated above, EPAL provides the possibility of an integration with the P3P standard, which can be used to receive privacy policy preferences from end users that are then stored and enforced in an enterprise's IT system relying on EPAL. However, this approach should not be taken as paradigmatic, in that the EPAL policy language has a greater expressivity, so that if there were only a P3P-based end user interface, EPAL would not be exploited at full.
An important contribution from this proposal is the focus on the issue of enforcement, through the PEP abstraction. This is a significant step on a critical path that also PrimeLife must deal with.
4.5.6 Status of the EPAL proposal
EPAL was submitted to W3C in 2003 for consideration as a privacy policy language standard. 4.6 CARML
CARML (Client Attribute Requirements Markup Language) is a specification language that aims at defining application identity requirements, that is, what identity information an application needs and how the application will use it.
A CARML document is an XML document that enables applications working on identity- related data to declare their data requirements and intended usage of personally identifiable information.
The CARML specification provides a standard way for a client application to request for data from a service provider, but it does not guarantee that the client application will receive what is requested.
37 It is assumed that applications only require a fixed set of interactions dealing with identity data, as follows:
• information about a user is looked up by means of one or more indexes, which typically consists of a subject name derived by an authentication process, or an attribute (e.g. social security number) • some tests are performed to check whether a subject has a property (with unknown value), or a property with a value that will be known at runtime, or a property with a fixed value • the values for a sequence of named properties are retrieved • some attributes in the form of name/value pairs associated with a subject can be modified.
CARML allows for the definition of a localised data dictionary for applications, but it is mostly expected that developer tools using CARML would promote the usage of schemata and dictionaries already specified by an enterprise.
4.6.1 Elements of the CARML language
CARML relies on the SAML syntax as described in SAML V2.0 [Semantic Web] for several of its elements.
For subject indexes, a SubjectIndexes element is introduced, including one IndexNameIdentifier element or one or more IndexAttribute elements. In the following example, the client declares that a pair of values (e-mail address and Country) will be used as indexes, the client will provide an e-mail address and the service provider is to assume that a static attribute of Country="US" is to be used:
When an application needs to send boolean questions to a service provider, those questions are specified in the form of Property elements. Property elements may include a description that aids the identity service managers in defining the appropriate values. The following example includes a sequence of properties: the first asks the question whether the user has property AboveEighteen, the second states that an EmploymentLevel will be provided at runtime and the third that the application wishes to check whether the user has a Department property and whether it is set to value Information Technology.
38
Finally, CARML defines an Attribute element that lists the attributes (specified on the basis of the SAML attribute schema) the client application is requesting to be returned with the subject by the service provider, like in the following example:
For each attribute-related request, the reply may include no values, one or more values, or an exception indicating unauthorised requests or filtering due to policy conditions. Attribute declarations can include a Modifiable permission flag to enable users to modify the relevant values, as in the following example, in which Language is modifiable, while Country is read- only:
SubjectIndexes, Property, and Attribute elements are included in a NamedInteraction element. An IRData element contains one or more NamedInteraction elements.
4.6.2 Status of the CARML proposal
The latest working draft on CARML was published in 2006.
4.6.3 AAPML
AAPML (Attribute Authority Policy Markup Language) is an XACML (see chapter 3) profile which aims at enabling owners of identity-related data to specify in the form of policies the conditions under which information in their control may be used by other applications. 4.7 Identity Governance Framework
The Identity Governance Framework [IGF] is an open initiative which aims at tackling the issues related to the management of identity related information across enterprise IT systems. This initiative includes proposals of specifications for a common framework to define usage policies (AAPML Specification [AAPML Spec]), attribute requirements (CARML Specification [CARML Spec]), and the relevant developer APIs. These proposals are meant to enable businesses to guarantee documentation, control, and auditing with respect to acquirement, use, storage, and propagation of identity-related data through applications and systems.
39 Oracle announced the initiative together with the founding participants (Computer Associates, Layer 7 Technologies, HP, Novell, Ping Identity, Securent, Sun Microsystems) in November 2006. The initiative was submitted royalty-free in February 2007 to the Liberty Alliance consortium, which aims at building a more trusted Internet by addressing the technology, business and privacy aspects of digital identity management and whose Management Board includes representatives from AOL, Ericsson, Fidelity Investments, France Telecom, HP, Intel, Novell, NTT, Oracle, and Sun Microsystems. 4.8 PRIME Policy Languages
The PRIME project is a large-scale research effort aimed at developing an identity management system able to protect user personal information and to provide a framework that can be smoothly integrated with current architectures and online services. In this context an important service for helping users to keep control over their personal information is represented by access control solutions enriched with the ability to support privacy requirements. To fully address the requirements posed by a privacy-aware access control system, the following different types of privacy policies have been defined in the context of PRIME.
• Access control policies. They govern access/release of data/services managed by the party (as in traditional access control). Access control policies define authorisation rules concerning access to data/services. Authorisations correspond to traditional (positive) rules usually enforced in access control systems. An access control rule is an expression of the form:
A prototype providing functionalities for integrating access control, release and data handling policies evaluation and enforcement has been developed in the context of the PRIME project.
4.8.1 Rough use cases
The reference scenario is a distributed infrastructure that includes three parties: i) users are human entities that request online services; ii) service provider is the entity that provides
40 online services to users and collects personal information before granting an access to its services; iii) external parties are entities (e.g., business partners) to which the service provider may want to share or trade personal information of users. The functionalities offered by a service provider are defined by a set of objects/services. This scenario considers a user that needs to access a service. The user can be registered and characterised by a unique user identifier (user id, for short) or, when registration is not mandatory, characterised by a persistent user identifier (pseudonym). Three major use cases are listed in the following.
• E-commerce. A major factor in the evolution of the Web has been the widespread diffusion of e-commerce, that is, the ability to purchase, sell, and distribute goods and services to customers. A primary concern in the development of e-commerce has been to provide a secure global infrastructure through solutions for secure data exchange and systems for protecting e-services from unauthorised accesses. However, in the last years, the focus is shifted from the protection of server-side resources to the protection of user privacy. If users do not have confidence that their private data are managed in a privacy-oriented way by the server, they will refuse participation in e-commerce. In this scenario, it is mandatory to provide users with the possibility of protecting their privacy and their sensitive data, still accessing the online services. • Online healthcare system. Healthcare systems support interactions among patients, medical and emergency personnel, insurance companies, and pharmacies. These systems allow for anonymous access to general information and advice, and enforce access control to individual patient records according to general rules, context (e.g., treatment, emergency), and the patient’s specific choices (e.g., primary care physician, health insurance). In this context, it is important to ensure to the patients enhanced privacy functionalities to define restrictions regulating access and management of their data. • Location-Based Service (LBS). Technical improvements of location technologies permit to gather location information with high accuracy and reliability. Physical location of individuals is then rapidly becoming easily available as a class of personal information that can be processed for providing a new wave of online and mobile services, such as location-based access control (LBAC) services. In addition to LBAC services, many mobile network providers offer a variety of location-based services such as point of interests proximity, friend-finder, or location information transfer in case of an accident (e.g., 112 european emergency number). Such services naturally raise privacy concerns. Users consider their physical location and movements as highly privacy sensitive, and demand for solutions able to protect such an information in a variety of environments.
4.8.2 Distinctive features of PRIME languages
Access Control/Release Model and Language
• XML-based syntax. The language provides an XML-based syntax for the definition of powerful and interoperable access control and release policies. • Attribute-based restrictions. The language supports the definition of powerful and expressive policies based on properties (attributes) associated with subjects and objects. • Credential definition and integration. The language supports requests for certified data, issued and signed by authorities trusted for making the statement, and uncertified data, signed by the owner itself.
41 • Anonymous credentials support. The language supports definition of conditions that can be satisfied by means of zero-knowledge proof. • Support for context-based conditions and metadata. The language allows the definition of conditions based on physical position of the users and context information, and integration with metadata identifying and possibly describing entities of interest. • Ontology integration. Policy definition is fully integrated with subject and object ontology in defining access control restrictions. Also, the language takes advantages from the integration with credentials ontology that represents relationships among attributes and credentials. • Interchangeable policy format. Parties need to specify protection requirements on the data they make available using a format both human- and machine-readable, easy to inspect and interchange. • Interactive enforcement. Rather than providing a simple yes or no decision, policy evaluation provides a way of interactively applying criteria to retrieve the correct sensitive information, possibly managing complex user interactions such as the acceptance of written agreements and/or online payment. • Variables support. Currently, access control/release language supports two placeholders, one for the subject and one for the object. This solution represents a good trade-off between expressivity and simplicity but can be easily extended to support variables definition.
Data Handling Model and Language
• Attribute-based restrictions and XML-based syntax. As for access control/release language, data handling language supports the definition of powerful and expressive XML-based policies based on properties associated with subjects and objects. • Customised policies. Data handling policies are defined through a negotiation between the user and the service provider. When a user requires a service, predefined policy templates are provided by the service provider as a starting point for creating data handling policies. The templates are then customised to meet different privacy requirements. A user can directly customise the templates or it can be supported by a customisation process that automatically applies some user privacy preferences. If the customised data handling policies will be accepted by the service provider, the personal information provided by the user will be labeled with the customised data handling policies. This represents the most flexible and balanced strategy for the definition of data handling policies. • Stand-alone policies. Data handling policies are defined as independent rules. Personal data are then tagged with such data handling policies, which physically follows the data when they are released to an external party, thus building a chain of control coming from the data owner.
4.8.3 Relation to standards
XACML v2.0
XACML version 2.0 was ratified by OASIS standards organisation on 1 February 2005. Similarly to PRIME languages, XACML proposes a XML-based language allowing the specification of attribute-based restrictions. Main differences with PRIME languages are as follows.
• XACML does not explicitly support privacy features.
42 • Although XACML supports digital credentials exchange, it does not provide request for certified credentials. • XACML does not support and integrate location-based conditions and ontologies.
P3P/APPEL
P3P allows Web sites to declare their privacy practices in a standard and machine-readable XML format. Designed to address the need of users to assess that the privacy practices adopted by a server provider comply with their privacy requirements, P3P has been developed by the World Wide Web Consortium (W3C). Users specify their privacy preferences through a policy language, called A P3P Preference Exchange Language (APPEL), and enforce privacy protection by means of an agent. Similarly to PRIME languages, P3P proposes a XML-based language for regulating secondary use of data disclosed for the purpose of access control enforcement. It provides restrictions on the recipients, on the data retention and on purposes. Main differences with PRIME languages are as follows.
• P3P does not support privacy practices negotiation. In fact, users can only accept the server privacy practices or stop the transaction. The opt-in/opt-out mechanisms result in limitations. • P3P does not support definition of policies based on attributes of the recipients. • P3P does not provide protection against chains of releases (i.e., releases to third parties). 4.9 WS-Policy
WS-Policy defines a framework for expressing the capabilities and the requirements of entities in the form of policies in XML-based Web service systems.
A policy is defined as a collection of one or more policy assertions. These policy assertions may deal with lower-level communication properties, like which transport protocol is to be used, whether an authentication scheme should be maintained, as well as higher-level service characteristics, such as a privacy policy or Quality of Service (QoS). The semantics of individual assertions (ranging from simple strings to complex combinations of items with attributes) is domain-dependent and lies beyond the scope of the WS-Policy framework, which treats them as opaque. WS-Policy aims at providing constructs to indicate how a policy assertion or a set of assertions apply in a Web services environment.
4.9.1 Structure of a policy
A policy is built from individual assertions grouped by policy operators, which are specific XML tags with a wsp prefix referring to the namespace http://www.w3.org/ns/ws- policy of the WS-Policy specification [WS-Policy 1.5]. Two operators in the form of XML tags are used to make statements about policy combinations: wsp:ExactlyOne asserts that only one child node must be satisfied; wsp:All asserts that all child nodes must be satisfied.
Here is an example of a policy:
43
The sp prefix corresponds to the namespace relevant to the domain in which the assertions are defined (i.e.: WS-SecurityPolicy). As different assertions are inserted in an ExactlyOne operator, here we have different alternatives. A Web service invocation must then use one of the asserted algorithm suites to comply with, or support the policy above. More generally, a policy assertion made by a service provider is supported by a service requester when the requester satisfies the requirement expressed by the assertion; a policy alternative is supported by a requester when all the assertions in the alternative are supported; finally, a policy is supported when the requester supports at least one of the alternatives in the policy.
The flexible syntax might lead to the formulation of rather complex policies.
4.9.2 Normal form of a policy
A normal form is defined to simplify the manipulation and clarify the understanding of policies. The structure of a normal form reflects the steps the basic policy processing operation is comprised of: all the alternatives are enumerated within a wsp:ExactlyOne operator, and each alternative enumerates in turn all the assertions in a wsp:All operator.
The policy above in a normal form would then be as follows:
4.9.3 Compact form of a policy
As policies in a normal form can be very verbose, constructs are provided to express them in a compact form. If required by the policy processing software, the normal form can always be obtained by means of a recursive procedure which is illustrated in the WS-Policy specification.
Compact expression of policies may be achieved in different ways, such as optional assertions, policy assertion nestings, policy operator nestings, and policy inclusions.
The WS-Policy specification provides an optional attribute to indicate that a policy assertion is optional. This is semantically equivalent to express two policy alternatives with and without the assertion, respectively, so that
44
Setting the value of this attribute to false is equivalent to omitting the attribute and thus having a mandatory assertion.
4.9.4 Nested policies
The WS-Policy syntax allows for an assertion to include a nested policy expression, as in the following schema:
Policy assertions with nested policy expressions are normalised recursively.
Policies can be compactly expressed also by nesting operators wsp:Policy, wsp:All, and wsp:ExactlyOne within one another. Inference rules exploiting these operators' properties (e.g.: commutativity, associativity, idempotency, and distributivity) allow for the transformation of compact expressions into normal form.
For instance, wsp:All distributes over wsp:ExactlyOne, so that
4.9.5 References to other policies
The WS-Policy allows for sharing of assertions across different policy expressions, by means of the wsp:PolicyReference element. This element comes with an URI attribute that provides a reference to a policy expression. For policy expressions within the same XML document, the reference should point toward an expression identified by an ID, while for external policy expressions there is no requirement that the reference be resolvable, as retrieval mechanisms are external to the WS-Policy specification. When a wsp:PolicyReference element refers to a wsp:Policy element, it prescribes to replace the wsp:PolicyReference element with a wsp:All element whose children are the same as the children of the referenced policy. In other words,
45 when processed, a reference element is substituted by the referenced policy, wrapped in a wsp:All element. Here follows an example with a reference within a document.
The specification prescribes that a policy must not refer to itself either directly or indirectly be means of a wsp:PolicyReference element.
4.9.6 Intersection of policies
Generally, and more specifically also in the context of Web services, interactions can take place only when all involved parties agree on at least one policy alternative.
The WS-Policy specification allows for an intersection process that compares two policies looking for common, or mutually compatible, alternatives. As the semantics of the compared assertions lies beyond the scope of the domain-neutral WS-Policy framework, domain knowledge is clearly required to complete the intersection process.
Thus, in this specification only an algorithm is provided that approximates compatibility in a domain-independent fashion. The two policies are first normalised.
In a first comparison phase, each alternative from the first policy is compared to all alternatives from the second policy vocabulary-wise: to be compatible, two alternatives must at least share the same vocabulary, that is, they must include assertions of the same type. Two alternatives with different vocabularies are considered incompatible and discarded in this phase.
The intersection of two compatible alternatives is an alternative which contains all the assertions from both intersected alternatives. If policy A contains an alternative which is compatible with an alternative from policy B, then the two policies are compatible, and their intersection is built as the set of the intersection between all pairs of compatible alternatives (by choosing one alternative from each policy, of course).
In the following example, policy P1 and policy P2 present only one pair of compatible alternatives (alternative A2 from P1 and alternative A3 from P2), whose assertions constitute the intersected policy:
Policy P1:
46
Policy P2:
Intersection of policies P1 and P2:
The interpretation of the combined alternatives is beyond the scope of this specification, as it strongly depends on the assertions' semantics. The rationalisation of the new, intersected alternatives into something meaningful to the infrastructure requires domain knowledge. The
47 new policy might require further processing that might show that an alternative is contradictory, and thus not meaningful to the underlying infrastructure that is responsible for performing the required behaviours. In such a case the invocation of the intersection function fails.
4.9.7 Relations to other proposals and to the PrimeLife project
WS-Policy provides a framework for expressing alternative sets of policy assertions from various domains, such as security, and reliable messaging, that are supported by a service. Still, there are no WS-Policy assertions defined for authorization, access control, or privacy policies. WS-XACML (see chapter 4) is a proposal aiming at fulfilling this need.
WS-Policy offers an example of abstraction that separates the domain-dependent assertions from the domain-independent framework of policy management which should work as a significant guideline for PrimeLife research.
4.9.8 Status of the WS-Policy proposal
WS-Policy became a W3C Recommendation in September 2007, standardized by the W3C Web Services Policy Working Group [WS-Policy WG]. The WS Policy Primer [WS-Policy Primer] is available as a companion document. 4.10 OASIS WS-XACML
WS-XACML [WS-XACML Spec] is a Web service profile that defines a standard way to use XACML for authorisation, access control, and privacy policy in a Web Services environment. The document is currently an OASIS working draft.
The profile describes how client and service can match mutually their requirements and capabilities. WS-XACML defines a new XACML assertion to express them. Requirements are expectations that each side has of the communication peer. Capabilities define what each side can fulfil. Hence, we have four sets of assertions: capabilities and requirements both for client side and the service side. WS-XACML offers a basic matching algorithm to match these four sets of policy. It mutually matches the requirements of the client side with the capabilities of the services and vice versa the requirements of the service with the capabilities of the client. The standard gives some very interesting examples which fit well with planned work in PrimeLife. The service could require a particular authorisation attribute; the client can avoid trying to invoke the service if it does not possess this attribute. An extension of this example is that the service accepts only attribute claims which are signed by a trusted third party. The service could demand that the client is acting in a particular role; the service knows this in advance and can initiate the role switch before invoking the service. Of course also the client could impose obligations on the service. The standard mentions an example policy that demands that the service does not share private information which a client has to submit when invoking this service. Given that a client can choose between various instances of a particular service, it now can decide which one is willing to fulfil the requirements best. In a more flexible scenario one service could offer various resources coming with different privacy policies. Although WS-XACML does not offer a pattern to negotiate between client and service, it is easily imaginable to build such a negotiation on top of WS-XACML. WS- XACML is particularly useful in the scope of P3P privacy policies. It allows expressing P3P policy preferences and matching them using the new assertion for requirements and capabilities.
48 In summary, WS-XACML addresses an important practical issue of XACML. XACML itself defines just the assertions and how to combine them. The WS-XACML draft standard offers a profile how to use, compare and match them on both sides of a service interaction. However, currently we see four shortcomings of WS-XACML: it is not yet an official standard, it lacks a negotiation protocol to balance requirements and capabilities, the matching algorithms are very basic, and to the best of our knowledge there is not a single implementation available. 4.11 Security Policy Assertion Language (SecPAL)
SecPAL (Becker et al., 2006 [Becker et al.]) is a declarative security policy language developed to meet the access control requirements of large-scale Grid Computing Environments. It is a declarative, logic-based, language that builds on a large body of work showing the value of such languages for flexibly expressing security policies. It was designed to be comprehensive and provides a uniform mechanism for expressing trust relationships, authorisation policies, delegation policies, identity and attribute assertions, capability assertions, revocations, and audit requirements. This provides tangible benefits by making the system understandable and analysable. It also improves security assurance by avoiding, or at least severely curtailing, the need for semantic translation and reconciliation between disparate security technologies.
49 Chapter 5 Authentication Infrastructure
5.1 The ITU-T X.509 Standard
X.509, also known as ISO/IEC 9594, is an ITU-T that represents the normative standard for Public Key Infrastructure (PKI). It addresses some of the security requirements in the areas of authentication and other security services through the provision of a set of frameworks upon which full services can be based.
Specifically, this standard defines frameworks for:
• Public-key certificates • Attribute certificates • Authentication services
The public-key certificate framework defined in this standard includes a definition of the information objects for Public Key Infrastructure (PKI) and Certificate Revocation List (CRL).
The attribute certificate framework defines the information objects for Privilege Management Infrastructure (PMI) and Attribute Certificate Revocation List (ACRL). This specification provides, for instance, the framework for issuing, managing, using and revoking certificates; an extensibility mechanism that defines formats for both certificate types and for all revocation list schemes; a set of standard extensions which is expected to be generally useful across a number of applications of PKI and PMI, and, schema components such as object classes, attribute types and matching rules for storing PKI and PMI objects in the directory. Beyond these frameworks other elements of PKI and PMI are expected to be defined by other standards bodies (e.g. ISO TC 68, IETF), such as key and certificate management protocols, operational protocols, additional certificate and CRL extensions.
The authentication scheme defined in this standard is generic and may be applied to a variety of applications and environments. The directory makes use of public-key and attribute certificates, and the framework for using these facilities is also defined in the standard. Public-key technology, including certificates, is used by the directory to enable strong
50 authentication, signed and/or encrypted operations, and for storage of signed and/or encrypted data in the directory. Attribute certificates can be used by the directory to enable rule-based access control. Although the framework for these is provided in this specification, the full definition of the directory's use of these frameworks, and the associated services provided by the directory and its components is supplied in the complete set of directory specifications.
This standard, in the authentication services framework, also:
• specifies the form of authentication information held by the directory; • describes how authentication information may be obtained from the directory; • states the assumptions made about how authentication information is formed and placed in the directory; • defines three ways in which applications may use this authentication information to perform authentication and describes how other security services may be supported by authentication.
It describes two levels of authentication: simple authentication, using a password as a verification of claimed identity; and strong authentication, involving credentials formed using cryptographic techniques. While simple authentication offers some limited protection against unauthorised access, only strong authentication should be used as the basis for providing secure services. It is not intended to establish this as a general framework for authentication, but it can be of general use for applications which consider these techniques adequate.
5.1.1 X.509 Certificate and Certification Process
X.509 is part of the hierarchical X.500 standard and thus assumes a strict hierarchical system of certificate authorities (CAs) for issuing the certificates. This is in contrast to Web of trust models, like PGP, where anyone (not just special CAs) may sign (and thus attest to the validity) of others' key certificates. X.500 standard defines how global directories should be structured. Directories are a way to organise a database, a sort of evolution of a phone book. X.500 directories are hierarchical with different levels for each category of information, such as country, state, and city.
The X.500 standard was intended to give a worldwide unique identifier structure. The X.500 system has never been fully implemented, so the IETF's public-key infrastructure Working Group has made extensive updates to the standard in order to make it work with the more loose organisation of the Internet. In the X.509 system, a CA issues a certificate binding a public key to a particular name. This name is the Distinguished Name defined by X.500. Depending on the issuing authority, the binding can be between a public key and an e-mail address or a DNS-entry.
Root certificates can be issued to all employees by an organisation so that all employees can use the company PKI system. Browsers such as Microsoft Internet Explorer, Netscape/ Mozilla and Opera come with root certificates pre-installed, so SSL certificates from larger vendors who have paid for the privilege of being pre-installed will work instantly; in essence the browser's programmers determine which CAs are trusted third parties. Whilst their root certificates can be disabled, users rarely do it.
X.509 also includes standards for Certificate Revocation List implementations, an often overlooked necessity in PKI systems. The X.509 standard defines what information can go into a certificate, and describes how to write it down (the data format).
51 All X.509 (up to version 3) certificates have the following data, in addition to the signature:
Version This identifies which version of the X.509 standard applies to this certificate, which affects what information can be specified in it. Thus far, three versions are defined.
Serial Number The entity that created the certificate is responsible for assigning it a serial number to distinguish it from other certificates it issues. This information is used in numerous ways, for example when a certificate is revoked its serial number is placed in a Certificate Revocation List (CRL).
Signature Algorithm Identifier This identifies the algorithm used by the CA to sign the certificate.
Issuer Name The X.500 name of the entity that signed the certificate. This is normally a CA. Using this certificate implies trusting the entity that signed this certificate. (Note that in some cases, such as root or top-level CA certificates, the issuer signs its own certificate.)
Validity Period Each certificate is valid only for a limited amount of time. This period is described by a start date and time and an end date and time, and can be as short as a few seconds or almost as long as a century. The validity period chosen depends on a number of factors, such as the strength of the private key used to sign the certificate or the amount one is willing to pay for a certificate. This is the expected period that entities can rely on the public value, if the associated private key has not been compromised.
Subject Name The name of the entity whose public key the certificate identifies. This name uses the X.500 standard, so it is intended to be unique across the Internet. This is the Distinguished Name (DN) of the entity, for example, CN=Joe Bloggs, OU= Research, O=SAP, C=France. These refer to the subject's Common Name, Organisational Unit, Organisation, and Country.
Subject Public Key Information This is the public key of the entity being named, together with an algorithm identifier which specifies which public key crypto system this key belongs to and any associated key parameters.
5.1.2 Evolution of the X509 standard
X.509 Version 1 It has been available since 1988, is widely deployed, and is the most generic.
X.509 Version 2 The second version introduced the concept of subject and issuer unique identifiers to handle the possibility of reuse of subject and/or issuer names over time. Most certificate profile documents strongly recommend that names not be reused, and that certificates should not make use of unique identifiers. Version 2 certificates are not widely used.
X.509 Version 3 The most recent version (1996) supports the notion of extensions, whereby anyone can define an extension and include it in the certificate. Some common extensions in use today are: KeyUsage (limits the use of the keys to particular purposes such as "signing- only") and AlternativeNames (allows other identities to also be associated with this public key, e.g. DNS names, e-mail addresses, IP addresses). Extensions can be marked critical to indicate that the extension should be checked and enforced/used. For example, if a certificate has the KeyUsage extension marked critical and set to "keyCertSign" then if this certificate is presented during SSL communication, it should be rejected, as the certificate extension
52 indicates that the associated private key should only be used for signing certificates and not for SSL use.
All the data in a certificate is encoded using two related standards called ASN.1/DER. Abstract Syntax Notation 1 describes data. The Definite Encoding Rules describe a single way to store and transfer that data. People have been known to describe this combination simultaneously as "powerful and flexible" and as "cryptic and awkward". The IETF PKIX Working Group is in the process of defining standards for the Internet Public Key Infrastructure. 5.2 PKIX
The PKIX is a Working Group established in the autumn of 1995 with the intent of developing Internet standards needed to support an X.509-based PKI. The scope of PKIX work has expanded beyond this initial goal. PKIX not only profiles ITU PKI standards, but also develops new standards apropos to the use of X.509-based PKIs in the Internet. PKIX has produced several informational and standards track documents in support of the original and revised scope of the WG.
The first of these standards, RFC 2459, profiled X.509 version 3 certificates and version 2 CRLs for use in the Internet. Profiles for the use of Attribute Certificates (RFC 3281), LDAP v2 for certificate and CRL storage (RFC 2587), the Internet X.509 Public Key Infrastructure Qualified Certificates Profile (RFC 3039/3739), and the Internet X.509 Public Key Infrastructure Certificate Policy and certification Practices Framework (RFC 2527/3647 - Informational) are in line with the initial scope.
The Certificate Management Protocol (CMP) (RFC 2510), the Online Certificate Status Protocol (OCSP) (RFC 2560), Certificate Management Request Format (CRMF) (RFC 2511), Time-Stamp Protocol (RFC 3161), Certificate Management Messages over CMS (RFC 2797), Internet X.509 Public Key Infrastructure Time Stamp Protocols (RFC 3161), and the use of FTP and HTTP for transport of PKI operations (RFC 2585) are representative of the expanded scope of PKIX, as these are new protocols developed in the Working Group, not profiles of ITU PKI standards.
5.2.1 X.509 Attribute Certificate and Privilege Management Infrastructure
X.509v3 2000 recommendation includes an architecture for Privilege Management based on a form of Attribute Certificate. The attribute certificate framework defined here provides a foundation upon which Privilege Management Infrastructures (PMI) can be built. These infrastructures can support applications such as access control.
The binding of a privilege to an entity is provided by an authority through a digitally signed data structure called an attribute certificate or through a public-key certificate containing an extension defined explicitly for this purpose. The format of attribute certificates is defined here, including an extensibility mechanism and a set of specific certificate extensions.
Revocation of attribute certificates may or may not be needed. For example, in some environments, the attribute certificate validity periods may be very short (e.g. minutes), negating the need for a revocation scheme. If, for any reason, an authority revokes a
53 previously issued attribute certificate, users need to be able to learn that revocation has occurred so they do not use an untrustworthy certificate.
Revocation lists are one scheme that can be used to notify users of revocations. The format of revocation lists is also defined in this specification, including an extensibility mechanism and a set of revocation list extensions. Additional extensions are defined here. In both the certificate and revocation list case, other bodies may also define additional extensions that are useful to their specific environments.
A system using an attribute certificate needs to validate it prior to using that certificate for an application. Procedures for performing that validation are also defined here, including verifying the integrity of the certificate itself, its revocation status, and its validity with respect to the intended use.
This framework includes a number of optional elements that are appropriate only in some environments. Although the models are defined as complete, this framework can be used in environments where not all components of the defined models are used. For example there are environments where revocation of attribute certificates is not required. Privilege delegation and the use of roles are also aspects of this framework that are not universally applicable. However these are included in this specification so that those environments that do have requirements for them can also be supported. The directory uses attribute certificates to provide rule-based access control to Directory information.
5.2.2 Relationship to PrimeLife
As X.509v3 is traditionally used to structure public key certificates, it seems natural to offer X.509v3 versions of issuer keys, used in anonymous credential systems. These keys are needed for the user of an anonymous credential to check the validity of the private certificate, generated in interaction with the issuer. A party, relying on the result of a transaction with this user, will also need these issuer keys to check the correctness of the proof. The effort to represent issuer keys in X509v3 will be possible without massive impact on the X.509 standard, as it would only require to look for a way to represent non-standard key material in the structure. The signature in the X.509 certificate could be a classical one, for example, RSA. Handling X.509v3 certificates is implemented in all major browsers and operating systems but it remains to be investigated how these would react in an unknown key format.
Taking it one step further, leveraging existing X.509v3 handling implementations, it is also possible to represent the private certificate of the user in X.509v3 format. However, this would introduce additional complexity:
• the issuer verification key should be present in the certificate, so an unsupported key format is needed (same as above) • the process of generating the signature and the representation of the signature value in the X.509v3 certificate is regulated by CMS (Cryptographic Message Syntax, PKCS#7). Solving the problem of the signature value representation, and the signature algorithm identifier, might be possible, but it might be necessary to change the PKCS#7 processing rules to be able to produce a usable X.509v3 representation of a private certificate. Those changes would violate the standard, which would force us to write our own PKCS#7 software, or to massively change an existing open source implementation. In this case, standard PKCS#7 implementations wouldn't be able to parse our changed format, even if they would allow for plug-in implementations of new signature algorithms
54 • Building a private certificate is the result of an interaction between issuer and user, and therefore, the issuer is not generating the resulting X.509v3 certificate. Apart from the fact that this might seem odd for those used to X.500, it is necessary to investigate how certain data fields have to be completed (one of those examples is Subject DN)
A third opportunity is to represent the result of a credential show in CMS/PKCS#7 format or as a X.509v3 attribute certificate. In the CMS case, this would be done in a similar fashion as mentioned in "Assertion-Based Signatures" (XMLDSIG (see chapter 5)). Most of the problems originate from the fact that the signature algorithm employed does not have a classical structure. As the X.509v3 case is very similar with regards to limitations, it would require a way to represent the proved assertions in the X.509 attribute data model. 5.3 XML Signature
5.3.1 Specification Overview
The XML Signature specification [XML Sig] describes a format that can be used to encapsulate cryptographic signatures of arbitrary content in XML, and to sign XML documents, or subsets of such documents. The specification is designed to be highly extensible: Signed information can be subject to arbitrary transformations before signing. Algorithms - both cryptographic and otherwise - are identified by way of URIs and therefore exchangeable.
A typical signature consists of a SignedInfo element that describes the data that were signed, and the steps applied to it in order to generate the signature. Specifically, SignedInfo identifies the canonicalisation method that is applied to transform the element itself into an octet stream, the signature method, and any number of Reference elements. Each of these elements identifies a resource (or document subset), a chain of transformations, a digest method, and a digest value. To compute the final signature, SignedInfo is canonicalised, hashed and signed according to the given signature algorithm. Information about the signing key can be part of a KeyInfo element.
The processing model for XML Signature requires that each Reference element be dereferenced, transformed, and hashed. The validity of an XML Signature therefore implies that the referenced resource (as transformed) was unchanged.
To enable different models and broader semantics, XML Signature supports the Object element as an extensibility point which may, in particular, hold a Manifest which is by itself a collection of Reference elements. Processing for Reference elements within a Manifest differs from processing for those which are direct children of SignedInfo: They need not be dereferenced; the precise meaning of a signature that involves a Manifest will depend on the application context. (For example, a manifest might be used to hold digest values of multiple representations of the same resource; in this case, it might be enough for one of several digest values to match.)
To hold further signature semantics, the optional SignatureProperty element may occur within an Object element; this element is specifically designed to hold additional information about the creation of its target signature. It can, e.g., be used to hold information about time stamps or signature generation hardware.
55 5.3.2 Status
XML Signature is a broadly implemented specification, and used as a basic signing primitive for - among others - SAML and WS-Security. The XADES [XADES] specification for advanced electronic signatures profiles and extends XML Signature.
The original XML Signature specification was jointly developed by W3C and the IETF, and first released as a W3C Recommendation in 2002. At the time of writing of this document, W3C is reviewing a lightly changed version for publication as a Second Edition of the XML Signature Recommendation. Republication of this document within the IETF framework is expected.
The W3C Workshop on Next Steps for XML Signature and XML Encryption [XML Sig/Enc Workshop] in September 2007 led to a proposal for further work on XML Signature. This new work [XML Security] -- launched in May 2008 -- will focus on issues with the specification that have been identified as a result of six years of research and deployment experience, in particular peculiarities of its referencing and transform model, choice of mandatory cryptographic algorithms, and the performance impact of XML canonicalisation.
5.3.3 PrimeLife Impact
In PrimeLife we are interested in capturing the privacy enhancing aspects of signature related primitives. Such primitives include group signatures, but also e-cash and ring signatures. However, our main interest in PrimeLife is in anonymous credentials that have a wide variety of features that allow them to emulate other privacy enhancing mechanisms such as group signatures and e-cash. They are also a major building block in realising privacy preserving attribute based access control. While our discussion could be kept more general we focus on anonymous credentials as they cover most of the cases.
There are several ways in which signatures and anonymous credentials are related. Those relations are elaborated on in the following paragraphs.
XMLDSIG as Format for Private Certificates
The show of a credential is a proof of knowledge of a signature (this signature is sometimes called the private certificate). The signature needs to be obtained in an interactive protocol, but it could be stored locally in XMLDSIG format.
As only knowledge of the signature is proven there is not much need to exchange these signatures directly with a verifying entity. So this would be mostly an archiving and data exchange standard for synchronisation between different devices of the same user.
XMLDSIG as Format for Anonymous Credential-based Signatures
Proofs of knowledge of some secret material (in our case a signature on the users secret key and different attributes) can be turned into non-interactive proofs using the Fiat-Shamir heuristic. Many known signature schemes follow this approach, e.g. Schnorr signatures, group signatures, many ring signatures.
Some of these Fiat-Shamir heuristic based signatures are conventional signatures that fit into the current XMLDSIG framework (i.e., all signature scheme where the messages do not need
56 to be input in the clear but rather as a hash). Others such as assertion-based signatures, that prove assertions about the attributes of credentials, such as anonymous credentials, group signatures, and ring signatures, do not that easily fit into the framework (as they require the message in the clear) and this would deserve further evaluation.
XMLDSIG as Format for Credential Shows
The proof of knowledge of a signature on certain attributes can be seen as 'passing on' the original signature on these attributes to a verifier. This passing on has certain desirable privacy preserving properties, such as: unlinkable to issued signature, selective disclosure of attributes, conditional showing of attributes (basically all those features that anonymous credentials provide). In this interpretation no new message is signed by the user. The user only transforms the signature obtained by the credential issuer into a new format that reveals less information about data that was already signed hiding for instance his identity.
This again could be expressed in XMLDSIG and deserves further consideration. A critical property of XML Signature is the fact that signature algorithms proper are applied to an XML description of the signed material; this description includes a digest value of the signed data. To apply advanced signing algorithms (i.e. to selectively reveal attributes), it is often desirable to be able to directly interact with the signed material.
Such direct interactions with the signed material include showing only parts of the signed material, or predicates or functions computed from signed values. This partial showing of signed material involves the owner of the signature as an active entity. As such the owner can choose what to reveal about the signed material and what to keep secret. However, he can only generalise the data but not change the assertions made by the issuing organisation.
57 Chapter 6 User Control Infrastructure
6.1 Smart Cards: User-controlled Token for Privacy Protection
6.1.1 Introduction
In a single sentence a smart card can be defined as
a personalised physical token under control of the user that can be used to perform cryptographic computations and keep data confidential.
In a more elaborate description, the important aspects of a smart card and its common use are:
• it is associated with a unique human user, the cardholder; • the cardholder has physical possession of the card; • some commercial entity, the card issuer, has prepared the card for use and delivered it to the cardholder; • some commercial entity, the application issuer, has initialised the card with personalised data, e.g. account number; • the application issuer defines the services that a card can deliver to the card holder and configures the card accordingly; • a cardholder controls the use of the card and its functions; • use of the card is localised to a terminal that has the facility to render the services the card has been configured for.
In many practical cases of deployed smart cards the application issuer and the card issuer are the same. A multi-application card, where multiple independent application issuers maintain separate "card applications" on a shared card is technically possible, yet has not seen any real deployments.
58 Deployments
Smart cards have been widely deployed, over 3 billion in 2007 (estimated by Eurosmart [Eurosmart])and the deployments are still increasing. By far the largest deployment is in mobile telephones where the card is used as the subscriber identity module (SIM). Banking cards are being migrated from pure magnetic strip cards to smart cards with magnetic strip as backup. Citizen ID cards and healthcare insurance cards have been issued or will be issued in many countries.
Trusted device
A smart card is operated as a trusted device in the application managed by the application issuer to deliver security functions. The trust is based on the tamper-resistance of the smart card chip, on the reliability of the card operating software and on the cryptographically maintained chain of trust between the card manufacturer (with any pre-issuance card processing agents), the card issuer and the application issuer. As a basis for trust many smart card products have undergone security evaluation according to the Common Criteria [CC]. And the card industry has produced a number of protection profiles to guide these security evaluations.
Cardholder control
The cardholder has control over the card:
• by inserting the card in a reader, or for contactless cards by holding the card in front of it; • by entering a PIN or password; • by providing a biometric sample.
With the first two control factors the card holder indicates her intent to use the card. A biometric sample indicates presence of the card holder at the location of the biometric sensor. Applications in the card can be configured for the type of user control required for the functions it provides:
• PIN or biometric entry a single time when the card service session starts; • PIN or biometric entry each time a particular service function is requested; • different PINs or passwords may be configured for different functions; • different biometric aspects may be configured for different functions; • any combination of above.
In practice, a smart card has a single PIN and any application on the card that needs a PIN uses that single one. Similarly, if the card supports biometric on-card verification, any application on the card may use it. Since most deployed smart cards support a single application these convenience cardholder-control configurations are usually sufficient. Privacy aspects of biometric control methods are further investigated in the next section (see chapter 6) of this chapter.
Contactless cards, which by definition allow reading at a distance, are sensitive to snooping and physical control of use would require the card to be carried around in an RF shield (blocking Radio Frequency electromagnetic radiation).
59 Form Factor
In a formal view, based on the international standard ISO/IEC 7810 a smart card can be in the form of the conventional credit card, or alternatively, in the smaller card used for SIMs. The mobile phone, with an inserted SIM card, can be seen as providing an alternative form factor for the user controlled trusted functions. (The one-sentence definition above could be easily applied to a mobile phone). For interactions with the Web, and Web 2.0 service architectures targeted in PrimeLife, the mobile phone will be a convenient platform for user control as it has internet connectivity and provides a user interface.
The NFC [NFC] technology takes this extended form factor and actually transforms the mobile phone into a contactless card. Since there now is a user interface snooping abuse inherent to contactless cards can be reduced, e.g. by an on/off input.
6.1.2 Standardisation
International standardisation for smart card technology is done in ISO/IEC [ISO/IEC WG4], in CEN TC 244 and in ETSI/3GPP [ETSI/3GPP]. Standardisation is concentrated in three areas:
• physical communication and application infrastructure; • cryptographic algorithms; • applications.
Work on communication and application infrastructure is done in SC17/WG4 (see chapter 8) (cards with contacts) and SC17/WG8 (contactless cards). The main standard documents are:
• ISO/IEC 7816-3, specifying the basic command-response interaction with a card and low-level details for operating and communicating over contacts; • ISO/IEC 7816-4, specifying a structure for data stored on a card and commands to access stored data; • ISO/IEC 7816-8, specifying commands to perform cryptographic operations; • ISO/IEC 14443-*, specifying operating and of communicating with an RF field; • ISO/IEC 24727-*, specifying an API for interacting with a card as a device that carries user identification data.
Work on Cryptographic algorithms is done in TC224/WG16. Work on applications for cards is done in ETSI/3GPP (SIM, USIM, SIM toolkit), SC17/WG11 (drivers license), TC224/ WG15 (citizen ID card) and by industry groups EMV, for payment cards and Global Platform [Global Platform] for application management.
6.1.3 Architectures
At a technical level the card can be modeled in three alternative and complementary views:
• as a storage device with an hierarchically organised data structure enhanced with access control and transport security; • as a cryptographic co-processor with tamper resistant key store; • as a general-purpose, programmable computer.
Privacy protection and PET in general are not explicitly addressed in most activities in current standardisation. Where addressed the concern is the protection of privacy sensitive data in
60 transfer from card to host. Specification of privacy protection rules and the interpretation of privacy security attributes is left to the application outside the card.
The standards do not specify access conditions for reading of unique identifiers in the card, like a chip serial number, an application serial number or a public key certificate. In the ISE/ IEC 14443 series. However, a fixed chip identifier initially broadcast to establish a connection has been replaced by a random one.
6.1.4 Strategy and Actions
Two areas of activities in PrimeLife may need to interact with standardisation for smart cards:
• in the development of algorithms for user control, • in the development of user interfaces for user control.
Possible actions:
• participation in SC27/WG5 to additionally address the adaptation and design of protocols with a role for the smart card in giving the user control in protecting her privacy; • participation in SC17/WG4 to introduce PET protocols and algorithms in the areas of: ◦ protecting user data exchanged with the card for PIN or biometric identification ◦ privacy protecting enhancements for the requests and procedures for entity authentication and card management ◦ restriction on access to unique card identifying data • identify protocols that are suitable for deployment on cards or require support by smart card functions and organise timely technical input to the work on standards from other work packages; • plan to integrate a smart card in the M4 demonstrator milestone with a mobile phone and SIM card application as user control user interface. 6.2 Biometrics Standardisation and Privacy
Biometrics is the science of measuring physical or behavioural characteristics that are suitable for the identification of individuals. There is a variety of applications using biometric user authentication today including national ID cards, digital signatures and physical or logical access control. A biometric trait, such as a fingerprint, iris, dynamic signature or face is stored in the system and typically, a claimant presents his or her biometric characteristic again to be compared with the previously recorded reference data. From a cryptographic point of view, biometric data must be regarded public, not secret. It is true, that biometric credentials are unique identifiers, not secrets. From a privacy viewpoint, however, biometric data must be considered confidential. Biometric data is critical in terms of privacy. It is not only related information, like a bank account number or street address but it is tied to the individual usually for the whole life. Biometric information can contain unwanted additional personally identifiable information like gender, age, susceptibility to some diseases or even sexual preferences.
The open mass applications applying biometrics led to a need for standardisation of biometrics. Industry, government and academic delegates attend the standardisation
61 consortiums. This document briefly describes the standardisation landscape for biometrics and points to aspects that are relevant in terms of privacy.
6.2.1 Biometrics Standardisation
Standardisation of biometrics started with national groups strongly led by NIST (National Institute for Standards and Technology) from the United States. Several industries are also dealing with biometrics standardisation, e.g. ICAO (international civil aviation organisation). The most important standardisation activity today is ISO/IEC JTC1 SC37 biometrics. It has established liaisons to all major standardisation bodies and is organised into 6 Working Groups:
• WG1: Harmonised Biometric Vocabulary and Definitions • WG2: Biometric Technical Interfaces • WG3: Biometric Data Interchange Format • WG4: Profiles for Biometric Applications • WG5: Biometric Testing and Reporting • WG6: Cross-Jurisdictional and Societal Aspects
Another important group is ISO/IEC JTC1 SC17 WG11 applied biometrics on cards. It deals with on-card comparison of biometrics as will be explained below.
6.2.2 Architectures
A biometric system operates in two phases: enrolment and verification/identification. A biometric reference data set is recorded in the enrolment phase and stored in a database or portable data carrier. The actual application assumes that reference data was previously recorded. In a physical access control system, users would present biometric traits, e.g. their faces to the system to be compared with the reference data. If the two samples are considered similar, access is granted. From a privacy point of view, it is of utmost importance where the storage and comparison actually take place. In a networked world where one would not trust a communication partner or the operating system on a host computer, one can still trust the smart card carried in a wallet. It enhances privacy when an application using a global database is reorganised to store all biometric data on a portable data carrier. The same is true for changing from an online verification, where data has to be transmitted to offline verification in a tamper-proof embedded system. A special case of such an embedded system is a smart card and the technology to perform a biometric comparison within a smart card is named Match-on-Card as addressed in SC17 WG11.
6.2.3 Strategy and Actions
To enhance privacy in today and future applications, standardisation activities should be observed and influenced where necessary. Depending on the particular application, databases and insecure data management should be avoided. Protecting biometric data by cryptographic means and storage as well as comparison in portable data carriers should be promoted.
The most important groups to address are the following:
• SC37 WG2: care needs to be taken, that the most common interfaces respect the needs for privacy and do not exclude Privacy-Enhancing Technologies.
62 • SC37 WG3: the data formats should also carefully be inspected and comments be made to ease the use of offline storage and verification. • SC37 WG4: today there is only little application profiles and the existing profiles are not well designed to protect the privacy of individuals. Further profiles should be encouraged to change this dramatically. • SC17 WG11: the standards produced by this group deal exactly with privacy- enhancing technology. They should be supported to reach a stable document status and promoted in other liaisons. • Other activities such as testing should be observed in a passive role.
63 Chapter 7 Identity Systems
In this section we provide an overview over different identity system as well as an insight into identity federation protocols. The reason behind the presentation of those topics in one section is that there are specifications and their implementations released under the identical name (e.g. OpenID). 7.1 OpenID
Main OpenID specifications:
• OpenID Attribute Exchange 1.0 [OpenID 1.0] • OpenID Authentication 2.0 [OpenID 2.0]
Additional information is avaiable from the OpenID foundation [OpenID Foundation].
7.1.1 Background
The OpenID protocol traces some of its roots back to Web blog commenting use cases: The fundamental idea is that, instead of asking a commenter to coin a user name / password pair, the commenters should identify themselves by providing the URI of their own blog. The protocol is based on simplistic data formats, and layered on top of HTTP.
OpenID therefore only requires implementation effort from the relying party and OpenID provider sides. From the user's side, an ordinary Web browser is sufficient.
7.1.2 Protocol Flow
The OpenID protocol is executed between the relying party (RP), the OpenID provider (OP), and the user.
In a typical scenario, the user will visit the RP's Web site, where a login-like form will ask him to enter an OpenID identifier (a URI or XRI, in typical use cases). Upon submission, the
64 RP will then use this identifier to discover the OP's URI. RP and OP perform an anonymous Diffie-Hellman key exchange (called association in OpenID parlance); the key that is negotiated is used later to authenticate further messages that are exchanged. The user's Web browser is then redirected to the OpenID provider, with an authentication request.
Then OpenID provider will at this step perform user authentication (which might be as simple as verifying the presence of the cookie, or as complex as the execution of another federation protocol), and possibly interact with the user to enable the user to authorise the overall OpenID transaction. The details of this step are out of scope for the core OpenID specifications.
If user authentication (and authorisation of the transaction) is successful, the OpenID provider redirects the user's browser back to the relying party; any assertions that are passed back to the relying party carry a message authentication code which is keyed with the shared secret established during the association phase.
The OpenID protocol exchange will scale badly to use cases in which individual HTTP requests are to be authenticated; in typical deployments, the OpenID protocol will be executed one (or a few) time(s) while the user interacts with the relying party. Authentication state is then attached to the user's session.
7.1.3 Message Formats
The abstract syntax for OpenID messages consists of a collection of simple tag-value pairs. There is no provision for more deeply structured data.
The messages are transmitted through HTTP (or HTTPS); there are several concrete syntaxes depending on the environment in which the message is passed.
During the association phase, the relying party will submit the OpenID message as the body of an HTTP POST request, and receive the answer in a simple text-based format.
For messages that are passed through the user's browser (in particular the authentication request and response), messages are always encoded in HTTP requests -- either in the body of HTTP POST requests (i.e., through form submission), or in query parameters of an HTTP GET request.
Messages can be "signed" by using a message authentication code keyed with the shared secret established during the association phase.
The message format is extensible with additional tags; the authentication request and response can therefore be used to pass personal information about the user from the OpenID Provider to the relying party.
7.1.4 Trust and Privacy Properties
The OpenID protocol provides a framework for certain assertions about a user's association with a URI. It does not provide an independent cryptographic proof to the relying party that the user has indeed executed a certain protocol with the OpenID Provider.
The establishment of trust between the relying party and the OpenID provider is out of the protocol scope. In deployments, the requisite policies range from accepting identities from
65 _any_ OpenID provider, through OpenID provider blacklists, to approaches where few (or only one) previously known OpenID providers are trusted.
Privacy concerns focus on the ability of the user's OpenID provider to link user transactions with different relying parties. It should also be noted that OpenID can be used to pass along personal information; how the release of this information is authorised is up to the individual OpenID Provider's choice.
Criticisms of OpenID center around certain aspects of the protocol design, and on risks that a malicious relying party might be able to successfully impersonate the user's OpenID provider.
7.1.5 Specification Development
The OpenID specifications were developed through an informal collaboration of interested parties. Since then, the OpenID foundation has been formed as a framework for future specification development; the foundation also manages intellectual property rights around OpenID.
7.1.6 Open Source Implementations
Numerous Open Source implementations of OpenID are available in different languages such as C#, Java, Perl or PHP. A list of OpenID libraries [OpenID libraries] is hosted at the OpenID wiki. In addition to the current implementations of OpenID there has been an Apache project which has been integrated into OpenID.
• Heraldry (06/09/2007) [Heraldry] ◦ supports OpenID-Protocol and plans to support CardSpace-Protocol, ◦ merged into OpenID. ◦ License: Apache 2.0. • OpenID4Java (Sxip) [OpenID4Java] ◦ Sxip also provides the Sxipper [Sxipper] Firefox plugin which is explained in more detail in Selected Open Source Projects (see chapter 8). ◦ Language: Java. ◦ License: Apache 2.0. • Netmesh Infogrid [Infogrid] ◦ Netmesh is the founder of LID and co-founder of Yadis (see chapter 7). ◦ Language: Java, PHP, Perl. ◦ License: Sleepycat-like open source/commercial license [Netmesh license].
A Firefox plugin provided by Versign might prove to be useful for users of OpenIDs. The so called Seatbelt [SeatBelt] plugin detects OpenID conformance of the RP. If the RP supports OpenID the user is prompted if he wants to use his OpenID to sign-in. The user might even choose between different OpenIDs that he controls by using the given toolbar button.
7.1.7 PrimeLife Perspective on OpenID
From a PrimeLife perspective, OpenID is a platform for decentralized identity federation and personal information transmittal that merits further investigation, in particular if its deployment is successful. The relative simplicity of many core aspects of OpenID - while easing deployment - will also be a challenge, as it might render the integration of advanced privacy enhancing technologies in the context of this protocol more difficult.
66 7.2 Higgins
The Higgins open source identity management project [Higgins] is an open source Internet identity framework designed to integrate identity, profile, and social relationship information across multiple sites, applications, and devices. Higgins is not a protocol, it is software infrastructure to support a consistent user experience that works with all popular digital identity protocols, including WS-Federation (see chapter 7), WS-Trust, SAML (see chapter 7), LDAP, Microsoft CardSpace (see chapter 7) and so on. The main contributing partners within the Higgins project are Parity Inc, Novell, IBM, and Serena with interested support from Computer Associates, Oracle, and Google.
The end-user paradigm of Higgins is based on the i-card metaphor: the user manipulates visual representations of an i-card which represent the user’s identity with identity granting institutions (identity providers). When accessing the provider of a Web service or a Web site (the relying party), the i-card GUI lets the user select an i-card and thus the identity provider and the personal information released to the relying party.
The Higgins user interfaces allow for the issuance of i-cards, their management, and their usage when accessing Web sites and services. The project currently supports various user interface implementations available on diverse platforms (Apple OS, Linux, Windows). These user interfaces are based on a pure Web-based architecture, as browser extensions or as a combination of browser extension/self-contained GUI application.
The data model of Higgins is based on the Higgins Global Graph (HGG) data model and the Higgins Identity Attribute Service (IdAS). The HGG distinguishes amongst: Identity contexts: the data space for digital identities such as a directory, a social network infrastructure etc. Entities, contained in contexts, represent the real-world abstractions, such as users, groups, organisations, etc. Entities have a set of attributes which can be simple or complex (e.g. composite values), such as given name, date of birth, nationality, etc.
Developers use a Java based framework that provides an interoperability and portability abstraction layer over existing “silos” of identity data. IdAS makes it possible to “mash-up” identity and social network data across highly heterogeneous data sources including directories, relational databases, and social networks. Support for OWL/RDF based ontologies is intended to allow for mapping between semantically equivalent identity attributes.
The overall, high-level, architectural schematic is shown in the figure below. The preliminary step (1) fashions an identity, represented as an i-card and stored in the user’s i-card store (commonly on disk or some other storage device). The identity provider (IP) relies on the IdAS to obtain the various identity attributes defining the user’s identity.
In order to access a Web service or a Web site (the relying party), the user contacts the site (for example via his or her browser) (step 2). The site redirects the request to the user and lets him or her select an appropriate i-card using the Higgins I-card GUI (also known as the identity selector service (ISS)). Once selected, the identity provider associated with the selected i-card is invoked in order to generate a secure token (implemented as a SAML assertion, for example) (step 3). This secure token is relayed to the relying party which verifies the presented access token and either grants or denies access (step 4) to the Web service or resource.
67 'Figure 2: High-level Higgins architecture'
Higgins is compatible with Microsoft CardSpace and allows to import CardSpace’s Information Cards and use these to access CardSpace compliant Web sites.
The Higgins project has released version 1.0 of the environment in March 2008. Further work is being investigated in the following areas: Policies: Higgins currently reuses the Microsoft CardSpace claims language to express secure token requirements. More sophisticated policy and claims syntax and semantics are of interest. Ontologies on attributes to allow the mapping between required policy claims and IdAS supplied identity attributes. Additional identity schemes: In addition to the support of Microsoft CardSpace, other identity schemes such as OpenID or IBM’s Identity Mixer technologies are considered for integration into the Higgins framework. IdAS Access Authorisation: a unified and generalised acess authorisation layer to the Higgins IdAS environment is discussed within the project. 7.3 CardSpace
CardSpace [CardSpace] is the identity selector provided by Microsoft. Hence, it is not a standardisation effort, but a product. Nevertheless we want to describe it here, because it completes the picture of commonly used identity systems. CardSpace is shipped with Windows Vista and the .NET Framework 3.0 and later. It provides four major features:
• support for any digital identity system • consistent user control of digital identity • replacement of password-based Web login • improved user confidence in the identity of remote applications.
68 CardSpace is built on top of the Web Services Protocol Stack. It uses WS-Security, WS-Trust, WS-MetadataExchange and WS-SecurityPolicy. This means that it can easily be integrated with other WS-* applications. In CardSpace a so called Information Card contains all claims which are associated with an identity of a user. If a Web site shall accept Information Cards for authentication, the developer needs to add an
We typically rely on a number of different digital identity systems, each of which may use a different underlying technology. To think about this diversity in a general way, it is useful to define three distinct roles:
• User is the entity that is associated with a digital identity • Identity provider is an entity that provides a digital identity for a user • Relying party is an application that in some way relies on a digital identity to authenticate a user, and then makes an authorisation decision
Given these three roles, it isn't difficult to understand how CardSpace can support any digital identity. A user might rely on an application that supports CardSpace, such as a Web browser, to access any of several relying parties. She might also be able to choose from a group of identity providers as the source of the digital identity she presents to those relying parties. Whatever choice she makes, the basic exchange among these parties comprises three steps:
First, the application gets the security token requirements of the relying party that the user wishes to access. This information is contained in the relying party's policy, and it includes things such as what security token formats the relying party will accept, and exactly what claims those tokens must contain. Once it received the details of the security token this relying party requires, the application passes this information to CardSpace, asking it to request a token from an appropriate identity provider. After this security token has been received, CardSpace gives it to the application, which passes it on to the relying party. The relying party can then use this token to authenticate the user or for some other purpose. Working with CardSpace does not require relying parties or identity providers to implement any proprietary protocols.
CardSpace implements an intuitive user interface for working with digital identities. Each digital identity is displayed as an Information Card. Each card represents a digital identity that the user can potentially present to a relying party. Along with the visual representation, each card also contains information about a particular digital identity. This information includes which identity provider to contact to acquire a security token for this identity, what kind of tokens this identity provider can issue, and exactly what claims these tokens can contain. By selecting a particular card, the user is actually choosing to request a specific security token with a specific (sub-)set of claims created by a specific identity provider. In fact, the user needs not to disclose the full information that is associated with an Information Card, but she can verify what will be revealed to the relying party.
There are different interoperability initiatives which are implementing CardSpace on the relying party side. Those initiatives are discussed in more detail in the discussion of Selected Open Source Projects (see chapter 8). The projects using CardSpace in one or another way are Bandit [Bandit], Concordia Project [Concordia], Higgins (see chapter 7), and OSIS [OSIS at Identity Commons].
69 7.4 WS-Federation
WS-Federation (see WSFed Technical Committee [WSFed TC]) introduces mechanisms to manage and broker trust relationships in a heterogeneous and federated environment. This includes support for federated identities, attributes and pseudonyms. ‘Federation’ refers to the concept that two or more security domains agree to interact with each other, specifically letting users of the other security domain accessing services in the own security domain. For instance, two companies that have a collaboration agreement may decide that employees from the other company may invoke specific Web services. These scenarios with access across security boundaries are called ‘federated environments’ or ‘federations’. Each security domain has its own security token service(s), and each service inside these domains may have individual security policies. WS-Federation uses the WS-Security, WS-SecurityPolicy and WS-Trust specifications to specify scenarios to allow requesters from the one domain to obtain security tokens in the other domain, thus subsequently getting access to the services in the other domain.
To illustrate this concept with an example, imagine that a user Alice from company A intends to access Bob’s Web service in company B. Alice and Bob do not have any prior relationship, but both companies have agreed to federate certain services, and the decision is that particular users from company A may access dedicated services inside company B. By some means, Alice knows the endpoint reference of Bob's service. Using the basic mechanisms defined in WS-PolicyAttachment, WS-MetadataExchange, and WS-SecurityPolicy, Alice retrieves the security policy of Bob’s service and detects that the security token service STSB of company B issues tokens to access this service. Alice issues a security token request to the security token service STSA of company A and claims to need a token to access STSB. Company A and company B are federated together, therefore STSA is able to issue a security token for Alice. Of course, that may depend on whether Alice belongs to the group of A’s employees that are permitted to access Bob’s services. In the next step, Alice requests a token for accessing Bob’s service from STSB and proves her authorisation by utilising the token issued by STSA. After validating that STSA security token is valid, STSB issues a security token for access to Bob's service (assuming that Bob’s Web service belongs to the group that company B offers to company A). In the last step, Bob’s Web service is invoked by Alice. During that final request, Alice presents the token issued by STSB.
Besides this introductory example, WS-Federation shows how such a federation could work across multiple security domains or how delegation could be used. Delegation means that a user may delegate certain access rights on one federated resource to a different federated resource. WS-Federation adds security to service aggregation. Additionally, WS-Federation defines mechanisms to handle pseudonyms (aliases used at different services and federations) and management mechanisms for the pseudonyms, including single sign-in and sign-out (sign-out refers to the removal of pseudonym related information at different services).
WS-Federation is helpful for establishing trust relationships and is therefore essential for Web service work in PrimeLife. 7.5 SAML
The Security Assertion Markup Language (SAML) is an XML standard that defines a framework for exchanging security information, such as authorisation, authentication and attribute statements. It was developed by standards organisation OASIS (see chapter 8) (the Organisation for the Advancement of Structured Information Standards).
70 7.5.1 Background
SAML 2.0 [Semantic Web] comes from the combined effort of OASIS, the Liberty Alliance and the Shibboleth Project. These standards bodies enhanced SAML 1.0 to create SAML 2.0.
SAML 2.0 was ratified as an official OASIS industry standard (2005) and is now backed by multiple vendors and organisations around the world as industry standard for deploying and managing open identity-based applications. SAML 2.0 represents a step toward the convergence of identity standards and all future enhancements to Liberty Federation will be based on SAML 2.0.
The Liberty Alliance added support for SAML 2.0 to Liberty Web Services in 2005 and at that time incorporated SAML 2.0 testing into its Liberty Interoperable conformance programme. WS-Security also supports SAML.
7.5.2 Architecture
SAML is defined in terms of:
• Protocols: How to define a request or a response. • Assertion: How to define the information about authentication, attribute and authorisation. An assertion contains a package of information that supplies one or more statements made by a SAML authority. SAML defines three different kinds of assertion statements: authentication (a subject was authenticated by a specified method at a certain time), attribute (the subject is associated to the a set of attributes) and authorisation (a request to allow the subject to access the specified resource.) A typical SAML assertion reads
7.5.3 Protocol Flow
As an example, let us consider the basic template for achieving SSO using SAML2, in particular the service provider (SP) initiated protocol.
In this scenario, a user visits for the first time a SP's Web site to access some resource. SP determines the location of an endpoint at an identity provider (IdP) for the authentication request protocol. The SP sends a SAML2 authorization request to the IdP (e.g., HTTP Redirect binding) through the user agent. The authorization request is read by the IdP The IdP firstly checks if the user is already logged in, if it is not, IdP asks the user to provide
71 authentication materials (credentials), for example login/password. If credentials are valid, IdP sends a SAML2 Response message and sends it to the SP, e.g., using SAML2 HTTP post, through the user agent. This message may indicate an error, or include an authentication assertion. SP receives and checks the SAML2 Response message, and it may respond to the user agent with its own error, or establish a security context for the user and provides the requested resource.
7.5.4 Open Source Implementations
• OpenSAML Implementation from Internet2 [OpenSAML] ◦ Implements SAML 2.0 ◦ C++ and Java libraries ◦ License: Apache 2 License • Enterprise Sign On Engine (ESOE) as SSO solution [ESOE] ◦ Implements SAML 2.0 and Lightweight XACML (LXACML) ◦ Java libraries ◦ License: Apache 2 License • Liberty Alliance Single Sign-On (LASSO), Free Liberty Alliance Implementation [LASSO] ◦ Support of SAML 2.0 also ◦ C libraries ◦ License: GNU GPL and Commercial License for proprietary use • Lightbulb (subproject of OpenSSO) [Lightbulb] ◦ Implements SAML 2.0 ◦ PHP ◦ License: Common Development and Distribution License • Shibboleth from Internet2 [Shibboleth] ◦ Privacy extended SAML implementation ◦ C and Java libraries ◦ License: Apache Software License • ZXID [ZXID] ◦ Implements SAML 2.0 as C library ◦ C libraries (supports Perl, PhP, Java) ◦ License: Apache 2 License 7.6 Liberty Identity Federation
The Liberty Identity Federation Framework (Liberty ID-FF) is one of the three modules of Liberty architecture. It defines a set of protocols, bindings, and profiles for identity federation, cross-domain authentication, and session management.
7.6.1 History and relationship with SAML
Previous versions of the Liberty ID-FF (up to 1.2) were built on SAML 1.0/1.1 specification. More recently, the Liberty ID-FF (v1.2) was integrated into the SAML 2.0 specification. Additionally, SAML 2.0 has also components from the Shibboleth initiative.
72 'Figure 3: ID-FF SAML convergence'
7.6.2 Liberty profiles
The Liberty ID-FF describes various profiles. A Liberty profile is basically a combination of content specifications and transport mechanisms to support specific functions. The existing Liberty profiles, grouped according to their functions, are the following:
• Single Sign-On and Federation: The profiles by which a service provider obtains an authentication assertion from an identity provider facilitating single sign-on and identity federation. • Name Registration: The profiles by which service providers and identity providers specify the name identifier to be used when communicating with each other. • Federation Termination Notification: The profiles by which service providers and identity providers are notified of federation termination. • Single Logout: The profiles by which service providers and identity providers are notified of authenticated session termination. • Identity Provider Introduction: The profile by which a service provider discovers which identity providers an user agent may be using. • Name Identifier Mapping: The profile by which a service provider may obtain a Name Identifier with which to refer to a user agent at a SAML Authority. • Name Identifier Encryption: The profile by which one provider may encrypt a Name Identifier to permit it to pass through a third party without revealing the actual value until received by the intended provider.
A full description of these profiles can be found at Liberty ID-FF Profiles [ID-FF Profiles]
A particularly relevant use case is single sign-on, the corresponding protocol and a specific profile is described below.
7.6.3 Profiles of the Single Sign-On and Federation Protocol
The Single Sign-On and Federation Protocol defines messages exchanged between service providers and identity providers for supporting single sign-on. The mapping of these messages to particular transfer (e.g., HTTP) and protocol flows are described in the the Single Sign-On and Federation profile, which lists various possible solutions. An example follows.
7.6.4 Single Sign-On Protocol Flow Example: Liberty Artifact Profile
User or user agent connects to a service provider (SP). To log in, he has to select the preferred identity provider (IdP), for example from a list presented on the service provider’s login page
73 (alternatively, in some implementations, the SP itself may discover the preferred IdP by other means). Then, the user’s browser is redirected to the IdP, with an embedded parameter indicating the originating SP, and the user may log in to the IdP providing the necessary credentials.
The IdP verifies login credentials and, if successful, redirects the user agent to the originating SP with a one-time-used, encrypted credential, called an artifact, included in the URI. The artifact is a user handle, which can be used by the SP for querying the IdP to receive a full SAML assertion. The main advantage of this approach is that the artifact is small enough to fit the URI.
In the next step, SP uses the artifact information for querying the IdP about the user. In its response, the IdP provides the assertions for the user, and the SP may then establish a secure context and respond with the requested resource.
7.6.5 Liberty and CardSpace
CardSpace (see chapter 7) is a Microsoft .Net component designed to manage digital identity. It is not a set of standards as Liberty, but a product. CardSpace is mainly built on WS-* standards, but also support some features from SAML.
There are some differences between the Liberty and CardSpace approaches. Liberty specifications are defined to be used with general Web browsers, on the contrary CardSpace introduces new functionality to user's Web browser and to the underlying operating system (it is currently shipped with Windows Vista and the .NET Framework 3.0 and later). In practice, CardSpace moves some of the identity management logic from the identity provider to the user's computer. This results in a loss of generality, but enables the use of proof-of-possession keys, which may increase the security of token delivery. Regarding authentication, CardSpace selector has a fixed list of authentication methods, whereas in Liberty framework identity providers can present a customised authentication page.
In short, although the two protocols try to solve the same general problem, CardSpace has a more client-centered approach, relying on a smart non-standard client, whereas Liberty provides a distributed and open, but more complex, framework.
7.6.6 PrimeLife and Liberty
Liberty standards are increasingly becoming adopted in many industries, and they play a major role in identity federation technologies. The PrimeLife consortium should evaluate them and compare them to other solutions (e.g., WS-Federation) for possible adoption.
7.6.7 Open Source Implementations
• FederID [FederID] ◦ Integrates Authentic [Authentic], LASSO [LASSO], LemonLDAP::NG [LemonLDAP] and InterLDAP [InterLDAP] ◦ Languages: Java, Perl, Python ◦ License: AGPLv3, GPL • OpenLiberty-J [OpenLiberty-J] • LASSO [LASSO] ◦ Implements ID-WSF, ID-FF 1.2
74 ◦ C library ◦ License: GNU GPL • Conor Cahill ID-WSF tools [ID-WSF tools] ◦ Implements ID-WSF ◦ C client and Java server toolkit ◦ License: BSD license 7.7 Yadis
Yadis [Yadis Spec] is an HTTP based protocol for authentication service discovery. It ensures compatibility between different authentication services. Currently three such services are supported: OpenID, LID and i-Names. The goal of the initiative is to make the used authentication system transparent to the user (i.e., a user sends a Yadis compatible identifier to the Yadis-enabled relying party (RP) which in turn is able to resolve the authentication system used by the Identity Provider.)
7.7.1 Protocol flow
The Yadis authentication service discovery is initiated by the user supplying an identifier to the RP. This ID must be resolvable to a URI. The process of resolving the authentication service is executed in at most three steps. The resolution process results in the RP having a Yadis document which allows to use a therein specified authentication mechanism.
As the initial step the RP issues an HTTP request to the indicated URL. This request can either be a GET or a HEAD request. The answer to the request can be a Yadis document or a Yadis Resource Descriptor URI. In case an HTTP HEAD request was issued, the response may not contain a Resource Descriptor URI in which case the RP is obliged to issue an HTTP GET request.
If the RP did not receive the Yadis document after the first request, it must request the document at the location indicated by the Yadis Resource Descriptor URI. This results in the retrieval of the Yadis document. The second request may also consist of launching an HTTP GET request in the case of having issued an HTTP HEAD request in the first step and not received either Yadis document or Yadis Resource Descriptor URI. The response to this request is as described in the first step.
The third step is only necessary in case of an unsuccessful HTTP HEAD request as first message. As either the Yadis document or Yadis Resource Descriptor URI must have been retrieved in the second step, this third step consists of retrieval of the Yadis document at the location indicated by the Yadis Resource Descriptor URI. The resolution process terminates as soon as a Yadis document has been received.
7.7.2 The Yadis document
An examplary Yadis document specifying two available authentication services looks as follows
75
According to the specification there can be several Extensible Resource Descriptors (XRD) with the semantics of only the last being taken into account. Additionally, there can be several other elements which may be disregarded by the RP. The XRD element may contain one or several Service entries. The absence of a Service element indicates that the Yadis URI is not meant to be used with a Yadis service. Otherwise, the Service element lists available services for authentication where the ordering of the elements is not relevant. The priority can be indicated using the optional priority attribute where smaller numbers refer to higher priorities and services with no priority refer to the lowest preference level. The Service element must contain one or more Type elements which are URIs or XRIs referring to the service specification document.
7.7.3 Trust and privacy properties
As the protocol only serves for service discovery, there are no privacy options in Yadis. The Yadis document, however, allows for elements other than the mandatory XRD element. In the current specification the interpretation of such elements by the RP is optional.
7.7.4 Opportunities for PrimeLife
Yadis is a small protocol enabling the transparent use of different authentication systems. The current limitation of Yadis is that the identifier used by the authentication mechanism must be resolvable to a URI. If that limitation does not restrict the authentication mechanism proposed by the PrimeLife project, a collaboration with the Yadis project could speed up the market adoption significantly. The implementation overhead seems to be minimal.
The specification of the Yadis protocol is released in version 1.0 and dates from March 2006.
7.7.5 Specification development
Yadis was developed by members of the OpenID and the LID community. In October 2005 the i-Names initiative joined the project.
7.7.6 Open Source Implementations
The project maintains a list of Yadis Implementations [Yadis Implementations].
76 Chapter 8 Specification Developing Organisations
8.1 W3C
The World Wide Web Consortium [W3C] is an International Consortium with over 400 member organisations from more than 40 countries. W3C Members include vendors of technology products and services, content providers, corporate users, research laboratories, standards bodies, and governments, all of whom work to reach consensus on a direction for the Web.
W3C's main role is to standardise Web technologies by creating and managing Working Groups, that produce specifications (called Recommendations) to describe the building blocks of the Web. W3C produces them freely available to all, as part of the Web open platform. Working Groups participants are individuals from member companies or invited experts selected on their expertise in the area. W3C also opens Interest Groups, to bring together people who wish to evaluate potential Web technologies and policies. An Interest Group is a forum for the exchange of ideas. The W3C technical team contributes and coordinates the activities in the various fields: Web Architecture, Protocols, Web applications, Ubiquitous Web, Interaction, Web Services, Semantic Web, Privacy and Security, Web Accessibility, Internationalisation.
Particularly relevant W3C work for the PrimeLife project includes:
• The Platform for Privacy Preferences (P3P 1.0 [P3P 1.0 Spec], P3P 1.1 [P3P 1.1 Spec]) • APPEL [APPEL] • XML Signature (XML Signature Syntax and Processing Recommendation [XML Sig], in collaboration with IETF (see chapter 8)) • XML Encryption (XML Encryption Syntax and Processing Recommendation [XML Enc], Decryption Transform for XML Signature [XML Sig Transform]) • Web Services Policy (Web Services Policy Framework [WS-Policy 1.5], Web Services Policy Attachment [WS-PolicyAttachment 1.5])
77 Currently, three Groups are specifically involved in Privacy and Security for the Web:
• Web Security Context Working Group (WSC [WSC]) • XML Security Specifications Maintenance Working Group (XMLSec [XMLSec]) • Policy Languages Interest Group (PLING [PLING])
The Web platform (see chapter 1) section also describes a number of key technologies for the Web, at the core of W3C work since its creation. 8.2 IETF
The Internet Engineering Task Force [IETF] is a community of international network experts. Participation is individual, but most participants are sponsored by organisations or companies: network operators, vendors, research centers, etc. There is no actual membership to IETF, anyone can register and attend the IETF meetings.
The Request For Comments [RFC] produced by the IETF community are in the following scope: “protocols and practices for which secure and scalable implementations are expected to have wide deployment and interoperation on the Internet, or to form part of the infrastructure of the Internet.”
The IETF operates Working Groups in 8 Areas, supervised by two entities: the Internet Engineering Steering Committee (IESG) [IESG] and the Internet Architecture Board (IAB) [IAB]. These Areas are:
• Applications (APP), including the Web • General (GEN) • Internet (INT), core technologies of Internet • Operations and Management (OPS) • Real-time Applications and Infrastructure (RAI) • Routing (RTG) • Security (SEC) • Transport (TSV)
The relevant IETF work for PrimeLife pertains to the Security Area [IETF SEC], though the Application Area may not be totally irrelevant to the project's target. The Security Area is constituted of 16 Working Groups and covers protocol-level security mechanisms, such as TLS, SASL, Kerberos, X.509, S/MIME, DKIM. 8.3 OASIS
The Organisation for the Advancement of Structured Information Standards [OASIS] perceives itself as “a non-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society.” The organisation was founded in 1993 and has currently “more than 5,000 participants representing over 600 organisations and individual members in 100 countries.”
The OASIS specifications which are of most interest for PrimeLife are WS-Trust [WS-Trust 1.3], WS-Federation (see chapter 7) (work in progress) and WS-SecurityPolicy [WS- SecurityPolicy 1.3]. They are publicly available and have broad industry support. The core
78 specifications have been around since 2002. The base specifications such as XML signature are robust, mature and well adopted.
These specifications depend on open standards such as SOAP Version 1.2 [SOAP12], XML Signature [XML Sig], XML Encryption [XML Enc], etc. They are stable specifications, with rich implementation support from multiple vendors. They are XML schemas and many of them are ratified by OASIS. Compatibility is likely given their widespread adoption.
The IPR on these set of specification is primarily based on the OASIS IPR charter [OASIS IPR]. In general the mentioned OASIS specifications are well-founded and established both in industry and academic. 8.4 Liberty Alliance
Liberty Alliance [Liberty] is a business alliance, formed in 2001, with the goal of defining and driving open technology standards, privacy and business guidelines for federated identity management. Its 160 members are vendor companies, consumer companies, government and education organisations. In addition, Special Interest groups are open communities, and OpenLiberty.org releases open source code for security and privacy.
The mission behind this alliance is to
• provide open standard and business guidelines for federated identity management spanning all network devices, • provide open and secure standard for single sign-on with decentralised authentication and open authorisation, • allow users to maintain personal information more securely, and on their terms.
The Liberty architecture is composed of 3 independent modules:
• Liberty Identity Federation Framework (ID-FF) (see chapter 7) is the basis of Liberty Single Sign-On and Federation framework.
It enables identity federation and management through features such as identity/account linkage, simplified sign-on, and simple session management. It was originally based on SAML 1.1, and recently it has been integrated in SAML2.
• Liberty Identity Web Services Framework (ID-WSF) [ID-WSF] is the Liberty's federation framework for Web services, allowing providers to share users identities in a permission-based model. This framework offers features like Permission Based Attribute Sharing, Identity Service Discovery (to discover identity and attribute providers), Interaction Service (a mechanism to obtain permissions from a user) and the associated security profiles. • Liberty Identity Services Interfaces Specifications (ID-SIS) [ID-SIS] defines service interfaces for each identity-based Web service so that providers can exchange different parts of identity in an interoperable way.
The ID-SIS is a set of specifications for interoperable services built on top of ID-WSF.
The Liberty Alliance also evaluates adoption of its specifications (see Case studies [Liberty Adoption]).
79 8.5 TCG
The Trusted Computing Group [TCG] (TCG) is an industry standardisation body that aims to develop and promote an open industry standard for trusted computing hardware and software building blocks to enable more secure data storage, online business practices, and online commerce transactions while protecting privacy and individual rights.
The core hardware module specified is the so called TPM, the Trusted Platform Module. The TPM is a microcontroller that stores keys, passwords and digital certificates. It typically is affixed to the motherboard of a PC. It potentially can be used in any computing device that requires these functions. The nature of this silicon ensures that the information stored there is made more secure from external software attack and physical theft. Security processes, such as digital signature and key exchange, are protected through the secure TCG subsystem. Access to data and secrets in a platform could be denied if the boot sequence is not as expected. Critical applications and capabilities such as secure email, secure web access and local protection of data are thereby made much more secure.
The TPM is questioned by the surrounding modules so that the decision process always involves the hardware - secured trust chain:
Figure 4: TCG Architecture
This generic architecture can be used in many use cases and circumstances. The following roadmap describes the main use cases targeted by TCG. But there are many more use cases as any kind of electronic device can benefit from the trust chain.
80 Figure 5: TCG map of documents
As can be seen from this roadmap, TCG targets different computing platforms including PCs, PDAs and mobile phones. It allows to prevent those in possession of the device or those attacking a device to take control or spy on data secured by TCG technology. In fact, the TPM controls secured memory that is only accessible by those having the right keys and information. The building up from the hardware makers ensures that the chain of trust is not interrupted.
One main application of TCG technology is securing storage devices. As the storage device itself is secured by cryptographic means, the policy control engine can enforce decisions into the disk/storage access. Initially developed mainly for rights management or DRM, this can be used to leverage constraints coming from identity management.
Another interesting application for PrimeLife is the suite of network access control specification. It uses the TPM and the controlled and protected memory of a device to determine its status and feed the information back to a console. Thus security policies can determine whether to allow or disallow such a device on a given network. Again, this is leveraging the TPM and the trust chain established by the cryptographic chain from the hardware up to the application in a certain use case.
Trusted Computing is an important tool in the PrimeLife toolbox. It allows ultimate enforcement into an infrastructure that is not in actual possession of the data subject or the data controller. PrimeLife may provide the necessary semantics where to disclose data, where to allow the copying of data while a TCG infrastructure can make sure that an enterprise must follow those constraints.
There are also caveats in using TCG. When using the TCG platform with its TPM, the entity controlling the TPM effectively takes over control of large parts of the data controller's infrastructure. While technically possible, this does not sound like a compelling argument to enterprises for wanting to implement and help end user identity management. Furthermore, the strong cryptographic link is mostly used for strong authentication. Such identification has
81 merits for data quality and security that are also part of the data protection world, but it is only usable in cases where the identification of a user is part of the scenario that PrimeLife is trying to solve. 8.6 ISO/IEC JTC 1
8.6.1 ISO/IEC JTC 1/SC 27/WG 5
Considering the promising new ways in which we use technologies in our daily life and the important challenge to handle an individual’s identity and personal information appropriately in the process, SC 27 has established its new WG 5 on Identity Management and Privacy Technologies in May 2006. Currently WG 5 is active in 7 projects and 2 Study Periods with more being expected. The seven projects line up as follows:
• Working Draft 24745 Biometric template protection describes the security techniques for Biometric Template Protection focusing on Privacy-Enhancing Techniques for Biometric Template Generation. • A Framework for Identity Management (Working Draft 24760) addresses the secure, reliable, and privacy respecting management of identity information considering that identity management is important for individuals as well as organizations, in any environment and regardless of the nature of the activities they are involved in. • The project on Authentication Context of Biometrics (Final Draft International Standard 24761) defines the structure and the data elements of authentication context for biometrics, by which service providers (verifiers) can judge whether a biometric verification result is acceptable or not. • A Privacy Framework (Working Draft 29100) is to provide a framework for defining privacy safeguarding requirements as they relate to personally identifiable information processed by any information and communication system in any jurisdiction. • A Privacy Reference Architecture (Working Draft 29101) is to provide a reference architecture model that will describe best practices for a consistent technical implementation of privacy requirements in information and communication systems. • Entity Authentication assurance (Working Draft 29115) aims at describing the guidelines or principles that must be considered in entity authentication assurance and the rationale for why it is important to an authentication decision. • A Framework for Access Management (New Project 29146) aims to provide a framework for the definition of access management and the secure management of the process to access information. This framework is to be applicable to any kind of users, individuals as well as organizations of all types and sizes, and should be useful to organizations at any location and regardless of the nature of the activities they are involved in.
The two study periods deal with Privacy Capability Maturity Models and Access Control Mechanisms.
It should be mentioned that also other working Groups in SC 27 maintain a number of projects with a relevant relation to privacy, most notably ISO/IEC JTC 1/SC 27/WG 3 Security evaluation criteria, that is responsible for IS 15408 Evaluation Criterial for IT Security and its Privacy Class covering anonymity, pseudonymity, unlinkability, and unobservability.
82 With 51 member countries ISO/IEC JTC 1/SC 27 has an immense global outreach. At the same time WG 5 has a significant topical overlap with PrimeLife and combines openness for Privacy and Identity Management aspects with a solid foundation in IT Security. Therefore PrimeLife is establishing a liaison to ISO/IEC JTC 1/SC 27/WG 5.
8.6.2 ISO/IEC JTC 1/SC 17/WG 4
A core activity in WG 4 is the maintenance and regular technology upgrade of the ISO/IEC series of standards for smart cards: Key parts of this standard are:
• ISO/IEC 7816-4 (2005) [ISO/IEC 7816-4:2005] This standard defines the basic model of operations of a smart card as a server responding to a standard formated request. It defines a set of standardized requests for: ◦ Opening one or more sessions with different applications that can co-reside on the card; ◦ Access and management to stored data; ◦ Identification of the card holder by PIN or biometry; ◦ Performing algorithm neutral cryptographic entity authentication; ◦ Establishing an algorithm neutral end-to-end transport-layer security to protect integrity and/or confidentiality of requests.
(See also http://www.cardwerk.com/smartcards/ smartcard_standard_ISO7816-4.aspx)
• ISO/IEC 7816-8 (2004) [ISO/IEC 7816-8:2004] This standard specifies a set of requests to perform cryptographic operations both for symmetric and asymmetric cryptographic algorithms with secret keys stored on the card. • ISO/IEC 7816-11 (2004) [ISO/IEC 7816-11:2004] This standard specifies a set of requests and associated data structure for use of biometric data on a smart card. • ISO/IEC 7816-13 (2007) [ISO/IEC 7816-13:2007] This standard specifies a set of requests to manage the content on the card, specifically to load and remove executable code for different applications. The requests specified by this standard are based on the Global Platform specifications [Global Platform Specs].
The parts of a series of international standards ISO/IEC 24727 are still at various stages of preparation. These standards cover:
• An architecture for applications on a card terminal to access card based services; • An API for access to card based services primarily for user identification and card data access; • Management and security of access to card based services.
Relevant results of PrimeLife for card-based PET could be incorporated in the ISO/IEC 7816 series, parts 4 or 8.
8.6.3 ISO/IEC JTC 1/SC 17/WG 11
A biometric system always splits into two phases: biometric reference data is collected in a registration phase from the user group and current biometric data will be compared with this reference data in the verification phase. Usually, the reference data is stored in a database or portable data carrier such as a smart card. The match-on-card technology allows to perform the comparison of the biometric data within the smart card, which means that the critical
83 reference data never has to leave the smart card chip. It enhances the security and privacy of an application requiring the security status of the comparison in the card.
SC 17/WG 11 was founded in 2005 to address applied biometrics on cards. Its main focus is the standardisation of on-card matching. The document ISO/IEC 24787 addresses the architectures, parameters and usage of on-card matching. It supplements the existing standaridsation landscape and gives a guidance for the application programmer to understand, implement and make use of the match-on-card technology. The group should be supported because its outcome are documents enabling to raise the privacy in daily life, particularly in digital identities used online.
8.6.4 ISO/IEC JTC 1/SC 37
SC37 was founded when the industry acknowledged that a significant level of standardisation is required to achieve acceptance of the biometrics technology in open mass markets and applications such as e-passports. The group addresses various aspects such as vocabulary, interfaces, data formats, testing and applications profiles as well as jurisdictional aspects of biometrics.
Raising the knowledge of biometrics amongst users and customers is one of the most important subjects for leading biometric vendors. Biometrics are not as secret as cryptographic keys. Biometric data, however, must be considered confidential personal information and has to be protected against misuse. From the viewpoint of privacy, the standardisation activities should be observed and influenced where necessary to protect user rights on individual data.
A variety of standards addressing biometrics are available today. Most standards can be purchased though the national standardisation committees. The documents currently under revision can only be accessed by the ISO committee.
84 Chapter 9 Selected Open Source Projects
There is a large number of open source projects that deal with privacy in one way or the other. Some of these projects provide implementations of standards, these we describe in the respective section about the standard. Refer to SAML (see chapter 7), Liberty Federation (see chapter 7), XACML (see chapter 3) or CARML / Oracle IGF (see chapter 4) for details. In this section we summarise other projects.
There are a number of projects which aim at driving interoperability between the different implementations or the different protocols. Some of which are depicted in detail in the sections OpenID (see chapter 6), Liberty (see chapter 7), CardSpace (see chapter 7) and Higgins (see chapter 7). Several other projects which are worth mentioning are shortly described below. 9.1 MozPETs: Mozilla Privacy Enhancement Technologies
MozPETs [MozPETs] is a project that was started by IT Transfer Office's [ITO] Prima Project [Prima] of the Technical University of Darmstadt. It was partly supported by research funding from the European Commission. TU Darmstadt closed the IT Transfer Office in 2006, so there is no institutional support for MozPETs anymore. There is an inactive Sourceforge project [MozPETSSourceforge] remaining.
The goal of MozPETs was to integrate all existing Privacy Enhancing Technologies into one browser. They used the Mozilla open source browser for their project and added all kinds of filters. Subsequently they tried to use the Web with the heavily privacy enhanced browser and failed. They documented their experiences in a paper published 2005 called MozPETs - a Privacy enhanced Web Browser [MozPETsPST05]. Of most interest is their analysis:
Privacy research has been done on a lot of different technologies. Most research focused on anonymity for network access, publishing, authorisation, and payment. E-mail fraud and phishing has lead to increased research on technical countermeasures. Data licenses were proposed to guarantee access rights to personal information. An identity management system combines privacy enhancement and security technologies to minimise the disclosure of
85 personal information, and provides the user with means to make informed decisions whether certain data is disclosed or not. The current identity management tools differ a lot in features and scope.
However, the Web looks different. Privacy invasive technologies, such as tracking users with Web bugs and third party cookies across multiple sessions and different sites, are common practice among site operators. Data mining is a key element of many commercial sites’ business plans. In general, the privacy and security features of today’s Web browsers are the same as of the Netscape Navigator 6 released in late 2000. The user can modify the cookie policy, wallet components store logins, passwords and other personal information. Many security tutorials advice users to disable cookies and active content, including JavaScript. Applying these settings makes the Web nearly unusable, as most sites will not work correctly. After this experience the disappointed user will restore the old settings.
MozPETs also tried to use P3P to give better information to the user within the iJournal. The iJournal tries to detect certain types of personal information within user's input, and looks for matching parts of the server`s P3P policy. With this information the user can evaluate if he really wants to submit the data. Instead of a user policy the iJournal gives the user context information for this special transaction. It also stores a copy of the relevant policy to have it available for later disputes, which was also done in the PRIME [PRIME] prototype.
As the Mozilla project is now focused on the Firefox browser, an investment into further development of MozPETs does not make too much sense. Instead, PrimeLife will rather look into the powerful extension mechanism for Firefox. But some code of MozPETs may be recovered. The important conclusion from this very practical exercise is also that Privacy Enhancing Technologies have to take Web functionalities into account to keep the browsing experience on a decent level. Usability considerations have to take the Web's reality into account and weigh the tradeoff between functionality and privacy preservation. 9.2 Firefox Plugins
Firefox plugins provide a variety of functionality for the browser. In this section the focus lies on the category of Privacy & Security [Firefox Addons]. Especially, the most interesting plugins can be grouped into three subcategories: Identity Management, Privacy and Trust. In the Identity Management category all addons allowing for an easier handling of the different digital identities are described. The Privacy categories summarises the efforts allowing for a better protection of the personal data and the Trust category shows the work going in the direction of visualisation of trust relationships between users and Web sites.
9.2.1 Formfiller and Identity Management Enhancement
As mentioned in the Firefox Plugins in PRIME (see chapter 10) section there are Firefox plugins which provide privacy enhancing technologies or allow for easier management of personal information. As an example the form filling extension Autofill Forms [Autofill Forms], published under the Mozilla Public License, is mentioned. This plugin provides automatic form filling based on pattern matching of the internal names for fields and the names of the fields in the form. The form of the plugin can be completed for several personas and upon usage the user can decide which persona is to be used.
Another plugin for the Firefox browser is called Sxipper [Sxipper]. Similar to Autofill Forms, the form filling functionality is based on predefined personas. Sxipper, however, does not try
86 to detect which field of the online form matches which field of the persona. To enable the automatic form filling on a particular site, one user (a so called 'trainer') has to provide his personal information into the form manually. Thereafter, Sxipper extracts the common fields of the form with the most appropriate persona of this user and then generates an assumed mapping. This mapping can subsequently be used by other users throughout the Internet to fill in the form automatically. In addition to the administration of personas, Sxipper offers password management functionality. The Firefox password manager is used as secure credential store. Also, Sxipper can handle OpenIDs which means that on an OpenID-enabled site the user will be presented her OpenIDs allowing for a login with a single click. The OpenID functionality is accompanied with phishing protection detecting unusual redirects whereupon the user will be warned. This plugin is free but not open source. It will be complemented with a commercial version which will have features such as a disposable e- mail which will not be available in the free version. The version as of April 2008 nonetheless contains the functionality of the commercial version as those functions are still in beta state.
Verisign's SeatBelt [SeatBelt] provides OpenID support which essentially means that it detects if a visited Web site is OpenID-enabled. If this is the case, the user is logged in automatically. There exists the possibility to change the OpenID with respect to which the login is executed using a menu button. SeatBelt provides phishing protection similar to Sxipper.
There are more plugins for simple form filling. InFormEnter [InFormEnter] adds clickable icons next to the form fields. Those icons allow choosing from the different contents that have actively been stored by the user before. As an example, the user can store his personal information by using the plugin. At any later point in time the same information is available by clicking the icon next to the field. This plugin is hardly an improvement of the autocomplete function provided by Firefox.
AutoFormer [AutoFormer] is a simple tool for saving form information entered into one page and make the form information reusable. The user selects to save the data entered into an online form. This data is then saved in a cookie and thus available at a later point in time. A severe drawback of this approach is that a restrictive handling of cookies also results in restrictions for the plugin.
9.2.2 Privacy Enhancement
While the above described extensions deal mostly with identity management and usability issues other extensions focus more on privacy enhancements. One such extension is CookieSafe [CookieSafe] which envisions a powerful yet simple management of cookies. The extension offers detailed control over the cookies which extends the capabilities that Firefox offers in this domain. As an example, a general cookie handling policy can be defined in addition to setting rules for each Web site individually. There exists even the possibility to change cookies which have been retrieved or to define cookies from scratch. A reduced set of functions is published as CS Lite [CS Lite] which has been newly designed. The CS Lite code is currently used to build the basis for the next version of CookieSafe. CookieSafe and CS Lite are published under the GNU General Public License.
Stealther [Stealther] is provided as freeware and allows the inhibition of traces that are left on a computer. This means that essentially all functions which allow retrieval of browsing behaviour are temporarily suspended. Examples of suspended functionalities are the browsing history, cookies, form filling information, sending referrer headers or cached data. In contrast to other tools this plugin does not effect any information which has been stored before the
87 activation of Stealther. After deactivation via a menu button, the data retrieval is reset to the default.
The functionality spectrum of DisTrust [DisTrust] is almost the same as the one of Stealther. Upon activation, DisTrust starts a session and records which actions the user is making. At the time of its deactivation, the plugin deletes the cookies set during the session, cleans up the history, cleans up the list of downloaded items and the respective items and deletes stored form information. In addition to those actions, the cache is disabled during such a DisTrust session. Clearly, the actions of the plugin can be adjusted to the personal preference using the options menu.
There are also plugins allowing for better usability of the functionality provided by TOR. One such plugin is called FoxTor [FoxTor] which enables the user to activate and deactivate TOR using toolbar. The latest version has been published in November 2006. The TOR project recommends the use of the Torbutton plugin [Torbutton] which also provides a button for enabling and disabling the usage of TOR for browsing. Unfortunately, the Torbutton plugin does not provide feedback upon failure of initiation of the TOR usage. Nonetheless, the plugin supports the anonymisation initiative of TOR by, e.g., stopping other plugins which might add identifying information, clear cookies, clear cache, spoofing the timezone and other local values or preventing identification using JavaScript- or CSS-techniques.
A simpler approach which leads to a certain anonymity when browsing the Web is the use of a proxy. All connections going through the proxy appear to be coming from one user which effectively hides all users among the users of the proxy. PhProxy - InBasic [PhProxy] makes use of such an approach. If a user wants to contact some server using the proxies defined in PhProxy, she simply prepends the address with PH:: which indicates the use of the proxy. As mentioned before, the benefit of such an approach is that all users of one proxy are anonymous where the anonymity set is all users of the respective proxy. Problematic is that the proxy can deanonymise the users which implies that the users trust their proxy.
A possible way of interfering with the privacy of a user is by analysing the behaviour. In particular, this is a promising approach for search engines to analyse the search queries of their users which leads to an identifiable person. This preceding is described for example in a New York Times article [AOL4417749]. TrackMeNot [TrackMeNot] tries to hide the queries of a user by sending randomised queries to the big search engines, namely AOL, Google, MSN and Yahoo!. While a first version of TrackMeNot used a static list to generate the queries, the most recent version issues queries based on actual queries issued by the user. The plugin tries to extract possible future queries based on those searches. The ideal behaviour would probably be different as the plugin should try to search for terms that are orthogonal to the user interest in order to best protect the user privacy.
Yet another way of threatening the privacy of a user is the use of HTTP referrer headers. Those headers can be used to signal where from a user reached a Web site. RefControl [RefControl] allows to control which site might send HTTP referrers and which sites are not allowed to do so.
9.2.3 Trust Enhancement
A plugin called Web Of Trust [WOT] takes a step in establishing a trust relation between a new user of a page and the page itself. The assumption is that all users knowing and using a Web site should rate the page. A user stumbling upon a Web site can see the trust ratings that this page has been given and, if the rating suggests, adapt the behaviour accordingly. A
88 principle idea behind this plugin is that 'a large enough crowd is improbable to lie'. Consequently, a user might mistrust the rating if only very few people have participated. A clear vote in favour of the trustworthiness of a page on the other hand is very probable to be a true statement. A user can make the confidence depenant on the confidence rating given by the plugin. In addition to the user rating there are lists of trustworthy sites used by the plugin. It is important to note that currently there are four topics which can be rated: the trustworthiness, the vendor reliability, the privacy and suitability for children. This plugin gets especially interesting when searching the Web using Google, MSN or Yahoo where small WOT icons are shown next to the search results.
9.2.4 Other Firefox Plugins
• BlockSite [BlockSite] allows to block specific sites. The blocking does affect links to the specified site as well as names entered directly into the address bar. To make it easier to block a range of sites, the plugin allows the use of wildcards. • BugMeNot is a site offering username / password combinations to certain sites. The BugMeNot [BugMeNot] plugin allows easy access to this service. A user presented a login screen can, subsequently, use the plugin to acquire a valid username/ password combination. Another functionality of BugMeNot is the offer of temporary e-mail accounts. These accounts can be given when creating an account in order not to provide the real e-mail address. Such a temporary e-mail inbox is also made available by another Firefox plugin called Temporary Inbox [Temporary Inbox]. Both services relieve the user of the hassle of providing personal information to each and every service in the Internet. • SafeCache [SafeCache] takes care of separating cache segments from each other. This hinders possible attacks that take advantage of reading or writing to cache that has been allocated by another Web site. This can lead to information exposition to an unauthorised Web site. The latest update of this plugin dates back to November 23, 2006.
Some additional plugins are really interesting, e.g., Roboform [Roboform], but they are not open source or free, so we do not describe them further here.
9.2.5 Opportunities for PrimeLife
The Firefox extension mechanism should definitely be considered by the PrimeLife project as it allows the implementation of powerful functionality. Additionally, very fast deployment can be achieved as there is a quite large community already using this browser. The rather large amount of open source code available is yet another argument in favor of producing Firefox plugins. Still there is an inherent limitation of such a plugin to Web-based services. 9.3 TOR
The TOR project [TOR] enables anonymous use of TCP-based services. The TOR software tunnels the user's data through a chain of encrypted tunnels that connect multiple intermediate relays. The protocol's design ensures that each node in the chain only knows its immediate neighbours, and (with the exception of the entry and exit nodes, respectively) can discover neither the origin, destination, nor content of the user's data stream.
89 The project's focus is on usability and easy installation. In terms of interfaces, the TOR client acts as a SOCKS proxy that can be used by most common TCP-based applications without additional modification.
While TOR does lead to anonymous communication that is protected against traffic analysis for a number of common attack scenarios, it does not by itself assist users in keeping personal information private that is passed through the anonymous data channel: Solving that issue is left to additional application-level software, such as Privoxy (see chapter 9).
Torbutton [Torbutton] is a Firefox plugin that enables users to control easily whether or not they wish to use TOR.
The TOR project runs under the auspices of a non-governmental organisation. Software development is performed by a number of project employees, contractors, and contributing volunteers. The software itself is available as open source under a BSD style license. 9.4 Privoxy
Privoxy [Privoxy Homepage] is a filtering tool implemented as a proxy. The HTTP stream passes through the filters and protocol or other information is stripped or altered based on normal matching procedures. Privoxy is based on Junkbuster, one of the first well-known filtering proxies. Junkbuster was developed in 1998 by Jason Catlett. Jason was one of the most prominent critics of P3P around 2001 and 2002. The junkbuster software has not been updated since 1998 according to Wikipedia [Wikipedia] and the Privoxy copyright notice [Privoxy]. Catlett moved on to develop Guidescope [Guidescope], an advertisement blocker. As of 08 April 2008, Guidescope recommends the Adblock Plus Firefox plugin [Adblock Firefox plugin].
Privoxy is still under development and available on all major platforms. It has a new architecture and is currently maintained by Fabian Keil and David Schmidt. All those tools are mainly targeted to block cookies, advertisement and defend against the abuse of pop-up windows.
Privoxy is suggested by TOR as an additional semantic filter. While TOR is making sure that the routers and the server do not see the origin of the request, privoxy can be configured to make sure that the content transferred does not reveal the identity of the users. But this requires a rather high level of knowledge about the techniques of Web sites to extract personal information from their users. Privoxy is the tool to stop it, if the user happens to know how the personal information is supposed to leak. It has no semantic ability to distinguish between sensitive information and non-sensitive information as it remains on a protocol-level string matching, which is useful.
PrimeLife may use privoxy on specific identified invasive techniques. This would require also the elaboration of complex rulesets to cope with the complexity of social network systems of today. As only preset complicated rules will have the desired effects, feedback to the user is important to avoid the experience of a magic blackbox that increases the feeling of powerlessness on the side of the user. The nature as a proxy has intrinsic limitations on the way feedback can be given to the user. Those limitations may hinder the establishment of the controls necessary to implement the goals of a data protection philosophy.
90 9.5 Invisible Internet Project (I2P)
The Invisible Internet Project [I2P] is an underlying network layer (actually several encryption layers) designed to work with Internet applications where anonymity and privacy can be considered as critical. It uses encrypted tunnels built between peers knows as garlic routers. The network of routers is based on an overlay architecture with cryptographic keys as identifiers. In consequence, the identity of both ends of a communication can be protected and the content of the communication itself is secure, while a regular proxy-based solution would protect only one end. Most TCP-based exchanges can be streamed into I2P tunnels. 9.6 Bandit
The goal of the Bandit project [Bandit] is to provide an open source framework for authentication, authorisation and auditing. To achieve this goals the project is destined to provide a simple access to identity stores, support diverse authentication systems, provide an interface role based system access and ease the achievement in common compliance of applications.
The Bandit project is composed of components taken from open source projects. The components are:
• OpenXDAS (Auditing) • CASA (Credential Store) • Bandit Common Identity/Higgins IdAS • Identity Selector Service (DigitalMe)
OpenXDAS is the auditing system that is used by Bandit. Compliance with corporate governance implies past and future compliance. Past compliance is ensured by searching the database for compliance deviations while future compliance can be analysed by looking at requests that are issued but not actually carried out. OpenXDAS is built upon the OpenGroups Distributed Auditing System (XDAS).
Common Authentication Services Adapter (CASA) is the infrastructure used to store the identity information. It also allows to administer and retrieve data from credentials or other secure data stored in kwallet, Firefox Password Manager, Gnome Keyring and SecretStore.
Identity information can be stored in many different ways. To be able to compare, query or authenticate several, possibly heterogeneous systems, there is a component extracting the identity information. The Bandit project used to call this component Identity Abstraction and renamed it to Common Identity Provider. The Bandit project contributes to the Higgins Identity Attribute Service (IdAS) and subsequently uses this service for the handling of disparate identity stores. The Common Identity component is maintained for backward compatibility.
The DigitalMe set of components allow for an interaction of the user with an InformationCard compatible service. Currently, this interaction occurs by accessing an InformationCard enabled service using the Web browser.
Opportunities for PrimeLife
91 The boundaries between the Bandit project and Higgins become more and more blurry. Bandit approached from a more enterprise-centered perspective where Higgins centered the user. Certain parts of Bandit, which are not (yet) integrated into the Higgins source, provide extra functionality in the domain of auditing and role based access control. Thus a combination of Bandit and Higgins could be considered useful in the project.
9.6.1 Development Framework
The Bandit project's development [Bandit Development] is mainly driven by Novell. Other contributers are ActivIdentity, Higgins, Liberty Alliance, Microsoft, Novacoast, Red Hat, Sun, Sxip, Symantec, and Trusted Network Technologies.
The Bandit project components are licensed under different licenses as they origin from different sources which determined their respective license. Concretely, this means that OpenXDAS is licensed under MIT license, the CASA under the GNU LGPL and the Identity Selector Service as well as the the Higgins IdAS under the EPL. 9.7 Concordia Project
The Concordia Project [Concordia] aims at driving interoperability between the different projects in the identity management domain. It issues definitions of real world scenarios and requirements for identity protocols which should encourage the solution of existing problems by the technology drivers. The solution of the given use cases requires the use of several identity protocols.
Development is ideally initiated by the description of a new problem. Thereafter the community discusses possible solutions using existing technology or possibly extending standards or their implementations. The most recent interoperability demonstration has been shown at the RSA conference 2008 where InformationCards have been used in a federated scenario as well as the combination of SAML and WS-Federation has been shown. Additionally there is much effort in documenting, thus solving, the problem of discovery of an identity provider.
The most recent meeting of the Concordia Project members has taken place at the Burton's Catalyst Conference where AOL, Boeing, General Motors and others have presented issues which have subsequently been discussed by the Concordia Project members.
The project has been initiated by the Liberty Alliance (see chapter 8) in June 2007 and is now run as an independent community which does not generate code. The documentation of use cases and proposed solutions are released under the Creative Commons License.
Opportunities for PrimeLife
Concordia is a very recent initiative which nonetheless has received remarkable interest at the RSA 2008 workshop. Interoperability will be a key factor when it comes to market adoption of the tools and frameworks resulting from PrimeLife. As such, the results from the Concordia Project Interop should be followed closely. Still, PrimeLife might rather join forces with one of the Projects which are already committing to the Concordia Interop.
92 9.8 Open-Source Identity System (OSIS)
The Open Source Information Systems (OSIS) [OSIS at Identity Commons] working group was created to intensify the work on interoperability between the different identity management projects. The declared goal is to align the arising protocols, projects and companies such that overlaps can be avoided and the resulting infrastructure is interoperable. The main focus currently lies in the interoperability between InformationCards and OpenIDs which shows that proprietary protocols and projects are considered as well as open source initiatives. The open source projects taken into account are Bandit, Heraldry (integrated into OpenID (see chapter 6)), Higgins (see chapter 7), OpenSSO, OpenXRI, Shibboleth and xmldap.
A list of OSIS Participants [OSIS Participants] is publicly available.
Opportunities for PrimeLife
If PrimeLife decides not to join forces with one of the current projects the participation in one of the interoperability initiatives would be necessary to allow for an improved market acceptance. It would even be desirable to develop interoperable prototypes.
9.8.1 Specification development
OSIS is an opportunity for developers to gather data considering the interoperability of their code with respect to other standards or implementations. Consequently, there is no specification development apart from the specification of the features to test [OSIS Feature Test].
9.8.2 Open Source Interoperability Workshops
The different projects developed various features which where tested for interoperability. The results of those interoperability tests are used to increase the quality of the respective project. The most recent identity interoperability conferences where the implementations were tested to discover the shortcommings of either the implementation of the respective standards were:
• I3a User-Centric Identity Interop at the 2nd European Identity Conference 2008 in Munich, April 22-25 2008 • I3 User-Centric Identity Interop through RSA 2008, RSA Conference, April 7-11 2008 • Catalyst Barcelona: October, 2007 • Catalyst San Francisco: June 27, 2007 • IIW 2007a Mountain View USA: May 2007 9.9 Pamela Project
The Pamela Project [Pamela Project] is a community driving the implementations of relying parties for InformationCards. Currently, an InformationCard supporting relying party plugin for Wordpress, Joomla and MediaWiki is developed and released under the BSD license. The project founders believe that an important reason for the slow market adoption of user-centric identity technology (i.e. InformationCards) is the lack of available implementations of relying parties. The project tries to help overcoming this problem.
93 Opportunities for PrimeLife
While providing open source relying parties which lowers the initial costs for developers of social networking technology is an important fragment to incite market adoption, this project does not offer many interfaces which allow for a connection to the PrimeLife project at this time. 9.10 OpenSSO
The OpenSSO [OpenSSO] project aims at the development of a simple yet effective single sign-on infrastructure for Web sites, which should allow for more secure electronic transactions, as users are no longer tempted to choose the same username/password pair for different sites. Identity federation is supported in addition to the single sign-on solution.
The OpenSSO project and the OpenFederation project are based on Sun's commercial products System Access Manager and System Federation Manager, respectively. Currently the following standards are implemented by the OpenSSO project:
• ID-FF v.1.1 and v.1.2 (including identity provider and service provider extended profiles) • ID-WSF v.1.0 and v.1.1 • SAML v.1.0 and v.1.1 • SAML v.2.0 (Operational modes: IdP and SP Complete)
There are plans for the implementation of ID-WSF v.2.0, WS-Federation Passive Requestor Profile and the Web Services Interoperability (WS-I) Basic Security Profile (BSP). The source is released under the Common Development and Distribution License (CDDL).
9.10.1 Architectural Overview
OpenSSO is a HTTP-based environment which provides an authentication service, a session service and a logging service to provide the functionality of authentication, maintenance of session information and building of an audit trail. Those services are shared among different instances which leads to a single-sign on solution for the respective applications. A naming service allows for addressing over different domains allowing an OpenSSO instance running on a Web server to discover another OpenSSO instance. This enables not only single-sign on scenarios but also identity federation by using an implemented standard such as SAML to exchange identity information.
In an example scenario, a user wants to use a resource at a service provider (SP). The OpenSSO aware SP will present an authentication interface to the user who, thereafter, provides the credentials. The authentication interface communicates with the authentication service. Upon successful authentication the session service is requested to issue a session cookie to the user. After this procedure the user is able to use the requested resource using the session cookie.
9.10.2 Opportunities for PrimeLife
OpenSSO is rather a single-sign on mechanism then an identity management scheme. While this functionality is very relevant for the user experience and therefore has to be considered
94 by PrimeLife, it is not sufficient. Consequently, a collaboration with this project might not be preferable for PrimeLife.
There are other approaches which aim in the same direction as OpenSSO. One such initiative is the OpenIAM [OpenIAM] project funded by Diamelle Technologies or the SourceID [OpenIAM] project sponsored by Ping Identity. OpenIAM simplifies user management, single sign-on, password management and the mantainance of an audit trail as well as it allows for role based access control, strong authentication or federation. The data consumed by OpenIAM is provided by an identity administration tool (e.g. Diamelle IDM system), however, to enable federation it supports SAML (1.1 and 2). The SourceID project releases open source relying parties which can be used together with the commercial server product sold by Ping Identity.
9.10.3 Open Source Implementations
• OpenSSO Source Code [OpenSSO Code] • OpenIAM Source Code [OpenIAM Code] • SourceID Toolkits [SourceID] 9.11 OAuth
The OAuth protocol [OAuth Core 1.0] is built on top of HTTP. It enables authority delegation on the Web: A user can authorise a third party (the Consumer) to access a Protected Resource (controlled by the Service Provider) in some useful way. Authoriation is revocable. The protocol design assumes a prior out-of-band agreement between Consumer (C) and Service Provider (SP) about data usage and certain protocol aspects.
An example scenario is authorising a location information hub to access a social travel site's information about the user's location: The location hub learns (from the user, or through a referral) about the URL of the user's travel profile. The user is redirected to the travel profile site, where he can determine what information (if any) is given to the location hub, and how long that authorisation should last. The authorisation information is passed back to the location hub, which can now process location information further. The user can revoke the authorisation without collaboration from the location hub's side.
Another example scenario is authorising an application (on the Web or locally) to fetch photos from a social photo sharing site.
9.11.1 Protocol flow
OAuth assumes that a consumer and a service provider have an advance agreement which manifests itself in an (opaque) consumer identifier known to both consumer and service provider, establishment of a signing mechanism and key material for that mechanism; requests from the consumer and the service provider are signed, and must be verified by the service provider.
The basic authentication flow consists of three steps: First, the consumer obtains an unauthorised request token from the service provider. In requesting this token through HTTP, the consumer can provide additional parameters to the service provider, which might influence the scope of the authorisation. The protocol provides a framework for passing these parameters, but does not define a vocabulary for them, as this aspect is deemed application-
95 specific. The service provider will return the token and a corresponding shared secret (plus, possibly, service-specific additional parameters) to the consumer. The initial request message is signed with the prearranged key; it includes the prearranged consumer identity, a possibly opaque string.
In the second step, the user authorises the request in an interaction with the service provider. This authorisation request is linked to the protocol's remaining steps through the request token, which may even be entered manually, enabling the user-facing parts of the protocol to be executed through referral methods other than HTTP redirects. (E.g., the authorisation step could be performed through text message on a mobile phone.)
During the authorisation step, the service provider will authenticate the user and be informed about the consumer identity and other pertinent information. When the user decision is communicated to the service provider through HTTP (and a callback URI was passed to the service provider beforehand), then the service provider will redirect the user browser back to the consumer; again, the request token is used to link the various requests. Otherwise, some other referral method might be used -- from contextual knowledge on the user side (the consumer displaying an appropriate message) to URIs in text messages.
The consumer now performs the third step of the protocol: exchanging the request token for an access token. To this end, the consumer sends a specific signed request to the service provider (through a direct HTTP request), which will (if the user had indeed authorised the consumer) respond with an access token and corresponding secret. The request includes the request token that had previously been used in interactions between the service provider, the consumer and the user; and the consumer opaque identifier. The service provider answers with the access token, a shared secret corresponding to that token, and any additional parameters.
The access token and corresponding secret are then used to generate authorisation tokens on subsequent requests for the protected resource from the consumer to the service provider (e.g., accessing the user location information from the travel site, or accessing a private photo for purposes of printing). The authorisation information can be passed through the HTTP authorisation header, as a POST parameter or as a query parameter on a GET request. The protocol does not impose any limitations on reuse of the access token; the life cycle of that token is determined by the service provider.
The protocol is implemented through simple HTTP-based transactions (including referrals around the user authorisation decision); to achieve confidentiality of transactions, TLS is used. Confidentiality of network transactions is particularly significant for interactions between consumers and service providers that establish tokens and corresponding secrets.
The authorisation tokens sent when the consumer accesses the protected resource are one- time tokens. They are, however, subject to an offline brute-force attack to recover the corresponding secrets.
9.11.2 Trust and privacy properties
The semantics of authorisations are out of scope for the protocol's definition: they are a matter of (out-of-band) negotiation between consumer and service provider, which are expected to share API definitions, and of human-readable interactions between the service provider and the user. Extension points in the protocol can be used to pass these semantics between the parties.
96 The user trust decision is made in a transaction with the service provider. The service provider is the source of the human-readable information about the scope of the authorisation. Information about the consumer identity is derived from a prior out-of-band interaction between the service provider and the consumer, so that the protocol only bears an opaque identifier (though implementations might choose a human-readable identifier) bound to a signature verification key known to the service provider.
Authorisation tokens can be revoked through an interaction between the user and the service provider. The consumer does not require knowledge of the user credentials with the service provider, and does not need to know the user identity with the service provider. In addition, the protected resource URI might be anonymous.
9.11.3 Specification development
OAuth [OAuth.NET] was developed by an ad-hoc group of contributors.
9.11.4 Open Source Implementations
A list of implementations [OAuth Code] is maintained by the OAuth project. 9.12 Noserub
Noserub [Noserub] aims at realising a decentralised social network. It is built of three things: the Identity-URL, the Profile and the Contacts. The Identity-URL currently is a Noserub-URL, which can be hosted at any server running Noserub. At the location where this URL points, there needs to be some meta-information which identifies the URL as a Noserub-URL. In the future it is envisioned that any URL could be used as an Identity-URL.
The metadata at the Identity-URL is composed of the profile and the contacts which can both either be embedded or referenced. It needs to be given in XFN/Microformat or FOAF where the Web accounts of this identity can be specified using a specific field in the FOAF or a field in a specific way in XFN. The contacts use the similar mechanism with XFN and FOAF to indicate that the URI refers to a contact. Noserub allows for a certain interoperability which means that a contact which no Noserub Identity-URL can be added and their accounts (e.g. at flickr, del.icio.us, ...) can still be monitored.
Opportunities for PrimeLife
The documentation of Noserub is not extensive so far, which makes it challenging to judge the project. It is obvious that the project does not implement any privacy features yet. However, this is claimed that it will be added at some point in the future. In this area, it is a challenging task to federate some formulated privacy requirements over the different services that are integrated into Noserub. The other difficulty is clearly to formulate the privacy requirements. Although the initiative of bringing different social networks together is valuable, from a privacy point of view it adds much complexity.
97 Chapter 10 Conclusion
The PRIME Project [PRIME] has implemented a prototype of a privacy-enhancing identity management systems (called integrated prototype) and, based on it, a number of application prototypes. Some of these components were made available as open source in the life time of the PRIME project and for some will be made available in the near future. This section reviews these components so that the PrimeLife project can evaluate which of these components are mature enough or should be extended and matured and then open sourced by the PrimeLife project.
This section also shortly discusses the different activities 1,2,4,5, and 6 of PrimeLife, what results these aim to produce, and their potential for open source or standardisation. 10.1 Results Available From PRIME
10.1.1 Privacy Ontologies
Within most PRIME components, the ontology is used as an unified framework to access the data storage of the different PRIME subcomponents. For example, Session information about a contact partner is stored and passed through the ontology. Some subcomponents e.g. the policy database and SPCC) use an legacy database or data storage back-end wired to the ontology for internal usage.
The design of the ontology system supports the linkage of a complete legacy database containing personal informations (e.g. a customers table in an SQL database) to the ontology framework. Static relationship and data type definitions specify the translation of the legacy data information to an pre-agreed PII data scheme, which is currently a slight extension of P3P data schema. However, this has not been implemented to the last extend within PRIME. The BluES'n application prototype implements such a legacy database, but the translation description is incomplete.
The design of the ontology also supports attaching data handling policies to exposed personal information, but the current implementation state lacks behind and this feature is currently not working completely in the PRIME code.
98 The PRIME privacy ontology provides a flexible and powerful framework to model personal information and information about privacy-relevant properties of that information using Semantic Web technologies.
Goals of the ontology developed in PRIME include:
• the ability to model arbitrary relational data schemata in a unified framework, based on RDF • the ability to model the relationship of such a data schema to an agreed ontology for personal information, such as the top levels of the P3P data schema • the ability to thereby phrase privacy and access control policies in broadly agreed terms, while preserving their automatic applicability to data processed and stored in business processes • the ability to model the relationships between information that anonymous credentials can provide, the information needed in authorization decisions, and personal information otherwise processed • the ability to model privacy requirements, attach them to the data that are being processed in a specific process, and to automatically verify whether privacy requirements have been fulfilled.
All of these abilities involve the dynamic processing of a relatively simple ontology framework, and of ontology components that model a specific application's needs and data schemata.
The PRIME ontology and reasoner constitute a prototype implementation of these ideas, scoped by the requirements and use cases within the project. They are, in particular, used in the processing of relevant policies, and in the retrieval and processing of personal information.
We expect that PrimeLife work on policy languages will take up lessons learned in the PRIME project work on ontologies, Semantic Web technologies and data modeling ideas.
The current way of accessing the ontology in PRIME heavily limits the flexibility of its design. For example, static structures modelled as Java classes are used to read out parts of the data, which prohibits to transfer dynamic relation graphs and so later prohibits reasoning on this data. It is planned to fix this within the PrimeLife project.
However, additional resources to enhance the reasoning capabilities of PRIME are not explicitely assigned in PrimeLife. In PrimeLife, work on ontologies is not an explicit work item specified in the work plan, but ontology work might greatly benefit the work to be done in various areas of PrimeLife, e.g., policies, identity federation, and trusted content. Details on further elaboration of ontologies are not decided on yet.
10.1.2 The JRC Policy Workbench
The JRC Policy Workbench [JRC Policy API] is an API for building policy editing and testing environments, which includes an implementation of an editor for P3P 1.1 and P3P 1.0 policies.
During the P3P 1.0 development IBM developed a policy editor. People in the W3C P3P Working Group had realised that writing down the XML source code was an option only for professional privacy providers. There were just too many options. IBM developed the editor
99 until compliance with P3P 1.0. But the further work on P3P 1.1, which was especially addressing the challenges of the interface with the user, was not implemented anymore.
In the PRIME project, the policies and mechanisms used were even more complicated and complex than the basic P3P expressions. It quickly became clear that a policy editor would be a good idea as a proof of concept as it would force to think through the main possibilities of the language developed by PRIME.
The JRC Workbench actually is not only a fully compliant P3P 1.1 editor, but it also exposes its APIs in a way to allow the easy integration of other policy languages. This will allow for the easy creation of editors for newer languages with richer semantics.
The user interface remains a challenge as the display of all options at all times would just confuse users and bloat the interface into an unusable option-soup. So the guidance of the user in the right direction allows to define a certain path a user has to go through.
The JRC Policy Workbench is a tool for service providers. If PrimeLife wants to have a real world impact, it will have to make the implementation of service side components easy. The JRC Workbench is the only tool around being capable of serving as a good basis for further development.
10.1.3 Policy Language
PRIME results on policy languages are discussed in depth in PRIME Policy Languages (see chapter 4).
10.1.4 SendPersonalData dialog
The SendPersonalData dialog, also known as AskSendData dialog is the component asking the user for selecting and confirming data sent between the local PRIME instance on the client and the PRIME instance on the Web server side.
It is an Java application opened by the local PRIME instance when the interceptor plugin (see chapter 10) calls the Web service accessRemoteResource.
The purpose of the SendPersonalData dialog is to give the user an informed consent about privacy circumstances, to query for PII data to expose to the server and for on-the-fly management of personal information.
The dialog communicate with the local PRIME instance through two Web service interfaces, the so called common and restricted. The documentation of these interfaces are contained in the source code documentation of PRIME (classes CommonMediatorService and RestrictedMediatorService).
The current architecture of PRIME allows to plug in any implementation of an SendPersonalData dialog and is not restricted to the current default implementation. However, only this does support all features available of the PRIME toolbox (e.g. PrivPrefs, Credentials, SPCC, Assurance Control Blacklists).
The minimum interface that a SendPersonalData dialog has to implement to be supported by PRIME is to:
100 • call the Web service listSession to obtain the suggested Claim information • choose one of the suggested Claims or choose not to send data at all.
Additional functions are provided in the restricted Web service to e.g. build a new Claim out of PII information from the local PRIME instance's database. As of current implementation, to use this extended features of creating an own Claim from PII information, the dialog has to be written in Java and has to be called within the process space of the local PRIME instance. It is planned to extend this in PRIME extension to enable non-Java SendPersonalData dialogs which can create own Claims.
It has to be decided which of the prototypes developed in Activity 1 will use and extend the current SendPersonalDialog and which will use an other dialog replacing the current one. User interface extensions and research about HCI (Activity 4) will be built into this SendPersonalData dialog.
There exists other implementations of the SendPersonalData dialog in some application prototypes similar to PRIME BluES'n (see chapter 10). The effort to replace the current dialog by other simple PII selection dialogs like Higgins [Higgins] is moderate. However, the more advanced features like AssuranceControl or the PrivPref management is very specific to PRIME, thus these features could only be reused with much effort in other open source software.
Using the SendPersonalData dialog as an open source project separated from PRIME is only possible if the local PRIME instance Web services are implemented (much like for the Console plugin (see chapter 10)). Other than the console, the HCI design of the dialog is based on research results from within the PRIME project and represents a final HCI prototype. So, decoupling the SendPersonalData dialog from PRIME could be advisable, if the usage in a separate open source project is targeted.
10.1.5 Firefox plugins
The PRIME project's results include three different Firefox plugins. All plugins are briefly introduced, and their possible usage in PrimeLife and their relation to existing open source programs are discussed.
Interceptor
The interceptor is the smallest and simplest Firefox extension provided by PRIME. It listen for incoming and outgoing HTTP connections from the Web browser and inserts or interprets special PRIME http headers to communicate with the local PRIME instance. The headers intercepted are:
• All incoming Web sites are scanned for an HTTP-Header named X-PRIME-Handle and X-PRIME. If both are found, the Web service accessRemoteResource on the local PRIME instance is called, passing both header fields as parameter. The return value of the Web service call is stored temporary. • All outgoing Web site requests are inspected and if they point to a site, where previously an session id was sent, the previously stored return value of accessRemoteResource is inserted as X-PRIME-Handle.
The overall code base of the interceptor is about 250 lines of JavaScript code (including comments).
101 There may be some minor modifications necessary to make it possible to call other PRIME client functionality than accessRemoteResource, as example to trigger the fetching of credentials or to open configuration dialogs etc.
The interceptor could be replaced by direct P2P communication frameworks based on Web browsers JavaScript to enable the PRIME server to communicate directly with the PRIME client as long as the browser has the Web server site open. One example is JXTA [JXTA]. This would require changes in the PRIME core as well.
However, as the interceptor is currently really low in complexity, additional advantages of the used framework should be evaluated before introducing complexity.
About the possibility to use the Interceptor as another open source project: The interceptor is very specific tight to the needs of PRIME and it makes no sense to make an open source project out of this component alone. It could be evolved into an generic framework for callback communication from Web server sites, but this would almost be the same effort as writing an new one.
Console
The current user interfaces for managing personal information (PII) used in PRIME is implemented as a Firefox extension called PRIME console. The main component is the information window for showing and editing the PII. Another component shows the DataTrack (see chapter 10).
Most of the implementation is still in beta state and some parts are non-functional. The JavaScript implementation of the console is considered only a prototype of the human- computer interface and was never meant to be the final version.
Plans exist to enhance the user interface and layouts and prototypes will be provided by WP4.4. In this progress, it is planned to reimplement the user interface in Java (there was a former Java prototype, but this rewrite does not make use of it), because of easier implementation of more advanced graphical interactions. The SendPersonalData (see chapter 10) dialog has already been ported back to Java within the scope of PRIME and the DataTrack (see chapter 10) (which is currently part of the JavaScript-Console plugin) will probably also be ported to Java within the PRIME extension.
There exists new requirements to the user interface coming from A1 and designed in WP4.4, but which are not completely available yet. These would be integrated into the Java version of the user interface. The extensions will extend the interaction possibilities of the user with the data in the local PRIME instance.
Lots of single-sign-on solutions exists with simple user interfaces for managing personal information (OpenID, SXIP). Also, some Web browser like Opera have personal data dialogs already included for sending information through Web forms. Other applications provide address book functionality, where the user can edit several personal identities and later on (e.g. in the context of sending an Email) choose from one of these (Thunderbird, KAddressbook, Evolution). These tools provide usually only one identity (or a simple enumeration of a few identities) with a static set of categories. It is imaginable to include display possibilities of PII's from PRIME in those interfaces. However, some prototypes of A1 require more sophisticated management of PII than these tools provide.
102 More complex solutions to personal information management user interfaces include Microsoft CardSpace (see chapter 7) (which is not open source) and Higgins (see chapter 7). Higgins, being an open source environment, could probably be enhanced such that it carries out PII management as desired by PrimeLife. However, a close inspection is necessary to decide if such enhancements are possible in the time frame of PrimeLife.
There are plans in PRIME to access the MS CardSpace (see chapter 7) API with the current PRIME user interface as well as use the CardSpace (see chapter 7) interface to access PRIME enabled Web sites (only plans - AFAIK no delivery covers this). However, CardSpace (see chapter 7) does not support some features of PRIME as purpose binding, has only limited data track and no "transfer to third parties" - policy (this isn't implemented in PRIME yet either). Thus, if PrimeLife uses PRIME as a tool library, it is considered not easy possible to fully replace the console with an existing open source alternative, but only extend existing products to additional include parts of the console functionality.
Furthermore, the console functionality is specialised to the needs of the data model and PII model of PRIME, so if it were used outside of PRIME as an own open source product, this would limit its usage. From a technical point of view, extraction is as easy as implementing all required Web services that the console needs. Currently, there are about 15 Web services providing mostly CRUD-functionality on several data types, but within PrimeLife this will extend to more sophisticated interfaces (including providing search functions or the intelligent suggestion functions of PRIME). Although the Console could be used outside of the PRIME toolbox, the development of the new Java console would probably always be forked from the main development in order to support the very customised requirements of the PRIME PII model.
Formfiller
The PRIME firefox extension named "Formfiller" is an attempt to provide typical form filler functionality with the PRIME as PII data source. This way, other PRIME features like the DataTrack (see chapter 0) and SendPersonalData (see chapter 10) dialog can be used to fill in Web forms. As of IPv3, the plugin no longer works.
As far as we know, the form filler functionality is not explicitly requested in PrimeLife's prototypes. Providing a form filler functionality can be interesting for real user acceptance of other prototype functionalities. There exist several plugins and form filler systems for Web browsers, e.g. RoboForm [Roboform], AutoForm or SignupShield. Even more single sign-on or keystore solutions are available: PasswordSafe, Kesto [KESTO] and many others. It is advisable to use an existing open source form filler instead of fixing the existing one, should the functionality be needed in PrimeLife.
As the form filler is only an interface to call the SendPersonalData (see chapter 10) dialog, it cannot be used separately from PRIME. The user interface is restricted to only one combination box, so reusing interface design is not possible either.
10.1.6 DataTrack
The DataTrack is a tool integrated into the PRIME Console to display information about released information. It is currently written in JavaScript using XUL as the GUI language. It uses a Web service provided by the PRIME client core to obtain information about transactions and past service partners of the user and shows them in different ways.
103 The main view is a graphical slider that zooms through the history of data sent to other parties, showing the revealed information in a card-like fashion. The data is obtained via a Web service from the PRIME client core. Other views show a table of all information sent through PRIME to any contact.
In its current state the DataTrack uses XUL RDF queries to obtain the data presented by the mediator Web service. However, as long as the data is presented in a similar manner, presumably there is no reason why the RDF source could not be replaced by any other source with minimal change in the code base. The implementation relies heavy on Gecko DOM calls and most content is constructed dynamically. Because of this some code part could be considered quite complex for coders that are unfamiliar with the DOM coding paradigms. Currently the DataTrack implements all showing views as well as the possibility to do a free text search. It also displays a full contact information window when a receiver is double clicked in any view. However, the date search and the other search categories are not fully implemented in all views. The correct, delete and info functionalities of the current version of the DataTrack will only produce a placeholder e-mail with the subject and the contact e-mail of the receiver. These values are currently constants but if contact information is available in the database it is not difficult to make them variable based on this information. The XUL/ JavaScript incarnation of the DataTrack is an indivisible unity but it is our belief that the different components of the JAVA incarnation (see below) could be used to display and handle personal as pluggable classes in other JAVA applications.
The DataTrack is currently being ported to JAVA and a port with at least the functionality of the current IPv3 version will be available at the end of IPv3x. After this the transparency functionality (i.e correct, remove and inform on personal data) will be implemented in a service per service fashion for the first step in the 2.2.1 Transparency part of WP2.2. Together with WP4.4 of PrimeLife, the user interface will be evaluated. Feedback will be integrated into the DataTrack and is used for the prototypes of WP1.2 and WP1.3
The functionality of the DataTrack would be fit well in the Higgins (see chapter 7) project. Working towards common interfaces supported by Higgins like WS-* would be advisable. It could be of further evaluation, whether existing products like iJournal from MozPETs suite, Higgins User Interface or the "Enhanced History Manager [EnhancedHistory]" plugin for Firefox could be enhanced to support the full feature spectrum planned for the Data Track within PrimeLife.
10.1.7 Privacy Policy Decision Engine
PRIME Access Control Decision Function (ACDF)
The PRIME Access Control Decision Function (ACDF) component is responsible for taking an access decision for all access requests directed to data/services. ACDF produces the final response possibly combining the access decisions coming from the evaluation of different policies (both access control/release and data handling). The elements relevant to the decision are applicable policies, context which contains the information associated with the requester during a session, and subject, action, object, and purpose of the access request. The decision component can return three different decisions:
• Yes: the request can be granted; • No: the request must be denied;
104 • Undefined: current information is not sufficient to determine whether the request can be granted or denied. In this case, additional information is needed and the counterpart will be asked to provide such an information.
ACDF mainly interacts with others two components: the Request Context module and the Policy Management (PM). The Request Context module keeps track of all contextual information, combines information from various context sources and deducts new contextual information from this aggregation. The main tasks of the Request Context module is to provide contextual information from various sources in a standardised way, and to provide reasoning functionalities for boosting the evaluation process (i.e., integration with ontology). The Policy Management component manages, stores, and distributes the policies to be used in the access control evaluation process. The ACDF communicates directly with the Policy Management for retrieving all the policies applicable to an access request. One of the most important functionalities of ACDF is to provide an infrastructure that combines the evaluation of access control, release and data handling policies. Given an access request of the form
• In the first step, the access request is evaluated against the applicable access control (or release) policies collected from the Policy Management component. Note that, if no policy is selected the access is denied (i.e., the default access decision is deny- all). The actual implementation is based on policies specified in a Disjunctive Normal Form (DNF), meaning that rules inside the policies are ORed and conditions inside the rules are ANDed. After collecting all applicable policies, each policy is evaluated inserting the policy conditions in a Reverse Polish Notation (RPN) stack that is used to perform the evaluation. At the end of the policies evaluation, the system combines the single policies result to reach a yes, no, or undefined access decision. In case of a negative (no) access decision, the access request is denied, and the process terminates. In case of an 'undefined' access decision, the information submitted by the requester is insufficient to determine whether the request can be granted or denied. Additional information is required by communicating filtered queries to the requester. Such requests are called claim requests. It is important to highlight that, a claim request could contain sensitive information. In this case, a sanitisation process can be performed before the claim request is sent to the counterpart, to avoid the release of sensitive information related to the policy itself. In case of a positive (yes) access decision, the access request evaluation continues and the ACDF has to verify whether there are some restrictions on the secondary use of the requested target. • In the second step, the ACDF retrieves all data handling policies attached to the target of the request. If no data handling policy is applicable to the request, this step is skipped and the access is granted. Otherwise, applicable data handling rules are retrieved and evaluated.
A privacy-aware access control system prototype
A Java-based prototype of the ACDF that is part of the privacy-aware access control system has been developed in the context of the European PRIME project. The ACDF component takes an access decision for all access requests directed to data/services, by evaluating all the policies applicable to the requests. The ACDF has been designed to be thread-safe and then its implementation supports the execution of multiple ACDF instances running at the same time, without any interaction among them. After receiving the access request, the ACDF:
105 • retrieves the access control (release, resp.) policies by querying the Policy Management; • evaluates the access control (release, resp.) policies by using a Reverse Polish Notation (RPN) stack, and takes an access decision; • collects the Data Handling Policies (DHPs) attached to the target of the request; • evaluates the DHPs by using a Reverse Polish Notation (RPN) stack, and takes a decision; • composes the different evaluations to generate a single access decision.
The mechanism used to evaluate the different types of policies (i.e., access/release and data handling policies) is the same and relies on a Reverse Polish Notation (RPN) stack. The RPN stack-based evaluation has the main advantages of being very fast and of making independent the evaluation process from policy syntax and semantics. The translation from each policy language (both access/release and data handling languages) to the RPN format is made by the specific implementation of a policy loader. In particular, two different classes interpret the syntax of DHPs and the syntax of access/release policies. In this way, it is possible to add new policy languages by adding the specific loading class, with a minimal impact on current implementation. To conclude, it is important to remark that ACDF supports conditions to be evaluated both on certified data, issued and signed by authorities trusted for making the statement, and uncertified data, signed by the data owner itself. The declared and certified information relevant to an evaluation process is retrieved from the Request Context module.
The Access Control Architecture is based on the traditional PEP-PDP-PAP infrastructure described in the XACML proposal. The ACDF has the same role and responsibilities of the XACML’s PDP.
The ACDF evaluation infrastructure has been developed to be flexible, extendible, reusable, and to support different access control models and languages that can be integrated with small coding effort. While the ACDF and Higgins address different problems, controlling access and managing identities, respectively, they are therefore based on a similar paradigm: the use of an abstraction layer to unify different solutions. The ACDF has the following three main extension points.
• Policy Loader. Multiple policy loaders can be added to allow the evaluation of languages based on policy syntax different from the ones used in PRIME project. It is possible to evaluate new policy languages by adding the specific loading class, with a minimal impact on current implementation. • RPN Stack Element Loader. RPN Stack Elements are predicates that model policy components and mechanisms to combine policy conditions. RPN Stack Element can be extended, changed (if their semantic changes), and deleted. • Predicate Manager. ACDF manages several pre-defined predicates, which are used to define conditions in the policies. The ACDF infrastructure is designed to support nonstandard predicates defined a posteriori with a minimal impact on the evaluation engine.
To conclude, in the context of open source and standards, the main possible contribution that current ACDF implementation can provide is a stable and flexible evaluation infrastructure that can be easily extended to cope and integrate different languages and models with a limited effort and changes to the evaluation engine. In particular, focusing on open source, the heterogeneity (in terms of diverse background and skill of the contributors) and the vitality of the community should foster the definition and development of many policy plug-ins to create adapter allowing the ACDF to evaluate several policy specifications, while keeping the complexity low.
106 10.1.8 BluES'n
BluES is an online collaboration system which includes many components (e.g. chat, mailforum, calendar, content creation and presentation …) BluES'n is the privacy enhanced version of BluES, which is extended with functionality coming from PRIME. Additionally there is an integrated pID management, reputation management and some awareness features.
BluES'n will not be developed actively in PrimeLife, as we will focus on another prototype. However, we can learn from concepts and design criterias made in BluES'n.
Especially while designing the collaborative workspace demonstrator in WP 1.2, we should have the BluES'n concepts in mind, namely the group and privacy awareness features (info center), the contexts/Decision Suggestion Module and the Pseudonym-Alias-Mapping. Furthermore, BluES'n uses the transaction concept in place of sessions. This way, it facilitates the concept of unlinkability (which is a principle of privacy: start from maximum privacy).
10.1.9 PRIME Policy Manager
The PRIME Policy Management (PM) component manages the overall policy life cycle by providing functionalities for administering policies. It is also the component that interacts with the Access Control (AC) and the Identity Management (IDM) modules for filtering responses coming from AC to IDM and for restricting the release of sensitive information related to the policy itself or to the status against which the policy has been evaluated. The definition of sensitive information and sanitisation operations are issues managed in cooperation with the AC module. The Policy Management component addresses the following requirements:
• it provides operations for policy administration, such as search, store, update, check, and delete; • it provides functions for searching policies applicable to a certain request; • it provides filtering functions that restrict the release of sensitive information related to the policies, when additional requests have to be generated from the AC; • it provides policies storage.
The PM component is composed by the Policy Presentation (Ppres) and the Policy Processing (Pproc) components. The Policy Presentation component acts as a policy presentation interface. It receives as input an access request and it returns as output all the applicable policies. Ppres is used by the ACDF to take an access decision. Note that Ppres interacts directly with the Policy Repository to retrieve policies. The Policy Processing component provides filtering functionalities on the response that the AC module returns to the counterparts. This avoids the release of sensitive information related to the policy itself. For instance, suppose that the response returned by the access control is equal(citizenship,'EU'). The PM could decide to return to the user the response as it is, or otherwise it could modify (sanitise) the response by requesting the user to declare its nationality (e.g., 'give me your citizenship'). This way, the fact that the access is restricted to EU citizens is not disclosed. The filtered information is called sanitised information. The definition of sensitive information and sanitisation operations are issues managed in cooperation with the AC module. Finally, the Policy Repository (PR) module provides policies storage and search functionalities. The PR is based on the relational database concept and it is designed to be independent from the real storage infrastructure. The PR provides a fine-grained query infrastructure, based on policy constraints (i.e., object, multiple actions, subject, and so on). An Abstraction Layer hides low-level details and isolates the PR from the outside. By default,
107 the PR works in an asynchronous way, allowing concurrent access to the data. Each request to the PR is filtered by the Abstraction Layer, and this implies that the Abstraction Layer unifies the interfaces to the PR module.
The PM component provides functionalities for policies administration. However, considering a privacy-aware access control, the PM component accomplishes two main tasks: i) it provides a searching engine to retrieve applicable policies to a given request, and ii) it provides sanitisation functionality. The policy search engine is based on an Abstraction Layer that provides generic interfaces for accessing the PR module. The Abstraction Layer is designed to support multi-threading access to the physical policies storage. The multi-thread supported in PR is based on the Simple Concurrent Object Oriented Programming (SCOOP) model, where the concept of thread is extended to the concept of active object. To support the SCOOP model, the PR module is designed as a singleton Consumer. The Singleton pattern ensures that a class has only one instance and provides a global point of access to that instance. The PR then runs in a separate thread and waits asynchronously for the requests that a set of Producers insert in the PR’s requests queue. Each Producer registers a callback method within the request. Finally, the PR processes the requests one-by-one, and the results are returned to the original requesters. The PR has been designed to support different kinds of repositories. In the current implementation, two different storages are supported:
• MySQL: it represents the world’s most popular open source database because of its consistent fast performance, high reliability and ease of use. • HSQLDB: it is a leading SQL relational database engine written in Java. It has a JDBC driver and supports a rich subset of ANSI-92 SQL plus SQL 99 and 2003 enhancements. It offers a small, fast database engine which gives both in-memory and disk-based tables and supports embedded and server modes.
New storages can be added, if necessary, by implementing a single interface. This interface works as a Facade class on the physical storage, assuring the following basic functionalities: policy addition, policy update, policy deletion, and policy searching. Focusing on sanitisation, the PM gives a thread-safe process, which provides filtering functionalities on the response to be returned to the counterpart to avoid release of sensitive information related to the policy itself. In particular, it cleans the condition to be returned to the counterpart as the access response, according to three possible levels of sanitisation: i) strong sanitisation means that a full sanitised condition is generated (e.g., rather than returning original condition 'equal(user.Name.Given,'Alice')' as it is, a request for declaring user.Name.Given is returned); ii) weak sanitisation means that a partial sanitised condition is returned (e.g., rather than returning original condition 'greater_than(user.Age,18)' as it is, a request for declaring user.Age together with the applied operator is returned); iii) no sanitisation means that the full, un-sanitised condition is returned (e.g., 'equal(user.Citizenship,'Italy')' is sent to the counterpart without changes).
The PM has the same role and responsibilities of XACML’s PAP.
10.1.10 Obligation Manager
The Obligation Management System (OMS) aims at providing privacy-aware identity life cycle management capabilities to organisations that collect and process PII data. By automating the management of obligation policies, the OMS system ensures that expectations, duties and personal preferences on how to handle personal data (including PII data retention, deletion, data transformation, notifications, etc.) are fulfilled by organisations. This is
108 achieved by explicitly representing privacy obligations in an extentible format, automatically scheduling and enforcing them and monitoring for their compliance
The PRIME Obligation Management System was implemented by PRIME partner HP labs. They are currently planning to release this code.
10.1.11 Identity Mixer
The IBM identity mixer [Idemix] system developed IBM's Zurich Research Laboratory is an implementation of the Camenisch-Lysyanskaya anonymous credential system. A credential system consists of users and organisations. Organisations know the users only by pseudonyms. Different pseudonyms of the same user cannot be linked. Yet, an organisation can issue a credential to a pseudonym and the corresponding user can prove possession of this credential to another organisation (who knows this user by a different pseudonym) without revealing anything more than the fact that such a credential is in this user's possession. Credentials can be set for unlimited use (these are called multiple-show credentials) and for one-time use (these are called one-show credentials). Possession of a multiple-show credential can be demonstrated an arbitrary number of times; these demonstrations cannot be linked to each other.
Apart from the pure cryptographic operations of the Camenisch-Lysyanskaya credential system, Identity Mixer also implements the high-level protocols and policies to deal with credentials (issue and presentation) as well as user interfaces to select credentials upon a request for information. The first version of the Identity Mixer software was developed by IBM Research about 6 years ago and has been subject to continuous improvement ever since, in particular in the context of the PRIME project. All parts of Identity Mixer except for the cryptographic operations have been made available as open source under the within the framework of the Higgins project. The cryptographic parts are expected to be available shortly.
Anonymous credentials are a core element to enable privacy enhancing identity management. The Identity Mixer system will be maintained and extended through the PrimeLife project. While contributing Identity Mixer to the open source community is an ongoing effort, not many aspects of it (nor anonymous credential in general) have been standardised. Relevant aspects include token formats, wire formats, cryptographic algorithms, claim languages, API for a credential system, etc. 10.2 Results Expected from PrimeLife
PrimeLife has just started and therefore we have only just started to define the details of the results that we aim to achieve by the end of the project. Thus, we can at this point only give a rough idea of the planned results and their suitability for standardisation and for contributions to open source bodies, which we do below.
10.2.1 Activity 1 - Privacy Life
This activity's goal is to supply privacy-enabled identity management for the whole life of people. To this end, the activity will building research prototypes for the following real-life scenarios:
109 • Trusted Content: Supporting at least some user-centric control over a user’s personal data in situations where she wants to share personal information with several other people. • Selective Access Control in Social Networks: Adapting the user-centric privacy- enhancing identity management of bi- or at most trilateral settings to new technological as well as business settings. • Managing identity, trust and privacy throughout life: Sustainable Privacy and Identity Management from birth to death.
A focus will be to formulate appropriate use cases and scenarios, condense them into requirements, build an appropriate prototype which concentrates on the relevant aspects (otherwise both expenses as well as complexity explodes), learn the relevant lessons from building, using, and evaluating the prototype, without being stuck in what is irrelevant detail and shortcomings in the prototype.
While we will make these prototypes open source when possible and feasible, we do not expect that the outcomes of this activity will reach a suitable maturity level for standardisation.
10.2.2 Activity 2 - Mechanisms
The objective of Activity 2 is to perform basic research addressing the complex tool-related problems of guaranteeing privacy and trust in the electronic society. The results of the activity will be research findings advancing the state of the art of current technologies and solutions. Proof-of-concepts prototypes implementing novel techniques will also be developed, therefore producing tools that can be used by other activities or even be made available publicly.
The development of privacy-enhancing mechanisms and techniques will in particular focus on the following key problems:
• Development of cryptographic solutions for protecting users’ credentials, identity management transactions; This includes various extensions of anonymous credential that will potentially be implemented as part of the Identity Mixer as well as mechanisms to store credentials securely. • Development of metrics for expressing privacy compliance, trust and utility of released data; • Identification of privacy threats due to re-identification and correlation in data collection and of means to assess protection/exposure against them; • Definition of novel approaches for empowering the users, enabling them to acquire control over accesses and uses of their own data.
The results of this activity will influence the work of Activity 5 in terms of requirements and/ or new policy mechanisms. We expect that a number of mechanisms produced by this activity can be made available as open source and that some of them will be relevant to standardisation bodies (either directly or in conjunction of the results' use in other activities).
10.2.3 Activity 4 - User Interfaces
Privacy-enhancing identity management will only be successful if its technologies are accepted and employed by the end users. For this reason, the research and development of user interfaces for PrimeLife technologies that are user-friendly and compliant with
110 regulations will play a key role. The activity will work on UI Representation of privacy- enhancing identity management concepts, for trust and assurance as well as for for policy display and administration.
In particular, The protocols between the user side online functions for exercising user rights and the services sides' transparency support tools that respond to them need to be standardised. PrimeLife Partner KAU has already brought this up at the ISO/IEC JTC 1/SC 27/WG 5 meetings. The transparency tools that will be developed can also be provided as open source.
Besides, we have derived in PRIME a set of predefined privacy preferences, which a user could choose from and fill in with concrete data values or customise "on the fly" and store them under a new name. The predefined privacy preferences describe what types of data should be released for specific purposes under specific conditions and the type of pseudonymity and level of linkability to be used. This set also includes the most privacy- friendly options for acting anonymously or for releasing as little information as needed for a certain service. Such a set of predefined privacy preferences as well as mechanisms for customising them on-the-fly (i.e. when they are used in interactions with services sides) could be standardised and provided to our open source products.
Furthermore, the multi-layered structures of privacy policies as suggested by the Art. 29 WP working party in combination with mechanisms for obtaining informed consent for the disclosure of personal data/ proofs with credentials could be standardised. In task 4.3.2, we also mention in particular that the multi-layered structure for presenting policies could be extended by another top level consisting of standardised policy icons.
10.2.4 Activity 5 - Policies
The goal of Activity 5 is to design security and privacy policy systems for PrimeLife. This includes analysis and formalisation of legal requirements, research into new policy mechanisms, machine-readable languages for privacy as well as design & analysis of actual policy decision engines for the demonstrators that we build. Activity 5 is structured in 3 Work Packages focusing on requirements, research aspects and development of policy systems.
Today, privacy policies have largely focused on formalising permitted usage of personal data. They were often based on a central model where an administrator defined a single policy that covered given data items. The policy activity faces multiple research challenges besides satisfying the:
• Broader coverage: Privacy requirements cover more than mere access to information. Examples include retention of data or combination of data items. The goal is to cover the complete life-cycle of identities. • Policy Composition: In the emerging Web, data and policy will be composed. We need to find ways to enable distributed management and authoring of policies. • Stronger Enforcement: Today, privacy policies are mainly enforced by means of access control monitors. One challenge we face is to invent additional enforcement mechanisms that allow protection despite the dispersion of data and the limited trust in the processor of personal information.
We expect that a number of the results of this activity will be suitable for making them available as open source and also to influence standardisation bodies: On the one hand, we
111 can build upon work done in the PRIME project. On the other hand, we aim to base upon and to extend existing standards as much as possible to achieve the best impact.
10.2.5 Activity 6 - Infrastructures
The goal of Activity 6 is to investigate the impact of security and privacy requirements on infrastructures. It studies technical and non-technical (e.g. legal, economic) requirements for successfully implementing solutions on top of existing and newly developed infrastructural elements. In particular, its work packages are concerned with:
• Privacy-preserving identity management for service architectures and general issues of identity management infrastructures, with a special focus on web architectures, web service architectures, and related architectures. • Trusted Infrastructure elements using trusted devices as an infrastructure foundation. This includes smart cards, TPMs, and similar solutions. • Privacy-enabled service composition.
We expect that this activity to produce results that are relevant for standards regarding infrastructures and interoperability, in particular for Work Packages 6.1 and 6.3. As the activity will also do some implementation, contributions to open source are feasible. 10.3 Perspectives
Our analysis shows a number of initiatives world-wide. Not every existing initiative is shown, but only those with a certain relevance to the undertaking of PrimeLife. The broad variety of different genres, architectures and infrastructures complicates our task. Some technologies are already standardised, others are just open source projects without an open specification attached to it. Some technologies are old well established standards for a given usage and context. PrimeLife has to find out whether they are usable in the context of the project. Some of the technologies mentioned did not fully succeed in the market. PrimeLife has to analyze what factors contributed to these effects, in order to prevent obstacles for dissemination of the projects' results. By design, this report gives only an initial overview, it draws a certain landscape of opportunities for PrimeLife. This report also confirms the conclusions from the W3C Workshop on Languages for Privacy Policy Negotiation and Semantics-Driven Enforcement [W3C Privacy Workshop] that was initiated and very prominently supported by the PRIME Project [PRIME]: While there is a large number of standards and open source projects producing relevant technology for PrimeLife, the coordination between them is insufficient. This issue falls in the scope of PrimeLife. It is taking over the coordination task from the PRIME project, that lead to the creation of the W3C Policy and Languages Interest Group (PLING) [PLING]. A well-established community can also provide for PrimeLife a much smoother path to the dissemination of its results into the initiatives found in this report. PLING will allow PrimeLife to benefit from the multiple liaisons already established, from the coordination power of a well-recognised W3C Working Group, thus sparing the cost of creation of such a platform.
Obviously there are privacy standardisation issues besides Policy and Languages, so the PrimeLife descision to establish a Liaison with ISO/IEC JTC 1/SC 27/WG 5 [JCT1SC27] on “Identity Management and Privacy Technologies” seemed a natural step: The liaison will be used for influencing e.g. the architecture documents that WG 5 works on.
112 In conclusion, while there is some policy language or open source initiative for every aspect of our undertaking, nobody knows how to make them work together. It is already clear that selected initiatives in standardisation as well as in open source will have to be improved to meet the PrimeLife quality expectations and to reflect the advancement of science intended by our project. This document provides a sound basis to resolve issues coming up while integrating privacy enhancing technologies into social networks. It provides the necessary information to the inside of the project and will serve as warehouse for off-the-shelf technologies that can be used by researchers and implementers exploring the path towards increasing privacy control in our daily life with the information society. Wherever PrimeLife discovers inconsistencies, issues of interoperability and gaps, it will try to influence the well identified projects in some well defined aspect.
But taking into account the experience from the PRIME project, notably the policy languages created by PRIME, PrimeLife may also be forced to engage in further improvement and development of the PRIME languages including the standardisation of those languages. 10.4 Recommended next steps for standardisation & open source
The present document has defined the landscape PrimeLife is operating in. The various requirement documents to be produced by the project will determine which of those initiatives are targeted with priority. Where there are incompatible approaches, PrimeLife will have to make a choice to integrate in one or the other platform. The evaluation will depend on a matrix of factors ranging from the facility and ability to influence and create or extend to small simple improvements, contribution of patches and simple use of existing technologies. Where there are opportunities to further the European paradigm of privacy and data protection, PrimeLife may well just present its way of thinking to initiatives.
113 References
[AAPML Spec] AAPML: Attribute Authority Policy Markup Language, 28 November 2006. http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF-AAPML-spec-08.pdf
[AOL4417749] A Face Is Exposed for AOL Searcher No. 4417749, New York Times Article, 09 August 2006. http://www.nytimes.com/2006/08/09/technology/09aol.html
[APPEL] A P3P Preference Exchange Language 1.0 (APPEL1.0), 15 April 2002. http://www.w3.org/TR/P3P-preferences/
[Adblock Firefox plugin] Adblock Plus 0.7.5.4, Wladimir Palant, 09 April 2008. https://addons.mozilla.org/en-US/firefox/addon/1865
[Authentic] Authentic - Home, accessed 20 May 2008. http://authentic.labs.libre-entreprise.org/
[AutoFormer] AutoFormer 0.4.1.4, M. Onyshchuk, 05 April 2008 https://addons.mozilla.org/en-US/firefox/addon/1958
[Autofill Forms] Autofill Forms 0.9.3, Sebastian Tschan, 08 May 2008. https://addons.mozilla.org/en-US/firefox/addon/4775
[Bandit] Bandit Project Home, accessed 15 May 2008. http://www.bandit-project.org/
[Bandit Development] Bandit Project's Code pages, accessed 15 May 2008. https://code.bandit-project.org/trac
[Becker et al.] Moritz Y. Becker, Andrew D. Gordon, Cédric Fournet: SecPAL: Design and Semantics of a Decentralized Authorization Language. Technical Report MSR-TR-2006-120. Microsoft Research, 2006. http://research.microsoft.com/research/pubs/view.aspx?tr_id=1166
[BlockSite] BlockSite 0.7, Erik van Kempen and Noel Briggs, 01 March 2008. https://addons.mozilla.org/en-US/firefox/addon/3145
[BugMeNot] BugMeNot 1.8, Eric Hamiter, 05 April 2008. https://addons.mozilla.org/en-US/firefox/addon/6349
114 [CARML Spec] Client Attribute Requirements Markup Language (CARML) Specification, 24 November 2006. http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF-CARML-spec-03.pdf
[CC] Common Criteria - Home, accessed 20 May 2008. http://www.commoncriteriaportal.org/
[CS Lite] CS Lite 1.3.8, Ron Beckman, 30 March 2008. https://addons.mozilla.org/en-US/firefox/addon/5207
[CSS 2] Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification, W3C Candidate Recommendation, 19 July 2007. http://www.w3.org/TR/CSS/
[Caja] Caja Code Site, accessed 19 May 2008. http://code.google.com/p/google-caja/
[CardSpace] CardSpace, . http://www.microsoft.com/net/cardspace.aspx
[Compact Policy] Section "Compact Policies" in "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", 16 April 2002. http://www.w3.org/TR/P3P/#compact_policies
[Concordia] Concordia Project, accessed 15 May 2008. http://projectconcordia.org/index.php/Concordia
[CookieSafe] CookieSafe 2.0.6, Ron Beckman, 12 January 2007. https://addons.mozilla.org/de/firefox/addon/2497
[DOM Level 3 Core] Document Object Model (DOM) Level 3 Core Specification, W3C Recommendation, 07 April 2004. http://www.w3.org/TR/DOM-Level-3-Core
[DisTrust] Distrust 0.8, Itamar Kerbel, 23 April 2008. https://addons.mozilla.org/en-US/firefox/addon/1559
[ECMA TC39] TC39 - ECMAScript, accessed 19 May 2008. http://www.ecma-international.org/memento/TC39.htm
115 [ECMAScript] ECMAScript Language Specification 3rd edition, December 1999. http://www.ecma-international.org/publications/standards/Ecma-262.htm
[EPAL] Enterprise Privacy Authorization Language (EPAL 1.2), 10 November 2003. http://www.w3.org/Submission/2003/SUBM-EPAL-20031110/
[ESOE] Enterprise Sign On Engine - Home, accessed 20 May 2008. http://www.esoeproject.org/
[ETSI/3GPP] ETSI - e-Standardisation Portal, accessed 20 May 2008. http://portal.etsi.org/portal_common/home.asp?tbkey1=SCP
[EnhancedHistory] Enhanced History, AnonEMoose, 2 November 2006, accessed 30 May 2008. https://addons.mozilla.org/en-US/firefox/addon/420
[Enterprise-Java-XACML] Enterprise-Java-XACML from Google Code, (beta) version 0.0.14, February 2008. http://code.google.com/p/enterprise-java-xacml/
[Eurosmart] Eurosmart - Smart Card shipments Global Forecast 2007 (March 2007), accessed 20 May 2008. http://www.eurosmart.com/4-Documents/ForecastShipGlobalForecast.htm
[FederID] FederID - Home, accessed 20 May 2008. http://federid.objectweb.org/xwiki/bin/view/Main/WebHome
[Firefox Addons] Firefox Privacy & Security Addons, accessed 15 May 2008. https://addons.mozilla.org/en-US/firefox/browse/type:1/cat:12
[FoxTor] FoxTor 0.7.3, Sasha Romanosky, 05 November 2006. https://addons.mozilla.org/en-US/firefox/addon/3606
[Future of P3P Workshop 2002] W3C Workshop on the Future of P3P, 12-13 November 2002. http://www.w3.org/2002/p3p-ws/
[Future of P3P Workshop 2003] W3C Workshop on the long term Future of P3P and Enterprise Privacy Languages, 19-20 June 2003. http://www.w3.org/2003/p3p-ws/
[Geuer-Pollmann/Claessens] Web services and web service security standards. Information Security Technical Report, 2005, 10, 15-24. http://dx.doi.org/10.1016/j.istr.2004.11.001
116 [Global Platform] Global Platform - Home, accessed 20 May 2008. http://www.globalplatform.org/
[Global Platform Specs] Global Platform Card specifications, accessed 29 May 2008. http://www.globalplatform.org/specificationview.asp?id=card
[Guidescope] Guidescope - Take control of the Web, accessed 15 May 2008. http://www.guidescope.com/
[HTML 4.01] HTML 4.01 specification, W3C Recommendation, 24 December 1999. http://www.w3.org/TR/html401/
[HTML 5] HTML 5, A vocabulary and associated APIs for HTML and XHTML, W3C Working Draft, 22 January 2008. http://www.w3.org/TR/html5/
[HTML WG] W3C HTML Working Group, accessed 19 May 2008. http://www.w3.org/html/wg/
[HTML5] Hyper Text Markup Language 5 - News and Opinions, accessed 19 May 2008. http://www.w3.org/html
[HTTP bis] Hypertext Transfer Protocol Bis charter, 26 December 2007. http://www.ietf.org/html.charters/httpbis-charter.html
[HTTPbis-security] Security Requirements for HTTP, 22 February 2008. http://www.ietf.org/internet-drafts/draft-ietf-httpbis-security-properties-01.txt
[Heraldry] Heraldry Project Incubation Status, accessed 20 May 2008. http://incubator.apache.org/projects/heraldry.html
[Higgins] Higgins open source identity management project, accessed 20 May 2008. http://www.eclipse.org/higgins
[I2P] Invisible Internet Project Anonymous Network, accessed 15 May 2008. http://www.i2p2.de/
[IAB] Internet Architecture Board, accessed 20 May 2008. http://www.iab.org/
117 [IBM WebSphere] IBM WebSphere, accessed 19 May 2008. http://www.ibm.com/websphere
[ID-FF Profiles] Liberty ID-FF Bindings and Profiles Specification, 2004. https://www.projectliberty.org/liberty/content/download/319/2369/file/draft-liberty-idff- bindings-profiles-1.2-errata-v2.0.pdf
[ID-SIS] Liberty Alliance ID-SIS 1.0 Specifications, 17 December 2007. https://www.projectliberty.org/resource_center/specifications/ liberty_alliance_id_sis_1_0_specifications
[ID-WSF] Liberty Alliance ID-WSF 1.1 Specifications, 20 May 2005. https://www.projectliberty.org/resource_center/specifications/ liberty_alliance_id_wsf_1_1_specifications
[ID-WSF tools] Conor Cahill - Liberty Open Source Toolkit, accessed 20 May 2008. http://www.cahillfamily.com/OpenSource/
[IESG] The Internet Engineering Steering Group, accessed 20 May 2008. http://www.ietf.org/iesg.html
[IETF] The Internet Engineering Task Force, accessed 20 May 2008. http://www.ietf.org/
[IETF SEC] IETF - Security Area, accessed 20 May 2008. http://www.tools.ietf.org/area/sec/
[IGF] Identity Governance Framework, 26 Jul 2007. http://www.oracle.com/technology/tech/standards/idm/igf/index.html
[ISO/IEC 7816-11:2004] Identification cards -- Integrated circuit cards -- Part 11: Personal verification through biometric methods. http://www.iso.org/iso/iso_catalogue/catalogue_tc/ catalogue_detail.htm?csnumber=31419
[ISO/IEC 7816-13:2007] Identification cards -- Integrated circuit cards -- Part 13: Commands for application management in a multi-application environment. http://www.iso.org/iso/iso_catalogue/catalogue_tc/ catalogue_detail.htm?csnumber=40605
[ISO/IEC 7816-4:2005] Identification cards -- Integrated circuit cards -- Part 4: Organization, security and commands for interchange.
118 http://www.iso.org/iso/iso_catalogue/catalogue_tc/ catalogue_detail.htm?csnumber=36134
[ISO/IEC 7816-8:2004] Identification cards -- Integrated circuit cards -- Part 8: Commands for security operations. http://www.iso.org/iso/iso_catalogue/catalogue_tc/ catalogue_detail.htm?csnumber=37989
[ISO/IEC WG4] ISO/IEC - WG4 - Integrated Circuit Cards with Contacts, accessed 20 May 2008. http://www.sc17.com/ index.cfm?pageTitle=Structure&DepartmentID=6&GroupID=4&HAT=7830215901208265222974-02130042-502097&ts=02150047-478941
[ITO] IT Transfer Office (ITO), closed in 2006. http://www.ito.tu-darmstadt.de/
[Idemix] Idemix (identity mixer): Pseudonymity for e-transactions, accessed 29 May 2008. http://www.zurich.ibm.com/security/idemix/
[InFormEnter] InFormEnter 0.5.5.2, M. Onyshchuk, 05 April 2008. https://addons.mozilla.org/en-US/firefox/addon/673
[Infogrid] NetMesh InfoGrid LID, accessed 20 May 2008. http://netmesh.org/downloads/
[InterLDAP] InterLDAP - Home, accessed 20 May 2008. http://wiki.interldap.objectweb.org/xwiki/bin/view/Main/WebHome
[JCT1SC27] Homepage ISO/IEC JTC 1/SC 27 - IT SECURITY TECHNIQUES, accessed 30 May 2008. http://www.jtc1sc27.din.de/
[JRC] Joint Research Centre, accessed 19 May 2008. http://ec.europa.eu/dgs/jrc/index.cfm
[JRC P3P Resource Centre] JRC P3P Resource Centre, accessed 19 May 2008. http://p3p.jrc.it/
[JRC Policy API] JRC Policy WorkBench, accessed 29 May 2008. http://sourceforge.net/projects/jrc-policy-api
[JTC1 SC27] ISO/IEC JTC 1/SC 27 IT Security Techniques Homepage, accessed 29 May 2008. http://www.jtc1sc27.din.de/cmd?level=tpl-home&contextid=jtc1sc27
119 [JXTA] JXTA Community Projects, accessed 30 May 2008. https://jxta.dev.java.net/
[KESTO] kesto.org alpha, accessed 30 May 2008. http://kesto.org
[Kerberos TP 1.1] Web Services Security Kerberos Token Profile 1.1, OASIS Standard Specification, 1 February 2006. http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-KerberosTokenProfile.pdf
[LASSO] Liberty Alliance Single Sign-On (LASSO) - Home, accessed 20 May 2008. http://lasso.entrouvert.org/
[LemonLDAP] LemonLDAP - Home, accessed 20 May 2008. http://wiki.lemonldap.objectweb.org/xwiki/bin/view/NG/Presentation
[Liberty] The Liberty Alliance, accessed 20 May 2008. https://www.projectliberty.org/
[Liberty Adoption] Liberty Standards Adoption, accessed 20 May 2008. http://projectliberty.org/liberty/adoption
[Lightbulb] Lightbulb - Federated Identity Integration for LAMP and MARS, accessed 20 May 2008. https://lightbulb.dev.java.net/
[MS .NET] Microsoft .NET Framework, accessed 19 May 2008. http://www.microsoft.com/net/
[Microformats] Microformats, accessed 19 May 2008. http://www.microformats.org
[MozPETSSourceforge] MozPETS Sourceforge Project Page, accessed 30 May 2008. http://sourceforge.net/projects/mozpets/
[MozPETs] MozPETs: Mozilla Privacy Enhancement Technologies, accessed 15 May 2008. http://mozpets.sourceforge.net/
[MozPETsPST05] MozPETs - a Privacy enhanced Web Browser, In Procedings of the Third Annual Conference on Privacy, Security and Trust (PST05). http://www.ito.tu-darmstadt.de/publs/pdf/BruecknerVoss_Mozpets.pdf
120 [NFC] The Near Field Communication (NFC) Forum, accessed 20 May 2008. http://www.nfc-forum.org/home
[Netmesh license] Netmesh Sleepycat License, accessed 20 May 2008. http://netmesh.org/downloads/netmesh-infogrid-lid/license.txt
[Noserub] Noserub - Decentral Social Network, accessed 21 May 2008. http://noserub.com/
[Noserub Code] Noserub Source Code, accessed 21 May 2008. http://noserub.com/download/
[OASIS] Organisation for the Advancement of Structured Information Standards (OASIS), accessed 19 May 2008. http://www.oasis-open.org/
[OASIS IPR] OASIS Intellectual Property Rights (IPR) Policy, 2 May 2008. http://www.oasis-open.org/who/intellectualproperty.php
[OASIS XACML] OASIS XACML Technical Committee page, accessed 19 May 2008. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
[OAuth Code] OAuth - Source Code, accessed 15 May 2008. http://oauth.net/code/
[OAuth Core 1.0] OAuth Core 1.0, accessed 15 May 2008. http://oauth.net/core/1.0/
[OAuth.NET] OAuth - Home, accessed 15 May 2008. http://oauth.net
[OSIS Feature Test] OSIS - Create New Feature Tests, accessed 15 May 2008. http://osis.idcommons.net/wiki/How_to_Create_New_FeatureTests
[OSIS Participants] OSIS Participants, accessed 15 May 2008. http://osis.idcommons.net/wiki/Category:Participant
[OSIS Results] I3:Overall Results, accessed 15 May 2008. http://osis.idcommons.net/wiki/I3:Overall_Results
121 [OSIS at Identity Commons] OSIS: Open Source Identity Systems, accessed 15 May 2008. http://osis.idcommons.net/
[OWL] OWL Web Ontology Language Overview, Deborah L McGuinness?, Frank van Harmelen, W3C Recommendation 10 February 2004, accessed 30 May 2008. http://www.w3.org/TR/owl-features/
[OpenIAM] OpenIAM - Project Home, accessed 15 MAy 2008.SourceID - Open Source Federated Identity Management, accessed 15 May 2008. https://openiam.dev.java.net/
[OpenIAM Code] OpenIAM - Source Code Browser, accessed 15 May 2008. https://openiam.dev.java.net/source/browse/openiam/
[OpenID 1.0] OpenID Attribute Exchange 1.0 - Final, 05 December 2007. http://openid.net/specs/openid-attribute-exchange-1_0.html
[OpenID 2.0] OpenID Authentication 2.0 - Final, 05 December 2007. http://openid.net/specs/openid-authentication-2_0.html
[OpenID Foundation] OpenID Foundation, accessed 20 May 2008. http://openid.net/foundation/
[OpenID libraries] OpenID Libraries, accessed 20 May 2008. http://wiki.openid.net/Libraries
[OpenID4Java] OpenID4Java Source Code, accessed 20 May 2008. http://code.sxip.com/openid4java/
[OpenLiberty-J] OpenLiberty-J - Home, accessed 20 May 2008. http://www.openliberty.org/wiki/index.php/Main_Page
[OpenSAML] OpenSAML - Home, accessed 20 May. https://spaces.internet2.edu/display/OpenSAML/Home
[OpenSSO] OpenSSO - OpenFederation: The Open Web SSO project, accessed 15 May 2008. https://opensso.dev.java.net/
[OpenSSO Code] OpenSSO - Source Code FAQ, accessed 15 May 2008. https://opensso.dev.java.net/public/about/faqcenter/faqsourcecode.html
122 [P3P] Platform for Privacy Preferences (P3P) Project, 20 November 2007. http://www.w3.org/P3P/
[P3P 1.0 Spec] The Platform for Privacy Preferences 1.0 (P3P1.0) Specification, 16 April 2002. http://www.w3.org/TR/P3P
[P3P 1.1 Spec] The Platform for Privacy Preferences 1.1 (P3P1.1) Specification, 13 November 2006. http://www.w3.org/TR/P3P11/
[PLING] PLING - W3C Policy Languages Interest Group, accessed 20 May 2008. http://www.w3.org/Policy/pling/
[PRIME] PRIME - Privacy and Identity Management for Europe, EU FP6 IST-507591, 2004-2008. https://www.prime-project.eu/
[Pamela Project] The Pamela Project, accessed 15 May 2008. http://pamelaproject.com/
[PamelaWare] PamelaWare, accessed 15 May 2008. http://code.pamelaproject.com/
[PhProxy] PhProxy - InBasic 3.0.2C, InBasic, 18 April 2008. https://addons.mozilla.org/en-US/firefox/addon/3239
[Prima] The PRIMA project, accessed 15 May 2008. http://www.ito.tu-darmstadt.de/projects/prima/
[Privacy Bird] Privacy Bird - Find web sites that respect your privacy, accessed 19 May 2008. http://www.privacybird.org/
[Privoxy] Privoxy Copyright, License and History, accessed 15 May 2008. http://www.privoxy.org/user-manual/copyright.html
[Privoxy Homepage] Privoxy - Home Page, accessed 15 May 2008. http://www.privoxy.org/
[RDF-PRIMER] RDF Primer, Frank Manola, Eric Miller, W3C Recommendation 10 February 2004, accessed 30 May 2008. http://www.w3.org/TR/rdf-primer/
123 [REL TP 1.1] Web Services Security Rights Expression Language (REL) Token Profile 1.1, OASIS Standard: 1 February 2006. http://www.oasis-open.org/committees/download.php/16687/oasis-wss-rel-token- profile-1.1.pdf
[RFC] Request for Comments, accessed 20 May 2008. http://www.ietf.org/rfc.html
[RFC 2616] Hypertext Transfer Protocol -- HTTP/1.1 specification, June 1999. http://www.ietf.org/rfc/rfc2616.txt
[RFC 2818] HTTP Over TLS, May 2000. http://www.ietf.org/rfc/rfc2818.txt
[RIF] RIF Working Group, accessed 19 May 2008. http://www.w3.org/2005/rules/wiki/RIF_Working_Group
[RIF Use Cases] RIF Use Cases and Requirements, 20 April 2008. http://www.w3.org/2005/rules/wiki/UCR
[RefControl] RefControl 0.8.10, James Abbatiello, 02 February 2008. https://addons.mozilla.org/en-US/firefox/addon/953
[Removing Data Transfer from P3P] Removing Data Transfer from P3P, 21 September 1999. http://www.w3.org/P3P/data-transfer.html
[Roboform] AI Roboform Toolbar for Firefox 6.9.84, Siber Systems, 14 November 2007. https://addons.mozilla.org/en-US/firefox/addon/750
[SAML 2.0 Bindings] Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0, 15 March 2005. http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
[SAML TP 1.1] Web Services Security SAML Token Profile 1.1, OASIS Standard, 1 February 2006. http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf
[SICSACML] SICSACML: XACML 3.0 Patch for Sun's XACML 2.0 Implementation, accessed 19 May 2008. http://www.sics.se/node/2465
124 [SOAP12] SOAP Version 1.2, Second Edition, W3C Recommendation, 27 April 2007. http://www.w3.org/TR/soap12
[SPARQL] SPARQL Query Language for RDF, Eric Prud'hommeaux, Andy Seaborne, W3C Recommendation 15 January 2008, accessed 30 May 2008. http://www.w3.org/TR/rdf-sparql-query/
[SafeCache] SafeCache 0.9, Collin Jackson, 23 November 2006. https://addons.mozilla.org/en-US/firefox/addon/1474
[SeatBelt] VeriSign's OpenID SeatBelt 1.0.0.2846, VeriSign, Inc., 23 July 2007. https://addons.mozilla.org/de/firefox/addon/5133
[Semantic Web] W3C Semantic Web Activity, accessed 20 May 2008.OASIS SAML V2.0 Specification, approved on 15 March 2005. http://www.w3.org/2001/sw/
[Shibboleth] Shibboleth - Home, accessed 20 May 2008. http://shibboleth.internet2.edu/
[SourceID] SourceID - SAML, Liberty, WS-Federation and CardSpace Toolkits, accessed 15 May 2008. http://www.sourceid.org/download/index.cfm
[Stealther] Stealther 1.0.2, Filip Bozic, 29 April 2008. https://addons.mozilla.org/en-US/firefox/addon/1306
[Sun XACML] Sun Implementation of XACML, version 1.2, 14 February 2006. http://sourceforge.net/projects/sunxacml/
[Sxipper] Sxipper 2.1.0, Sxip Identity, 06 May 2008. https://addons.mozilla.org/en-US/firefox/addon/4865
[TCG] The Trusted Computing Group, accessed 16 May 2008. https://www.trustedcomputinggroup.org/home
[TOR] Tor: anonymity online, accessed 15 May 2008. http://www.torproject.org/
125 [TREPALXACML] A Comparison of Two Privacy Policy Languages: EPAL and XACML, Anne Anderson, accessed 30 May 2008. http://research.sun.com/techrep/2005/smli_tr-2005-147/TRCompareEPALandXACML
[Temporary Inbox] Temporary Inbox 2.1.1, Pascal Beyeler, 05 April 2008. https://addons.mozilla.org/en-US/firefox/addon/2650
[Torbutton] Torbutton 1.0.4.01, Scott Squires and Mike Perry, 13 August 2007. https://addons.mozilla.org/en-US/firefox/addon/2275
[TrackMeNot] TrackMeNot 0.5.17, Daniel C. Howe and Helen Nissenbaum, 02 July 2007. https://addons.mozilla.org/en-US/firefox/addon/3173
[URI] Uniform Resource Identifier (URI): Generic Syntax, January 2005. http://www.ietf.org/rfc/rfc3986.txt
[W3C] The World Wide Web Consortium, accessed 20 May 2008. http://www.w3.org
[W3C Privacy Workshop] W3C Workshop on Languages for Privacy Policy Negotiation and Semantics-Driven Enforcement, October 2006. http://www.w3.org/2006/07/privacy-ws/
[WAF WG] Web Application Formats Working Group, accessed 19 May 2008. http://www.w3.org/2006/appformats
[WEBARCH] Architecture of the World Wide Web, Volume 1, W3C Recommendation 15 December 2004. http://www.w3.org/TR/webarch/
[WOT] Web of Trust - WOT 20080421, Against Intuition, 23 April 2008. https://addons.mozilla.org/en-US/firefox/addon/3456
[WS-MetadataExchange 1.1] Web Services Metadata Exchange, Version 1.1, August 2006. http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-mex/ metadataexchange.pdf
[WS-Policy 1.5] Web Services Policy 1.5 - Framework, W3C Recommendation, 04 September 2007. http://www.w3.org/TR/ws-policy/
126 [WS-Policy Primer] Web Services Policy 1.5 - Primer, 12 November 2007. http://www.w3.org/TR/2007/NOTE-ws-policy-primer-20071112/
[WS-Policy WG] Web Services Policy Working Group, accessed 20 May 2008. http://www.w3.org/2002/ws/policy/
[WS-PolicyAttachment 1.2] Web Services Policy 1.2 - Attachment, W3C Member Submission, 25 April 2006. http://www.w3.org/Submission/WS-PolicyAttachment/
[WS-PolicyAttachment 1.5] Web Services Policy 1.5 - Attachment, 04 September 2007. http://www.w3.org/TR/ws-policy-attach/
[WS-SecureConversation] WS-SecureConversation, OASIS Standard, 1 March 2007. http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.3/ws-secureconversation.pdf
[WS-Security] Web Services Security Core Specification 1.1, OASIS Standard, 01 February 2007. http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os- SOAPMessageSecurity.pdf
[WS-SecurityPolicy 1.3] WS-SecurityPolicy 1.3, OASIS Editor Draft, 1 February 2008. http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/ws-securitypolicy-1.3-spec- ed-01.pdf
[WS-Trust 1.3] WS-Trust 1.3, OASIS Standard, 19 March 2007. http://docs.oasis-open.org/ws-sx/ws-trust/v1.3/ws-trust.pdf
[WS-XACML Spec] Web Services Profile of XACML (WS-XACML) Version 1.0, 12 December 2006. http://www.oasis-open.org/committees/download.php/21490/xacml-3.0-profile- webservices-spec-v1.0-wd-8-en.pdf
[WSC] Web Security Context Working Group, accessed 20 May 2008. http://www.w3.org/2006/WSC/
[WSFed TC] OASIS Web Services Federation (WSFED) Technical Committee, accessed 20 May 2008. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsfed
[Web API] Web API Working Group, accessed 19 May 2008. http://www.w3.org/2006/webapi
127 [Wikipedia] Wikipedia - Internet Junkbuster, accessed 15 May 2008. http://en.wikipedia.org/wiki/Internet_Junkbuster
[X.509 Certificate TP 1.1] Web Services Security X.509 Certificate Token Profile 1.1, OASIS Standard Specification, 1 February 2006. http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-x509TokenProfile.pdf
[XADES] XML Advanced Electronic Signatures (XAdES) - Details of 'RTS/ESI-000034' Work Item, accessed 20 May 2008. http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=21353
[XHTML 1.0] XHTML 1.0 The Extensible HyperText Markup Language (Second Edition), W3C Recommendation, 1 August 2002. http://www.w3.org/TR/xhtml1/
[XHTML 2] XHTML2 Working Group Home Page, accessed 19 May 2008. http://www.w3.org/MarkUp
[XML Enc] XML Encryption Syntax and Processing, W3C Recommendation, 10 December 2002. http://www.w3.org/TR/xmlenc-core/
[XML Security] XML Security Working Group Charter, accessed 20 May 2008. http://www.w3.org/2008/02/xmlsec-charter
[XML Sig] XML-Signature Syntax and Processing, W3C Recommendation, 12 February 2002. http://www.w3.org/TR/xmldsig-core/
[XML Sig Transform] Decryption Transform for XML Signature, 10 December 2002. http://www.w3.org/TR/xmlenc-decrypt
[XML Sig/Enc Workshop] W3C Workshop on Next Steps for XML Signature and XML Encryption, 25-26 September 2007. http://www.w3.org/2007/xmlsec/ws/report.html
[XMLHttpRequest] The XMLHttpRequest Object specification, W3C Working Draft, 15 April 2008. http://www.w3.org/TR/XMLHttpRequest/
[XMLSec] XML Security Specifications Maintenance Working Group, accessed 20 May 2008. http://www.w3.org/2007/xmlsec/
128 [Yadis Implementations] Yadis Implementations Overview, accessed 20 May 2008. http://yadis.org/wiki/Yadis_Implementations
[Yadis Spec] Yadis Specification Version 1.0, 18 March 2006. http://yadis.org/wiki/Yadis_1.0_(HTML)
[Yadis.ORG] Yadis 1.0 - The Identity and Accountability Foundation for Web 2.0, accessed 20 May 2008. http://yadis.org/
[ZXID] ZXID Home - Open Source IdM for the Masses, accessed 20 May 2008. http://www.zxid.org/
129