Title: SECURITY REQUIREMENTS FOR IDENTITY MANAGEMENT IN BUSINESS PROCESSES

Security Requirements for Identity Management in Business Processes

The analysis on a customer’s privacy and on security interests of the service providers involved shows the focus on the protection goals of confidentiality with regard to the personal data of the customer and accountability with regard to the transactions of the data provider, whether he is a customer or his proxy. In summary, the analysis shows that a customer’s privacy is violated precisely when his consent for data collection, processing, storage and delegation is contravened. With his consent, a customer provides the framework in which the respective personal data can be processed. This framework also contains the particulars of the parties, i.e. the service providers who should have access to the data and can use it according to the consent. Thus, an authorisation for the service providers concerned for processing the specified personal is on hand with a customer’s consent. Moreover, it must be ensured that unauthorised persons are refused access to the customer’s data and his communication relations in order to avoid abuse and profile creation. Based on the identified threats, the requirements of such an access and usage control system for identity management are described in the following. The requirements refer to the access to personal data in the first part and to their application in the second part.

Access to Personal Data

In order to self-determine the disclosure of personal data by a customer, identity management systems have the following properties concerning access to personal data: 

1. Secure data storage: According to assumption, a customer governs his data with a personal end device. In order that unauthorised persons do not gain access to his data it must be confidentially stored on the end device.

2. Situation-dependent disclosure of personal data: To counteract an undesirable creation of profiles and a collection of identifying data, the customer is able to control the release of his personal data. The situation, i.e. the respective service provider and the desired service, is to be thereby taken into consideration [Jen2002]. In addition to a conscious release of his data, it is also possible for a customer to have profiles generated in such a way that they do not overlap and that these various transactions of the customer cannot be traced back to him. However, this is only the case when two applications require different customer data for their service.

3. Delegation of the minimal authorisation: If an authorisation is to be used for access to a customer’s personal data, then the access is only concern the minimal customer data required for the purpose of data economy according to the Least Privilege principle (Saltzer and Schroeder, 1975). The requesting service provider should not receive additional data with such a specified authorisation. This property concerns the release of personal data if it is externally governed by a service provider. This corresponds to the access to a profile generated about the customer and, depending on the scope of the authorisation, enables a linking of profiles.

4. Unlinkability of transactions: If a customer appears under various pseudonyms, he can protect himself from a linking of his transactions and the profiles thereby generated. Depending on the type of pseudonym, the protection goal of accountability is at the same time fulfilled. This takes place subject to the number of persons appearing under the same pseudonym. If a customer only uses transaction pseudonyms, i.e. for each transaction a new pseudonym different from the previously used pseudonym is used, then each transaction appears uniquely. For a differentiation of pseudonym types and the associated possibility of a clear identification of a person, reference should be made to the classification of Andreas Pfitzmann und Marit Hansen (Pfitzmann and Hansen, 2006).

5. Authentication without showing identifying data: In order to protect himself from undesirable identification and linking of transactions, a customer is able to authenticate himself towards a service provider but without showing identifying data. One example is the proof of nationality by the customer verifying that the respective identity card was issued for him but without revealing its data, e.g. the personal identity card number.

6. Non-repudiation of customer’s transactions: Identity management systems guarantee that a transaction is clearly related to the agent, i.e. the customer or his proxy. Even if a pseudonym appears with a transaction, it cannot be used by the recipient of the pseudonym without further measures. This rules out an abuse of the transmitted data, i.e. the partial identity with the pseudonym.

7. Revoking customer’s anonymity in case of fraud: In order that prosecution is possible in the event of fraud and the fraudster can be called to account, his identity can be revealed. A case of fraud is to be clearly related to the fraudster together with the non-repudiation requirement of transactions.

These properties apply to the disclosure of personal and identifying data. At the same time, the security interests of the service providers can be preserved. These properties are however inadequate if personal and identifying data of the customer is needed for a service by another service provider. In the following section, the security requirements for controlling the use of personal data by identity management are derived from the threats of abuse and a delegation of customer data. 

Use of Personal Data

The security requirements of usage control are aimed against an abuse and undesirable delegation of collected customer data. At the centre of the security requirements for a use determined by the customer of his collected data is his consent in the form of an authorisation. An authorisation contains the rules for the access to and the use of the customer’s personal data. The security requirements for usage control are as follows:

1. Reference to purpose of an authorisation: If an authorisation is used for the use of personal data, then is should specify the connected purpose of collection and the subsequent processing, duration of storage and assertions for delegation of this data. The rules of the authorisation apply to the customer data concerned, the service provider who is hereby authorised for the usage, the operations to the customer data and to the period of time during which the usage is permitted.

2. Restricted delegation of an authorisation: If a service provider delegates a received customer authorisation to further service providers, the authorisation should only be valid if the customer has agreed to the re-delegation and a further authorisation relating to this is on hand.

3. Revocation of an authorisation: A customer should be able to revoke an authorisation for a proxy at any time if a proxy has turned out to be an attacker, the purpose of the data use has been prematurely completed and the original customer data is no longer up-to-date or invalid.

4. Integrity of an authorisation: A modification of an authorisation should be detected in order to prevent an abuse after receipt of a correct authorisation and to prevent or retrace it.

5. Enforceability of an authorisation: An authorisation should be able to be enforced according to its rules and limits so that an abuse of the pertaining customer data and its delegation by a service provider are ruled out. If it is not possible to enforce an authorisation, then the use of the associated customer data according to the authorisation should be traceable.

6. Access to collected personal data: Customers should have access to automatically generated profiles that may be applied to them and the possibility to actively adapt their own profiles.

Together with the requirements of an access to personal data, an access and usage control mechanism therefore ensues with which a customer can protect his privacy in the sense of informational self-determination in single or multi-stage business processes.