D3.1: Overview on IMS

 

Mechanisms to Meet Requirements of IMS with Respect to Privacy

 

Introduction

 

The following categories and mechanisms are derived – among others – from [ICP03]. The categorisation is commented with respect to privacy.  

The mechanisms are listed in sections. Each block has enumerations describing the mechanisms and listing partial mechanisms. 

Section I to III is describing the main functionality of the different types of IMS.  

Section IV is describing security as a mechanism. Generally security is also seen as fundamental for privacy. 

Section V describes specific and general mechanisms to meet privacy requirements. 

Section VI describes mechanisms to achieve interoperability. Depending on the type of IMS those requirements differ. Type 1 IMS especially require compliance with standards in the area of authentication systems (e.g. PKI) and directory services (e.g. LDAP, SAML etc.). Type 2 IMS require Interfaces to collect data generated or transferred from the user-client. Type 3 IMS require in addition to the standards mentioned for IMS Type 1 the integration of various existing identity management applications to larger identity management systems.  

Section VII to X describes mechanisms for Type 3 IMS which are important to make the existing applications (today mainly client-side tools) attractive for the majority of users. Those mechanisms are meant to overcome the main observed obstacles for a better market penetration of Type 3 IMS.  

 

Type 1 IMS: Account Management Systems

 

1. Functionality: Centralised and decentralised account administration 

   1. Centralised creation of accounts, decentralised administration of identity information 

   2. Centralised role Management 

   3. Identity recovery 

 

1. Functionality: Logging  

   1. To determine the attempt to access restricted data 

 

1. Functionality: Access control 

   1. Authentication and application of roles 

   2. Single Sign-On 

 

1. Security (the following aspects of Security are taken from1, the IT Baseline Protection Manual and the British Standards (ISO/EIC 17799))

   1. Confidentiality (e.g. secrecy of authentication data) 

   2. Integrity (including non-repudiation) 

   3. Availability 

 

1. Privacy 

   1. Privacy control functionality (consent, objection, disclosure, correction, deletion and addition of privacy information) 

   2. Role-based access to privacy information stored in the accounts 

   3. Data minimisation: Storing and processing only data which is really necessary 

   4. Standards (e.g. P3P), seals (e.g. Privacy Seal by ICPP) and penalties

 

1. Interoperability for third party integration 

   1. Compliance to existing standards  

      1. Examples: LDAP, SAML etc. 

   2. Well defined interfaces 

 

Type 2 IMS: Profiling

 

1. Functionality: Logging user interaction and generate profiles for further internal use 

 

1. Functionality: Notice 

1. 1. Share profile data with the user 

 

1. Functionality: User control  

1. Rule handling 

1. 1. 1. User is in control of the data transferred into the profile or the profile itself (by local storage and central processing) 

 

1. Security 

1. Confidentiality (e.g. anonymisation, secrecy) 

2. Integrity (including non-repudiation) 

3. Availability 

 

1. Privacy 

1. Privacy control functionality (consent, objection, disclosure, correction, deletion and addition of privacy information) 

2. Data minimisation: Storing and process only data which is really necessary 

3. Standards (e.g. P3P), seals (e.g. Privacy Seal by ICPP) and penalties 

 

1. Interoperability for third party integration 

1. Compliance to existing standards 

2. Well defined interfaces 

 

Type 3 IMS: User-Controlled Context-Related Role and Pseudonym Management

 

1. Functionality: Identity administration 

1. Communication-independent handling and representation of identities: Possibility to choose between different profiles / data schemes; creating, updating, deleting identity and identity information 

2. Pseudonyms with specific properties: Using pseudonyms for privacy enhancement by averting linkability 

3. Credentials: To reach an optimised privacy protection credentials can be used as convertible certifications by which authorisations obtained under one pseudonym can be transferred to another pseudonym without loosing unlinkability. Although an authorisation is bound to an individual and can be reliably used in many contexts, its use does not automatically lead to data trails or unwanted disclosure of personal data. As long as the individual does not misuse the credential, anonymity is guaranteed. 

4. Identity recovery: A user may want to prove that a given pseudonym was in his control at an earlier time.  

 

1. Functionality: Notice 

1. History management: Possibility to log transaction for reconstructing and analysing data flow 

1. Example: Illustrating what the communication partner knows from previous transactions; filters could be used to get a view e.g. on identity and identity information 

2. Practical view: email communications have to be stored completely, because the privacy-relevant content cannot be analysed automatically. 

1. Context detection: which partial identity was used in which transactional context? 

 

1. Functionality: Control  

1. Rule handling 

1. Support user to choose the right profile / preferences etc. 

1. Anonymity as base-rule for privacy enhancement 

1. Essential on the lower layers to enable Identity Management 

2. Anonymity is also seen as mechanism for security, especially confidentiality 

 

1. Security 

1. Confidentiality (e.g. anonymity, secrecy) 

2. Integrity (including non-repudiation) 

3. Availability (e.g. if a cascade within anonymising service such as JAP/AN.ON goes down an automatic redirect to another cascade takes place) 

 

1. Privacy 

1. Privacy control functionality (consent, objection, disclosure, correction, deletion and addition of privacy information) 

2. Data minimisation: Storing and process only data which is really necessary 

3. Standards (e.g. P3P), seals (e.g. Privacy Seal by ICPP) and penalties 

 

1. Interoperability for third party integration 

1. Compliance to existing standards 

2. Well defined interfaces for integration in popular software (e.g. mailers, browsers, etc) 

 

1. Trustworthiness 

1. Segregation of power, separating knowledge, reviewing by independent parties 

2. Using Open Source 

3. Trusted seals of approval 

 

1. Law Enforcement / Liability 

1. Digital evidence 

1. Example: Proof of transactions etc. 

1. Digital signatures 

2. Data retention 

1. Comment: this is contrary to privacy 

 

1. Usability 

1. Comfortable and informative user interfaces 

2. Training and education 

3. Low complexity 

4. Raising awareness 

 

1. Affordability 

1. Power of market: Create IMS that are competitive and are able to reach a remarkable penetration of market  

2. Using open source building blocks 

3. Subsidies for development, use, operation, etc. 

 

 

19 / 31