Análisis estadístico

(PPIdP) has been introduced. A PPIdP is a special type of IdP hosted in a mobile device of a user and acts as the central component in User-controlled Identity Management. How the proposal of PPIdP can tackle a few of the stated limitations has been investigated. Addition- ally, the advantages and the current limitations of the proposal have been discussed. To show the applicability of the approach, several use-cases have been illustrated. A PPIdP imposes several functional, security, privacy and trust requirements. Therefore, it is also analysed how these requirements have been satisfied while designing and developing a PPIdP.

6.2

Definitions and Requirement Analysis

User-controlled Identity Management can be considered as an extension of the traditional concept of Identity Management. In essence, User-controlled Identity Management empow- ers users with the authority and control over their data which have been missing in the current setting of IdM. A few existing extensions of Identity Management may seem to offer a sim- ilar level of authority and control. One such extension known as the User-centric Identity Management[4, 107] will be investigated. The term User-centric Identity Management itself has two interpretations. In one interpretation, it refers to the IdM technology that will ensure that a user is placed at the centre of all protocol flows using that technology [107]. The argu- ment is that putting a user at the centre of all protocol flows will enable the user to control the data flow ensuring that the user knows what data is released to which entities. Modern IdM technologies such as SAML and OpenID are based on this concept. Unfortunately, this does not solve the problem of data ownership and the provider has the ultimate control over user data. In addition, even though such technologies are supposed to provide more control (e.g. the selective disclosure of attributes) during the data flow, it has been found that it entirely depends on a specific implementation and many implementations simply do not offer such a facility. The findings regarding this will be presented in Chapter 8. The second interpretation of User-centric Identity Management refers to the theoretical use-case of utilising a personal device to collect and store data from different IdPs. Then, the personal device can be used to authenticate and access different services [4]. Since this is only a theoretical model, this is not clear how such a model can be realised and how such a model can be used to tackle the stated problems. Also, this interpretation does not deal with the issue of data ownership since all data is stored at an IdP. In summary, the User-centric Identity Management moves toward the right direction to ensure users have more control over their data, unfortunately, does not handle all issues regarding data ownership and controllability. User-controlled Iden- tity Management builds upon the concept of User-centric Identity Management while adding the additional functionalities. In that sense, the User-controlled Identity Management can be thought of as an evolution of the User-centric Identity Management.

6.2. Definitions and Requirement Analysis 107

6.2.1

Definitions

At first, a definition of User-controlled Identity Management is provided.

Definition 24 User-controlled Identity Management consists of all the functions and capa- bilities of the traditional Identity Management as defined in Definition 15 while allowing users the following additional functionalities:

• full ownership of their data so that no other entities can impose ownership of it;

• ultimate controllability over their data including the selective disclosure of attributes, and thus ensuring no entity can get hold of any subset of it without her consent;

• availability of their data so that it can be used for online services and applications in a secure manner.

A system that can be used for User-controlled Identity Management is regarded as the User- controlled Identity Management System. Like any traditional IMS, such a system consists of three classes of entities - IdPs, SPs and Users - and respective protocols to enable interactions among entities of these classes. To equip the proposed system with capabilities of a tradi- tional IMS, any existing model (e.g. the Federated or Open Unfederated Identity model) can be used. Unfortunately, the IdPs and the SPs in these models fall short of realising the addi- tional functionalities. The two ways by which the additional functionalities can be realised are discussed next.

• The first way is to allow users to encrypt their data at source (e.g. at the device from where the data is being uploaded) before storing it at a provider. Then a third party (including a provider itself) will only be able to access the data when the user allows it by decrypting the data before sharing. In this manner, the provider will have no way to know which value for any attribute is being stored at their end. Ultimately, this will also undermine the possibility of abusing user data or sharing user data with any third party and thus solving a few of the existing problems (the second issue in Definition 24) and allowing users to have the ultimate controllability over their data. Unfortu- nately, this does not tackle the problem that arises due to the effect of multiple partial identities since users will still need to manage those partial identities across different providers as described previously. Moreover, this does not ensure data ownership. For example, a provider has the ultimate control on how and when the data is available to a user, even though the data is unusable by it. Also, if a provider is unavailable (it may go through a maintenance phase or may be forced out of business), users will not be able to access any data stored at the provider when required. In essence, this approach is promising, unfortunately, it does not solve all issues.

6.2. Definitions and Requirement Analysis 108

• The second way is to introduce a novel type of IdP that will be under the full control of a user. One way to achieve this is to ensure that users are the owners of this type of IdP. This enables a user to own any data stored in the IdP. However, the IdP must be equipped with appropriate technologies to allow users the full controllability of their data and to make these data available whenever required. In addition, such an IdP can be used to replace a significant number of IdPs where a user’s data is currently stored. This will reduce the difficulty that arises from the effect of multiple partial identities.

Clearly, the second approach is more advantageous for a user and that is why this approach has been adopted. With this goal in mind, a novel type of IdP called the Portable Personal Identity Provider is introduced and defined below.

Definition 25 A Portable Personal Identity Provider (PPIdP) is an Identity Provider that is under the full control of a single user and resides in a mobile device owned by the user. It is the user who must decide what attributes should be stored in such an IdP and which attributes should be released to which SP by this IdP.

Since a PPIdP is hosted inside a mobile device of a user, all attributes stored in it will be owned by the user. Hence there is no chance of any abuse by an IdP. However, it must be ensured that a PPIdP is equipped with appropriate technologies to allow a user to fully control the stored attributes. Apart from this, the IdP must provide an interface to allow users to add, update and remove attributes into this IdP as well as to set a Attribute Release Policy (ARP) that dictates which attributes will be released to which SP. Moreover, it is the responsibility of the IdP to ensure that all user attributes are stored safely and securely. Interestingly, such an IdP adds the feature of portability allowing a user to use it while on the move. Windows CardSpace, a former initiative from Microsoft, could act as a type of personal IdP [108] and was included with several versions of the Windows operating system such as Windows 7 and Windows Vista. However, it was not portable since it was only available for desktop computers. Currently, there is no such personal yet portable IdP and the implementation described here aims to fill this gap.

In short, additional functionalities of the User-controlled IMS will be realised using a PPIdP. Other entities (such as an SP and user) must be equipped with capabilities so that they can interact with the PPIdP using a protocol. Thus, the PPIdP takes the central stage for realising the concept of the User-controlled IMS.

6.2.2

Requirement Analysis

To ensure that additional functionalities are properly met and different key issues are effec- tively addressed, the following set of requirements, in addition to those given in the taxonomy

6.2. Definitions and Requirement Analysis 109

of Chapter 4), have been formulated.

Functional Requirements.

• Online Service Integration. All IdM protocols are based on standard web technolo- gies. Therefore, it needs to be ensured that a PPIdP is compatible with such web technologies and is integrable with online services.

• Visibility. The existing API of different IdM protocols (e.g. SAML and OpenID) have not been developed with a locally hosted IdP in mind. The general assumption is that both an IdP and SP are online and visible to each other. Since a PPIdP will be hosted inside a mobile device, this assumption does not hold. Therefore, there must be a mechanism to make a PPIdP and SP visible to each other.

• Federation. As discussed previously, SAML requires every entity to be a part of a federation before they can interact with each other and such a federation is established by exchanging metadata. Since a PPIdP is hosted inside a user’s mobile device and is maintained by the user herself, the traditional approach of exchanging metadata cannot be used to create federations. A mechanism needs to be provided to federate a PPIdP with other entities.

• Attribute Storage and Update. A PPIdP must store and handle attributes of a user locally and must provide an interface to allow the user to provide new attributes and update existing ones.

• Attribute Release Policy. There should be an interface to set up any attribute release policy which will dictate what attributes can be released to which SPs.

• Attribute Synchronisation. Nowadays, many users have more than one mobile de- vice. Some have a smart phone as well as a tablet and some have more than one smart phone and tablet. To enable a user to access the same set of online services using a PPIdP across multiple devices, a PPIdP must be installed on each of these devices. While using a PPIdP across multiple devices, a user may add, remove or update dif- ferent attributes in different PPIdPs in different devices during different interactions. Thus, she may end up with inconsistent sets of attributes in different PPIdPs. To en- sure consistency, there must be a mechanism to allow a user to synchronise attributes in these PPIdPs across multiple devices.