Resources
- Identity Use Cases & Scenarios.
- FIDIS Deliverables.
- Identity of Identity.
- Interoperability.
- Profiling.
- Forensic Implications.
- HighTechID.
- D3.1: Overview on IMS.
- D3.2: A study on PKI and biometrics.
- D3.3: Study on Mobile Identity Management.
- D3.5: Workshop on ID-Documents.
- D3.6: Study on ID Documents.
- D3.7: A Structured Collection on RFID Literature.
- D3.8: Study on protocols with respect to identity and identification – an insight on network protocols and privacy-aware communication.
- D3.9: Study on the Impact of Trusted Computing on Identity and Identity Management.
- D3.10: Biometrics in identity management.
- D3.11: Report on the Maintenance of the IMS Database.
- D3.15: Report on the Maintenance of the ISM Database.
- D3.17: Identity Management Systems – recent developments.
- D12.1: Integrated Workshop on Emerging AmI Technologies.
- D12.2: Study on Emerging AmI Technologies.
- D12.3: A Holistic Privacy Framework for RFID Applications.
- D12.4: Integrated Workshop on Emerging AmI.
- D12.5: Use cases and scenarios of emerging technologies.
- D12.6: A Study on ICT Implants.
- D12.7: Identity-related Crime in Europe – Big Problem or Big Hype?.
- D12.10: Normality Mining: Results from a Tracking Study.
- Privacy and legal-social content.
- Mobility and Identity.
- Other.
- IDIS Journal.
- FIDIS Interactive.
- Press & Events.
- In-House Journal.
- Booklets
- Identity in a Networked World.
- Identity R/Evolution.
D3.1: Overview on IMS
Good Practice Examples and Considerations of Privacy Enhancing Technical Implementation of These Mechanisms
Type 1 IMS: Account Management Systems
Personal data about employees and customers is often stored in so-called directory services (e.g. NDS, MS ActiveDirectory, LDAP, X.500). From a privacy perspective, it would be desirable if different groups or departments (or roles) would have different views on subsets of the personal data. For example, the authentication server should have access to authentication data of an employee, but not to address, phone number, etc. This can be achieved by role-based access control.
Type 2 IMS: Profiling Systems
Type 2 IMS will be subject of Deliverable 7.2 (Inventory on actual profiling techniques and practices). In this chapter we discuss some technical and organisational privacy enhancing techniques which are quite apparent. In some cases they collide with the targets of the operators of the profiling systems. To get a more practice oriented view on those techniques the scenarios in Chapter 2 of Deliverable 2.2 (Set of use cases and scenarios) can be used.
Section I - III (Functionality):
Profile data could be stored local and processed centrally.
Section IV (Security)
Data transfer is appropriately encrypted.
Section V (Privacy) and section VI (Interoperability):
The operator of the profiling system has a privacy rsp. data protection policy. Transferred data is negotiated automatically based upon privacy principles stated by the user using protocols like P3P. The transfer of the profile data needs the explicit consent of the user.
Type 3 IMS: User-Controlled Context-Dependent Role and Pseudonym Management
We list examples of e-mail, web and instant messaging software and configurations which partially implement the mechanisms categorised above.
Section I (Functionality: Identity administration):
Management of identities: Many mail readers facilitate automated handling of multiple e-mail accounts; to name a few: Eudora, Mozilla Thunderbird, fetchmail. Several web browsers have so called password managers to store username/password pairs per context; e.g., Mozilla, Opera. Divers instant messaging clients manage multiple nicknames for the user; e.g., gaim, irssi.
Credentials: Although the technique is published (see idemix, Chapter 5.4), there seems to be no available implementation of credentials for either e-mail, http or instant messaging.
Identity Recovery: We found no example.
Section II (Functionality: Notice):
Logging/history: Practically all e-mail readers allow logging of sent/received messages. Some instant-messaging clients allow logging of conversations. Local caching HTTP proxies like wwwoffle allow inspection of downloaded data to get an idea of which servers were connected to. There seems to be no convenient way of evaluating the logs automatically, though.
Context detection: Several web-browsers feature automated form-filling and password management as mentioned above.
Section III (Functionality: Control):
Rule handling: Internet Explorer implements (at least partially) P3P.
Anonymity: JAP helps to anonymise HTTP traffic, Remailers like mixmaster or mixminion to anonymise e-mail, services like Tor facilitate anonymity of TCP connections in general.
Section IV (Security):
Confidentiality: The OpenPGP and S/MIME standards define e-mail encryption and authentication. Tools like PGP, gnupg and openssl implement the standards. SSL/TLS for HTTP encryption is implemented in most web-browsers, e.g, Links, Lynx, Opera, Mozilla Firefox. A few instant-messaging clients allow encryption, e.g., skype, jabber, gaim with patches, silc, Trillian.
Integrity: Comes as side-effect of strong encryption.
Availability: Applications depend on many layers and components. Methods for assurance of availability range from redundant hardware to remembering to pay for the DNS entry.
Section V (Privacy):
Privacy control functionality and data minimisation are not easy to apply to client-side technologies. One example would be HTML forms that mark certain fields as optional, or web pages that present a privacy policy.
Standards: The TRUSTe seal announces conformance to TRUSTe’s License Agreements. These include among other points data minimisation. However, on one occasion of blatant privacy policy violations, TRUSTe proved extremely reluctant to revoke their seal on the offending site.
Section VI (Interoperability):
Compliance to existing standards: as most tools try to implement identity management aspects on top of e-mail, HTTP or existing instant-messaging protocols, the tools have to comply to the standards that define the underlying protocols.
Interfaces: Strict definition of the protocols behind the protocol used in Tor allowed an alternative, interoperable implementation.
Section VII (Trustworthiness):
Segregation of power, separating knowledge, reviewed by independent parties:
The businesses of authoring software and providing services are so different that the involved parties do not overlap.
Using Open Source: Most of the tools of type 3 IMS run on the client side or use peer-to-peer protocols, an area full of open source implementations.
Trusted seals of approval: There seems to be no example.
Section VIII (Law Enforcement / Liability):
Digital evidence and digital signatures: Existing tools implement “advanced signatures” according to the European signature framework Using, e.g., Mozilla’s PKCS#11 plug-in together with a smartcard could meet the requirements for even qualified signatures.
Data retention: Since end-users are not required by law to keep any transaction logs, there is no example.
Section IX (Usability):
Comfortable and informative user interfaces: The variance is extremely high. Some tools like the HTTP proxy privoxy show useful information and are easy to configure, while, e.g., the old PGP-based remailer network is extremely hard to use.
Training and education: Given the non-commercial nature of many of the tools there is almost no training available.
Low complexity: this varies greatly, depending on the problem. The complexity is comparatively low in HTTP-proxies like junkbuster, privoxy, webwasher, and quite high in mail-processing tools like mixmaster.
Raising awareness: the grass-roots nature of the market precludes systematic marketing attempts. Privacy problems are pointed out mainly by journalists, hackers and privacy protection officials.
Section X (Affordability):
Power of market: E-mail and web depend strongly on interoperability and conformance to the relevant IETF standards. As these are open standards, there is a healthy competition between implementers of clients or servers in this area. Commercial providers of instant-messaging repeatedly tried to stifle competition by changing their protocols between versions of their client software. In 2004, the IETF decided to standardise an instant-messaging protocol along the lines of an existing non-commercial one (Jabber). It remains to be seen if this will create stronger competition. There are open source implementations of every protocol for e-mail (in fact, the majority of mail transport agents that provide the e-mail infrastructure are open source) and HTTP (in fact, the majority of web servers are open source). Government subsidies are rare, a notable exception being projects developed and maintained at state-owned universities.
20 / 31 |