Privacy and Identity Management in Europe for Life

First Report on Standardisation andInteroperability

Overview and Analysis of Open SourceInitiatives

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.1Type: DeliverableClass: PublicDate: 30 May 2008

Copyright © 2008 by the PrimeLife ConsortiunThe research leading to these results has received funding from the European Community'sSeventh Framework Programme (FP7/2007-2013) under grant agreement no 216483.

Members of the PrimeLife Consortium1. 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 theinformation is fit for any particular purpose. The below referenced consortium members shall have no liability fordamages of any kind including without limitation direct, special, indirect, or consequential damages that mayresult from the use of these materials subject to any liability which is mandatory due to applicable law. Copyright2008 by IBM Research GmbH, Technische Universität Dresden, Università degli Studi di Milano, JohannWolfgang Goethe - Universität Frankfurt am Main, GEIE ERCIM, Katholieke Universiteit Leuven, Giesecke &Devrient GmbH, Europäisches Microsoft Innovations Center GmbH, SAP AG.

2

AbstractThis document is a merged deliverable, covering items D3.3.1 (Overview and Analysis ofOpen 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 sourcesoftware, public educational material and contributions to open standardisation bodies.

The first chapter will introduce the scope of this report and its importance in the PrimeLifeproject. The second chapter essentially describes the target technology platforms, the Weband 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 sourceimplementations are mentioned. A brief description of the organisations which coordinatestandardisation of the previously described specifications follows. The last part of thedocument reviews in detail a number of selected open source projects which relate to thescope of the PrimeLife project.

The conclusion summarises results from the PRIME project and expectations for thePrimeLife work, so as to contribute to the definition of the project's next steps.

3

List of ContributorsContributions from several PrimeLife partners are contained in this document. The followinglist 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), ThomasRoessler (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 DevelopingOrganisations

Michele Bezzi (SAP), Carine Bournez (W3C), Eduard de Jong(GD), Robert Mueller (GD), Ulrich Pinsdorf (EMIC), KaiRannenberg (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), BenjaminKellermann (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 Contents1 Introduction 9

1.1 Scope of this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Historic Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 PrimeLife Aims and Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.4 PrimeLife Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5 PrimeLife's Approach to Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Target Technology Platforms 132.1 The Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.2 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.3 Evolving Web Application Development Paradigms - Web 2.0 . . . . . . . . . . . . . 162.1.4 Semantic Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.5 Privacy technologies for the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Service Oriented Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.1 OASIS WS-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.2 OASIS WS-SecureConversation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.3 OASIS WS-Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.4 W3C WS-Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.5 OASIS WS-SecurityPolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.6 Primelife Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Architectures and Frameworks 233.1 Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 IdM Framework (24760) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.2 A Framework for Access Management (29146) . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.3 Entity authentication assurance (29115) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.1 A Privacy Framework (29100) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.2 A Privacy Reference Architecture (29101) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Policy and rule languages 274.1 Extensible Access Control Markup Language (XACML) . . . . . . . . . . . . . . . . . . . . . . 27

4.1.1 An XACML scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1.2 An example of XACML policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.1.3 Relations to other proposals and to the PrimeLife project. . . . . . . . . . . . . . . . . . 304.1.4 Current status of the XACML proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 The Rule Interchange Format (RIF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.2.1 RIF Dialects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2.2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 P3P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3.1 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.4 APPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4.1 Shortcomings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.5 Enterprise Privacy Authorisation Language (EPAL) . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5.1 Structure of an EPAL policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5.2 An EPAL policy example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5.3 An EPAL query example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5.4 A typical EPAL scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.5.5 Relations to other standards and to the PrimeLife project . . . . . . . . . . . . . . . . . . 37

5

4.5.6 Status of the EPAL proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.6 CARML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.6.1 Elements of the CARML language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.6.2 Status of the CARML proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.6.3 AAPML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.7 Identity Governance Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.8 PRIME Policy Languages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.8.1 Rough use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.8.2 Distinctive features of PRIME languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.8.3 Relation to standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.9 WS-Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.9.1 Structure of a policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.9.2 Normal form of a policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.9.3 Compact form of a policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.9.4 Nested policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.9.5 References to other policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.9.6 Intersection of policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.9.7 Relations to other proposals and to the PrimeLife project. . . . . . . . . . . . . . . . . . 484.9.8 Status of the WS-Policy proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.10 OASIS WS-XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.11 Security Policy Assertion Language (SecPAL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5 Authentication Infrastructure 505.1 The ITU-T X.509 Standard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.1.1 X.509 Certificate and Certification Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1.2 Evolution of the X509 standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2 PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.2.1 X.509 Attribute Certificate and Privilege Management Infrastructure . . . . . . . . 535.2.2 Relationship to PrimeLife . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.3 XML Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.3.1 Specification Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.3.2 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.3.3 PrimeLife Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6 User Control Infrastructure 586.1 Smart Cards: User-controlled Token for Privacy Protection . . . . . . . . . . . . . . . . . . . . 58

6.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.1.2 Standardisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.1.3 Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.1.4 Strategy and Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.2 Biometrics Standardisation and Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.2.1 Biometrics Standardisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.2.2 Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.2.3 Strategy and Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7 Identity Systems 647.1 OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647.1.2 Protocol Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647.1.3 Message Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657.1.4 Trust and Privacy Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657.1.5 Specification Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.1.6 Open Source Implementations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.1.7 PrimeLife Perspective on OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.2 Higgins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6

7.3 CardSpace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687.4 WS-Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.5 SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.5.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717.5.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717.5.3 Protocol Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717.5.4 Open Source Implementations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.6 Liberty Identity Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.6.1 History and relationship with SAML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.6.2 Liberty profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.6.3 Profiles of the Single Sign-On and Federation Protocol . . . . . . . . . . . . . . . . . . . 737.6.4 Single Sign-On Protocol Flow Example: Liberty Artifact Profile. . . . . . . . . . . . 737.6.5 Liberty and CardSpace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.6.6 PrimeLife and Liberty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.6.7 Open Source Implementations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

7.7 Yadis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.7.1 Protocol flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.7.2 The Yadis document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.7.3 Trust and privacy properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767.7.4 Opportunities for PrimeLife. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767.7.5 Specification development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767.7.6 Open Source Implementations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8 Specification Developing Organisations 778.1 W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778.2 IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788.3 OASIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788.4 Liberty Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798.5 TCG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808.6 ISO/IEC JTC 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.6.1 ISO/IEC JTC 1/SC 27/WG 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828.6.2 ISO/IEC JTC 1/SC 17/WG 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838.6.3 ISO/IEC JTC 1/SC 17/WG 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838.6.4 ISO/IEC JTC 1/SC 37 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

9 Selected Open Source Projects 859.1 MozPETs: Mozilla Privacy Enhancement Technologies . . . . . . . . . . . . . . . . . . . . . . . 859.2 Firefox Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

9.2.1 Formfiller and Identity Management Enhancement . . . . . . . . . . . . . . . . . . . . . . 869.2.2 Privacy Enhancement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879.2.3 Trust Enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889.2.4 Other Firefox Plugins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899.2.5 Opportunities for PrimeLife. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

9.3 TOR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899.4 Privoxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909.5 Invisible Internet Project (I2P) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919.6 Bandit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

9.6.1 Development Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929.7 Concordia Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929.8 Open-Source Identity System (OSIS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

9.8.1 Specification development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939.8.2 Open Source Interoperability Workshops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

9.9 Pamela Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939.10 OpenSSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7

9.10.1 Architectural Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949.10.2 Opportunities for PrimeLife. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949.10.3 Open Source Implementations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

9.11 OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959.11.1 Protocol flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959.11.2 Trust and privacy properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969.11.3 Specification development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979.11.4 Open Source Implementations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

9.12 Noserub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9710 Conclusion 98

10.1 Results Available From PRIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9810.1.1 Privacy Ontologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9810.1.2 The JRC Policy Workbench. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9910.1.3 Policy Language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10010.1.4 SendPersonalData dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10010.1.5 Firefox plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10110.1.6 DataTrack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10310.1.7 Privacy Policy Decision Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10410.1.8 BluES'n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10710.1.9 PRIME Policy Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10710.1.10 Obligation Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10810.1.11 Identity Mixer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

10.2 Results Expected from PrimeLife . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10910.2.1 Activity 1 - Privacy Life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10910.2.2 Activity 2 - Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11010.2.3 Activity 4 - User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11010.2.4 Activity 5 - Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11110.2.5 Activity 6 - Infrastructures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

10.3 Perspectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11210.4 Recommended next steps for standardisation & open source . . . . . . . . . . . . . . . . . 113

8

Chapter1Introduction1.1 Scope of this DocumentThis deliverable aims at giving an overview of standardisation and open source initiatives thatare relevant for PrimeLife. It decribes the state of work there as well as possible and actualcooperations.

1.2 Historic BackgroundHidden data collection and the slow erosion of people’s privacy led to the start of the P3Pwork by W3C in 1997. Using P3P, a service can make statements about its privacy practisesin both human and machine readable form to support the individual using the service inmaking informed decisions. Informed decisions by indivduals and procurers were also the aimof ISO/IEC's work on IS 15408 "Evaluation Criterial for IT Security", that started in 1991 andwas enhanced by a "Privacy" Class covering Anonymity, Pseudonymity, Unlinkability, andUnobservability, 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 arebuilt around online communities or offer personalised services. Exchanges of values, ideasand information require a certain level of trust or reputation. In some cases, access to theinformation is regulated. Currently, a number of initiatives in open source and standardisationexist: OpenID, CardSpace, Higgins, Liberty Alliance, OSIS, as well as language driven oneslike FOAF, XACML or SAML. Mostly, the goal is to provide the notion of “Identity” acrossseveral completely decentralised services and add the necessary hooks for services to managethe relationship to its users. Often, the frameworks and languages are limited to a specifictechnology or service. Privacy or security are ignored or only minimally addressed.

As a consequence, identity management today consists of isolated initiatives. Industrialsolutions provide control schemes without privacy support. The current standardisation effortstry to federate several solutions. Such federation, in turn, makes the application of Privacy-Enhancing Technologies (PET) even harder as the semantics must participate in theinteroperability 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 processingafter the transmission of personal data (user-centric approach). The MIT based projects TAMIand PAW showed that data found on the Web can be used to create hooks for data protectiondecisions, access control and other constraints on the use of data. This work allows openingup the constraint of data use from a strict user-input driven scheme to larger communityconsiderations 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. AtW3C’s Privacy Workshop in October 2006, researchers and practitioners explored newdirections in privacy policy languages and enforcement mechanisms. There was significantinterest in exploring the interfaces between different, possibly domain-specific, policylanguages. In May 2006, ISO/IEC JTC 1/SC 27 "IT Security techniques" has establishedWorking Group (WG) 5 on “Identity Management and Privacy Technologies”. This initiativefollowed two SC 27 Study Periods on "Identity Management" and "Privacy". The new WGstarted work with projects such as “A framework for identity management” (24760), “Aprivacy framework” (29100) and “A privacy reference architecture” (29101).

1.3 PrimeLife Aims and ActivitiesPrimeLife will explore how current identity management schemes can be influenced toinclude privacy-enhancing tools and hooks. This necessarily means also influencing currentstandardisation efforts and creating new initiatives where needed. Within this context,PrimeLife will significantly advance the state of the art in standardisation. PrimeLife willwork with selected bodies such as ITU, ISO/IEC JTC 1/SC 27/WG 5, OASIS, and W3C toinfluence the relevant standards activities to encourage them to incorporate advanced privacy-enhancing concepts and technologies. For example 7 privacy related projects are beingworked on in SC 27/WG 5, and PrimeLife is establishing a liaison to this group due to itsglobal 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 firstcontributions to Higgins), user interfaces, various kinds of policies (where so far only little,isolated efforts have been made), and also infrastructure components. The most prominentopen 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 thecurrently developed global solutions will integrate PrimeLife solutions, thus, leading to aglobal impact of the project's results and thus to better privacy protection in the nextgeneration services. Success will be measured by the (success of the) workshop forstandardisation of the projects’ technologies and for the cooperation with other projects, bythe contributions to standardisation bodies and (existing) open source communities, and bythe extent to which these contributions get taken up.

1.4 PrimeLife Project OverviewIndividuals in the Information Society want to protect their autonomy and retain control overpersonal information, irrespective of their activities. Information technologies hardly considerthose requirements, thereby putting the privacy of the citizen at risk. Today, the increasinglycollaborative 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-longtrail of personal data.

This raises substantial new privacy challenges: A first challenge is how to protect privacy inemerging Internet applications such as collaborative scenarios and virtual communities. Asecond challenge is how to maintain life-long privacy.

PrimeLife will resolve the core privacy and trust issues pertaining to these challenges. Itslong-term vision is to counter the trend to life-long personal data trails without compromisingon functionality. We will build upon and expand the sound foundation of the FP6 projectPRIME that has shown how privacy technologies can enable citizens to execute their legalrights 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 computerinterfaces, configurable policy languages, Web service federations, infrastructures andprivacy-enhancing cryptography.

PrimeLife will ensure that the community at large adopts privacy technologies. As one of theactivities to this effect PrimeLife will work with the relevant open source communities andstandardisation bodies. This document summaries these communities and bodies and relatesthem to the technologies and mechanisms PRIME has produced and PrimeLife aims toproduce.

1.5 PrimeLife's Approach to PrivacyWe envision that users will be able to act and interact electronically in an easy and intuitivefashion while retaining control of their personal data throughout their life. Users might use amultitude of different means to communicate with several partners employing a variety ofplatforms. For instance, a user Alice might authenticate to an on-line service created by amash-up. She automatically logs on using her laptop and later confirms a payment transactionfor an electronic article using her mobile phone. In all those transactions, despite manypotentially untrusted services collaborate in the mash-up, Alice is able to reveal only theminimally necessary information to establish mutual trust and conduct the transaction. Forinstance, no service will learn any personal information about Alice. Nevertheless, a merchantis guaranteed payment for the services.

In other words, privacy needs to be addressed in a user centric way, i.e., in a way where theusers 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 dataneeds 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 insuch 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 anACL that lists which users are allowed to access, the attribute-based access control definesfor each item what attributes (requirements, credentials) a requester needs to satisfy to getaccess to a resource. Next, access control needs to be done such that the user is notauthenticated with respect to a user ID (and then checking whether that user has the requiredattributes) but rather by allowing access to any user who can provide proof that the attributesare 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 begiven intuitive user interfaces that guide them through such authorisation procedures. Itshould be able to investigate which data will be sent to which partners at what time andthereby maintain a profile (or partial identity) with the communication partners.

Let us discuss the second item. Some of the technologies we have already mentioned: accesscontrol 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 theusers (e.g., an electronic version of a driver's license) that allow users to control whatinformation contained in the certificate shall be revealed at what time. So for instance, usingan anonymous driver's license credential, user Alice could convince a bar tender that she isold enough to order a beer without disclosing any other information attributed to her in thelicense (in fact, she does not even have to reveal her birth date but only the fact that she wasborn a sufficient time ago to be old enough for that beer). This aspect of PrimeLife's approachis taken over from the PRIME project and hence can draw on the these results many of whichare quite mature already. Therefore we deem this offers many opportunities forstandardization and open source contributions.

However, the approach to reveal only the minimally necessary information does not addressall the privacy problems arising. In many cases, e.g., social networks or wiki pages, the usersindeed 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 tojudge whether the information is trustworthy. The establish the latter, users will potentiallyhave to reveal even more information about themselves in order for their communicationpartners to assess to what extent and with respect to what they can be trusted. PrimeLife aimsto address these challenges as well. In this area, PrimeLife is to a large extend conductingbasic research and therefore we here expect fewer opportunities for standardization andmaybe just a few isolated contributions to open source communities.

12

Chapter2Target Technology PlatformsData is exchanged between various kinds of computer systems connected to Internet. Thetarget platform for PrimeLife work is generally the Web. This section reviews the architectureof the Web and its essential technology components. Although few standards are available forprivacy and security on the Web in general, the deployment of Web services has led todedicated work for Service-Oriented Architectures.

2.1 The Web2.1.1 ArchitectureThe World Wide Web (see WEBARCH [WEBARCH]) is a global information space built ontop of a set of relatively simple technologies which, in combination, have enabled its worldwide deployment, and have catalysed the Internet's growth and use over the last 15 years.

Key design elements of the World Wide Web include:

IdentificationUniform Resource Identifiers [URI] serve to identify resources on the Web. Theyprovide an abstraction layer for resource identification across protocols and acrossdocument formats. New URI schemes can be introduced without having to change thesurrounding format (e.g., HTML, SVG, MathML). Extension by URI scheme enablesdeployment 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 sameprotocol interaction. Further, different URI schemes expose different methods -- theHTTP protocol, e.g., supports both retrieval and information posting methods (GET andPOST).

InteractionWhile 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 asthe primary protocol for the Web. Key properties of HTTP include safe informationretrieval (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 resourcerepresentations (depending on, e.g., language preferences and supported data formats).

FormatsFor data formats (as for protocols) the practically unlimited extensibility of the protocoland addressing layers is complemented by social conventions (codified in deployment)about the formats in use: Various variants of HTML, style and scripting languages, and afew graphics formats effectively form the backbone of today's Web.

2.1.2 StandardsThis section summarises the specifications that are at the core of today's instantiation of theWeb: HTTP as the primary retrieval protocol, HTML and CSS as the primary formats usedfor documents and their style, and the Document Object Model's application programminginterfaces as used by the ECMAScript scripting language (more commonly referred to asJavaScript).

HTTP and TLS

The Hypertext Transfer Protocol (RFC 2616 [RFC 2616]) is a fundamentally statelessrequest/response protocol that is used to interact with Web resources. Methods that can beused in this interaction include both simple retrieval (GET; a so-called safe method, as it mustnot cause side effects), submission of information (using POST or PUT), and othermanipulations (using, e.g., DELETE). HTTP further supports content and languagenegotiation, redirection functionality, and advanced mechanisms for caching and proxying ofrequests.

Browser cookies -- while broadly deployed -- are a notoriously underspecified aspect ofHTTP; yet, they serve a critical function on today's Web, by adding session management toan 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 formsto solicit user names and passwords, and on cookie-based session management to tie a priorauthentication 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 separateprotocol, and the result of that transaction is then tied to a session.

Similarly, confidentiality and signature services are out of scope for HTTP. Thesefunctionalities 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 anynetwork enabled device (often as configuration and control interface of choice); HTTP clientsare 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 theIETF [HTTP bis] is at this time (April 2008) focused on specification maintenance and erratawork; it is expected that this work will produce a higher-quality version of the HTTP/1.1specification.

14

As far as security and identity mechanisms for HTTP are concerned, the currently active IETFworking group is specifically chartered to only document the protocol's properties. Yet, thereis a certain amount of momentum to further investigate security mechanisms for HTTP, and itis expected that this momentum will further materialise during the lifetime of Prime Life (seeHTTP bis Security Properties [HTTPbis-security]).

HTML, CSS

The Hypertext Markup Language, HTML, is (like HTTP) at the root of the Web's stack ofspecifications. 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 thefunctionality of the deprecated applet tag. Extensions to HTML can also be based on usingclass 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 interoperablespecification for HTML and associated APIs, and XHTML 2 [XHTML 2], the nextgeneration of the XML-based XHTML.

Layout information for HTML (and other structured document formats, including XMLapplications) 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 manipulatesHTML and XML documents. It relies on a structure model of the document and definesaccessors to the various components of this structure. It is platform-neutral and languageneutral. It is organised in levels which specify required and optional features: Level 1 definesa 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 moreDOM types) and provides load-and-save and validation APIs. All the W3C DOM Levelsrecommendations include bindings to Java and to ECMAScript. DOM is the preferred API tomanipulate 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 1999is mostly used as a language to manipulate Document Object Models on the Web. It is themajor language for client-side scripting, implemented in all common clients for all kinds ofplatforms. ECMA TC39 [ECMA TC39] is actively working on the ECMAScript 4 language.

15

The XMLHttpRequest [XMLHttpRequest] object is another neutral API that allows scripts toperform HTTP client requests without reloading the Web pages. It builds on some parts of theDOM model and constitutes the core of the Ajax technique. The goal of such a specificationis to unify the techniques used for dynamicity of content and achieve the necessaryinteroperability 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.0The power of Web applications often comes from the easy combination of data and servicesacross multiple sources: In the easiest case, a meeting description might include a map serviceinline, highlighting the meeting location. More complex mash-ups might combine anynumber of data sources, factor in personal information (e.g., travel plans) to answer the user'squestions, and trigger activities on multiple possible services.

As application programming interfaces and client-side scripting have matured in recentbrowser generations, they have enabled an increasing shift of complexity toward the clientside: 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 serverside 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: Onthe one hand, there is increased susceptibility of services to abuse, as careless use of Web 2.0design 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 scriptsfrom different trust domains within a single domain of control (or within several,insufficiently isolated domains of control). As a result, the technical environment'senforcement of social and business agreements between different data processing partiesbecomes difficult in actually deployed mash-up environments.

Some recent research and development into JavaScript security models has the potential tohelp change this environment to improve the client-side Web programming environment'sability 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. Thissecurity model is deployable now, through a JavaScript-to-JavaScript compiler.

On the other hand, modern Web application development techniques improve the abilities ofcollaborating actors to share user data and track behaviour, beyond what is possible withsimple 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 Webapplications), 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 enforcementof privacy policies into Web applications, and to create business and technical incentives forWeb application developers to disclose privacy intents.

Additional approaches to data sharing in Web 2.0 scenarios involve the passing of personalinformation 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 personalinformation are going to stay with us. In the context of Activity 1, PrimeLife will analysethese use cases in more detail.

Standardisation Efforts

Specifications relevant to Web 2.0 programming patterns are under development in a numberof places: The W3C HTML Working Group [HTML WG] is developing the HTML5 [HTML5] specification, which includes numerous APIs (including APIs for local storage of data,cross-domain communications, and relevant security models); additional related work is doneby the W3C Web Application Formats [WAF WG] and Web API Working Groups [WebAPI]; a proposal to merge these groups is currently (May 2008) under consideration by theW3C membership. Some work on Caja [Caja] has found its way into the ECMAScriptstandardisation work at ECMA TC39 [ECMA TC39]. Other relevant work is either beingdone under the umbrella of open source projects or ad-hoc initiatives, and may make its wayinto more formal standardisation during the lifetime of the project.

2.1.4 Semantic WebThe Semantic Web provides a common framework that allows data and metadata to be sharedand reused across application, enterprise, and community boundaries. Key ingredients of thisframework include the simple, yet powerful data model of the Resource DescriptionFramework [RDF-PRIMER]; a standardised query language [SPARQL]; and an ontologylanguage [OWL] that enables machine-readable expression of the relationships betweendifferent concepts.

The usage of URI references as identifiers enables different parties to coin new terms withoutthe 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 morepowerful aggregation of personal information. Where a lack of integration might in the pasthave 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 ofidentity management by providing a framework that can be used to express not just personalinformation, but also privacy practices, policies, and preferences. As broader and moreeffective data integration becomes possible, distributed and scalable compliance monitoringbecomes possible, leading to improved accountability of those who process personalinformation.

2.1.5 Privacy technologies for the WebVery few Privacy-Enhancing Technologies (PET) are standardised today. There is a largevariety of tools (see chapter 8) that do not interoperate. Wisdom put into one tool can't beused in another tool. This way it is also very hard for E-Commerce sites to obtain predictableresults when designing their portals. P3P is the only major exception to this rule. It isdiscussed 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, hasnever reached the status of Recommendation.

17

2.2 Service Oriented ArchitecturesThe 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 andnetworking domains. Generally speaking, ‘Web service’ refers to the transfer of XML viainternet protocols, such as HTTP or SMTP. The ‘Simple Object Access Protocol’ (SOAPVersion 1.2, 2007 [SOAP12]) is an XML based protocol, which provides a definition howstructured and typed information can be exchanged between peers in a distributed anddecentralised environment.

In order to provide security, reliability, transaction abilities and rich meta-data support forWeb services, additional specifications exist on top of the XML/SOAP stack. Figure 1provides an overview of important Web service specifications and how they relate to eachother. XML lays the basis for all the standards. Other basis technologies in this group areSOAP encoding service invocations, its transport protocols HTTP/UDP, and basic XMLcryptography schemas. The next layer, called 'Messaging', groups standards that provideadvanced communication features such as flow control, transactions, establishing of securecommunication channels, and trust establishment. The layer 'Infrastructure and Profiles' layercontains standards which typically affect the interaction between multiple services, such asinteroperability, trust establish between services/parties across organizational borders, anddistributed management. The 'Metadata' group is somehow orthogonal to the latter threelayers. 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 statusof the specification. The core technologies in the XML space are all defined by the WorldWide Web Consortium (W3C). Many of the higher-layer specifications are driven by multipleindustry players, including Microsoft, IBM, BEA Systems, SAP and others. Thesespecifications help to make progress in the interoperability between the different industryplatforms, most notably Microsoft’s .NET [MS .NET] platform and IBM’s WebSphere [IBMWebSphere] 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-SecurityThe WS-Security [WS-Security] specification defines mechanisms for integrity andconfidentiality protection, and data origin authentication for SOAP messages and selectedparts thereof. The cryptographic mechanisms are utilised by describing how XML Signatureand XML Encryption are applied to parts of a SOAP message. That includes processing rulesso that a SOAP node (intermediaries and ultimate receivers) can determine the order in whichparts of the message have to be validated or decrypted. These cryptographic properties aredescribed using a specific header field, the <wsse:Security> header. This header provides amechanism for attaching security-related information to a SOAP message, whereas multiple<wsse:Security> headers may exist inside a single SOAP message. Each of these headers isintended for consumption by a different SOAP intermediary. This property enablesintermediaries to encrypt or decrypt specific parts of a message before forwarding it orenforces that certain parts of the message must be validated before the message is processedfurther. Besides the cryptographic processing rules for handling a message, WS-Securitydefines a generic mechanism for associating security tokens with the message. ‘Associating asecurity token’ means that one or more tokens are included in <wsse:Security> headers in themessage and that a referencing mechanism is introduced to refer to these tokens. Tokensgenerally are either identification or cryptographic material or it may be expressions ofcapabilities (e.g. signed authorisation statements). For instance, the certificate for signaturevalidation may be added into the header. That may be done by either placing it into thesignature itself (which makes re-usage a bit complicated and fragile) or by directly making ita child of the <wsse:Security> header and referencing it from the signature. The latter use hasthe advantage that other signatures or security operations may directly refer to that token.WS-Security, available in version 1.1 since February 2007, defines a simple username token,

19

a container for arbitrary binary tokens (base64 encoded), a container for XML-formattedtokens, 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 howX.509 certificates, certificate chains or PKCS#7 certificate revocation lists may be used inconjunction with WS-Security. The ‘Username Token Profile 1.1’ extends the existingusername token by adding literal plaintext passwords, hashed passwords, time variantparameters (nonce) and creation time stamps. The Rights Expression Language (REL) TokenProfile 1.1 [REL TP 1.1] links WS-Security to ISO/IEC 21000-5. The Kerberos Token Profile1.1 [Kerberos TP 1.1] defines how Kerberos tickets are embedded into SOAP messages andthe SAML Token Profile 1.1 [SAML TP 1.1] defines how SAML 1.1 and 2.0 assertions (seealso 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 itis definitively relevant for PrimeLife.

2.2.2 OASIS WS-SecureConversationThe WS-Security specification introduced the concept of message level security. By utilisingonly WS-Security to encrypt and sign Web service messages, a lot of overhead related to keymanagement is necessary. For instance, if a Web service requires each message beingencrypted using a 2048-bit RSA operation and given the fact that 1000 service invocationsmay happen during the next 3 minutes, it becomes obvious that this concept does not scalevery well. In the transport layer, HTTP 1.1 permits to keep an existing SSL/ TLS connectionopen so that subsequent requests to a Web server may be sent via the already establishedsecured connection. WS-SecureConversation [WS-SecureConversation] brings this conceptinto the Web services world. This is done by introducing mechanisms to establish and shareso-called ‘security contexts’. Based on established security contexts or arbitrary alreadyexisting shared secret keys, WS-SecureConversation provides mechanisms to derive sharedkey 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. Inthat case, the requestor retrieves the SCT from some security token service that is trusted bythe Web service. The second way is that the requestor creates an own SCT and sends thatSCT to the Web service. The problem may be that the Web service may not trust therequestor to create an appropriate SCT and may reject that self-created SCT. A third option isthat both the requestor and the Web service mutually agree on a security context using achallenge-and-response process. An established SCT is afterwards used to derive sessionkeys. These session keys may then be used for subsequent message encryption and messageauthentication 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-TrustThe WS-Trust [WS-Trust 1.3] specification introduces the concept of ‘security tokenservices’ (STS). A security token service is a Web service that can issue and validate securitytokens. For instance, a Kerberos ticket granting server would be an STS in the non-XMLworld. A security token service offers functionality to issue new security tokens, to re-newexisting tokens that are expiring and to check the validity of existing tokens. Additionally, asecurity 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 requiredsecurity tokens for Web service calls using WS-SecurityPolicy/PolicyAttachment. Arequestor may want to call that specific Web service but may not have the right securitytokens indicated by the policy. The Web service may require SAML credentials from aparticular trust domain whereas the requestor only has an X.509 certificate from its owndomain. 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 Webservice in question. The decision what exactly the ‘right’ token is can be made either by therequestor or by the STS. The requestor may inspect the Web service’s policy and specificallyask the STS: "I have the attached X.509 certificate and need a SAML token". The otheroption is that the requestor includes its possessed tokens and states what Web service itintends to call: "I possess the following tokens and I would like to call the Web servicehttp://foo/bar. Please give me whatever token may be appropriate." WS-Trust provides a richinterface that permits the implementation of various use cases. For instance, the requestormay include time variant parameters as entropy for a token generation process. The tokenservice 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 thesecurity token. For instance, the requested security token may be a certificate whereas theproof-of-possession token is the associated private key. The security token service may alsoreturn multiple keys like a certificate along with its validation chain or it may create keyexchange tokens with which the requestor can encrypt key material for the intended Webservice. A requestor can also express requirements on algorithms and key strengths forrequired tokens. WS-Trust defines protocols including challenge-and-response protocols toobtain the requested security tokens, thus enabling the mitigation of man-in-the-middle andmessage replay attacks. The WS-Trust specification also permits that a requestor may need asecurity token to implement some delegation of rights to a third party. For instance, arequestor could request an authorisation token for a colleague that may be valid for a giventime interval. WS-Trust utilises WS-Security for signing and encrypting parts of SOAPmessages as well as WS-Policy/SecurityPolicy to express and determine what particularsecurity 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 existingsecurity protocols and make them fit directly in the Web services world by using Web serviceprotocols and data structures. It is thus essential for service composition in PrimeLife.

2.2.4 W3C WS-PolicyThe 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 Webservice only provides services between 8:00 AM and 5:00 PM or that service requests must besigned 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 basedon their own policy and a service’s policy what requests may be accepted and what requestsmay be not. WS-Policy by itself only provides a framework to describe logical relationshipsbetween policy assertions, without specifying any assertion. WS-PolicyAttachment [WS-PolicyAttachment 1.2] attaches policies to different subjects. ‘Web service related’ meanspolicies apply to service endpoints or to XML data. A policy can be attached to an XMLelement (by embedding the policy itself or a link to the policy inside the element) or bylinking from the policy to the subject that is described by the policy. WS-PolicyAttachmentalso defines how policies can be referenced from WSDL documents and how policies can beattached to UDDI entities and stored inside a UDDI repository. WS-MetadataExchange [WS-

21

MetadataExchange 1.1] defines protocols to retrieve metadata associated with a particularWeb services endpoint. For example, a WS-Policy document can be retrieved from a SOAPnode using WS-Metadata.

2.2.5 OASIS WS-SecurityPolicyWS-SecurityPolicy [WS-SecurityPolicy 1.3] defines certain security-related assertions that fitinto the WS-Policy framework. These assertions are utilised by WS-Security, WS-Trust andWS-SecureConversation. The ‘SecurityToken’ assertion tells a requestor what security tokensare 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 partsthat have to be protected and it defines what algorithms are permitted. Visibility assertionsidentify what particular message parts have to remain unencrypted in order to allow SOAPnodes along the message path to operate on these parts. The ‘MessageAge’ assertion enablesentities to constrain after what time a message is to be treated as expired.

2.2.6 Primelife PerspectiveWeb 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 projectgoals. In PrimeLife, Activity 6 will analyze this area in more detail and will investigate newapproaches to address the main privacy issues.

22

Chapter3Architectures and FrameworksThis section presents work of the Working Group (WG) 5 "Identity Management and PrivacyTechnologies" of ISO/IEC JTC 1/SC 27 "IT Security techniques" which is described in moredetail 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 topicalportfolio overlapping significantly with that of PrimeLife. The terminology in this sectionfollows that of the respective standards.

3.1 Identity Management3.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 beapplicable to individuals as well as organisations of all types and sizes, in any environmentand regardless of the nature of the activities they are involved in.

Identity Management (IdM) is the secure management of identities, the identification processduring which an entity may be authenticated, and the information associated with theidentification of an entity within some context. The entity might be anything that can beuniquely recognised, a person, an animal, a device, an object, a group, an organisation, aninformation object, etc. Entities may have multiple identities that may be used in differentcontexts, often called Partial Identities.

The context for the identification process might be within an organisation’s boundaries, orfederated across organisations. This standard will cover the life cycle of identities and identityinformation as they are established, modified, suspended, terminated or archived. Informationassociated with identities may change over time and must therefore be carefully managed.Some associations of an entity might be informal and change frequently. Other associationsmight be formal, specific relationships, such as people, policy-based organisational roles, andfinancial accounts that remain stable over time. Identity attributes are often securely storedwithin tokens, directories, access devices, or database management systems.

23

Identities may be associated with policy-based roles, and these roles may be associated withduties and responsibilities, and privileges and permissions to access resources. An IdentityManagement System (IdMS) also needs to interact with other information systems thatrequire 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 thesecure management of the process to access information. This framework is applicable to anykind of users, individuals as well as organisations of all types and sizes, and should be usefulto organisations at any location and regardless of the nature of the activities they are involvedin.

Access Management (AcM) is the secure management of the processes to access informationand the information associated with the accountability of an entity within some context. Theentity might be anything that can be uniquely recognised, a person, an animal, a device, anobject, a group, an organisation, a piece of information, etc. Entities may have multipleidentities that may be used in different contexts. Identities may be federated or not. Theprocesses include, without limitation, the identification, the authorisation, the entitlement andprivilege management; the authentication, and the review of information usage. The intent isnot to define in details the technical aspects of each of these processes but to identify theoverall process of the access to the information. The different services composing an AccessManagement 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 foran Access Management framework is composed of several services that could be decoupledor integrated in a solution suite. The standard must clarify the relation between the frameworkand to the services mentioned and their interactions. The context for access might be withinan organisation's boundaries or federated across organisations. This standard describes the lifecycle of access and security services associated to that access as they are established,modified, suspended and terminated. Information associated with accesses may change overtime and must therefore be carefully managed. The framework must provide the means toadministrate the access definitions of all users and to publish the definitions to theinformation 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 thesecure management of access definitions that also include the delivery of credentials to usersentitled to roles and the secure maintenance thereof.

This project is in the "New Project" stage and a first Working Draft is expected for Summer2008.

24

3.1.3 Entity authentication assurance (29115)This project aims at describing the guidelines or principles that must be considered in entityauthentication, assurance and the rationale for why it is important to an authenticationdecision, especially: a framework for assessing "how close" an entity is to the claimed onethroughout 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 ofauthentication 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 Privacy3.2.1 A Privacy Framework (29100)This Project aims at providing a framework for defining privacy safeguarding requirements asthey relate to PII (Personally Identifiable Information) processed by any information andcommunication system in any jurisdiction. The framework is to be applicable on aninternational level and addresses system specific issues on a high-level. It is general in natureand puts organisational, technical, procedural and regulatory aspects in perspective. It is thepurpose of this international standard to provide guidance concerning information andcommunication system requirements for processing PII by setting a common privacyterminology, defining privacy principles when processing PII, categorising privacy featuresand relating all described information privacy aspects to existing security guidelines. Theframework can serve as a basis for desirable additional privacy standardisation initiatives, forexample for a technical reference architecture, for the implementation and use of specificprivacy technologies, for an overall privacy management, for the assurance of privacycompliance for outsourced data processes, for privacy impact assessments or for specificengineering specifications.

The Privacy Framework is being developed for those individuals with an interest in thestandardisation of privacy safeguarding controls as they relate to PII processed by enterpriseICT 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 insystem development life cycles or, more specifically, in security development life cycles thisInternational Standard addresses the target audience of ICT system developers in a separatesection, providing a framework and guidelines for an approach to built-in privacy-enhancingfunctionalities 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 bestpractices for a consistent, technical implementation of privacy safeguarding requirements asthey relate to the processing of personally identifiable information in information andcommunication systems. It is to cover the various stages in data life cycle management andthe required privacy functionalities for PII in each data life cycle, as well as positioning theroles and responsibilities of all involved parties. The privacy reference architecture aims atpresenting a best practice, privacy-enhanced architecture model and provides guidance forplanning and building system architectures that facilitate the proper handling of PII acrosssystem platforms. It sets out the necessary prerequisites to allow the categorisation of data andcontrol over specific sets of data within various data life cycles. It is the purpose of thisproject to provide guidance concerning a consistent and effective technical implementation ofprivacy safeguarding requirements within information and communication systems. Thereforeit establishes a privacy reference architecture that enables system architects to build necessaryprivacy safeguarding measures into the system in a cohesive way across system platforms andto combine them with existing security measures, all to improve the proper handling of PIIoverall. Additionally, the privacy reference architecture gives best practices in advancing theuse of privacy-enhancing technologies.

Interested parties that would benefit from using the concepts of the privacy referencearchitecture include representatives from organisations designing, developing, implementing,and operating information and communication systems. Most likely, these are representativesfrom various IT organisation departments such as from development, support, and operationsor business units or quality assurance and data protection units that have a specific interest inapplying consistent architectural decisions to accomplish compliance with specific privacyrequirements, rules and regulations.

This project is in the "Working Draft" stage.

26

Chapter4Policy and rule languagesThis 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 thePrimeLife project's research work on policy languages proceeds. Based on that review, and onthe project's research results, suitable avenues for standardisation of such results will beproposed.

4.1 Extensible Access Control Markup Language(XACML)XACML is a general-purpose access control policy language. It provides an XML syntaxboth for a policy language and an access control decision language.

The policy language allows for descriptions of general access control requirements, while thedecision language enables users to create queries about whether a given action on a certainresource should be allowed or not, and also to interpret the result. The response is alwayscomprised of one of the following answers: Permit, Deny, Indeterminate (an error occurred ora 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 scenarioIn a typical XACML scenario, a user wants to perform some action on a resource. In thiscontext, a resource is anything to which access can be controlled, such as an XQuery moduleor a Java method, and the requested action may be a query execution and a methodinvocation, respectively.

The user issues a request to the device protecting the resource (e.g.: filesystem or a Webserver), which is called a Policy Enforcement Point (PEP). The PEP creates a request whichconsists 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 specificallylinked 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 lookingfor some policy that applies to it.

An XACML Policy consists of a single access control policy, in the form of a collection ofrules. A policy specifies the conditions under which access to the requested resource can beallowed or must be denied. Each policy and each rule within the policy contain a set ofapplicability predicates used to determine whether the policy (or the rule) applies to a givendecision request.

The applicability predicates are organised in an item called Target. A Target is a set ofconditions for the Subject, the Resource, the Action, and the Environment that must besatisfied for a policy or rule to apply to a given request. Boolean functions are used tocompare values found in a request with those included in the Target. If all the conditions of aTarget are met, then the relevant policy or rule applies to the request. Target information notonly is useful to check applicability, but also provides a policy indexing service, in thatpolicies may be searched through by a PDP on the basis on their Target constraints. If apolicy has no Target, it means that it is always applicable. If a particular type is missing (forexample, there are no Subjects) the policy applies to all instances of that type (i.e. to allsubjects). If there is more than one group of predicates of a given type, all predicates in atleast one group for each type must be true.

A Target element may be followed by at most one Condition, comprised of a single predicateor a Boolean combination of predicates. XACML does not make any distinction amongattributes in specifying whether they should appear in the Target or in the Conditionpredicates. If the Condition is missing, then the Condition is treated as implicitly true. Ifeither the Target predicates or the Condition predicates evaluate to false, the policy or rule isconsidered not applicable to the request, and a Not Applicable value is returned. When a ruleapplies to a request, the value of its Effect attribute (Permit, or Deny) is returned as a result ofthe evaluation. As a policy typically contains multiple rules, XACML specifies a set ofCombining Algorithms to compose possibly contradictory multiple results into a uniqueresponse. For instance, when a policy relies on the Deny Overrides Algorithm, if anyevaluation 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 toyield a Permit final result.

The PDP is thus able to produce an answer on whether access should be granted (that is, adecision is taken). Such answer is returned to the PEP, which can then allow or deny access tothe requester (that is, the decision is enforced).

PEP and PDP are here treated as two logically distinct units, but they might both be includedin 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 policyA Request element generated to meet the request from Seth of the developers' group to read adocument on the server would look like this:

28

<Request><Subject>

<Attribute Id="subject-id" DataType="rfc822Name"><AttributeValue>seth@users.example.com</AttributeValue>

</Attribute><Attribute Id="group" DataType="string">

<AttributeValue>developers</AttributeValue></Attribute>

</Subject><Resource>

<Attribute Id="resource-id" DataType="URI"><AttributeValue>http://server.example.com/docs/guide.html</AttributeValue>

</Attribute></Resource><Action>

<Attribute Id="action-id" DataType="string"><AttributeValue>read</AttributeValue>

</Attribute></Action>

</Request>

A Policy that applies to such request follows:<Policy PolicyId="ExamplePolicy"

RuleCombiningAlgId="permit-overrides"><Target>

<Resources><Resource>

<ResourceMatch MatchId="URI-equal"><AttributeValue DataType="URI">

http://server.example.com/docs/guide.html</AttributeValue><ResourceAttributeDesignator DataType="URI"

Id="resource-id"/></ResourceMatch>

</Resource></Resources>

</Target><Rule RuleId="ReadRule" Effect="Permit">

<Target><Actions>

<Action><ActionMatch MatchId="string-equal">

<AttributeValue DataType="string">read</AttributeValue><ActionAttributeDesignator DataType="string"

AttributeId="action-id"/></ActionMatch>

</Action></Actions>

</Target><Condition FunctionId="string-equal">

<Apply FunctionId="string-one-and-only"><SubjectAttributeDesignator DataType="string"

AttributeId="group"/></Apply><AttributeValue DataType="string">developers</AttributeValue>

</Condition></Rule>

</Policy>

This policy, called ExamplePolicy, targets all requests of actions on a resource whose URI ishttp://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 requestingsubject 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 thepolicy. The PDP then sends to the PEP the following Response item:

29

<Response><Result>

<Decision>Permit</Decision><Status>

<StatusCode Value="ok"/></Status>

</Result></Response>

XACML does not provide any description of the vocabularies used in the policies, whosedefinition lies outside the scope of this specification. Policies must include all the informationneeded to identify and evaluate each attribute used in the policy.

4.1.3 Relations to other proposals and to the PrimeLife projectXACML 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 intoexisting entitlement engines. Still, detailed comparisons in the literature [TREPALXACML]show that XACML provides a more comprehensive access control policy language than itsmost significant competitor EPAL (see chapter 4), and also a fully-featured privacy policylanguage.

4.1.4 Current status of the XACML proposalThe latest XACML version 2.0 was ratified by OASIS standards organisation on 1 February2005. 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 XACMLTechnical 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 RuleInterchange Format (RIF [RIF]) Working Group at W3C to allow computer-processable rulesto be transferred between rule systems. RIF is a work-in-progress, and what is described hereis 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 theWorking Group proceeds.

4.2.1 RIF DialectsThe RIF family of languages (each called a "dialect") is organised to match the different kindsof technologies used to work with rules. It starts with a common language, RIF Core, whichcorresponds to the shared subset (the intersection) of major rule languages. Rules written inthis XML language can be translated with relative ease to nearly all other major rulelanguages. Simple rules can be be written in RIF Core, or translated to RIF Core, but manypractical rule bases will only be transferable using some other dialect. Expressively, RIF Coreis datalog (the language of positive Horn clauses without function terms), along with someprimitive datatypes (such as integers and strings), and the common operations on thosedatatypes (such as addition and string concatenation). The syntax of RIF is designed to bequite general, and to be straightforward to parse and generate, so it is naturally verbose. Apart of an example rule about the perishability of items, from one of the RIF working drafts, isgiven here:

...<sentence>

<Forall><declare><Var>item</Var></declare><declare><Var>deliverydate</Var></declare><declare><Var>scheduledate</Var></declare><declare><Var>diffduration</Var></declare><declare><Var>diffdays</Var></declare><formula>

<Implies><if>

<And><formula>

<Atom><op><Const type="rif:iri">cpt:perishable</Const></op><arg><Var>item</Var></arg>

</Atom></formula>

...

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 betrue)", or if-condition-then-condition. This is the style of rule handled by pure Prolog, by FOLlogic theorem provers, and by many systems with varying degrees of acceptance over the past40+ years. Along the logic branch, the RIF Basic Logic Dialect, or RIF BLD provides acommon subset language. It extends RIF Core by adding function terms and equality, alongwith argument naming and membership/subclass structures. It does not, however, include anyform of negation, since logic languages diverge sharply around the types of negation theyimplement, primarily (monotonic) classical negation as opposed to some form of (non-monotonic) negation-as-failure. In the future, the Working Group expects to provide somedialects aligned with some of these branches.

4.2.2 Use CasesThe use cases [RIF Use Cases] and applications for RIF cover much of the space ofdistributed information systems. Wherever there is information processing, the option ofusing 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 (FairIsaac, the company behind FICO credit scores, is a major rule system vendor and a foundingparticipant in the RIF Working Group), regulatory compliance in banking, and health caredelivery. To date, most major rule systems have been closed-architecture, single-providersystems. With RIF, we begin to see the possibility of rules being developed on one systemand then easily moved to another, allowing customers to avoid vendor lock-in, developing astronger market, and encouraging more investment in long-term rule bases. Ruleinteroperability enables many more applications, though, when distributed systems canexchange rules. For example, vendors can publish complex, dynamic pricing structures (asrules), and then customers can (computationally) determine the most efficient purchases toinitiate. Complex negotiations, with ensuing efficiencies become possible all along the supplychain, 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 researchand health care delivery. In research, data integration is an enormous problem because of thevast variety of medical research; effectively mining that data, to find the relevant bits of aparticular task, is essential. Rule systems (and related Semantic Web technologies, like theOWL Web Ontology Language) can greatly ease the integration effort. On the clinical side,rule systems can help physicians make diagnoses and orchestrate treatments (includingdetecting likely errors). Since many of these benefits increase with the scale of the market forrules (more users of rulebases, more providers of rulebases), a common interchange formatshould significantly improve the end benefits for research and to patients.

4.3 P3PThe Platform for Privacy Preferences Project [P3P] enables Web sites to express their privacypractices in a standard format that can be retrieved automatically and interpreted easily byuser agents. P3P user agents will allow users to be informed of site practices (in bothmachine- and human-readable formats) and to automate decision-making based on thesepractices when appropriate. Thus users need not read the privacy policies at every site theyvisit.

Although P3P provides a technical mechanism for ensuring that users can be informed aboutprivacy policies before they release personal information, it does not provide a technicalmechanism for making sure sites act according to their policies. Products implementing thisP3P 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. Wherevernotices 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 transferringdata or for securing personal data in transit or storage, but it can be used by tools that decideon data flow.

P3P has 3 components:

• a protocol: The P3P protocol allows user agents to discover privacy metadata abouta given Web site. This is done either via a well-known location, a HTTP header, or alink-tag inside the <head> - element of an HTML page.

• a vocabulary: The P3P vocabulary allows to express data handling practices likeidentification 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 toexpress personal data. It is used to express the object of the statement element. This

32

allows to have a level of detail that can go down to one policy per data item, e.g. totreat the given name different than the family name.

4.3.1 StatusThe P3P 1.0 Specification [P3P 1.0 Spec] became a W3C Recommendation on 16 April 2002after 5 years of intense development with numerous obstacles. The initial idea of a walletservice and a negotiation protocol [Removing Data Transfer from P3P] proved to be tooambitious and P3P was toned down to a pure policy language able to express data collectionand usage services in a machine readable syntax.

The first rather rudimentary implementation was Microsoft's Internet Explorer 6.0. It onlyanalysed the HTTP headers that contained tokens called Compact Policy [Compact Policy] inthe P3P Specification. Based on the privacy practices expressed in the tokens, cookies wereblocked 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 goodreporting tool. Whenever there is a mismatch, the bird turns into angry red and the policyreport shows exactly where the mismatch between the user's preferences and the site's policyis. The most complete tool implemented was the P3P Implementation [JRC P3P ResourceCentre] of JRC [JRC]. This is a Java based proxy implementation, but development hasstopped.

After experiences with P3P, feedback triggered two further Workshops: One on incrementalimprovements [Future of P3P Workshop 2002] and another on the long term vision [Future ofP3P 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 relatedsites. P3P 1.0 did not say anything about the user agent. After testing, it appeared that peoplewanted to have a standard answer to a standard situation. The user agent guidelines reflectedthis. Even today, the challenge of an efficient privacy dashboard is still open, let alone theintegration into the Web browsers.

But in the aftermath of 9/11 governments started massively to increase data collection. Theprivacy debate shifted back where it came from, notably privacy as a right against thegovernment. This debate took near to all interest away from privacy in private services anddevelopment slowed down. P3P 1.1 [P3P 1.1 Spec] was published as a Working Group Note.

4.3.2 ConclusionP3P work remains very important for PrimeLife as it was the first attempt to express datahandling in a structured machine readable way. It shows the way forward and resulted notonly in a lot of Web site implementations, but also in a flood of research publications thattried to further the approach taken by P3P. Despite the fact that it was not addressed in theP3P Specification, the use of policies for data governance was always one aspect of the workand IBM realised this approach with the Tivoli Privacy manager handling data in the backendusing 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 sitesto acquire metadata and draw conclusions. Many of the P3P challenges are still unresolvedand can be further advanced by the research done in PrimeLife.

33

4.4 APPELAPPEL [APPEL] specifies a language for describing collections of preferences regarding P3Ppolicies between P3P agents. Using this language, a user can express preferences in a set ofpreference-rules (called a ruleset), which can then be used by the user agent to makeautomated or semi-automated decisions regarding the acceptability of machine-readableprivacy policies from P3P enabled Web sites.

At some point in time, the P3P Specification Working Group thought that a commoninterchange language for specifying user preferences which is understood by all P3Pimplementations is a condition for user acceptance and adoption of this technology. Severalother efforts have addressed a similar problem for other communities, PICS Rules, andProfiles 0.94 for example. An interchangeable format for preference rules would allow dataprotection professionals to disseminate minimum guidelines and default privacy protectionlevels to users who have neither the time nor the knowledge to create it themselves.

4.4.1 ShortcomingsIn 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 XMLrule 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 resultsin an extremely complex interface. Only one utility was ever built, designed as part of theJRC P3P project [JRC P3P Resource Centre] tried to come up with an interface. Thisinterface proved to be even too complex for experts.

Additionally, APPEL had some unpredictable behaviour as a P3P policy could be written intwo different ways but having the same meaning and the APPEL rule would lead to the sameunexpected results. This was due to the fact that APPEL was the first trial to construct a rulelanguage based on RDF technologies. There were suggestions to improve the user interfaceby a move of P3P to a formalised ontology, but this was not taken up by the P3P SpecificationWorking Group due to a lack of support from the community and the implementers. As anendpoint APPEL was published as a Working Group Note on 15 April 2002. It is used inmost P3P implementations (e.g. PrivacyBird [Privacy Bird]) as an import format andsubsequently 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 theSemantic Web [Semantic Web] technology. The engineers realised that they needed a newclean approach that is not tight to privacy only. After long scientific discussions, W3Cchartered the Rule Interchange Format (RIF) Working Group [RIF] that is still running. Aprivacy ontology was developed by the PRIME Project [PRIME]. RIF is only a frameworkfor rulesets. There is the option for PrimeLife to combine the privacy ontology developed byPRIME with the framework set by RIF in order to develop a new RIF-compliant rulelanguage. The PRIME obligation language is an obvious candidate to learn more and to refinethe approach to rules.

4.4.2 ConclusionAPPEL is a very important historical step towards rule languages and was slightly premature.APPEL helps to understand the very fundamental issues concerning semantics and syntaxraised 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 toprivacy rules.

4.5 Enterprise Privacy Authorisation Language(EPAL)Enterprise Privacy Authorisation Language [EPAL] is a framework for managing collectedpersonal 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 policyAn EPAL policy is given in the form of a XML data structure and includes three mainsections.

• 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 EPALvocabulary that describes all the components that can be used in the rules in thefollowing section. These components deal with the entities typically involved in atransaction: Data Users, Data Categories, Actions, Purposes, Conditions,Obligations, Context Models.

• The Ruling Set includes the rules that define whether a Data User is allowed ordenied to perform an Action on a Data Category for a certain Purpose under specificConditions. The rules are ordered with descending precedence, that is, if a ruleapplies (i.e. allows or denies a request), subsequent rules are ignored. To beapplicable 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 mandatoryDefault Ruling. The Default Ruling ("allow", "deny, or "not-applicable") is returned as aresult of the policy evaluation if the Global Condition is false or no rule within the policy isapplicable.

4.5.2 An EPAL policy exampleA simplified example of an EPAL policy follows:

<epal-policydefault-ruling="deny"global-condition="isChild"xmlns=..."><policy-information

id="coppa-policy"><issuer>

<name>Guenter...</name><organization>IBM Research</organization>...

</issuer><version-info

last-modified="2003-12-10T12:00:00".../>

35

</policy-information><epal-vocabulary-ref

id="coppa-vocabulary"revision-number="1"location="http://www.epal-research.com/epal-coppa-vocabulary.xml"/>

<conditionid="isChild"><short-description

language="en">This condition is true if the data-subject is a childaccording to COPPA (i.e., age<=13).

</short-description><predicate

refid="http://www.research.ibm.com/privacy/epal#integer-less-than"><attribute-reference

container-refid="datSubjectInfo"attribute-refid="age"/>

<attribute-valuesimpleType="http://www.w3.org/2001/XMLSchema#integer">13</attribute-value>

</predicate></condition><condition

id="hasParentConsentToCollect"><short-description

language="en">Parent consent for collection.

</short-description><predicate

refid="http://www.research.ibm.com/privacy/epal#boolean-equal"><attribute-value

simpleType="boolean">true</attribute-value><attribute-reference

attribute-refid="parentConsentedToCollect"/></predicate>

</condition>

<ruleid="rule1"ruling="allow"><user-category

refid="Operator"/><data-category

refid="PI"/><purpose

refid="any-purpose"/><action

refid="store"/><condition

refid="hasParentConsentToCollect"/></rule>

</epal-policy>

The policy above allows to collect children's data and store it provided parent consent hasbeen given. All elements whose definition is not provided in this epal-policy element aredefined in vocabularies to which references are provided in the policy itself.

4.5.3 An EPAL query exampleA typical EPAL authorisation query looks like follows. This is an example to which thepolicy above applies.

<epal-queryxmlns=...><user-category refid="Operator"/><data-category refid="PI"/><purpose refid="Inventory"/><action refid="Store"/>

36

<container refid="UsersRecord"><attribute refid="UserID">

<value>0123456789</value></attribute>

</container></epal-query>

The refid attribute of the Container element refers to the container of the policy that isinstantiated for the authorisation evaluation. Moreover, it contains one or more attributeelements with the actual attribute values to be used to evaluate the relevant conditions. Somepolicies 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 scenarioIn 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 identifiableinformation data. The consent and the relevant policy are logged, and the privacymanagement enforcement monitors ensure that only data accesses by the enterprise'semployees are allowed that conform to the privacy policy.

4.5.5 Relations to other standards and to the PrimeLife projectAs 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 storedand enforced in an enterprise's IT system relying on EPAL. However, this approach shouldnot be taken as paradigmatic, in that the EPAL policy language has a greater expressivity, sothat 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 PrimeLifemust deal with.

4.5.6 Status of the EPAL proposalEPAL was submitted to W3C in 2003 for consideration as a privacy policy language standard.

4.6 CARMLCARML (Client Attribute Requirements Markup Language) is a specification language thataims at defining application identity requirements, that is, what identity information anapplication 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 identifiableinformation.

The CARML specification provides a standard way for a client application to request for datafrom a service provider, but it does not guarantee that the client application will receive whatis requested.

37

It is assumed that applications only require a fixed set of interactions dealing with identitydata, as follows:

• information about a user is looked up by means of one or more indexes, whichtypically consists of a subject name derived by an authentication process, or anattribute (e.g. social security number)

• some tests are performed to check whether a subject has a property (with unknownvalue), or a property with a value that will be known at runtime, or a property with afixed 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 ismostly expected that developer tools using CARML would promote the usage of schemataand dictionaries already specified by an enterprise.

4.6.1 Elements of the CARML languageCARML relies on the SAML syntax as described in SAML V2.0 [Semantic Web] for severalof its elements.

For subject indexes, a SubjectIndexes element is introduced, including oneIndexNameIdentifier element or one or more IndexAttribute elements. In the followingexample, the client declares that a pair of values (e-mail address and Country) will be used asindexes, the client will provide an e-mail address and the service provider is to assume that astatic attribute of Country="US" is to be used:

<SubjectIndexes><IndexNameIdentifier>

urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</IndexNameIdentifier><IndexAttribute Name="Country"

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"xsi:type="countrycode">

<saml:AttributeValue xsi:type="xs:string">US</saml:AttributeValue></IndexAttribute>

</SubjectIndexes>

When an application needs to send boolean questions to a service provider, those questionsare specified in the form of Property elements. Property elements may include a descriptionthat aids the identity service managers in defining the appropriate values. The followingexample includes a sequence of properties: the first asks the question whether the user hasproperty AboveEighteen, the second states that an EmploymentLevel will be provided atruntime and the third that the application wishes to check whether the user has a Departmentproperty and whether it is set to value Information Technology.

<Properties><CarmlProperty Name="AboveEighteen"

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"Description="Is the subject over eighteen as of current date?"/>

<CarmlProperty Name="EmploymentLevel"><saml:AttributeValue xsi:type="xs:string"></saml:AttributeValue>

</CarmlProperty><CarmlProperty Name="Department">

<saml:AttributeValue xsi:type="xs:string">Information Technology

38

</saml:AttributeValue></CarmlProperty>

</Properties>

Finally, CARML defines an Attribute element that lists the attributes (specified on the basis ofthe SAML attribute schema) the client application is requesting to be returned with thesubject by the service provider, like in the following example:

<Attributes><CarmlAttribute Name="FirstName"

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" /><CarmlAttribute Name="LastName"

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" /><CarmlAttribute Name="EmployeeId"

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"xsi:type="string" />

</Attributes>

For each attribute-related request, the reply may include no values, one or more values, or anexception indicating unauthorised requests or filtering due to policy conditions. Attributedeclarations can include a Modifiable permission flag to enable users to modify the relevantvalues, as in the following example, in which Language is modifiable, while Country is read-only:

<Attributes><CarmlAttribute Name="Language"

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Modifiable="true"/><CarmlAttribute Name=”Country”

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" /></Attributes>

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 proposalThe latest working draft on CARML was published in 2006.

4.6.3 AAPMLAAPML (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 ofpolicies the conditions under which information in their control may be used by otherapplications.

4.7 Identity Governance FrameworkThe Identity Governance Framework [IGF] is an open initiative which aims at tackling theissues related to the management of identity related information across enterprise IT systems.This initiative includes proposals of specifications for a common framework to define usagepolicies (AAPML Specification [AAPML Spec]), attribute requirements (CARMLSpecification [CARML Spec]), and the relevant developer APIs. These proposals are meantto enable businesses to guarantee documentation, control, and auditing with respect toacquirement, use, storage, and propagation of identity-related data through applications andsystems.

39

Oracle announced the initiative together with the founding participants (Computer Associates,Layer 7 Technologies, HP, Novell, Ping Identity, Securent, Sun Microsystems) in November2006. The initiative was submitted royalty-free in February 2007 to the Liberty Allianceconsortium, which aims at building a more trusted Internet by addressing the technology,business and privacy aspects of digital identity management and whose Management Boardincludes representatives from AOL, Ericsson, Fidelity Investments, France Telecom, HP,Intel, Novell, NTT, Oracle, and Sun Microsystems.

4.8 PRIME Policy LanguagesThe PRIME project is a large-scale research effort aimed at developing an identitymanagement system able to protect user personal information and to provide a framework thatcan be smoothly integrated with current architectures and online services. In this context animportant service for helping users to keep control over their personal information isrepresented by access control solutions enriched with the ability to support privacyrequirements. To fully address the requirements posed by a privacy-aware access controlsystem, the following different types of privacy policies have been defined in the context ofPRIME.

• Access control policies. They govern access/release of data/services managed by theparty (as in traditional access control). Access control policies define authorisationrules concerning access to data/services. Authorisations correspond to traditional(positive) rules usually enforced in access control systems. An access control rule isan expression of the form:

<subject> with [<subject_expression>] can <actions> on <object>with [<object_expression>] for <purposes> if [<conditions>]

• Release policies. They govern release of properties/credentials/personal identifiableinformation (PII) of the party and specify under which conditions they can bereleased. Release policies define the party’s preferences regarding the release of itsPII by specifying to which party, for which purpose/action, and under whichconditions a particular set of PII can be released. Although different in semanticaccess control and release policies share the same syntax.

• Data handling policies. They define how personal information will be (or should be)dealt with at the receiving parties. Data handling policies regulate how PII will behandled at the receiving parties (e.g., information collected through an online servicemay be combined with information gathered by other services for commercialpurposes). Users exploit these policies to define restrictions on secondary use oftheir personal information. In this way, users can manage the information also afterits release. Data handling policies will be attached to the PII or data they protect, andtransferred as sticky policies to the counterparts. A DHP rule is an expression of theform:

<recipients> can <actions> for <purposes> if [<gen_conditions>]provided [<provisions>] follow [<obligations>]

A prototype providing functionalities for integrating access control, release and data handlingpolicies evaluation and enforcement has been developed in the context of the PRIME project.

4.8.1 Rough use casesThe reference scenario is a distributed infrastructure that includes three parties: i) users arehuman 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 itsservices; iii) external parties are entities (e.g., business partners) to which the service providermay want to share or trade personal information of users. The functionalities offered by aservice provider are defined by a set of objects/services. This scenario considers a user thatneeds to access a service. The user can be registered and characterised by a unique useridentifier (user id, for short) or, when registration is not mandatory, characterised by apersistent 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 widespreaddiffusion of e-commerce, that is, the ability to purchase, sell, and distribute goodsand services to customers. A primary concern in the development of e-commerce hasbeen to provide a secure global infrastructure through solutions for secure dataexchange and systems for protecting e-services from unauthorised accesses.However, in the last years, the focus is shifted from the protection of server-sideresources to the protection of user privacy. If users do not have confidence that theirprivate data are managed in a privacy-oriented way by the server, they will refuseparticipation in e-commerce. In this scenario, it is mandatory to provide users withthe possibility of protecting their privacy and their sensitive data, still accessing theonline services.

• Online healthcare system. Healthcare systems support interactions among patients,medical and emergency personnel, insurance companies, and pharmacies. Thesesystems allow for anonymous access to general information and advice, and enforceaccess control to individual patient records according to general rules, context (e.g.,treatment, emergency), and the patient’s specific choices (e.g., primary carephysician, health insurance). In this context, it is important to ensure to the patientsenhanced privacy functionalities to define restrictions regulating access andmanagement of their data.

• Location-Based Service (LBS). Technical improvements of location technologiespermit to gather location information with high accuracy and reliability. Physicallocation of individuals is then rapidly becoming easily available as a class ofpersonal information that can be processed for providing a new wave of online andmobile services, such as location-based access control (LBAC) services. In additionto LBAC services, many mobile network providers offer a variety of location-basedservices such as point of interests proximity, friend-finder, or location informationtransfer in case of an accident (e.g., 112 european emergency number). Such servicesnaturally raise privacy concerns. Users consider their physical location andmovements as highly privacy sensitive, and demand for solutions able to protectsuch an information in a variety of environments.

4.8.2 Distinctive features of PRIME languagesAccess Control/Release Model and Language

• XML-based syntax. The language provides an XML-based syntax for the definitionof powerful and interoperable access control and release policies.

• Attribute-based restrictions. The language supports the definition of powerful andexpressive policies based on properties (attributes) associated with subjects andobjects.

• Credential definition and integration. The language supports requests for certifieddata, issued and signed by authorities trusted for making the statement, anduncertified data, signed by the owner itself.

41

• Anonymous credentials support. The language supports definition of conditions thatcan be satisfied by means of zero-knowledge proof.

• Support for context-based conditions and metadata. The language allows thedefinition of conditions based on physical position of the users and contextinformation, and integration with metadata identifying and possibly describingentities of interest.

• Ontology integration. Policy definition is fully integrated with subject and objectontology in defining access control restrictions. Also, the language takes advantagesfrom the integration with credentials ontology that represents relationships amongattributes and credentials.

• Interchangeable policy format. Parties need to specify protection requirements onthe data they make available using a format both human- and machine-readable, easyto inspect and interchange.

• Interactive enforcement. Rather than providing a simple yes or no decision, policyevaluation provides a way of interactively applying criteria to retrieve the correctsensitive information, possibly managing complex user interactions such as theacceptance of written agreements and/or online payment.

• Variables support. Currently, access control/release language supports twoplaceholders, one for the subject and one for the object. This solution represents agood trade-off between expressivity and simplicity but can be easily extended tosupport variables definition.

Data Handling Model and Language

• Attribute-based restrictions and XML-based syntax. As for access control/releaselanguage, data handling language supports the definition of powerful and expressiveXML-based policies based on properties associated with subjects and objects.

• Customised policies. Data handling policies are defined through a negotiationbetween the user and the service provider. When a user requires a service,predefined policy templates are provided by the service provider as a starting pointfor creating data handling policies. The templates are then customised to meetdifferent privacy requirements. A user can directly customise the templates or it canbe supported by a customisation process that automatically applies some userprivacy preferences. If the customised data handling policies will be accepted by theservice provider, the personal information provided by the user will be labeled withthe customised data handling policies. This represents the most flexible and balancedstrategy 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 physicallyfollows the data when they are released to an external party, thus building a chain ofcontrol 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 thespecification of attribute-based restrictions. Main differences with PRIME languages are asfollows.

• XACML does not explicitly support privacy features.

42

• Although XACML supports digital credentials exchange, it does not provide requestfor 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-readableXML format. Designed to address the need of users to assess that the privacy practicesadopted by a server provider comply with their privacy requirements, P3P has been developedby the World Wide Web Consortium (W3C). Users specify their privacy preferences througha policy language, called A P3P Preference Exchange Language (APPEL), and enforceprivacy protection by means of an agent. Similarly to PRIME languages, P3P proposes aXML-based language for regulating secondary use of data disclosed for the purpose of accesscontrol enforcement. It provides restrictions on the recipients, on the data retention and onpurposes. Main differences with PRIME languages are as follows.

• P3P does not support privacy practices negotiation. In fact, users can only accept theserver privacy practices or stop the transaction. The opt-in/opt-out mechanismsresult 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-PolicyWS-Policy defines a framework for expressing the capabilities and the requirements ofentities 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 assertionsmay deal with lower-level communication properties, like which transport protocol is to beused, whether an authentication scheme should be maintained, as well as higher-level servicecharacteristics, such as a privacy policy or Quality of Service (QoS). The semantics ofindividual assertions (ranging from simple strings to complex combinations of items withattributes) 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 policyassertion or a set of assertions apply in a Web services environment.

4.9.1 Structure of a policyA policy is built from individual assertions grouped by policy operators, which are specificXML 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 XMLtags are used to make statements about policy combinations:

wsp:ExactlyOne asserts that only one child node must be satisfied; wsp:All asserts that allchild nodes must be satisfied.

Here is an example of a policy:<wsp:Policy

xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"xmlns:wsp="http://www.w3.org/ns/ws-policy" >

43

<wsp:ExactlyOne><sp:Basic256Rsa15 /><sp:tripleDesRsa15 />

</wsp:ExactlyOne></wsp:Policy>

The sp prefix corresponds to the namespace relevant to the domain in which the assertions aredefined (i.e.: WS-SecurityPolicy). As different assertions are inserted in an ExactlyOneoperator, here we have different alternatives. A Web service invocation must then use one ofthe asserted algorithm suites to comply with, or support the policy above. More generally, apolicy assertion made by a service provider is supported by a service requester when therequester satisfies the requirement expressed by the assertion; a policy alternative is supportedby a requester when all the assertions in the alternative are supported; finally, a policy issupported 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 policyA normal form is defined to simplify the manipulation and clarify the understanding ofpolicies. The structure of a normal form reflects the steps the basic policy processingoperation is comprised of: all the alternatives are enumerated within a wsp:ExactlyOneoperator, 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:<wsp:Policy

xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"xmlns:wsp="http://www.w3.org/ns/ws-policy" >

<wsp:ExactlyOne><wsp:All>

<sp:Basic256Rsa15 /></wsp:All><wsp:All>

<sp:tripleDesRsa15 /></wsp:All>

</wsp:ExactlyOne></wsp:Policy>

4.9.3 Compact form of a policyAs policies in a normal form can be very verbose, constructs are provided to express them ina compact form. If required by the policy processing software, the normal form can alwaysbe obtained by means of a recursive procedure which is illustrated in the WS-Policyspecification.

Compact expression of policies may be achieved in different ways, such as optionalassertions, policy assertion nestings, policy operator nestings, and policy inclusions.

The WS-Policy specification provides an optional attribute to indicate that a policy assertionis optional. This is semantically equivalent to express two policy alternatives with andwithout the assertion, respectively, so that

<Assertion wsp:Optional="true"> ... </Assertion>

is equivalent to

44

<wsp:ExactlyOne><wsp:All>

<Assertion> ... </Assertion></wsp:All><wsp:All />

</wsp:ExactlyOne>

Setting the value of this attribute to false is equivalent to omitting the attribute and thushaving a mandatory assertion.

4.9.4 Nested policiesThe WS-Policy syntax allows for an assertion to include a nested policy expression, as in thefollowing schema:

<Assertion>...<wsp:Policy> ... </wsp:Policy>...

</Assertion>

Policy assertions with nested policy expressions are normalised recursively.

Policies can be compactly expressed also by nesting operators wsp:Policy, wsp:All, andwsp:ExactlyOne within one another. Inference rules exploiting these operators' properties(e.g.: commutativity, associativity, idempotency, and distributivity) allow for thetransformation of compact expressions into normal form.

For instance, wsp:All distributes over wsp:ExactlyOne, so that<wsp:All>

<wsp:ExactlyOne><!--Assertion 1--><!--Assertion 2-->

</wsp:ExactlyOne></wsp:All>

is equivalent to<wsp:ExactlyOne>

<wsp:All><!--Assertion 1-->

</wsp:All><wsp:All>

<!--Assertion 2--></wsp:All>

</wsp:ExactlyOne>

4.9.5 References to other policiesThe WS-Policy allows for sharing of assertions across different policy expressions, by meansof the wsp:PolicyReference element. This element comes with an URI attribute that providesa 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 policyexpressions there is no requirement that the reference be resolvable, as retrieval mechanismsare external to the WS-Policy specification. When a wsp:PolicyReference element refers to awsp:Policy element, it prescribes to replace the wsp:PolicyReference element with a wsp:Allelement 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 awsp:All element. Here follows an example with a reference within a document.

<wsp:Policyxmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"xmlns:wsp="http://www.w3.org/ns/ws-policy" >xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"

wsu:ID="Protection" ><sp:EncryptSignature wsp:Optional="true" /><sp:ProtectTokens wsp:Optional="true" />

</wsp:Policy>

<wsp:Policyxmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"xmlns:wsp="http://www.w3.org/ns/ws-policy" ><wsp:PolicyReference URI="#Protection" /><sp:OnlySignEntireHeadersAndBody />

</wsp:Policy>

The specification prescribes that a policy must not refer to itself either directly or indirectly bemeans of a wsp:PolicyReference element.

4.9.6 Intersection of policiesGenerally, and more specifically also in the context of Web services, interactions can takeplace only when all involved parties agree on at least one policy alternative.

The WS-Policy specification allows for an intersection process that compares two policieslooking for common, or mutually compatible, alternatives. As the semantics of the comparedassertions lies beyond the scope of the domain-neutral WS-Policy framework, domainknowledge is clearly required to complete the intersection process.

Thus, in this specification only an algorithm is provided that approximates compatibility in adomain-independent fashion. The two policies are first normalised.

In a first comparison phase, each alternative from the first policy is compared to allalternatives from the second policy vocabulary-wise: to be compatible, two alternatives mustat least share the same vocabulary, that is, they must include assertions of the same type. Twoalternatives with different vocabularies are considered incompatible and discarded in thisphase.

The intersection of two compatible alternatives is an alternative which contains all theassertions from both intersected alternatives. If policy A contains an alternative which iscompatible with an alternative from policy B, then the two policies are compatible, and theirintersection 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 compatiblealternatives (alternative A2 from P1 and alternative A3 from P2), whose assertions constitutethe intersected policy:

Policy P1:<wsp:Policy

xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"xmlns:wsp="http://www.w3.org/ns/ws-policy" ><!-- Policy P1 --><wsp:ExactlyOne>

46

<wsp:All> <!-- Alternative A1 --><sp:SignedElements>

<sp:XPath>/S:Envelope/S:Body</sp:XPath></sp:SignedElements><sp:EncryptedElements>

<sp:XPath>/S:Envelope/S:Body</sp:XPath></sp:EncryptedElements>

</wsp:All><wsp:All> <!-- Alternative A2 -->

<sp:SignedParts><sp:Body /><sp:Header

Namespace="http://www.w3.org/2005/08/addressing" /></sp:SignedParts><sp:EncryptedParts>

<sp:Body /></sp:EncryptedParts>

</wsp:All></wsp:ExactlyOne>

</wsp:Policy>

Policy P2:<wsp:Policy

xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"xmlns:wsp="http://www.w3.org/ns/ws-policy" >

<!-- Policy P2 --><wsp:ExactlyOne>

<wsp:All> <!-- Alternative A3 --><sp:SignedParts /><sp:EncryptedParts>

<sp:Body /></sp:EncryptedParts>

</wsp:All><wsp:All> <!-- Alternative A4 -->

<sp:SignedElements><sp:XPath>/S:Envelope/S:Body</sp:XPath>

</sp:SignedElements></wsp:All>

</wsp:ExactlyOne></wsp:Policy>

Intersection of policies P1 and P2:<wsp:Policy

xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"xmlns:wsp="http://www.w3.org/ns/ws-policy" >

<!-- Intersection of P1 and P2 --><wsp:ExactlyOne>

<wsp:All><sp:SignedParts >

<sp:Body /><sp:Header

Namespace="http://www.w3.org/2005/08/addressing" /></sp:SignedParts><sp:EncryptedParts>

<sp:Body /></sp:EncryptedParts><sp:SignedParts /><sp:EncryptedParts>

<sp:Body /></sp:EncryptedParts>

</wsp:All></wsp:ExactlyOne>

</wsp:Policy>

The interpretation of the combined alternatives is beyond the scope of this specification, as itstrongly depends on the assertions' semantics. The rationalisation of the new, intersectedalternatives into something meaningful to the infrastructure requires domain knowledge. The

47

new policy might require further processing that might show that an alternative iscontradictory, and thus not meaningful to the underlying infrastructure that is responsible forperforming the required behaviours. In such a case the invocation of the intersection functionfails.

4.9.7 Relations to other proposals and to the PrimeLife projectWS-Policy provides a framework for expressing alternative sets of policy assertions fromvarious 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 privacypolicies. 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 assertionsfrom the domain-independent framework of policy management which should work as asignificant guideline for PrimeLife research.

4.9.8 Status of the WS-Policy proposalWS-Policy became a W3C Recommendation in September 2007, standardized by the W3CWeb Services Policy Working Group [WS-Policy WG]. The WS Policy Primer [WS-PolicyPrimer] is available as a companion document.

4.10 OASIS WS-XACMLWS-XACML [WS-XACML Spec] is a Web service profile that defines a standard way to useXACML 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 andcapabilities. WS-XACML defines a new XACML assertion to express them. Requirementsare expectations that each side has of the communication peer. Capabilities define what eachside can fulfil. Hence, we have four sets of assertions: capabilities and requirements both forclient side and the service side. WS-XACML offers a basic matching algorithm to matchthese four sets of policy. It mutually matches the requirements of the client side with thecapabilities of the services and vice versa the requirements of the service with the capabilitiesof the client. The standard gives some very interesting examples which fit well with plannedwork in PrimeLife. The service could require a particular authorisation attribute; the clientcan avoid trying to invoke the service if it does not possess this attribute. An extension of thisexample is that the service accepts only attribute claims which are signed by a trusted thirdparty. The service could demand that the client is acting in a particular role; the service knowsthis in advance and can initiate the role switch before invoking the service. Of course also theclient could impose obligations on the service. The standard mentions an example policy thatdemands that the service does not share private information which a client has to submit wheninvoking this service. Given that a client can choose between various instances of a particularservice, it now can decide which one is willing to fulfil the requirements best. In a moreflexible scenario one service could offer various resources coming with different privacypolicies. Although WS-XACML does not offer a pattern to negotiate between client andservice, 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 P3Ppolicy preferences and matching them using the new assertion for requirements andcapabilities.

48

In summary, WS-XACML addresses an important practical issue of XACML. XACML itselfdefines just the assertions and how to combine them. The WS-XACML draft standard offers aprofile 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 lacksa negotiation protocol to balance requirements and capabilities, the matching algorithms arevery 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 languagedeveloped to meet the access control requirements of large-scale Grid ComputingEnvironments. It is a declarative, logic-based, language that builds on a large body of workshowing the value of such languages for flexibly expressing security policies. It was designedto be comprehensive and provides a uniform mechanism for expressing trust relationships,authorisation policies, delegation policies, identity and attribute assertions, capabilityassertions, revocations, and audit requirements. This provides tangible benefits by making thesystem understandable and analysable. It also improves security assurance by avoiding, or atleast severely curtailing, the need for semantic translation and reconciliation betweendisparate security technologies.

49

Chapter5Authentication Infrastructure5.1 The ITU-T X.509 StandardX.509, also known as ISO/IEC 9594, is an ITU-T that represents the normative standard forPublic Key Infrastructure (PKI). It addresses some of the security requirements in the areas ofauthentication and other security services through the provision of a set of frameworks uponwhich 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 theinformation objects for Public Key Infrastructure (PKI) and Certificate Revocation List(CRL).

The attribute certificate framework defines the information objects for Privilege ManagementInfrastructure (PMI) and Attribute Certificate Revocation List (ACRL). This specificationprovides, for instance, the framework for issuing, managing, using and revoking certificates;an extensibility mechanism that defines formats for both certificate types and for allrevocation list schemes; a set of standard extensions which is expected to be generally usefulacross a number of applications of PKI and PMI, and, schema components such as objectclasses, 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 otherstandards 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 varietyof applications and environments. The directory makes use of public-key and attributecertificates, 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 encrypteddata in the directory. Attribute certificates can be used by the directory to enable rule-basedaccess control. Although the framework for these is provided in this specification, the fulldefinition of the directory's use of these frameworks, and the associated services provided bythe 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 supportedby authentication.

It describes two levels of authentication: simple authentication, using a password as averification of claimed identity; and strong authentication, involving credentials formed usingcryptographic techniques. While simple authentication offers some limited protection againstunauthorised access, only strong authentication should be used as the basis for providingsecure 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 ProcessX.509 is part of the hierarchical X.500 standard and thus assumes a strict hierarchical systemof certificate authorities (CAs) for issuing the certificates. This is in contrast to Web of trustmodels, like PGP, where anyone (not just special CAs) may sign (and thus attest to thevalidity) of others' key certificates. X.500 standard defines how global directories should bestructured. 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, suchas country, state, and city.

The X.500 standard was intended to give a worldwide unique identifier structure. The X.500system has never been fully implemented, so the IETF's public-key infrastructure WorkingGroup has made extensive updates to the standard in order to make it work with the moreloose organisation of the Internet. In the X.509 system, a CA issues a certificate binding apublic 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-mailaddress or a DNS-entry.

Root certificates can be issued to all employees by an organisation so that all employees canuse the company PKI system. Browsers such as Microsoft Internet Explorer, Netscape/Mozilla and Opera come with root certificates pre-installed, so SSL certificates from largervendors who have paid for the privilege of being pre-installed will work instantly; in essencethe browser's programmers determine which CAs are trusted third parties. Whilst their rootcertificates can be disabled, users rarely do it.

X.509 also includes standards for Certificate Revocation List implementations, an oftenoverlooked necessity in PKI systems. The X.509 standard defines what information can gointo 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, whichaffects 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 serialnumber to distinguish it from other certificates it issues. This information is used in numerousways, for example when a certificate is revoked its serial number is placed in a CertificateRevocation List (CRL).

Signature Algorithm Identifier This identifies the algorithm used by the CA to sign thecertificate.

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 somecases, 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 isdescribed by a start date and time and an end date and time, and can be as short as a fewseconds or almost as long as a century. The validity period chosen depends on a number offactors, such as the strength of the private key used to sign the certificate or the amount one iswilling to pay for a certificate. This is the expected period that entities can rely on the publicvalue, if the associated private key has not been compromised.

Subject Name The name of the entity whose public key the certificate identifies. This nameuses the X.500 standard, so it is intended to be unique across the Internet. This is theDistinguished 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, togetherwith an algorithm identifier which specifies which public key crypto system this key belongsto and any associated key parameters.

5.1.2 Evolution of the X509 standardX.509 Version 1 It has been available since 1988, is widely deployed, and is the mostgeneric.

X.509 Version 2 The second version introduced the concept of subject and issuer uniqueidentifiers to handle the possibility of reuse of subject and/or issuer names over time. Mostcertificate profile documents strongly recommend that names not be reused, and thatcertificates should not make use of unique identifiers. Version 2 certificates are not widelyused.

X.509 Version 3 The most recent version (1996) supports the notion of extensions, wherebyanyone can define an extension and include it in the certificate. Some common extensions inuse 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 publickey, e.g. DNS names, e-mail addresses, IP addresses). Extensions can be marked critical toindicate that the extension should be checked and enforced/used. For example, if a certificatehas the KeyUsage extension marked critical and set to "keyCertSign" then if this certificate ispresented 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 notfor 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 singleway to store and transfer that data. People have been known to describe this combinationsimultaneously as "powerful and flexible" and as "cryptic and awkward". The IETF PKIXWorking Group is in the process of defining standards for the Internet Public KeyInfrastructure.

5.2 PKIXThe PKIX is a Working Group established in the autumn of 1995 with the intent ofdeveloping Internet standards needed to support an X.509-based PKI. The scope of PKIXwork has expanded beyond this initial goal. PKIX not only profiles ITU PKI standards, butalso develops new standards apropos to the use of X.509-based PKIs in the Internet. PKIXhas produced several informational and standards track documents in support of the originaland revised scope of the WG.

The first of these standards, RFC 2459, profiled X.509 version 3 certificates and version 2CRLs for use in the Internet. Profiles for the use of Attribute Certificates (RFC 3281), LDAPv2 for certificate and CRL storage (RFC 2587), the Internet X.509 Public Key InfrastructureQualified Certificates Profile (RFC 3039/3739), and the Internet X.509 Public KeyInfrastructure 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 StatusProtocol (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 ofFTP and HTTP for transport of PKI operations (RFC 2585) are representative of theexpanded scope of PKIX, as these are new protocols developed in the Working Group, notprofiles of ITU PKI standards.

5.2.1 X.509 Attribute Certificate and Privilege ManagementInfrastructureX.509v3 2000 recommendation includes an architecture for Privilege Management based on aform of Attribute Certificate. The attribute certificate framework defined here provides afoundation upon which Privilege Management Infrastructures (PMI) can be built. Theseinfrastructures can support applications such as access control.

The binding of a privilege to an entity is provided by an authority through a digitally signeddata structure called an attribute certificate or through a public-key certificate containing anextension defined explicitly for this purpose. The format of attribute certificates is definedhere, including an extensibility mechanism and a set of specific certificate extensions.

Revocation of attribute certificates may or may not be needed. For example, in someenvironments, 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 hasoccurred so they do not use an untrustworthy certificate.

Revocation lists are one scheme that can be used to notify users of revocations. The format ofrevocation lists is also defined in this specification, including an extensibility mechanism anda set of revocation list extensions. Additional extensions are defined here. In both thecertificate and revocation list case, other bodies may also define additional extensions that areuseful to their specific environments.

A system using an attribute certificate needs to validate it prior to using that certificate for anapplication. Procedures for performing that validation are also defined here, includingverifying the integrity of the certificate itself, its revocation status, and its validity withrespect to the intended use.

This framework includes a number of optional elements that are appropriate only in someenvironments. Although the models are defined as complete, this framework can be used inenvironments where not all components of the defined models are used. For example there areenvironments where revocation of attribute certificates is not required. Privilege delegationand 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 haverequirements for them can also be supported. The directory uses attribute certificates toprovide rule-based access control to Directory information.

5.2.2 Relationship to PrimeLifeAs X.509v3 is traditionally used to structure public key certificates, it seems natural to offerX.509v3 versions of issuer keys, used in anonymous credential systems. These keys areneeded 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 thisuser, will also need these issuer keys to check the correctness of the proof. The effort torepresent issuer keys in X509v3 will be possible without massive impact on the X.509standard, as it would only require to look for a way to represent non-standard key material inthe 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 operatingsystems 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 alsopossible to represent the private certificate of the user in X.509v3 format. However, thiswould introduce additional complexity:

• the issuer verification key should be present in the certificate, so an unsupported keyformat is needed (same as above)

• the process of generating the signature and the representation of the signature valuein the X.509v3 certificate is regulated by CMS (Cryptographic Message Syntax,PKCS#7). Solving the problem of the signature value representation, and thesignature algorithm identifier, might be possible, but it might be necessary to changethe PKCS#7 processing rules to be able to produce a usable X.509v3 representationof a private certificate. Those changes would violate the standard, which would forceus to write our own PKCS#7 software, or to massively change an existing opensource implementation. In this case, standard PKCS#7 implementations wouldn't beable to parse our changed format, even if they would allow for plug-inimplementations 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. Apartfrom the fact that this might seem odd for those used to X.500, it is necessary toinvestigate how certain data fields have to be completed (one of those examples isSubject DN)

A third opportunity is to represent the result of a credential show in CMS/PKCS#7 format oras a X.509v3 attribute certificate. In the CMS case, this would be done in a similar fashion asmentioned in "Assertion-Based Signatures" (XMLDSIG (see chapter 5)). Most of theproblems originate from the fact that the signature algorithm employed does not have aclassical structure. As the X.509v3 case is very similar with regards to limitations, it wouldrequire a way to represent the proved assertions in the X.509 attribute data model.

5.3 XML Signature5.3.1 Specification OverviewThe XML Signature specification [XML Sig] describes a format that can be used toencapsulate cryptographic signatures of arbitrary content in XML, and to sign XMLdocuments, or subsets of such documents. The specification is designed to be highlyextensible: Signed information can be subject to arbitrary transformations before signing.Algorithms - both cryptographic and otherwise - are identified by way of URIs and thereforeexchangeable.

A typical signature consists of a SignedInfo element that describes the data that weresigned, and the steps applied to it in order to generate the signature. Specifically,SignedInfo identifies the canonicalisation method that is applied to transform the elementitself 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 iscanonicalised, hashed and signed according to the given signature algorithm. Informationabout the signing key can be part of a KeyInfo element.

The processing model for XML Signature requires that each Reference element bedereferenced, transformed, and hashed. The validity of an XML Signature therefore impliesthat the referenced resource (as transformed) was unchanged.

To enable different models and broader semantics, XML Signature supports the Objectelement as an extensibility point which may, in particular, hold a Manifest which is byitself a collection of Reference elements. Processing for Reference elements within aManifest 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 Manifestwill depend on the application context. (For example, a manifest might be used to hold digestvalues of multiple representations of the same resource; in this case, it might be enough forone of several digest values to match.)

To hold further signature semantics, the optional SignatureProperty element mayoccur within an Object element; this element is specifically designed to hold additionalinformation about the creation of its target signature. It can, e.g., be used to hold informationabout time stamps or signature generation hardware.

55

5.3.2 StatusXML Signature is a broadly implemented specification, and used as a basic signing primitivefor - among others - SAML and WS-Security. The XADES [XADES] specification foradvanced electronic signatures profiles and extends XML Signature.

The original XML Signature specification was jointly developed by W3C and the IETF, andfirst 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 XMLSignature Recommendation. Republication of this document within the IETF framework isexpected.

The W3C Workshop on Next Steps for XML Signature and XML Encryption [XML Sig/EncWorkshop] in September 2007 led to a proposal for further work on XML Signature. Thisnew work [XML Security] -- launched in May 2008 -- will focus on issues with thespecification that have been identified as a result of six years of research and deploymentexperience, in particular peculiarities of its referencing and transform model, choice ofmandatory cryptographic algorithms, and the performance impact of XML canonicalisation.

5.3.3 PrimeLife ImpactIn PrimeLife we are interested in capturing the privacy enhancing aspects of signature relatedprimitives. 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 varietyof features that allow them to emulate other privacy enhancing mechanisms such as groupsignatures and e-cash. They are also a major building block in realising privacy preservingattribute based access control. While our discussion could be kept more general we focus onanonymous credentials as they cover most of the cases.

There are several ways in which signatures and anonymous credentials are related. Thoserelations 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 sometimescalled 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 thesesignatures directly with a verifying entity. So this would be mostly an archiving and dataexchange 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 keyand different attributes) can be turned into non-interactive proofs using the Fiat-Shamirheuristic. 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 intothe 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, thatprove assertions about the attributes of credentials, such as anonymous credentials, groupsignatures, and ring signatures, do not that easily fit into the framework (as they require themessage 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' theoriginal signature on these attributes to a verifier. This passing on has certain desirableprivacy preserving properties, such as: unlinkable to issued signature, selective disclosure ofattributes, conditional showing of attributes (basically all those features that anonymouscredentials provide). In this interpretation no new message is signed by the user. The useronly transforms the signature obtained by the credential issuer into a new format that revealsless information about data that was already signed hiding for instance his identity.

This again could be expressed in XMLDSIG and deserves further consideration. A criticalproperty of XML Signature is the fact that signature algorithms proper are applied to an XMLdescription 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 oftendesirable to be able to directly interact with the signed material.

Such direct interactions with the signed material include showing only parts of the signedmaterial, or predicates or functions computed from signed values. This partial showing ofsigned material involves the owner of the signature as an active entity. As such the owner canchoose what to reveal about the signed material and what to keep secret. However, he canonly generalise the data but not change the assertions made by the issuing organisation.

57

Chapter6User Control Infrastructure6.1 Smart Cards: User-controlled Token for PrivacyProtection6.1.1 IntroductionIn a single sentence a smart card can be defined as

a personalised physical token under control of the user that can be used to performcryptographic 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 arethe same. A multi-application card, where multiple independent application issuers maintainseparate "card applications" on a shared card is technically possible, yet has not seen any realdeployments.

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 inmobile telephones where the card is used as the subscriber identity module (SIM). Bankingcards are being migrated from pure magnetic strip cards to smart cards with magnetic strip asbackup. Citizen ID cards and healthcare insurance cards have been issued or will be issued inmany countries.

Trusted device

A smart card is operated as a trusted device in the application managed by the applicationissuer to deliver security functions. The trust is based on the tamper-resistance of the smartcard chip, on the reliability of the card operating software and on the cryptographicallymaintained chain of trust between the card manufacturer (with any pre-issuance cardprocessing agents), the card issuer and the application issuer. As a basis for trust many smartcard 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 securityevaluations.

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 frontof 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. Abiometric 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 thefunctions 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 PINuses that single one. Similarly, if the card supports biometric on-card verification, anyapplication on the card may use it. Since most deployed smart cards support a singleapplication these convenience cardholder-control configurations are usually sufficient.Privacy aspects of biometric control methods are further investigated in the next section (seechapter 6) of this chapter.

Contactless cards, which by definition allow reading at a distance, are sensitive to snoopingand 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 theform of the conventional credit card, or alternatively, in the smaller card used for SIMs. Themobile phone, with an inserted SIM card, can be seen as providing an alternative form factorfor the user controlled trusted functions. (The one-sentence definition above could be easilyapplied to a mobile phone). For interactions with the Web, and Web 2.0 service architecturestargeted in PrimeLife, the mobile phone will be a convenient platform for user control as ithas internet connectivity and provides a user interface.

The NFC [NFC] technology takes this extended form factor and actually transforms themobile phone into a contactless card. Since there now is a user interface snooping abuseinherent to contactless cards can be reduced, e.g. by an on/off input.

6.1.2 StandardisationInternational 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 threeareas:

• 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 andlow-level details for operating and communicating over contacts;

• ISO/IEC 7816-4, specifying a structure for data stored on a card and commands toaccess 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 cardsis 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 ArchitecturesAt 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 withaccess 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 currentstandardisation. 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 ofprivacy 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 connectionhas been replaced by a random one.

6.1.4 Strategy and ActionsTwo 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 ofprotocols with a role for the smart card in giving the user control in protecting herprivacy;

• participation in SC17/WG4 to introduce PET protocols and algorithms in the areasof:

◦ protecting user data exchanged with the card for PIN or biometricidentification

◦ privacy protecting enhancements for the requests and procedures for entityauthentication 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 standardsfrom other work packages;

• plan to integrate a smart card in the M4 demonstrator milestone with a mobile phoneand SIM card application as user control user interface.

6.2 Biometrics Standardisation and PrivacyBiometrics is the science of measuring physical or behavioural characteristics that are suitablefor the identification of individuals. There is a variety of applications using biometric userauthentication today including national ID cards, digital signatures and physical or logicalaccess control. A biometric trait, such as a fingerprint, iris, dynamic signature or face is storedin the system and typically, a claimant presents his or her biometric characteristic again to becompared 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 areunique identifiers, not secrets. From a privacy viewpoint, however, biometric data must beconsidered confidential. Biometric data is critical in terms of privacy. It is not only relatedinformation, like a bank account number or street address but it is tied to the individualusually for the whole life. Biometric information can contain unwanted additional personallyidentifiable information like gender, age, susceptibility to some diseases or even sexualpreferences.

The open mass applications applying biometrics led to a need for standardisation ofbiometrics. Industry, government and academic delegates attend the standardisation

61

consortiums. This document briefly describes the standardisation landscape for biometricsand points to aspects that are relevant in terms of privacy.

6.2.1 Biometrics StandardisationStandardisation of biometrics started with national groups strongly led by NIST (NationalInstitute for Standards and Technology) from the United States. Several industries are alsodealing with biometrics standardisation, e.g. ICAO (international civil aviation organisation).The most important standardisation activity today is ISO/IEC JTC1 SC37 biometrics. It hasestablished liaisons to all major standardisation bodies and is organised into 6 WorkingGroups:

• 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 dealswith on-card comparison of biometrics as will be explained below.

6.2.2 ArchitecturesA biometric system operates in two phases: enrolment and verification/identification. Abiometric reference data set is recorded in the enrolment phase and stored in a database orportable data carrier. The actual application assumes that reference data was previouslyrecorded. In a physical access control system, users would present biometric traits, e.g. theirfaces to the system to be compared with the reference data. If the two samples are consideredsimilar, access is granted. From a privacy point of view, it is of utmost importance where thestorage and comparison actually take place. In a networked world where one would not trust acommunication partner or the operating system on a host computer, one can still trust thesmart card carried in a wallet. It enhances privacy when an application using a globaldatabase is reorganised to store all biometric data on a portable data carrier. The same is truefor changing from an online verification, where data has to be transmitted to offlineverification in a tamper-proof embedded system. A special case of such an embedded systemis a smart card and the technology to perform a biometric comparison within a smart card isnamed Match-on-Card as addressed in SC17 WG11.

6.2.3 Strategy and ActionsTo enhance privacy in today and future applications, standardisation activities should beobserved and influenced where necessary. Depending on the particular application, databasesand insecure data management should be avoided. Protecting biometric data by cryptographicmeans 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 theneeds for privacy and do not exclude Privacy-Enhancing Technologies.

62

• SC37 WG3: the data formats should also carefully be inspected and comments bemade to ease the use of offline storage and verification.

• SC37 WG4: today there is only little application profiles and the existing profiles arenot well designed to protect the privacy of individuals. Further profiles should beencouraged 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 statusand promoted in other liaisons.

• Other activities such as testing should be observed in a passive role.

63

Chapter7Identity SystemsIn this section we provide an overview over different identity system as well as an insight intoidentity federation protocols. The reason behind the presentation of those topics in one sectionis that there are specifications and their implementations released under the identical name(e.g. OpenID).

7.1 OpenIDMain 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 BackgroundThe OpenID protocol traces some of its roots back to Web blog commenting use cases: Thefundamental 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. Theprotocol is based on simplistic data formats, and layered on top of HTTP.

OpenID therefore only requires implementation effort from the relying party and OpenIDprovider sides. From the user's side, an ordinary Web browser is sufficient.

7.1.2 Protocol FlowThe 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 askhim 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 anonymousDiffie-Hellman key exchange (called association in OpenID parlance); the key that isnegotiated is used later to authenticate further messages that are exchanged. The user's Webbrowser 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 simpleas verifying the presence of the cookie, or as complex as the execution of another federationprotocol), and possibly interact with the user to enable the user to authorise the overallOpenID transaction. The details of this step are out of scope for the core OpenIDspecifications.

If user authentication (and authorisation of the transaction) is successful, the OpenID providerredirects the user's browser back to the relying party; any assertions that are passed back tothe relying party carry a message authentication code which is keyed with the shared secretestablished during the association phase.

The OpenID protocol exchange will scale badly to use cases in which individual HTTPrequests are to be authenticated; in typical deployments, the OpenID protocol will beexecuted one (or a few) time(s) while the user interacts with the relying party. Authenticationstate is then attached to the user's session.

7.1.3 Message FormatsThe 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 syntaxesdepending on the environment in which the message is passed.

During the association phase, the relying party will submit the OpenID message as the bodyof 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 authenticationrequest and response), messages are always encoded in HTTP requests -- either in the body ofHTTP POST requests (i.e., through form submission), or in query parameters of an HTTPGET request.

Messages can be "signed" by using a message authentication code keyed with the sharedsecret established during the association phase.

The message format is extensible with additional tags; the authentication request and responsecan therefore be used to pass personal information about the user from the OpenID Providerto the relying party.

7.1.4 Trust and Privacy PropertiesThe OpenID protocol provides a framework for certain assertions about a user's associationwith a URI. It does not provide an independent cryptographic proof to the relying party thatthe 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 theprotocol scope. In deployments, the requisite policies range from accepting identities from

65

_any_ OpenID provider, through OpenID provider blacklists, to approaches where few (oronly one) previously known OpenID providers are trusted.

Privacy concerns focus on the ability of the user's OpenID provider to link user transactionswith different relying parties. It should also be noted that OpenID can be used to pass alongpersonal information; how the release of this information is authorised is up to the individualOpenID Provider's choice.

Criticisms of OpenID center around certain aspects of the protocol design, and on risks that amalicious relying party might be able to successfully impersonate the user's OpenID provider.

7.1.5 Specification DevelopmentThe OpenID specifications were developed through an informal collaboration of interestedparties. Since then, the OpenID foundation has been formed as a framework for futurespecification development; the foundation also manages intellectual property rights aroundOpenID.

7.1.6 Open Source ImplementationsNumerous Open Source implementations of OpenID are available in different languages suchas C#, Java, Perl or PHP. A list of OpenID libraries [OpenID libraries] is hosted at theOpenID wiki. In addition to the current implementations of OpenID there has been an Apacheproject 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 socalled Seatbelt [SeatBelt] plugin detects OpenID conformance of the RP. If the RP supportsOpenID the user is prompted if he wants to use his OpenID to sign-in. The user might evenchoose between different OpenIDs that he controls by using the given toolbar button.

7.1.7 PrimeLife Perspective on OpenIDFrom a PrimeLife perspective, OpenID is a platform for decentralized identity federation andpersonal information transmittal that merits further investigation, in particular if itsdeployment is successful. The relative simplicity of many core aspects of OpenID - whileeasing deployment - will also be a challenge, as it might render the integration of advancedprivacy enhancing technologies in the context of this protocol more difficult.

66

7.2 HigginsThe Higgins open source identity management project [Higgins] is an open source Internetidentity framework designed to integrate identity, profile, and social relationship informationacross multiple sites, applications, and devices. Higgins is not a protocol, it is softwareinfrastructure to support a consistent user experience that works with all popular digitalidentity protocols, including WS-Federation (see chapter 7), WS-Trust, SAML (see chapter7), LDAP, Microsoft CardSpace (see chapter 7) and so on. The main contributing partnerswithin the Higgins project are Parity Inc, Novell, IBM, and Serena with interested supportfrom Computer Associates, Oracle, and Google.

The end-user paradigm of Higgins is based on the i-card metaphor: the user manipulatesvisual representations of an i-card which represent the user’s identity with identity grantinginstitutions (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 providerand the personal information released to the relying party.

The Higgins user interfaces allow for the issuance of i-cards, their management, and theirusage when accessing Web sites and services. The project currently supports various userinterface implementations available on diverse platforms (Apple OS, Linux, Windows). Theseuser interfaces are based on a pure Web-based architecture, as browser extensions or as acombination of browser extension/self-contained GUI application.

The data model of Higgins is based on the Higgins Global Graph (HGG) data model and theHiggins 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 portabilityabstraction layer over existing “silos” of identity data. IdAS makes it possible to “mash-up”identity and social network data across highly heterogeneous data sources includingdirectories, relational databases, and social networks. Support for OWL/RDF basedontologies is intended to allow for mapping between semantically equivalent identityattributes.

The overall, high-level, architectural schematic is shown in the figure below. The preliminarystep (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 theIdAS 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 letshim or her select an appropriate i-card using the Higgins I-card GUI (also known as theidentity selector service (ISS)). Once selected, the identity provider associated with theselected i-card is invoked in order to generate a secure token (implemented as a SAMLassertion, for example) (step 3). This secure token is relayed to the relying party whichverifies the presented access token and either grants or denies access (step 4) to the Webservice or resource.

67

'Figure 2: High-level Higgins architecture'

Higgins is compatible with Microsoft CardSpace and allows to import CardSpace’sInformation 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 workis being investigated in the following areas: Policies: Higgins currently reuses the MicrosoftCardSpace claims language to express secure token requirements. More sophisticated policyand claims syntax and semantics are of interest. Ontologies on attributes to allow the mappingbetween required policy claims and IdAS supplied identity attributes. Additional identityschemes: In addition to the support of Microsoft CardSpace, other identity schemes such asOpenID or IBM’s Identity Mixer technologies are considered for integration into the Higginsframework. IdAS Access Authorisation: a unified and generalised acess authorisation layer tothe Higgins IdAS environment is discussed within the project.

7.3 CardSpaceCardSpace [CardSpace] is the identity selector provided by Microsoft. Hence, it is not astandardisation effort, but a product. Nevertheless we want to describe it here, because itcompletes the picture of commonly used identity systems. CardSpace is shipped withWindows 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 integratedwith other WS-* applications. In CardSpace a so called Information Card contains all claimswhich are associated with an identity of a user. If a Web site shall accept Information Cardsfor authentication, the developer needs to add an <object> tag to the HTML code of the Website. This tag declares, what claims the Web site needs for authentication. The developer hasthen to decrypt and evaluate the token that CardSpace sends to the Web site.

We typically rely on a number of different digital identity systems, each of which may use adifferent underlying technology. To think about this diversity in a general way, it is useful todefine 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 digitalidentity. 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 ofidentity 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 userwishes to access. This information is contained in the relying party's policy, and it includesthings such as what security token formats the relying party will accept, and exactly whatclaims those tokens must contain. Once it received the details of the security token thisrelying party requires, the application passes this information to CardSpace, asking it torequest a token from an appropriate identity provider. After this security token has beenreceived, CardSpace gives it to the application, which passes it on to the relying party. Therelying 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 implementany proprietary protocols.

CardSpace implements an intuitive user interface for working with digital identities. Eachdigital identity is displayed as an Information Card. Each card represents a digital identity thatthe user can potentially present to a relying party. Along with the visual representation, eachcard also contains information about a particular digital identity. This information includeswhich identity provider to contact to acquire a security token for this identity, what kind oftokens this identity provider can issue, and exactly what claims these tokens can contain. Byselecting a particular card, the user is actually choosing to request a specific security tokenwith a specific (sub-)set of claims created by a specific identity provider. In fact, the userneeds not to disclose the full information that is associated with an Information Card, but shecan verify what will be revealed to the relying party.

There are different interoperability initiatives which are implementing CardSpace on therelying party side. Those initiatives are discussed in more detail in the discussion of SelectedOpen Source Projects (see chapter 8). The projects using CardSpace in one or another way areBandit [Bandit], Concordia Project [Concordia], Higgins (see chapter 7), and OSIS [OSIS atIdentity Commons].

69

7.4 WS-FederationWS-Federation (see WSFed Technical Committee [WSFed TC]) introduces mechanisms tomanage and broker trust relationships in a heterogeneous and federated environment. Thisincludes support for federated identities, attributes and pseudonyms. ‘Federation’ refers to theconcept that two or more security domains agree to interact with each other, specificallyletting users of the other security domain accessing services in the own security domain. Forinstance, two companies that have a collaboration agreement may decide that employees fromthe other company may invoke specific Web services. These scenarios with access acrosssecurity boundaries are called ‘federated environments’ or ‘federations’. Each securitydomain has its own security token service(s), and each service inside these domains may haveindividual security policies. WS-Federation uses the WS-Security, WS-SecurityPolicy andWS-Trust specifications to specify scenarios to allow requesters from the one domain toobtain security tokens in the other domain, thus subsequently getting access to the services inthe other domain.

To illustrate this concept with an example, imagine that a user Alice from company A intendsto 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 particularusers 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 inWS-PolicyAttachment, WS-MetadataExchange, and WS-SecurityPolicy, Alice retrieves thesecurity policy of Bob’s service and detects that the security token service STSB of companyB issues tokens to access this service. Alice issues a security token request to the securitytoken service STSA of company A and claims to need a token to access STSB. Company Aand company B are federated together, therefore STSA is able to issue a security token forAlice. Of course, that may depend on whether Alice belongs to the group of A’s employeesthat are permitted to access Bob’s services. In the next step, Alice requests a token foraccessing Bob’s service from STSB and proves her authorisation by utilising the token issuedby STSA. After validating that STSA security token is valid, STSB issues a security token foraccess to Bob's service (assuming that Bob’s Web service belongs to the group that companyB offers to company A). In the last step, Bob’s Web service is invoked by Alice. During thatfinal request, Alice presents the token issued by STSB.

Besides this introductory example, WS-Federation shows how such a federation could workacross multiple security domains or how delegation could be used. Delegation means that auser may delegate certain access rights on one federated resource to a different federatedresource. WS-Federation adds security to service aggregation. Additionally, WS-Federationdefines 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 Webservice work in PrimeLife.

7.5 SAMLThe Security Assertion Markup Language (SAML) is an XML standard that defines aframework for exchanging security information, such as authorisation, authentication andattribute statements. It was developed by standards organisation OASIS (see chapter 8) (theOrganisation for the Advancement of Structured Information Standards).

70

7.5.1 BackgroundSAML 2.0 [Semantic Web] comes from the combined effort of OASIS, the Liberty Allianceand 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 bymultiple vendors and organisations around the world as industry standard for deploying andmanaging open identity-based applications. SAML 2.0 represents a step toward theconvergence of identity standards and all future enhancements to Liberty Federation will bebased on SAML 2.0.

The Liberty Alliance added support for SAML 2.0 to Liberty Web Services in 2005 and atthat time incorporated SAML 2.0 testing into its Liberty Interoperable conformanceprogramme. WS-Security also supports SAML.

7.5.2 ArchitectureSAML 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 ormore statements made by a SAML authority. SAML defines three different kinds ofassertion statements: authentication (a subject was authenticated by a specifiedmethod 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.) Atypical SAML assertion reads

<saml:Assertionxmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"MajorVersion="1" MinorVersion="1"AssertionID="v56ydf55-1117-40cc-929f-12se452ebdfc"IssueInstant="2007-12-05T09:22:02Z"Issuer="https://this.example.org/saml"><saml:Conditions

NotBefore="2007-11-05T09:17:02Z"NotOnOrAfter="2007-11-05T09:27:02Z"/>

<!-- insert the statement here --></saml:Assertion>

• Bindings & Profiles: how SAML protocols are mapped onto transport layer(bindings) and how they are combined to support a specific use case (profiles). Forexample, the Web Browser Single Sign-On Profile describes how SAMLauthentication assertions are issued and communicated between an identity providerand service provider to enable single sign-on for a browser user.

7.5.3 Protocol FlowAs an example, let us consider the basic template for achieving SSO using SAML2, inparticular 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. SPdetermines the location of an endpoint at an identity provider (IdP) for the authenticationrequest protocol. The SP sends a SAML2 authorization request to the IdP (e.g., HTTPRedirect binding) through the user agent. The authorization request is read by the IdP The IdPfirstly 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 authenticationassertion. SP receives and checks the SAML2 Response message, and it may respond to theuser agent with its own error, or establish a security context for the user and provides therequested 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 FederationThe Liberty Identity Federation Framework (Liberty ID-FF) is one of the three modules ofLiberty 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 SAMLPrevious 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 profilesThe Liberty ID-FF describes various profiles. A Liberty profile is basically a combination ofcontent specifications and transport mechanisms to support specific functions. The existingLiberty profiles, grouped according to their functions, are the following:

• Single Sign-On and Federation: The profiles by which a service provider obtains anauthentication assertion from an identity provider facilitating single sign-on andidentity federation.

• Name Registration: The profiles by which service providers and identity providersspecify the name identifier to be used when communicating with each other.

• Federation Termination Notification: The profiles by which service providers andidentity providers are notified of federation termination.

• Single Logout: The profiles by which service providers and identity providers arenotified of authenticated session termination.

• Identity Provider Introduction: The profile by which a service provider discoverswhich identity providers an user agent may be using.

• Name Identifier Mapping: The profile by which a service provider may obtain aName 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 NameIdentifier to permit it to pass through a third party without revealing the actual valueuntil 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 specificprofile is described below.

7.6.3 Profiles of the Single Sign-On and Federation ProtocolThe Single Sign-On and Federation Protocol defines messages exchanged between serviceproviders and identity providers for supporting single sign-on. The mapping of thesemessages to particular transfer (e.g., HTTP) and protocol flows are described in the the SingleSign-On and Federation profile, which lists various possible solutions. An example follows.

7.6.4 Single Sign-On Protocol Flow Example: Liberty Artifact ProfileUser or user agent connects to a service provider (SP). To log in, he has to select the preferredidentity 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 othermeans). Then, the user’s browser is redirected to the IdP, with an embedded parameterindicating the originating SP, and the user may log in to the IdP providing the necessarycredentials.

The IdP verifies login credentials and, if successful, redirects the user agent to the originatingSP with a one-time-used, encrypted credential, called an artifact, included in the URI. Theartifact is a user handle, which can be used by the SP for querying the IdP to receive a fullSAML assertion. The main advantage of this approach is that the artifact is small enough tofit the URI.

In the next step, SP uses the artifact information for querying the IdP about the user. In itsresponse, the IdP provides the assertions for the user, and the SP may then establish a securecontext and respond with the requested resource.

7.6.5 Liberty and CardSpaceCardSpace (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. Libertyspecifications are defined to be used with general Web browsers, on the contrary CardSpaceintroduces new functionality to user's Web browser and to the underlying operating system (itis 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 theuser's computer. This results in a loss of generality, but enables the use of proof-of-possessionkeys, which may increase the security of token delivery. Regarding authentication, CardSpaceselector has a fixed list of authentication methods, whereas in Liberty framework identityproviders can present a customised authentication page.

In short, although the two protocols try to solve the same general problem, CardSpace has amore client-centered approach, relying on a smart non-standard client, whereas Libertyprovides a distributed and open, but more complex, framework.

7.6.6 PrimeLife and LibertyLiberty standards are increasingly becoming adopted in many industries, and they play amajor role in identity federation technologies. The PrimeLife consortium should evaluatethem 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 YadisYadis [Yadis Spec] is an HTTP based protocol for authentication service discovery. It ensurescompatibility between different authentication services. Currently three such services aresupported: OpenID, LID and i-Names. The goal of the initiative is to make the usedauthentication system transparent to the user (i.e., a user sends a Yadis compatible identifierto the Yadis-enabled relying party (RP) which in turn is able to resolve the authenticationsystem used by the Identity Provider.)

7.7.1 Protocol flowThe Yadis authentication service discovery is initiated by the user supplying an identifier tothe RP. This ID must be resolvable to a URI. The process of resolving the authenticationservice is executed in at most three steps. The resolution process results in the RP having aYadis 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 caneither be a GET or a HEAD request. The answer to the request can be a Yadis document or aYadis Resource Descriptor URI. In case an HTTP HEAD request was issued, the responsemay not contain a Resource Descriptor URI in which case the RP is obliged to issue an HTTPGET request.

If the RP did not receive the Yadis document after the first request, it must request thedocument at the location indicated by the Yadis Resource Descriptor URI. This results in theretrieval of the Yadis document. The second request may also consist of launching an HTTPGET request in the case of having issued an HTTP HEAD request in the first step and notreceived either Yadis document or Yadis Resource Descriptor URI. The response to thisrequest is as described in the first step.

The third step is only necessary in case of an unsuccessful HTTP HEAD request as firstmessage. As either the Yadis document or Yadis Resource Descriptor URI must have beenretrieved in the second step, this third step consists of retrieval of the Yadis document at thelocation indicated by the Yadis Resource Descriptor URI. The resolution process terminatesas soon as a Yadis document has been received.

7.7.2 The Yadis documentAn examplary Yadis document specifying two available authentication services looks asfollows

<?xml version="1.0" encoding="UTF-8"?><xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">

<XRD><Service priority="10">

<Type> http://lid.netmesh.org/sso/2.0 </Type></Service>

75

<Service priority="30"><Type> http://lid.netmesh.org/sso/1.0 </Type>

</Service></XRD>

</xrds:XRDS>

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 severalother elements which may be disregarded by the RP. The XRD element may contain one orseveral Service entries. The absence of a Service element indicates that the Yadis URI is notmeant to be used with a Yadis service. Otherwise, the Service element lists available servicesfor authentication where the ordering of the elements is not relevant. The priority can beindicated using the optional priority attribute where smaller numbers refer to higher prioritiesand services with no priority refer to the lowest preference level. The Service element mustcontain one or more Type elements which are URIs or XRIs referring to the servicespecification document.

7.7.3 Trust and privacy propertiesAs the protocol only serves for service discovery, there are no privacy options in Yadis. TheYadis document, however, allows for elements other than the mandatory XRD element. In thecurrent specification the interpretation of such elements by the RP is optional.

7.7.4 Opportunities for PrimeLifeYadis is a small protocol enabling the transparent use of different authentication systems. Thecurrent limitation of Yadis is that the identifier used by the authentication mechanism must beresolvable to a URI. If that limitation does not restrict the authentication mechanism proposedby the PrimeLife project, a collaboration with the Yadis project could speed up the marketadoption 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 developmentYadis was developed by members of the OpenID and the LID community. In October 2005the i-Names initiative joined the project.

7.7.6 Open Source ImplementationsThe project maintains a list of Yadis Implementations [Yadis Implementations].

76

Chapter8Specification DevelopingOrganisations8.1 W3CThe World Wide Web Consortium [W3C] is an International Consortium with over 400member organisations from more than 40 countries. W3C Members include vendors oftechnology products and services, content providers, corporate users, research laboratories,standards bodies, and governments, all of whom work to reach consensus on a direction forthe Web.

W3C's main role is to standardise Web technologies by creating and managing WorkingGroups, that produce specifications (called Recommendations) to describe the building blocksof 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 expertsselected on their expertise in the area. W3C also opens Interest Groups, to bring togetherpeople who wish to evaluate potential Web technologies and policies. An Interest Group is aforum for the exchange of ideas. The W3C technical team contributes and coordinates theactivities in the various fields: Web Architecture, Protocols, Web applications, UbiquitousWeb, 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.1Spec])

• 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 theWeb, at the core of W3C work since its creation.

8.2 IETFThe 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 followingscope: “protocols and practices for which secure and scalable implementations are expectedto have wide deployment and interoperation on the Internet, or to form part of theinfrastructure of the Internet.”

The IETF operates Working Groups in 8 Areas, supervised by two entities: the InternetEngineering 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 theApplication Area may not be totally irrelevant to the project's target. The Security Area isconstituted of 16 Working Groups and covers protocol-level security mechanisms, such asTLS, SASL, Kerberos, X.509, S/MIME, DKIM.

8.3 OASISThe Organisation for the Advancement of Structured Information Standards [OASIS]perceives itself as “a non-for-profit consortium that drives the development, convergence andadoption of open standards for the global information society.” The organisation was foundedin 1993 and has currently “more than 5,000 participants representing over 600 organisationsand individual members in 100 countries.”

The OASIS specifications which are of most interest for PrimeLife are WS-Trust [WS-Trust1.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 signatureare robust, mature and well adopted.

These specifications depend on open standards such as SOAP Version 1.2 [SOAP12], XMLSignature [XML Sig], XML Encryption [XML Enc], etc. They are stable specifications, withrich implementation support from multiple vendors. They are XML schemas and many ofthem 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 [OASISIPR]. In general the mentioned OASIS specifications are well-founded and established both inindustry and academic.

8.4 Liberty AllianceLiberty Alliance [Liberty] is a business alliance, formed in 2001, with the goal of definingand driving open technology standards, privacy and business guidelines for federated identitymanagement. Its 160 members are vendor companies, consumer companies, government andeducation organisations. In addition, Special Interest groups are open communities, andOpenLiberty.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 managementspanning all network devices,

• provide open and secure standard for single sign-on with decentralisedauthentication 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 ofLiberty Single Sign-On and Federation framework.

It enables identity federation and management through features such as identity/accountlinkage, simplified sign-on, and simple session management. It was originally based onSAML 1.1, and recently it has been integrated in SAML2.

• Liberty Identity Web Services Framework (ID-WSF) [ID-WSF] is the Liberty'sfederation framework for Web services, allowing providers to share users identitiesin a permission-based model. This framework offers features like Permission BasedAttribute Sharing, Identity Service Discovery (to discover identity and attributeproviders), Interaction Service (a mechanism to obtain permissions from a user) andthe associated security profiles.

• Liberty Identity Services Interfaces Specifications (ID-SIS) [ID-SIS] defines serviceinterfaces for each identity-based Web service so that providers can exchangedifferent 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 [LibertyAdoption]).

79

8.5 TCGThe Trusted Computing Group [TCG] (TCG) is an industry standardisation body that aims todevelop and promote an open industry standard for trusted computing hardware and softwarebuilding blocks to enable more secure data storage, online business practices, and onlinecommerce transactions while protecting privacy and individual rights.

The core hardware module specified is the so called TPM, the Trusted Platform Module. TheTPM is a microcontroller that stores keys, passwords and digital certificates. It typically isaffixed to the motherboard of a PC. It potentially can be used in any computing device thatrequires these functions. The nature of this silicon ensures that the information stored there ismade more secure from external software attack and physical theft. Security processes, suchas 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 asexpected. Critical applications and capabilities such as secure email, secure web access andlocal protection of data are thereby made much more secure.

The TPM is questioned by the surrounding modules so that the decision process alwaysinvolves the hardware - secured trust chain:

Figure 4: TCG Architecture

This generic architecture can be used in many use cases and circumstances. The followingroadmap describes the main use cases targeted by TCG. But there are many more use cases asany 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 thoseattacking a device to take control or spy on data secured by TCG technology. In fact, the TPMcontrols secured memory that is only accessible by those having the right keys andinformation. The building up from the hardware makers ensures that the chain of trust is notinterrupted.

One main application of TCG technology is securing storage devices. As the storage deviceitself is secured by cryptographic means, the policy control engine can enforce decisions intothe disk/storage access. Initially developed mainly for rights management or DRM, this canbe used to leverage constraints coming from identity management.

Another interesting application for PrimeLife is the suite of network access controlspecification. It uses the TPM and the controlled and protected memory of a device todetermine its status and feed the information back to a console. Thus security policies candetermine whether to allow or disallow such a device on a given network. Again, this isleveraging the TPM and the trust chain established by the cryptographic chain from thehardware up to the application in a certain use case.

Trusted Computing is an important tool in the PrimeLife toolbox. It allows ultimateenforcement into an infrastructure that is not in actual possession of the data subject or thedata controller. PrimeLife may provide the necessary semantics where to disclose data, whereto allow the copying of data while a TCG infrastructure can make sure that an enterprise mustfollow those constraints.

There are also caveats in using TCG. When using the TCG platform with its TPM, the entitycontrolling the TPM effectively takes over control of large parts of the data controller'sinfrastructure. While technically possible, this does not sound like a compelling argument toenterprises 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 onlyusable in cases where the identification of a user is part of the scenario that PrimeLife istrying to solve.

8.6 ISO/IEC JTC 18.6.1 ISO/IEC JTC 1/SC 27/WG 5Considering the promising new ways in which we use technologies in our daily life and theimportant challenge to handle an individual’s identity and personal information appropriatelyin the process, SC 27 has established its new WG 5 on Identity Management and PrivacyTechnologies in May 2006. Currently WG 5 is active in 7 projects and 2 Study Periods withmore being expected. The seven projects line up as follows:

• Working Draft 24745 Biometric template protection describes the securitytechniques for Biometric Template Protection focusing on Privacy-EnhancingTechniques for Biometric Template Generation.

• A Framework for Identity Management (Working Draft 24760) addresses the secure,reliable, and privacy respecting management of identity information considering thatidentity management is important for individuals as well as organizations, in anyenvironment and regardless of the nature of the activities they are involved in.

• The project on Authentication Context of Biometrics (Final Draft InternationalStandard 24761) defines the structure and the data elements of authentication contextfor biometrics, by which service providers (verifiers) can judge whether a biometricverification result is acceptable or not.

• A Privacy Framework (Working Draft 29100) is to provide a framework fordefining privacy safeguarding requirements as they relate to personally identifiableinformation processed by any information and communication system in anyjurisdiction.

• A Privacy Reference Architecture (Working Draft 29101) is to provide a referencearchitecture model that will describe best practices for a consistent technicalimplementation of privacy requirements in information and communication systems.

• Entity Authentication assurance (Working Draft 29115) aims at describing theguidelines or principles that must be considered in entity authentication assuranceand the rationale for why it is important to an authentication decision.

• A Framework for Access Management (New Project 29146) aims to provide aframework for the definition of access management and the secure management ofthe process to access information. This framework is to be applicable to any kind ofusers, individuals as well as organizations of all types and sizes, and should be usefulto organizations at any location and regardless of the nature of the activities they areinvolved in.

The two study periods deal with Privacy Capability Maturity Models and Access ControlMechanisms.

It should be mentioned that also other working Groups in SC 27 maintain a number ofprojects with a relevant relation to privacy, most notably ISO/IEC JTC 1/SC 27/WG 3Security evaluation criteria, that is responsible for IS 15408 Evaluation Criterial for ITSecurity and its Privacy Class covering anonymity, pseudonymity, unlinkability, andunobservability.

82

With 51 member countries ISO/IEC JTC 1/SC 27 has an immense global outreach. At thesame time WG 5 has a significant topical overlap with PrimeLife and combines openness forPrivacy and Identity Management aspects with a solid foundation in IT Security. ThereforePrimeLife is establishing a liaison to ISO/IEC JTC 1/SC 27/WG 5.

8.6.2 ISO/IEC JTC 1/SC 17/WG 4A core activity in WG 4 is the maintenance and regular technology upgrade of the ISO/IECseries 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 basicmodel of operations of a smart card as a server responding to a standard formatedrequest. It defines a set of standardized requests for:

◦ Opening one or more sessions with different applications that can co-resideon 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 ofrequests to perform cryptographic operations both for symmetric and asymmetriccryptographic algorithms with secret keys stored on the card.

• ISO/IEC 7816-11 (2004) [ISO/IEC 7816-11:2004] This standard specifies a set ofrequests 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 ofrequests to manage the content on the card, specifically to load and removeexecutable code for different applications. The requests specified by this standard arebased on the Global Platform specifications [Global Platform Specs].

The parts of a series of international standards ISO/IEC 24727 are still at various stages ofpreparation. 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 7816series, parts 4 or 8.

8.6.3 ISO/IEC JTC 1/SC 17/WG 11A biometric system always splits into two phases: biometric reference data is collected in aregistration phase from the user group and current biometric data will be compared with thisreference data in the verification phase. Usually, the reference data is stored in a database orportable data carrier such as a smart card. The match-on-card technology allows to performthe 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 ofan 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 isthe standardisation of on-card matching. The document ISO/IEC 24787 addresses thearchitectures, parameters and usage of on-card matching. It supplements the existingstandaridsation 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 supportedbecause its outcome are documents enabling to raise the privacy in daily life, particularly indigital identities used online.

8.6.4 ISO/IEC JTC 1/SC 37SC37 was founded when the industry acknowledged that a significant level of standardisationis required to achieve acceptance of the biometrics technology in open mass markets andapplications such as e-passports. The group addresses various aspects such as vocabulary,interfaces, data formats, testing and applications profiles as well as jurisdictional aspects ofbiometrics.

Raising the knowledge of biometrics amongst users and customers is one of the mostimportant subjects for leading biometric vendors. Biometrics are not as secret ascryptographic keys. Biometric data, however, must be considered confidential personalinformation and has to be protected against misuse. From the viewpoint of privacy, thestandardisation activities should be observed and influenced where necessary to protect userrights on individual data.

A variety of standards addressing biometrics are available today. Most standards can bepurchased though the national standardisation committees. The documents currently underrevision can only be accessed by the ISO committee.

84

Chapter9Selected Open Source ProjectsThere 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 therespective section about the standard. Refer to SAML (see chapter 7), Liberty Federation (seechapter 7), XACML (see chapter 3) or CARML / Oracle IGF (see chapter 4) for details. Inthis section we summarise other projects.

There are a number of projects which aim at driving interoperability between the differentimplementations or the different protocols. Some of which are depicted in detail in thesections OpenID (see chapter 6), Liberty (see chapter 7), CardSpace (see chapter 7) andHiggins (see chapter 7). Several other projects which are worth mentioning are shortlydescribed below.

9.1 MozPETs: Mozilla Privacy EnhancementTechnologiesMozPETs [MozPETs] is a project that was started by IT Transfer Office's [ITO] PrimaProject [Prima] of the Technical University of Darmstadt. It was partly supported by researchfunding from the European Commission. TU Darmstadt closed the IT Transfer Office in2006, so there is no institutional support for MozPETs anymore. There is an inactiveSourceforge project [MozPETSSourceforge] remaining.

The goal of MozPETs was to integrate all existing Privacy Enhancing Technologies into onebrowser. They used the Mozilla open source browser for their project and added all kinds offilters. Subsequently they tried to use the Web with the heavily privacy enhanced browser andfailed. They documented their experiences in a paper published 2005 called MozPETs - aPrivacy enhanced Web Browser [MozPETsPST05]. Of most interest is their analysis:

Privacy research has been done on a lot of different technologies. Most research focused onanonymity for network access, publishing, authorisation, and payment. E-mail fraud andphishing has lead to increased research on technical countermeasures. Data licenses wereproposed to guarantee access rights to personal information. An identity management systemcombines privacy enhancement and security technologies to minimise the disclosure of

85

personal information, and provides the user with means to make informed decisions whethercertain data is disclosed or not. The current identity management tools differ a lot in featuresand scope.

However, the Web looks different. Privacy invasive technologies, such as tracking users withWeb bugs and third party cookies across multiple sessions and different sites, are commonpractice 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 thesame as of the Netscape Navigator 6 released in late 2000. The user can modify the cookiepolicy, wallet components store logins, passwords and other personal information. Manysecurity 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. TheiJournal tries to detect certain types of personal information within user's input, and looks formatching parts of the server`s P3P policy. With this information the user can evaluate if hereally wants to submit the data. Instead of a user policy the iJournal gives the user contextinformation for this special transaction. It also stores a copy of the relevant policy to have itavailable 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 furtherdevelopment of MozPETs does not make too much sense. Instead, PrimeLife will rather lookinto the powerful extension mechanism for Firefox. But some code of MozPETs may berecovered. The important conclusion from this very practical exercise is also that PrivacyEnhancing Technologies have to take Web functionalities into account to keep the browsingexperience on a decent level. Usability considerations have to take the Web's reality intoaccount and weigh the tradeoff between functionality and privacy preservation.

9.2 Firefox PluginsFirefox plugins provide a variety of functionality for the browser. In this section the focus lieson the category of Privacy & Security [Firefox Addons]. Especially, the most interestingplugins can be grouped into three subcategories: Identity Management, Privacy and Trust. Inthe Identity Management category all addons allowing for an easier handling of the differentdigital identities are described. The Privacy categories summarises the efforts allowing for abetter protection of the personal data and the Trust category shows the work going in thedirection of visualisation of trust relationships between users and Web sites.

9.2.1 Formfiller and Identity Management EnhancementAs mentioned in the Firefox Plugins in PRIME (see chapter 10) section there are Firefoxplugins which provide privacy enhancing technologies or allow for easier management ofpersonal information. As an example the form filling extension Autofill Forms [AutofillForms], published under the Mozilla Public License, is mentioned. This plugin providesautomatic form filling based on pattern matching of the internal names for fields and thenames of the fields in the form. The form of the plugin can be completed for several personasand 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 theautomatic form filling on a particular site, one user (a so called 'trainer') has to provide hispersonal information into the form manually. Thereafter, Sxipper extracts the common fieldsof the form with the most appropriate persona of this user and then generates an assumedmapping. This mapping can subsequently be used by other users throughout the Internet to fillin the form automatically. In addition to the administration of personas, Sxipper offerspassword management functionality. The Firefox password manager is used as securecredential store. Also, Sxipper can handle OpenIDs which means that on an OpenID-enabledsite the user will be presented her OpenIDs allowing for a login with a single click. TheOpenID functionality is accompanied with phishing protection detecting unusual redirectswhereupon the user will be warned. This plugin is free but not open source. It will becomplemented 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 nonethelesscontains 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 itdetects if a visited Web site is OpenID-enabled. If this is the case, the user is logged inautomatically. There exists the possibility to change the OpenID with respect to which thelogin is executed using a menu button. SeatBelt provides phishing protection similar toSxipper.

There are more plugins for simple form filling. InFormEnter [InFormEnter] adds clickableicons next to the form fields. Those icons allow choosing from the different contents that haveactively been stored by the user before. As an example, the user can store his personalinformation by using the plugin. At any later point in time the same information is availableby clicking the icon next to the field. This plugin is hardly an improvement of theautocomplete function provided by Firefox.

AutoFormer [AutoFormer] is a simple tool for saving form information entered into one pageand make the form information reusable. The user selects to save the data entered into anonline form. This data is then saved in a cookie and thus available at a later point in time. Asevere drawback of this approach is that a restrictive handling of cookies also results inrestrictions for the plugin.

9.2.2 Privacy EnhancementWhile the above described extensions deal mostly with identity management and usabilityissues other extensions focus more on privacy enhancements. One such extension isCookieSafe [CookieSafe] which envisions a powerful yet simple management of cookies. Theextension offers detailed control over the cookies which extends the capabilities that Firefoxoffers in this domain. As an example, a general cookie handling policy can be defined inaddition to setting rules for each Web site individually. There exists even the possibility tochange cookies which have been retrieved or to define cookies from scratch. A reduced set offunctions is published as CS Lite [CS Lite] which has been newly designed. The CS Lite codeis currently used to build the basis for the next version of CookieSafe. CookieSafe and CSLite are published under the GNU General Public License.

Stealther [Stealther] is provided as freeware and allows the inhibition of traces that are left ona computer. This means that essentially all functions which allow retrieval of browsingbehaviour are temporarily suspended. Examples of suspended functionalities are the browsinghistory, cookies, form filling information, sending referrer headers or cached data. In contrastto 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 thedefault.

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. Atthe time of its deactivation, the plugin deletes the cookies set during the session, cleans up thehistory, cleans up the list of downloaded items and the respective items and deletes storedform information. In addition to those actions, the cache is disabled during such a DisTrustsession. Clearly, the actions of the plugin can be adjusted to the personal preference using theoptions menu.

There are also plugins allowing for better usability of the functionality provided by TOR. Onesuch plugin is called FoxTor [FoxTor] which enables the user to activate and deactivate TORusing toolbar. The latest version has been published in November 2006. The TOR projectrecommends the use of the Torbutton plugin [Torbutton] which also provides a button forenabling and disabling the usage of TOR for browsing. Unfortunately, the Torbutton plugindoes not provide feedback upon failure of initiation of the TOR usage. Nonetheless, theplugin supports the anonymisation initiative of TOR by, e.g., stopping other plugins whichmight add identifying information, clear cookies, clear cache, spoofing the timezone and otherlocal 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 ofa proxy. All connections going through the proxy appear to be coming from one user whicheffectively hides all users among the users of the proxy. PhProxy - InBasic [PhProxy] makesuse of such an approach. If a user wants to contact some server using the proxies defined inPhProxy, she simply prepends the address with PH:: which indicates the use of the proxy. Asmentioned before, the benefit of such an approach is that all users of one proxy areanonymous where the anonymity set is all users of the respective proxy. Problematic is thatthe 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. Inparticular, this is a promising approach for search engines to analyse the search queries oftheir users which leads to an identifiable person. This preceding is described for example in aNew York Times article [AOL4417749]. TrackMeNot [TrackMeNot] tries to hide the queriesof 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 thequeries, the most recent version issues queries based on actual queries issued by the user. Theplugin tries to extract possible future queries based on those searches. The ideal behaviourwould probably be different as the plugin should try to search for terms that are orthogonal tothe 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 notallowed to do so.

9.2.3 Trust EnhancementA plugin called Web Of Trust [WOT] takes a step in establishing a trust relation between anew user of a page and the page itself. The assumption is that all users knowing and using aWeb site should rate the page. A user stumbling upon a Web site can see the trust ratings thatthis 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. Aclear vote in favour of the trustworthiness of a page on the other hand is very probable to be atrue statement. A user can make the confidence depenant on the confidence rating given bythe 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: thetrustworthiness, the vendor reliability, the privacy and suitability for children. This plugingets especially interesting when searching the Web using Google, MSN or Yahoo wheresmall 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 iteasier to block a range of sites, the plugin allows the use of wildcards.

• BugMeNot is a site offering username / password combinations to certain sites. TheBugMeNot [BugMeNot] plugin allows easy access to this service. A user presenteda login screen can, subsequently, use the plugin to acquire a valid username/password combination. Another functionality of BugMeNot is the offer of temporarye-mail accounts. These accounts can be given when creating an account in order notto provide the real e-mail address. Such a temporary e-mail inbox is also madeavailable by another Firefox plugin called Temporary Inbox [Temporary Inbox].Both services relieve the user of the hassle of providing personal information to eachand 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 thathas been allocated by another Web site. This can lead to information exposition to anunauthorised 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 notopen source or free, so we do not describe them further here.

9.2.5 Opportunities for PrimeLifeThe Firefox extension mechanism should definitely be considered by the PrimeLife project asit allows the implementation of powerful functionality. Additionally, very fast deploymentcan be achieved as there is a quite large community already using this browser. The ratherlarge amount of open source code available is yet another argument in favor of producingFirefox plugins. Still there is an inherent limitation of such a plugin to Web-based services.

9.3 TORThe TOR project [TOR] enables anonymous use of TCP-based services. The TOR softwaretunnels the user's data through a chain of encrypted tunnels that connect multiple intermediaterelays. The protocol's design ensures that each node in the chain only knows its immediateneighbours, and (with the exception of the entry and exit nodes, respectively) can discoverneither 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 clientacts as a SOCKS proxy that can be used by most common TCP-based applications withoutadditional modification.

While TOR does lead to anonymous communication that is protected against traffic analysisfor a number of common attack scenarios, it does not by itself assist users in keeping personalinformation private that is passed through the anonymous data channel: Solving that issue isleft 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 notthey wish to use TOR.

The TOR project runs under the auspices of a non-governmental organisation. Softwaredevelopment is performed by a number of project employees, contractors, and contributingvolunteers. The software itself is available as open source under a BSD style license.

9.4 PrivoxyPrivoxy [Privoxy Homepage] is a filtering tool implemented as a proxy. The HTTP streampasses through the filters and protocol or other information is stripped or altered based onnormal matching procedures. Privoxy is based on Junkbuster, one of the first well-knownfiltering proxies. Junkbuster was developed in 1998 by Jason Catlett. Jason was one of themost prominent critics of P3P around 2001 and 2002. The junkbuster software has not beenupdated 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 [AdblockFirefox plugin].

Privoxy is still under development and available on all major platforms. It has a newarchitecture and is currently maintained by Fabian Keil and David Schmidt. All those toolsare mainly targeted to block cookies, advertisement and defend against the abuse of pop-upwindows.

Privoxy is suggested by TOR as an additional semantic filter. While TOR is making sure thatthe routers and the server do not see the origin of the request, privoxy can be configured tomake sure that the content transferred does not reveal the identity of the users. But thisrequires a rather high level of knowledge about the techniques of Web sites to extractpersonal information from their users. Privoxy is the tool to stop it, if the user happens toknow how the personal information is supposed to leak. It has no semantic ability todistinguish between sensitive information and non-sensitive information as it remains on aprotocol-level string matching, which is useful.

PrimeLife may use privoxy on specific identified invasive techniques. This would require alsothe elaboration of complex rulesets to cope with the complexity of social network systems oftoday. As only preset complicated rules will have the desired effects, feedback to the user isimportant to avoid the experience of a magic blackbox that increases the feeling ofpowerlessness on the side of the user. The nature as a proxy has intrinsic limitations on theway feedback can be given to the user. Those limitations may hinder the establishment of thecontrols 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 severalencryption layers) designed to work with Internet applications where anonymity and privacycan be considered as critical. It uses encrypted tunnels built between peers knows as garlicrouters. The network of routers is based on an overlay architecture with cryptographic keys asidentifiers. In consequence, the identity of both ends of a communication can be protected andthe content of the communication itself is secure, while a regular proxy-based solution wouldprotect only one end. Most TCP-based exchanges can be streamed into I2P tunnels.

9.6 BanditThe goal of the Bandit project [Bandit] is to provide an open source framework forauthentication, authorisation and auditing. To achieve this goals the project is destined toprovide a simple access to identity stores, support diverse authentication systems, provide aninterface role based system access and ease the achievement in common compliance ofapplications.

The Bandit project is composed of components taken from open source projects. Thecomponents 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 corporategovernance implies past and future compliance. Past compliance is ensured by searching thedatabase for compliance deviations while future compliance can be analysed by looking atrequests that are issued but not actually carried out. OpenXDAS is built upon the OpenGroupsDistributed Auditing System (XDAS).

Common Authentication Services Adapter (CASA) is the infrastructure used to store theidentity information. It also allows to administer and retrieve data from credentials or othersecure 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 orauthenticate several, possibly heterogeneous systems, there is a component extracting theidentity information. The Bandit project used to call this component Identity Abstraction andrenamed it to Common Identity Provider. The Bandit project contributes to the HigginsIdentity Attribute Service (IdAS) and subsequently uses this service for the handling ofdisparate identity stores. The Common Identity component is maintained for backwardcompatibility.

The DigitalMe set of components allow for an interaction of the user with an InformationCardcompatible service. Currently, this interaction occurs by accessing an InformationCardenabled 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 theuser. Certain parts of Bandit, which are not (yet) integrated into the Higgins source, provideextra functionality in the domain of auditing and role based access control. Thus acombination of Bandit and Higgins could be considered useful in the project.

9.6.1 Development FrameworkThe Bandit project's development [Bandit Development] is mainly driven by Novell. Othercontributers 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 fromdifferent sources which determined their respective license. Concretely, this means thatOpenXDAS is licensed under MIT license, the CASA under the GNU LGPL and the IdentitySelector Service as well as the the Higgins IdAS under the EPL.

9.7 Concordia ProjectThe Concordia Project [Concordia] aims at driving interoperability between the differentprojects in the identity management domain. It issues definitions of real world scenarios andrequirements for identity protocols which should encourage the solution of existing problemsby the technology drivers. The solution of the given use cases requires the use of severalidentity protocols.

Development is ideally initiated by the description of a new problem. Thereafter thecommunity discusses possible solutions using existing technology or possibly extendingstandards or their implementations. The most recent interoperability demonstration has beenshown at the RSA conference 2008 where InformationCards have been used in a federatedscenario 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 ofan identity provider.

The most recent meeting of the Concordia Project members has taken place at the Burton'sCatalyst Conference where AOL, Boeing, General Motors and others have presented issueswhich 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 nowrun as an independent community which does not generate code. The documentation of usecases 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 theRSA 2008 workshop. Interoperability will be a key factor when it comes to market adoptionof the tools and frameworks resulting from PrimeLife. As such, the results from theConcordia Project Interop should be followed closely. Still, PrimeLife might rather joinforces 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 groupwas created to intensify the work on interoperability between the different identitymanagement projects. The declared goal is to align the arising protocols, projects andcompanies such that overlaps can be avoided and the resulting infrastructure is interoperable.The main focus currently lies in the interoperability between InformationCards and OpenIDswhich shows that proprietary protocols and projects are considered as well as open sourceinitiatives. The open source projects taken into account are Bandit, Heraldry (integrated intoOpenID (see chapter 6)), Higgins (see chapter 7), OpenSSO, OpenXRI, Shibboleth andxmldap.

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 oneof the interoperability initiatives would be necessary to allow for an improved marketacceptance. It would even be desirable to develop interoperable prototypes.

9.8.1 Specification developmentOSIS is an opportunity for developers to gather data considering the interoperability of theircode with respect to other standards or implementations. Consequently, there is nospecification development apart from the specification of the features to test [OSIS FeatureTest].

9.8.2 Open Source Interoperability WorkshopsThe different projects developed various features which where tested for interoperability. Theresults of those interoperability tests are used to increase the quality of the respective project.The most recent identity interoperability conferences where the implementations were testedto discover the shortcommings of either the implementation of the respective standards were:

• I3a User-Centric Identity Interop at the 2nd European Identity Conference 2008 inMunich, April 22-25 2008

• I3 User-Centric Identity Interop through RSA 2008, RSA Conference, April 7-112008

• Catalyst Barcelona: October, 2007• Catalyst San Francisco: June 27, 2007• IIW 2007a Mountain View USA: May 2007

9.9 Pamela ProjectThe Pamela Project [Pamela Project] is a community driving the implementations of relyingparties for InformationCards. Currently, an InformationCard supporting relying party pluginfor Wordpress, Joomla and MediaWiki is developed and released under the BSD license. Theproject founders believe that an important reason for the slow market adoption of user-centricidentity technology (i.e. InformationCards) is the lack of available implementations of relyingparties. 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 ofsocial networking technology is an important fragment to incite market adoption, this projectdoes not offer many interfaces which allow for a connection to the PrimeLife project at thistime.

9.10 OpenSSOThe OpenSSO [OpenSSO] project aims at the development of a simple yet effective singlesign-on infrastructure for Web sites, which should allow for more secure electronictransactions, as users are no longer tempted to choose the same username/password pair fordifferent 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 commercialproducts System Access Manager and System Federation Manager, respectively. Currentlythe following standards are implemented by the OpenSSO project:

• ID-FF v.1.1 and v.1.2 (including identity provider and service provider extendedprofiles)

• 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 RequestorProfile and the Web Services Interoperability (WS-I) Basic Security Profile (BSP). Thesource is released under the Common Development and Distribution License (CDDL).

9.10.1 Architectural OverviewOpenSSO is a HTTP-based environment which provides an authentication service, a sessionservice and a logging service to provide the functionality of authentication, maintenance ofsession information and building of an audit trail. Those services are shared among differentinstances which leads to a single-sign on solution for the respective applications. A namingservice allows for addressing over different domains allowing an OpenSSO instance runningon a Web server to discover another OpenSSO instance. This enables not only single-sign onscenarios but also identity federation by using an implemented standard such as SAML toexchange identity information.

In an example scenario, a user wants to use a resource at a service provider (SP). TheOpenSSO aware SP will present an authentication interface to the user who, thereafter,provides the credentials. The authentication interface communicates with the authenticationservice. Upon successful authentication the session service is requested to issue a sessioncookie to the user. After this procedure the user is able to use the requested resource using thesession cookie.

9.10.2 Opportunities for PrimeLifeOpenSSO is rather a single-sign on mechanism then an identity management scheme. Whilethis 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 bepreferable for PrimeLife.

There are other approaches which aim in the same direction as OpenSSO. One such initiativeis 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 itallows for role based access control, strong authentication or federation. The data consumedby 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 releasesopen source relying parties which can be used together with the commercial server productsold by Ping Identity.

9.10.3 Open Source Implementations• OpenSSO Source Code [OpenSSO Code]• OpenIAM Source Code [OpenIAM Code]• SourceID Toolkits [SourceID]

9.11 OAuthThe OAuth protocol [OAuth Core 1.0] is built on top of HTTP. It enables authority delegationon 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. Theprotocol design assumes a prior out-of-band agreement between Consumer (C) and ServiceProvider (SP) about data usage and certain protocol aspects.

An example scenario is authorising a location information hub to access a social travel site'sinformation about the user's location: The location hub learns (from the user, or through areferral) about the URL of the user's travel profile. The user is redirected to the travel profilesite, where he can determine what information (if any) is given to the location hub, and howlong that authorisation should last. The authorisation information is passed back to thelocation hub, which can now process location information further. The user can revoke theauthorisation without collaboration from the location hub's side.

Another example scenario is authorising an application (on the Web or locally) to fetchphotos from a social photo sharing site.

9.11.1 Protocol flowOAuth assumes that a consumer and a service provider have an advance agreement whichmanifests itself in an (opaque) consumer identifier known to both consumer and serviceprovider, 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 theservice provider.

The basic authentication flow consists of three steps: First, the consumer obtains anunauthorised request token from the service provider. In requesting this token through HTTP,the consumer can provide additional parameters to the service provider, which mightinfluence the scope of the authorisation. The protocol provides a framework for passing theseparameters, 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 messageis signed with the prearranged key; it includes the prearranged consumer identity, a possiblyopaque 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 requesttoken, which may even be entered manually, enabling the user-facing parts of the protocol tobe executed through referral methods other than HTTP redirects. (E.g., the authorisation stepcould be performed through text message on a mobile phone.)

During the authorisation step, the service provider will authenticate the user and be informedabout the consumer identity and other pertinent information. When the user decision iscommunicated to the service provider through HTTP (and a callback URI was passed to theservice provider beforehand), then the service provider will redirect the user browser back tothe consumer; again, the request token is used to link the various requests. Otherwise, someother referral method might be used -- from contextual knowledge on the user side (theconsumer displaying an appropriate message) to URIs in text messages.

The consumer now performs the third step of the protocol: exchanging the request token foran access token. To this end, the consumer sends a specific signed request to the serviceprovider (through a direct HTTP request), which will (if the user had indeed authorised theconsumer) respond with an access token and corresponding secret. The request includes therequest token that had previously been used in interactions between the service provider, theconsumer and the user; and the consumer opaque identifier. The service provider answerswith the access token, a shared secret corresponding to that token, and any additionalparameters.

The access token and corresponding secret are then used to generate authorisation tokens onsubsequent 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 photofor purposes of printing). The authorisation information can be passed through the HTTPauthorisation header, as a POST parameter or as a query parameter on a GET request. Theprotocol does not impose any limitations on reuse of the access token; the life cycle of thattoken is determined by the service provider.

The protocol is implemented through simple HTTP-based transactions (including referralsaround the user authorisation decision); to achieve confidentiality of transactions, TLS isused. Confidentiality of network transactions is particularly significant for interactionsbetween 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 thecorresponding secrets.

9.11.2 Trust and privacy propertiesThe semantics of authorisations are out of scope for the protocol's definition: they are a matterof (out-of-band) negotiation between consumer and service provider, which are expected toshare API definitions, and of human-readable interactions between the service provider andthe user. Extension points in the protocol can be used to pass these semantics between theparties.

96

The user trust decision is made in a transaction with the service provider. The serviceprovider 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 interactionbetween the service provider and the consumer, so that the protocol only bears an opaqueidentifier (though implementations might choose a human-readable identifier) bound to asignature verification key known to the service provider.

Authorisation tokens can be revoked through an interaction between the user and the serviceprovider. The consumer does not require knowledge of the user credentials with the serviceprovider, 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 developmentOAuth [OAuth.NET] was developed by an ad-hoc group of contributors.

9.11.4 Open Source ImplementationsA list of implementations [OAuth Code] is maintained by the OAuth project.

9.12 NoserubNoserub [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 thefuture 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 botheither be embedded or referenced. It needs to be given in XFN/Microformat or FOAF wherethe Web accounts of this identity can be specified using a specific field in the FOAF or a fieldin a specific way in XFN. The contacts use the similar mechanism with XFN and FOAF toindicate that the URI refers to a contact. Noserub allows for a certain interoperability whichmeans that a contact which no Noserub Identity-URL can be added and their accounts (e.g. atflickr, del.icio.us, ...) can still be monitored.

Opportunities for PrimeLife

The documentation of Noserub is not extensive so far, which makes it challenging to judgethe 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 achallenging task to federate some formulated privacy requirements over the different servicesthat are integrated into Noserub. The other difficulty is clearly to formulate the privacyrequirements. Although the initiative of bringing different social networks together isvaluable, from a privacy point of view it adds much complexity.

97

Chapter10ConclusionThe PRIME Project [PRIME] has implemented a prototype of a privacy-enhancing identitymanagement systems (called integrated prototype) and, based on it, a number of applicationprototypes. Some of these components were made available as open source in the life time ofthe PRIME project and for some will be made available in the near future. This sectionreviews these components so that the PrimeLife project can evaluate which of thesecomponents are mature enough or should be extended and matured and then open sourced bythe PrimeLife project.

This section also shortly discusses the different activities 1,2,4,5, and 6 of PrimeLife, whatresults these aim to produce, and their potential for open source or standardisation.

10.1 Results Available From PRIME10.1.1 Privacy OntologiesWithin most PRIME components, the ontology is used as an unified framework to access thedata storage of the different PRIME subcomponents. For example, Session information abouta contact partner is stored and passed through the ontology. Some subcomponents e.g. thepolicy database and SPCC) use an legacy database or data storage back-end wired to theontology for internal usage.

The design of the ontology system supports the linkage of a complete legacy databasecontaining personal informations (e.g. a customers table in an SQL database) to the ontologyframework. Static relationship and data type definitions specify the translation of the legacydata information to an pre-agreed PII data scheme, which is currently a slight extension ofP3P 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 translationdescription is incomplete.

The design of the ontology also supports attaching data handling policies to exposed personalinformation, but the current implementation state lacks behind and this feature is currently notworking completely in the PRIME code.

98

The PRIME privacy ontology provides a flexible and powerful framework to model personalinformation and information about privacy-relevant properties of that information usingSemantic Web technologies.

Goals of the ontology developed in PRIME include:

• the ability to model arbitrary relational data schemata in a unified framework, basedon RDF

• the ability to model the relationship of such a data schema to an agreed ontology forpersonal information, such as the top levels of the P3P data schema

• the ability to thereby phrase privacy and access control policies in broadly agreedterms, while preserving their automatic applicability to data processed and stored inbusiness processes

• the ability to model the relationships between information that anonymouscredentials can provide, the information needed in authorization decisions, andpersonal information otherwise processed

• the ability to model privacy requirements, attach them to the data that are beingprocessed in a specific process, and to automatically verify whether privacyrequirements have been fulfilled.

All of these abilities involve the dynamic processing of a relatively simple ontologyframework, and of ontology components that model a specific application's needs and dataschemata.

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 inthe processing of relevant policies, and in the retrieval and processing of personalinformation.

We expect that PrimeLife work on policy languages will take up lessons learned in thePRIME 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 itsdesign. For example, static structures modelled as Java classes are used to read out parts ofthe data, which prohibits to transfer dynamic relation graphs and so later prohibits reasoningon this data. It is planned to fix this within the PrimeLife project.

However, additional resources to enhance the reasoning capabilities of PRIME are notexplicitely assigned in PrimeLife. In PrimeLife, work on ontologies is not an explicit workitem specified in the work plan, but ontology work might greatly benefit the work to be donein various areas of PrimeLife, e.g., policies, identity federation, and trusted content. Detailson further elaboration of ontologies are not decided on yet.

10.1.2 The JRC Policy WorkbenchThe JRC Policy Workbench [JRC Policy API] is an API for building policy editing andtesting environments, which includes an implementation of an editor for P3P 1.1 and P3P 1.0policies.

During the P3P 1.0 development IBM developed a policy editor. People in the W3C P3PWorking Group had realised that writing down the XML source code was an option only forprofessional 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 especiallyaddressing 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 andcomplex than the basic P3P expressions. It quickly became clear that a policy editor would bea good idea as a proof of concept as it would force to think through the main possibilities ofthe language developed by PRIME.

The JRC Workbench actually is not only a fully compliant P3P 1.1 editor, but it also exposesits APIs in a way to allow the easy integration of other policy languages. This will allow forthe 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 justconfuse users and bloat the interface into an unusable option-soup. So the guidance of theuser 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 realworld impact, it will have to make the implementation of service side components easy. TheJRC Workbench is the only tool around being capable of serving as a good basis for furtherdevelopment.

10.1.3 Policy LanguagePRIME results on policy languages are discussed in depth in PRIME Policy Languages (seechapter 4).

10.1.4 SendPersonalData dialogThe SendPersonalData dialog, also known as AskSendData dialog is the component askingthe user for selecting and confirming data sent between the local PRIME instance on theclient and the PRIME instance on the Web server side.

It is an Java application opened by the local PRIME instance when the interceptor plugin (seechapter 10) calls the Web service accessRemoteResource.

The purpose of the SendPersonalData dialog is to give the user an informed consent aboutprivacy circumstances, to query for PII data to expose to the server and for on-the-flymanagement 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 inthe source code documentation of PRIME (classes CommonMediatorService andRestrictedMediatorService).

The current architecture of PRIME allows to plug in any implementation of anSendPersonalData 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 byPRIME 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 outof 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 tobe 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 dialogswhich can create own Claims.

It has to be decided which of the prototypes developed in Activity 1 will use and extend thecurrent 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 thisSendPersonalData dialog.

There exists other implementations of the SendPersonalData dialog in some applicationprototypes similar to PRIME BluES'n (see chapter 10). The effort to replace the current dialogby other simple PII selection dialogs like Higgins [Higgins] is moderate. However, the moreadvanced features like AssuranceControl or the PrivPref management is very specific toPRIME, thus these features could only be reused with much effort in other open sourcesoftware.

Using the SendPersonalData dialog as an open source project separated from PRIME is onlypossible if the local PRIME instance Web services are implemented (much like for theConsole plugin (see chapter 10)). Other than the console, the HCI design of the dialog isbased on research results from within the PRIME project and represents a final HCIprototype. So, decoupling the SendPersonalData dialog from PRIME could be advisable, ifthe usage in a separate open source project is targeted.

10.1.5 Firefox pluginsThe PRIME project's results include three different Firefox plugins. All plugins are brieflyintroduced, and their possible usage in PrimeLife and their relation to existing open sourceprograms are discussed.

Interceptor

The interceptor is the smallest and simplest Firefox extension provided by PRIME. It listenfor incoming and outgoing HTTP connections from the Web browser and inserts or interpretsspecial PRIME http headers to communicate with the local PRIME instance. The headersintercepted are:

• All incoming Web sites are scanned for an HTTP-Header named X-PRIME-Handleand X-PRIME. If both are found, the Web service accessRemoteResource on thelocal PRIME instance is called, passing both header fields as parameter. The returnvalue of the Web service call is stored temporary.

• All outgoing Web site requests are inspected and if they point to a site, wherepreviously an session id was sent, the previously stored return value ofaccessRemoteResource is inserted as X-PRIME-Handle.

The overall code base of the interceptor is about 250 lines of JavaScript code (includingcomments).

101

There may be some minor modifications necessary to make it possible to call other PRIMEclient functionality than accessRemoteResource, as example to trigger the fetching ofcredentials or to open configuration dialogs etc.

The interceptor could be replaced by direct P2P communication frameworks based on Webbrowsers JavaScript to enable the PRIME server to communicate directly with the PRIMEclient 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 theused framework should be evaluated before introducing complexity.

About the possibility to use the Interceptor as another open source project: The interceptor isvery specific tight to the needs of PRIME and it makes no sense to make an open sourceproject out of this component alone. It could be evolved into an generic framework forcallback communication from Web server sites, but this would almost be the same effort aswriting an new one.

Console

The current user interfaces for managing personal information (PII) used in PRIME isimplemented as a Firefox extension called PRIME console. The main component is theinformation window for showing and editing the PII. Another component shows theDataTrack (see chapter 10).

Most of the implementation is still in beta state and some parts are non-functional. TheJavaScript 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 byWP4.4. In this progress, it is planned to reimplement the user interface in Java (there was aformer Java prototype, but this rewrite does not make use of it), because of easierimplementation of more advanced graphical interactions. The SendPersonalData (see chapter10) dialog has already been ported back to Java within the scope of PRIME and theDataTrack (see chapter 10) (which is currently part of the JavaScript-Console plugin) willprobably 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 ofthe user interface. The extensions will extend the interaction possibilities of the user with thedata in the local PRIME instance.

Lots of single-sign-on solutions exists with simple user interfaces for managing personalinformation (OpenID, SXIP). Also, some Web browser like Opera have personal data dialogsalready included for sending information through Web forms. Other applications provideaddress 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 simpleenumeration of a few identities) with a static set of categories. It is imaginable to includedisplay possibilities of PII's from PRIME in those interfaces. However, some prototypes ofA1 require more sophisticated management of PII than these tools provide.

102

More complex solutions to personal information management user interfaces includeMicrosoft 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 carriesout PII management as desired by PrimeLife. However, a close inspection is necessary todecide 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 currentPRIME user interface as well as use the CardSpace (see chapter 7) interface to access PRIMEenabled Web sites (only plans - AFAIK no delivery covers this). However, CardSpace (seechapter 7) does not support some features of PRIME as purpose binding, has only limited datatrack 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 fullyreplace the console with an existing open source alternative, but only extend existing productsto additional include parts of the console functionality.

Furthermore, the console functionality is specialised to the needs of the data model and PIImodel of PRIME, so if it were used outside of PRIME as an own open source product, thiswould limit its usage. From a technical point of view, extraction is as easy as implementingall required Web services that the console needs. Currently, there are about 15 Web servicesproviding mostly CRUD-functionality on several data types, but within PrimeLife this willextend to more sophisticated interfaces (including providing search functions or the intelligentsuggestion functions of PRIME). Although the Console could be used outside of the PRIMEtoolbox, the development of the new Java console would probably always be forked from themain development in order to support the very customised requirements of the PRIME PIImodel.

Formfiller

The PRIME firefox extension named "Formfiller" is an attempt to provide typical form fillerfunctionality with the PRIME as PII data source. This way, other PRIME features like theDataTrack (see chapter 0) and SendPersonalData (see chapter 10) dialog can be used to fill inWeb forms. As of IPv3, the plugin no longer works.

As far as we know, the form filler functionality is not explicitly requested in PrimeLife'sprototypes. Providing a form filler functionality can be interesting for real user acceptance ofother prototype functionalities. There exist several plugins and form filler systems for Webbrowsers, e.g. RoboForm [Roboform], AutoForm or SignupShield. Even more single sign-onor keystore solutions are available: PasswordSafe, Kesto [KESTO] and many others. It isadvisable to use an existing open source form filler instead of fixing the existing one, shouldthe functionality be needed in PrimeLife.

As the form filler is only an interface to call the SendPersonalData (see chapter 10) dialog, itcannot be used separately from PRIME. The user interface is restricted to only onecombination box, so reusing interface design is not possible either.

10.1.6 DataTrackThe DataTrack is a tool integrated into the PRIME Console to display information aboutreleased information. It is currently written in JavaScript using XUL as the GUI language. Ituses a Web service provided by the PRIME client core to obtain information abouttransactions 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 otherparties, showing the revealed information in a card-like fashion. The data is obtained via aWeb service from the PRIME client core. Other views show a table of all information sentthrough PRIME to any contact.

In its current state the DataTrack uses XUL RDF queries to obtain the data presented by themediator 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 sourcewith minimal change in the code base. The implementation relies heavy on Gecko DOM callsand most content is constructed dynamically. Because of this some code part could beconsidered 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 freetext search. It also displays a full contact information window when a receiver is doubleclicked in any view. However, the date search and the other search categories are not fullyimplemented in all views. The correct, delete and info functionalities of the current version ofthe DataTrack will only produce a placeholder e-mail with the subject and the contact e-mailof the receiver. These values are currently constants but if contact information is available inthe 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 thedifferent components of the JAVA incarnation (see below) could be used to display andhandle personal as pluggable classes in other JAVA applications.

The DataTrack is currently being ported to JAVA and a port with at least the functionality ofthe current IPv3 version will be available at the end of IPv3x. After this the transparencyfunctionality (i.e correct, remove and inform on personal data) will be implemented in aservice per service fashion for the first step in the 2.2.1 Transparency part of WP2.2. Togetherwith WP4.4 of PrimeLife, the user interface will be evaluated. Feedback will be integratedinto 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. Itcould be of further evaluation, whether existing products like iJournal from MozPETs suite,Higgins User Interface or the "Enhanced History Manager [EnhancedHistory]" plugin forFirefox could be enhanced to support the full feature spectrum planned for the Data Trackwithin 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 takingan access decision for all access requests directed to data/services. ACDF produces the finalresponse possibly combining the access decisions coming from the evaluation of differentpolicies (both access control/release and data handling). The elements relevant to the decisionare applicable policies, context which contains the information associated with the requesterduring a session, and subject, action, object, and purpose of the access request. The decisioncomponent 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 requestcan be granted or denied. In this case, additional information is needed and thecounterpart will be asked to provide such an information.

ACDF mainly interacts with others two components: the Request Context module and thePolicy Management (PM). The Request Context module keeps track of all contextualinformation, combines information from various context sources and deducts new contextualinformation from this aggregation. The main tasks of the Request Context module is toprovide contextual information from various sources in a standardised way, and to providereasoning functionalities for boosting the evaluation process (i.e., integration with ontology).The Policy Management component manages, stores, and distributes the policies to be used inthe access control evaluation process. The ACDF communicates directly with the PolicyManagement for retrieving all the policies applicable to an access request. One of the mostimportant functionalities of ACDF is to provide an infrastructure that combines the evaluationof access control, release and data handling policies. Given an access request of the form<user_id,action,object,purposes>, where the object can be a service or some PII associatedwith a user, the access request is first received by an enforcement point, called ACEF (PEP inthe XACML architecture), and then is evaluated by the ACDF in two steps as follows.

• 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, ifno 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 DisjunctiveNormal Form (DNF), meaning that rules inside the policies are ORed and conditionsinside the rules are ANDed. After collecting all applicable policies, each policy isevaluated inserting the policy conditions in a Reverse Polish Notation (RPN) stackthat is used to perform the evaluation. At the end of the policies evaluation, thesystem combines the single policies result to reach a yes, no, or undefined accessdecision. In case of a negative (no) access decision, the access request is denied, andthe process terminates. In case of an 'undefined' access decision, the informationsubmitted by the requester is insufficient to determine whether the request can begranted or denied. Additional information is required by communicating filteredqueries to the requester. Such requests are called claim requests. It is important tohighlight that, a claim request could contain sensitive information. In this case, asanitisation process can be performed before the claim request is sent to thecounterpart, to avoid the release of sensitive information related to the policy itself.In case of a positive (yes) access decision, the access request evaluation continuesand the ACDF has to verify whether there are some restrictions on the secondary useof the requested target.

• In the second step, the ACDF retrieves all data handling policies attached to thetarget of the request. If no data handling policy is applicable to the request, this stepis skipped and the access is granted. Otherwise, applicable data handling rules areretrieved 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 systemhas been developed in the context of the European PRIME project. The ACDF componenttakes an access decision for all access requests directed to data/services, by evaluating all thepolicies applicable to the requests. The ACDF has been designed to be thread-safe and thenits implementation supports the execution of multiple ACDF instances running at the sametime, without any interaction among them. After receiving the access request, the ACDF:

105

• retrieves the access control (release, resp.) policies by querying the PolicyManagement;

• evaluates the access control (release, resp.) policies by using a Reverse PolishNotation (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 datahandling policies) is the same and relies on a Reverse Polish Notation (RPN) stack. The RPNstack-based evaluation has the main advantages of being very fast and of making independentthe evaluation process from policy syntax and semantics. The translation from each policylanguage (both access/release and data handling languages) to the RPN format is made by thespecific implementation of a policy loader. In particular, two different classes interpret thesyntax of DHPs and the syntax of access/release policies. In this way, it is possible to add newpolicy languages by adding the specific loading class, with a minimal impact on currentimplementation. To conclude, it is important to remark that ACDF supports conditions to beevaluated both on certified data, issued and signed by authorities trusted for making thestatement, and uncertified data, signed by the data owner itself. The declared and certifiedinformation relevant to an evaluation process is retrieved from the Request Context module.

The Access Control Architecture is based on the traditional PEP-PDP-PAP infrastructuredescribed in the XACML proposal. The ACDF has the same role and responsibilities of theXACML’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 smallcoding effort. While the ACDF and Higgins address different problems, controlling accessand managing identities, respectively, they are therefore based on a similar paradigm: the useof an abstraction layer to unify different solutions. The ACDF has the following three mainextension points.

• Policy Loader. Multiple policy loaders can be added to allow the evaluation oflanguages based on policy syntax different from the ones used in PRIME project. Itis 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 policycomponents and mechanisms to combine policy conditions. RPN Stack Element canbe extended, changed (if their semantic changes), and deleted.

• Predicate Manager. ACDF manages several pre-defined predicates, which are usedto define conditions in the policies. The ACDF infrastructure is designed to supportnonstandard predicates defined a posteriori with a minimal impact on the evaluationengine.

To conclude, in the context of open source and standards, the main possible contribution thatcurrent ACDF implementation can provide is a stable and flexible evaluation infrastructurethat can be easily extended to cope and integrate different languages and models with alimited effort and changes to the evaluation engine. In particular, focusing on open source, theheterogeneity (in terms of diverse background and skill of the contributors) and the vitality ofthe community should foster the definition and development of many policy plug-ins to createadapter allowing the ACDF to evaluate several policy specifications, while keeping thecomplexity low.

106

10.1.8 BluES'nBluES is an online collaboration system which includes many components (e.g. chat,mailforum, calendar, content creation and presentation …) BluES'n is the privacy enhancedversion of BluES, which is extended with functionality coming from PRIME. Additionallythere 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 shouldhave the BluES'n concepts in mind, namely the group and privacy awareness features (infocenter), the contexts/Decision Suggestion Module and the Pseudonym-Alias-Mapping.Furthermore, BluES'n uses the transaction concept in place of sessions. This way, it facilitatesthe concept of unlinkability (which is a principle of privacy: start from maximum privacy).

10.1.9 PRIME Policy ManagerThe PRIME Policy Management (PM) component manages the overall policy life cycle byproviding functionalities for administering policies. It is also the component that interactswith the Access Control (AC) and the Identity Management (IDM) modules for filteringresponses coming from AC to IDM and for restricting the release of sensitive informationrelated to the policy itself or to the status against which the policy has been evaluated. Thedefinition of sensitive information and sanitisation operations are issues managed incooperation with the AC module. The Policy Management component addresses thefollowing 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 PolicyProcessing (Pproc) components. The Policy Presentation component acts as a policypresentation interface. It receives as input an access request and it returns as output all theapplicable policies. Ppres is used by the ACDF to take an access decision. Note that Ppresinteracts directly with the Policy Repository to retrieve policies. The Policy Processingcomponent provides filtering functionalities on the response that the AC module returns to thecounterparts. This avoids the release of sensitive information related to the policy itself. Forinstance, 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 yourcitizenship'). 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 sensitiveinformation and sanitisation operations are issues managed in cooperation with the ACmodule. Finally, the Policy Repository (PR) module provides policies storage and searchfunctionalities. The PR is based on the relational database concept and it is designed to beindependent from the real storage infrastructure. The PR provides a fine-grained queryinfrastructure, 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 tothe PR is filtered by the Abstraction Layer, and this implies that the Abstraction Layer unifiesthe interfaces to the PR module.

The PM component provides functionalities for policies administration. However, consideringa privacy-aware access control, the PM component accomplishes two main tasks: i) itprovides a searching engine to retrieve applicable policies to a given request, and ii) itprovides sanitisation functionality. The policy search engine is based on an Abstraction Layerthat provides generic interfaces for accessing the PR module. The Abstraction Layer isdesigned to support multi-threading access to the physical policies storage. The multi-threadsupported 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 theSCOOP model, the PR module is designed as a singleton Consumer. The Singleton patternensures that a class has only one instance and provides a global point of access to thatinstance. The PR then runs in a separate thread and waits asynchronously for the requests thata set of Producers insert in the PR’s requests queue. Each Producer registers a callbackmethod within the request. Finally, the PR processes the requests one-by-one, and the resultsare returned to the original requesters. The PR has been designed to support different kinds ofrepositories. In the current implementation, two different storages are supported:

• MySQL: it represents the world’s most popular open source database because of itsconsistent fast performance, high reliability and ease of use.

• HSQLDB: it is a leading SQL relational database engine written in Java. It has aJDBC driver and supports a rich subset of ANSI-92 SQL plus SQL 99 and 2003enhancements. It offers a small, fast database engine which gives both in-memoryand disk-based tables and supports embedded and server modes.

New storages can be added, if necessary, by implementing a single interface. This interfaceworks 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 tobe returned to the counterpart to avoid release of sensitive information related to the policyitself. In particular, it cleans the condition to be returned to the counterpart as the accessresponse, according to three possible levels of sanitisation: i) strong sanitisation means that afull 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 thanreturning original condition 'greater_than(user.Age,18)' as it is, a request for declaringuser.Age together with the applied operator is returned); iii) no sanitisation means that thefull, un-sanitised condition is returned (e.g., 'equal(user.Citizenship,'Italy')' is sent to thecounterpart without changes).

The PM has the same role and responsibilities of XACML’s PAP.

10.1.10 Obligation ManagerThe Obligation Management System (OMS) aims at providing privacy-aware identity lifecycle management capabilities to organisations that collect and process PII data. Byautomating 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, automaticallyscheduling 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 MixerThe IBM identity mixer [Idemix] system developed IBM's Zurich Research Laboratory is animplementation of the Camenisch-Lysyanskaya anonymous credential system. A credentialsystem consists of users and organisations. Organisations know the users only bypseudonyms. Different pseudonyms of the same user cannot be linked. Yet, an organisationcan issue a credential to a pseudonym and the corresponding user can prove possession of thiscredential to another organisation (who knows this user by a different pseudonym) withoutrevealing 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 forone-time use (these are called one-show credentials). Possession of a multiple-showcredential can be demonstrated an arbitrary number of times; these demonstrations cannot belinked to each other.

Apart from the pure cryptographic operations of the Camenisch-Lysyanskaya credentialsystem, Identity Mixer also implements the high-level protocols and policies to deal withcredentials (issue and presentation) as well as user interfaces to select credentials upon arequest for information. The first version of the Identity Mixer software was developed byIBM 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 thecryptographic operations have been made available as open source under the within theframework of the Higgins project. The cryptographic parts are expected to be availableshortly.

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, notmany aspects of it (nor anonymous credential in general) have been standardised. Relevantaspects include token formats, wire formats, cryptographic algorithms, claim languages, APIfor a credential system, etc.

10.2 Results Expected from PrimeLifePrimeLife has just started and therefore we have only just started to define the details of theresults that we aim to achieve by the end of the project. Thus, we can at this point only give arough idea of the planned results and their suitability for standardisation and for contributionsto open source bodies, which we do below.

10.2.1 Activity 1 - Privacy LifeThis activity's goal is to supply privacy-enabled identity management for the whole life ofpeople. To this end, the activity will building research prototypes for the following real-lifescenarios:

109

• Trusted Content: Supporting at least some user-centric control over a user’s personaldata in situations where she wants to share personal information with several otherpeople.

• Selective Access Control in Social Networks: Adapting the user-centric privacy-enhancing identity management of bi- or at most trilateral settings to newtechnological as well as business settings.

• Managing identity, trust and privacy throughout life: Sustainable Privacy andIdentity Management from birth to death.

A focus will be to formulate appropriate use cases and scenarios, condense them intorequirements, build an appropriate prototype which concentrates on the relevant aspects(otherwise both expenses as well as complexity explodes), learn the relevant lessons frombuilding, using, and evaluating the prototype, without being stuck in what is irrelevant detailand shortcomings in the prototype.

While we will make these prototypes open source when possible and feasible, we do notexpect that the outcomes of this activity will reach a suitable maturity level forstandardisation.

10.2.2 Activity 2 - MechanismsThe objective of Activity 2 is to perform basic research addressing the complex tool-relatedproblems of guaranteeing privacy and trust in the electronic society. The results of the activitywill 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 availablepublicly.

The development of privacy-enhancing mechanisms and techniques will in particular focus onthe following key problems:

• Development of cryptographic solutions for protecting users’ credentials, identitymanagement transactions; This includes various extensions of anonymous credentialthat will potentially be implemented as part of the Identity Mixer as well asmechanisms to store credentials securely.

• Development of metrics for expressing privacy compliance, trust and utility ofreleased data;

• Identification of privacy threats due to re-identification and correlation in datacollection and of means to assess protection/exposure against them;

• Definition of novel approaches for empowering the users, enabling them to acquirecontrol 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 activitycan be made available as open source and that some of them will be relevant tostandardisation bodies (either directly or in conjunction of the results' use in other activities).

10.2.3 Activity 4 - User InterfacesPrivacy-enhancing identity management will only be successful if its technologies areaccepted and employed by the end users. For this reason, the research and development ofuser 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 policydisplay and administration.

In particular, The protocols between the user side online functions for exercising user rightsand the services sides' transparency support tools that respond to them need to bestandardised. PrimeLife Partner KAU has already brought this up at the ISO/IEC JTC 1/SC27/WG 5 meetings. The transparency tools that will be developed can also be provided asopen source.

Besides, we have derived in PRIME a set of predefined privacy preferences, which a usercould choose from and fill in with concrete data values or customise "on the fly" and storethem under a new name. The predefined privacy preferences describe what types of datashould be released for specific purposes under specific conditions and the type ofpseudonymity 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 acertain service. Such a set of predefined privacy preferences as well as mechanisms forcustomising them on-the-fly (i.e. when they are used in interactions with services sides) couldbe standardised and provided to our open source products.

Furthermore, the multi-layered structures of privacy policies as suggested by the Art. 29 WPworking party in combination with mechanisms for obtaining informed consent for thedisclosure of personal data/ proofs with credentials could be standardised. In task 4.3.2, wealso mention in particular that the multi-layered structure for presenting policies could beextended by another top level consisting of standardised policy icons.

10.2.4 Activity 5 - PoliciesThe goal of Activity 5 is to design security and privacy policy systems for PrimeLife. Thisincludes analysis and formalisation of legal requirements, research into new policymechanisms, machine-readable languages for privacy as well as design & analysis of actualpolicy decision engines for the demonstrators that we build. Activity 5 is structured in 3 WorkPackages 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 thatcovered given data items. The policy activity faces multiple research challenges besidessatisfying the:

• Broader coverage: Privacy requirements cover more than mere access toinformation. Examples include retention of data or combination of data items. Thegoal is to cover the complete life-cycle of identities.

• Policy Composition: In the emerging Web, data and policy will be composed. Weneed to find ways to enable distributed management and authoring of policies.

• Stronger Enforcement: Today, privacy policies are mainly enforced by means ofaccess control monitors. One challenge we face is to invent additional enforcementmechanisms that allow protection despite the dispersion of data and the limited trustin the processor of personal information.

We expect that a number of the results of this activity will be suitable for making themavailable 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 andto extend existing standards as much as possible to achieve the best impact.

10.2.5 Activity 6 - InfrastructuresThe goal of Activity 6 is to investigate the impact of security and privacy requirements oninfrastructures. It studies technical and non-technical (e.g. legal, economic) requirements forsuccessfully implementing solutions on top of existing and newly developed infrastructuralelements. In particular, its work packages are concerned with:

• Privacy-preserving identity management for service architectures and general issuesof 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 regardinginfrastructures and interoperability, in particular for Work Packages 6.1 and 6.3. As theactivity will also do some implementation, contributions to open source are feasible.

10.3 PerspectivesOur 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 ofdifferent genres, architectures and infrastructures complicates our task. Some technologies arealready standardised, others are just open source projects without an open specificationattached to it. Some technologies are old well established standards for a given usage andcontext. PrimeLife has to find out whether they are usable in the context of the project. Someof the technologies mentioned did not fully succeed in the market. PrimeLife has to analyzewhat factors contributed to these effects, in order to prevent obstacles for dissemination of theprojects' results. By design, this report gives only an initial overview, it draws a certainlandscape of opportunities for PrimeLife. This report also confirms the conclusions from theW3C Workshop on Languages for Privacy Policy Negotiation and Semantics-DrivenEnforcement [W3C Privacy Workshop] that was initiated and very prominently supported bythe PRIME Project [PRIME]: While there is a large number of standards and open sourceprojects producing relevant technology for PrimeLife, the coordination between them isinsufficient. This issue falls in the scope of PrimeLife. It is taking over the coordination taskfrom the PRIME project, that lead to the creation of the W3C Policy and Languages InterestGroup (PLING) [PLING]. A well-established community can also provide for PrimeLife amuch 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, fromthe coordination power of a well-recognised W3C Working Group, thus sparing the cost ofcreation of such a platform.

Obviously there are privacy standardisation issues besides Policy and Languages, so thePrimeLife 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 beused 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 aspectof our undertaking, nobody knows how to make them work together. It is already clear thatselected initiatives in standardisation as well as in open source will have to be improved tomeet the PrimeLife quality expectations and to reflect the advancement of science intended byour project. This document provides a sound basis to resolve issues coming up whileintegrating privacy enhancing technologies into social networks. It provides the necessaryinformation to the inside of the project and will serve as warehouse for off-the-shelftechnologies that can be used by researchers and implementers exploring the path towardsincreasing privacy control in our daily life with the information society. Wherever PrimeLifediscovers inconsistencies, issues of interoperability and gaps, it will try to influence the wellidentified projects in some well defined aspect.

But taking into account the experience from the PRIME project, notably the policy languagescreated by PRIME, PrimeLife may also be forced to engage in further improvement anddevelopment of the PRIME languages including the standardisation of those languages.

10.4 Recommended next steps for standardisation &open sourceThe present document has defined the landscape PrimeLife is operating in. The variousrequirement documents to be produced by the project will determine which of those initiativesare targeted with priority. Where there are incompatible approaches, PrimeLife will have tomake a choice to integrate in one or the other platform. The evaluation will depend on amatrix of factors ranging from the facility and ability to influence and create or extend tosmall simple improvements, contribution of patches and simple use of existing technologies.Where there are opportunities to further the European paradigm of privacy and dataprotection, 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 August2006.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 2008https://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 Semanticsof 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 November2006.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 CandidateRecommendation, 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, 07April 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 20May 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 TechnicalReport, 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 WorkingDraft, 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 throughbiometric 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 applicationmanagement 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 andcommands 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 securityoperations.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 May2008.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, 1February 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 May2008.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 AnnualConference 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 vanHarmelen, 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 FederatedIdentity 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, OASISStandard: 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 March2005.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 19May 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, W3CRecommendation 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 May2008.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-DrivenEnforcement, 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 December2004.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 May2008.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 StandardSpecification, 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' WorkItem, 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), W3CRecommendation, 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-26September 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 May2008.http://yadis.org/

[ZXID]ZXID Home - Open Source IdM for the Masses, accessed 20 May 2008.http://www.zxid.org/

129