Title: :

The authentication model of Liberty Alliance focuses on a classification of identity providers with respect to their application domain. The tasks of an identity provider are certification of customer’s identities, management of these identities, authentication of customers towards service providers, and a confidential treatment of the knowledge about customer’s transactions. Application domains are defined depending on the trust and business relationships between service providers and identity providers. An application domain is called Circle of Trust. All identities of a customer for a given Circle of Trust are managed by the corresponding identity provider of this Circle of Trust. A login of a customer to an identity provider or to a service provider leads to an implicit logon to all service providers within this Circle of Trust. The relationship of different identities of a customer with in a Circle of Trust is called federated network identity (Cantor, Hodges, Kemp and Thompson, 2005).

Figure 5.6 shows two examples for a Circle of Trust. A customer uses two different identities for the application domains mobility and spare time. These two identities are disjunctive. Concerning the domain shopping, customer’s identities for the services car dealer, insurance, and finance are managed by the identity provider government. The identity provider myCity manages customer’s identities for the services free e-mail, sports, and ticketing of the application domain spare time. It is assumed that these identity providers also manage the personal data of a customer with respect to these applications. The identity providers government and myCity do not know a priori that the partial identities car holder and spare time belong to the same customer. A customer is able to distribute his identity to different identity providers and to divide one “Big Brother” in many “Big Brother” with less knowledge about the customer.

Figure 5.6 Distributing an identity to different identity providers for two Circles of Trust.

The General Single-Sign On Protocol of

Liberty Alliance specifies a general authentication protocol in order to realise a SSO. Based on this protocol, the protocols Liberty Artifact Profile for an exchange of a link to a credential of a customer, Liberty Browser POST Profile for an exchange of customer’s credential, and Liberty-Enabled Client and Proxy Profile for a redirect of an authentication request from one identity provider to another identity provider of different Circle of Trust are derived (Aarts, Kavsan and Wason, 2005). The general authentication protocol, as shown in Figure 5.7, has the following properties:

1. Involvement of an identity provider in all transactions within a Circle of Trust: All authentication requests of service providers to a customer within a given Circle of Trust are redirected to the corresponding identity provider. Thus, an identity provider is involved in each transaction of a customer with respect to a given Circle of Trust. This has an effect on the trust relationship between a customer and his identity provider with respect to the use of this knowledge: if a customer is not able to control the use of this knowledge by an identity provider, the customer has to trust his identity provider with respect to its use according to the negotiated policy.

2. Web browser as client software: This authentication protocol and its derivatives are based on the web protocols HTTP and SSL. A web browser without extensional functionality, such as Java or plug-ins, is sufficient for the use of this identity management system by customers.

3. Certification of an identity by a credential: An identity provider certifies the relationship between personal data and a customer by a credential. This credential is valid within the corresponding Circle of Trust. The grammar for a Liberty Alliance credential is derived from the standard SAML V1.1.

Figure 5.7 Authentification of a customer by using the general authentication protocol of Liberty Alliance.

A customer requests a service of a given service provider in step 1. Step 2 determines the address of the appropriate identity provider with respect to the current Circle of Trust. Step 3 requests the authentication of this customer by a service provider. This request is re-directed by the web browser of the customer to his identity provider in step 4, since an identity provider is responsible for an authentication response. This identity provider assigns the authentication requests to a customer. If this customer has not already proven his identity to his identity provider, the identity provider requests this customer for authentication in step 5. If the customer has proven his identity successfully, his identity provider responds in step 6 to the authentication requests of step 4 with the result of customer’s authentication. The result is either a credential of the customer consisting of his personal data with respect to the authentication request or a link to such a credential. This response is re-directed to the requesting service provider via the web browser of the customer in step 7. If the response is a link to a credential, step 8 and 9 are executed and the service provider gets this credential from the identity provider. Step 10 verifies the obtained credential. Depending on the authentication response, the service provider either grants or denies access to the requested service in step 11.

Access on Customer Data by an Authori

An exchange of customer’s data to service providers is carried out by a special service type called Data Services Template which complies with a directory service. Its specification (Angal, Cahill, Feng, Gourmelen, Kannappan, Kellomaki, Kemp and Sergent, 2005) defines a data model and an application interface for lookup and modification requests. This specification assumes that a data service protects customer’s data against an unauthorised access by an access control. If a service provider wants to have access on some customer’s data, he has to show his authorisation for the desired access. Liberty Alliance defines three use cases for showing an authorisation: a direct inquiry of the service provider at the customer, an indirect inquiry via an interaction service (Kemp, Madsen, Sergent and Whitehead, 2005), and a delegation of an authorisation from an identity provider to the requesting service provider (Aarts, Canales-Valenzuela, Cantor, Hirsch, Hodges, Kemp, Linn, Madsen, Sergent and Whitehead, 2005).

A direct inquiry is in fact a single-stage business process. Both a service provider and a data service provider interact directly with the customer. Figure 5.8 shows the interactions between these three participants. 

Figure 5.8 Authorisation of a customer with respect to access on his data according to a re-directed d inquiry of a service provider.

A customer authenticates towards a service provider and requests a service in step 1 by an authentication protocol of ID-FF. This service provider asks for some personal data of the customer stored by the data service provider in step 2. It is assumed that the service provider knows the address (URL) of this data service provider. Steps 3 to 5 re-direct this request to the customer. The customer decides on the access requests and thereby on the disclosure of his required personal data in step 6. The customer also shows his identity to the data service provider in step 6, too. This authentication is also carried out by an authentication protocol of Liberty Alliance. The data service provider receives the response of the customer in step 7. If the customer agrees to the desired access, the response in step 7 is the desired authorisation. Step 8 and 9 are a kind of acknowledgment together with the authorisation and gives the execution of this transaction back to the service provider. In step 10 repeats the service provider his request together with the authorisation of the customer to the data service provider. The data service provider checks the authorisation and, if it is valid, returns the requested personal data of the customer to the service provider in step 11. The customer gets the results of the data request in step 12.

Access and Use of Customer Data in Business Processes with Proxies

The other uses cases for an attribute exchange represent a multi-stage business process. In the second use case, an indirect inquiry and delegation of an authorisation, an interaction service provider takes up the role of a proxy. An interaction service is either carried out by the requesting or a third service provider. Figure 5.9 shows the interactions of an inquiry for data access via an external interaction service provider.

Figure 5.9 Delegation of an authorisation for an access on customer’s data to a service provider via an interaction service provider.

Step 1 corresponds to the request of a service provider to some personal data of a customer. A request is re-directed from a data service provider via an interaction service provider to the customer in step 2 and 3. A request consists of the URL of the data service provider, an informal description of the request, a URL of the request, and the request itself. A customer responds to the request in step 4. Since his response is re-directed via the interaction service provider, the interaction service provider gets to know the response. Thereby, the interaction service provider is a man-in-the-middle and as a proxy re-directs the delegates the response of the customer to the data service provider. Is the authorisation available to the data service provider, this provider discloses the requested personal data according to this authorisation in step 6 to the requesting service provider. The customer signs his authorisations optionally with his private key skU.

The third use case for an attribute exchange represents a delegation of an authorisation by means of a credential which has been issued by an identity provider of the customer. This identity provider confirms that a given service provider is allowed to act as a proxy of the customer towards another, so called, end service provider. By such an authorisation, a service provider is allowed to get access on customer’s data or to use customer’s data for a specific purpose. An end service provider trusts an identity provider that this identity provider issues authorisation according to his certification policy. A credential representing an authorisation is extended by attributes concerning the delegation participants and the purpose of a delegation. The statements of a delegation concern the identity of the customer and his proxy, latter by his public key pkProxy, the transaction identifier (TID), and the point of time when this credential has been issued. The statements concerning the purpose of a delegation relate to a service of a specific end service provider, given by a URL.

Furthermore, Liberty Alliance supports a delegation of an authorisation via several service providers. A delegation chain arises. The first node of a delegation chain is the service provider with whom a costumer interacts directly; the last node is the service provider who shows a delegated authorisation to the end service provider. In case of a transitive delegation, a delegation chain with at least two nodes, a credential for a proxy is extended by the nodes of the delegation chain. Thereby, an end service provider is able to reconstruct the certification chain by the delegation chain which is necessary to verify the credential of the requesting service provider. It is possible to restrict a transitive delegation in time and in the succeeding service providers respectively nodes. Liberty Alliance assumes that an end service provider will follow these restrictions, if he verifies a delegated credential. A transitive delegation via two service providers is shown in Figure 5.10.

Figure 5.10 Delegation and use of an authorisation with respect to an access on customer’s data via a delegation chain of two nodes.

In step 1 asks service provider 1 for an authorisation on behalf of service provider 2 in order to get access on some personal data of the customer which are stored at a data service provider. Step 2 re-directs the request to the identity provider of the customer who issues the credential with this delegation chain according to the privacy policy of the customer. By steps 3 and 4, service provider 1 gets the requested credential and forwards it in step 5 to service provider 2. In step 6, service provider 2 requests access on customer’s data and shows the delegated credential. The data service provider verifies the credential and grants or denies the access. Step 7 to 8 returns the result of this transaction to service provider 1.

But Liberty Alliance does not specify a protocol for the delegation of authorisations as a credential. Gomi, Hatakeyama, Hosono, and Fujita extend Liberty Alliance by a protocol specification for a delegation of authorisations (Gnomi, Hatakeyama, Hosono, and Fujita, 2005). Their approach is similar to Kerberos (Kohl and Neuman, 1993). Nodes in a delegation chain are seemed to be trustworthy with respect to customer’s privacy. Their protocol is not part of the current Liberty Alliance specification.

Security Properties of

The identity management system of Liberty Alliance realises an access control on the identity of customers. Additionally, this system supports a usage control by an authorisation concerning an access on customer’s data and using customer’s data for authentication of a proxy. The specification of the basic system ID-FF recommends using SSL or TLS in order to protect the communication channels with respect to accountability, integrity, and confidentiality of the messages between the participants. The security properties of Liberty Alliance with respect to disclosure and use of customer’s data and to accountability of customer’s activities are as follows:

1. Secure data storage: Personal data of customers which are stored by a data service provider are protected against unauthorised access [Aar2005b]. Since a customer is not able to control whether a data service provider enforces the access control according to his rules, a customer has to trust the data service provider.

2. Situation-dependent disclosure of personal data: Liberty Alliance refers to the principle of data economy during an authentication of a customer towards service providers. A customer is able to decide on the disclosure and so on the access on personal data. The implementation guideline of ID-FF (Kemp, Aarts, Bone, Castellanos-Zamora, Crom, Kannappan, Lindsay-Stewart, Maeda, Meyerstein, Nochimowski, Gonzalez, Poignet, Serret, Vanderbeek, Vittu, Walter, Sergent, Madsen, Cahill, Linn, Landau and Sibieta, 2005) recommends to respect customer’s privacy interests by a policy which is managed by an identity provider and followed in case of SSO. By using a privacy policy, a customer is able to decide on the use of his pseudonyms and to get informed when they have been used. The statements of a policy refer to a service provider. Depending on a service provider, a customer is able to specify his policy and thereby the use of his pseudonyms with respect to a transaction. But a customer has to trust his identity provider, that this provider follows the privacy policy of the customer.

3. Delegation of the minimal authorisation: A customer is able to specify the data types of the requested personal data in an authorisation. A request contains the requested data as attributes of type <InquiryElementType>. An authorisation picks up these attributes in combination with the decision of the customer. Depending on customer’s decisions, a data service provider grants access on these data. If an interaction service provider is used, an authorisation is not mandatory protected against modification. To ensure the integrity of an authorisation, Liberty Alliance recommends protecting an authorisation by a digital signature.

Since neither an inquiry nor the response of a customer is encrypted, an interaction service provider will get to know the information flow from this customer to the given service provider. Additionally, an interaction service provider is able to modify customer’s authorisation and use it for own purposes by replacing the name of the authorised service provider with his own name, if the authorisation is not digital signed. In this case, the least privilege of an authorisation cannot be guaranteed. The specification of an interaction service points these threats and a mandatory trust of customers in an interaction service provider out [Kem2005a]. In order to identify an abuse, a logging of an inquiry by all participating service providers and the customer is recommended but is not followed up.

1. Unlinkability of transactions: The basic system ID-FF considers personal data as customers’ pseudonyms.  By using pseudonyms, linkability of customers’ transactions by service providers is hindered. A pseudonym for a customer is either created by a service provider and federated with the identity by the corresponding identity provider or by an identity provider. Transaction pseudonyms are also possible and are implemented by a random number. The involved identity provider is able to link the transactions of his customers because of his involvement in each authentication of his customers.

A customer can also act with a pseudonym in a delegated authorisation. His pseudonym, given by the credential attribute <saml:NameIdentifier>, is encrypted by the pubic key of the end service provider and so cannot be read by his proxies. But, since the trust model of Liberty Alliance assumes untrustworthy service providers with respect to privacy, an end service provider would share his knowledge about customer’s pseudonym with the other service providers. Thus the encryption is useless.

If a delegated authorisation refers to an access on personal data, the mapping of a pseudonym to the corresponding data record at a data service provider must be identifiable for the data service provider in order to decide on the access inquiry. Consequently, a data service provider is also able to link customers’ transactions if they need access on those personal data which is stored by this provider. Profiling is possible. It follows that a customer has to trust his data service provider with respect to the enforcement of his access control and to the confidential treatment of his knowledge about customer’s transactions.

1. Authentification without showing identifying data: The response of an identity provider depends on the inquiry of a service provider and on the consent of the corresponding customer. If a service provider needs identifying data of a customer, this customer has to agree on this inquiry, if he wants to use this service. In this case, an authentication without showing identifying data is not possible.

2. Non-repudiation of customer’s transactions: Accountability of a customer to an identity respectively pseudonym is guaranteed by customer‘s authentication with a secure authentication token to his identity provider in step 5 of the general authentification protocol. An identity provider establishes accountability of customers for a given Circle of Trust. In case of a delegated authorisation, both customer and his proxy are given in the credential within the attribute SessionContextStatement. A proxy is given as a ProxySubject (Aarts, Canales-Valenzuela, Cantor, Hirsch, Hodges, Kemp, Linn, Madsen, Sergent and Whitehead, 2005). If an authorisation is available as credential, then it is protected by the digital signature of an identity provider.

3. Revoking customer’s anonymity in case of fraud: Depending on the application domain, the identity provider of the correspondent Circle of Trust is able to revoke the anonymity of a customer due to his involvement in each customer’s transaction within this Circle of Trust.

Usage of customer’s personal data for authentification is specified by an authorisation. An authorisation may be represented by a credential. Liberty Alliance has the following properties concerning a usage control of customer’s data:

1. Reference to purpose of an authorisation: The purpose of an authorisation with respect to a business process is given by the attribute ResourceAccessStatement. The purpose is given by the identifier of the customer and the proxy as well as the URL of the requested service.

2. Restricted delegation of an authorisation: An authorisation can be delegated via several service providers forming a delegation chain. A delegation chain for personalised services in a multi-stage business process is defined as ProxyTransitedStatement in a credential.

3. Revocation of an authorisation: Liberty Alliance does not consider a revocation of a delegated authorisation.

4. Integrity of an authorisation: If an authorisation is implemented by a credential, then its integrity is protected by the digital signature of the credential issuer. In case of a direct inquiry for an authorisation, the issuer is the customer. Otherwise it is the identity provider of the customer. In case of a direct delegation of an authorisation from a customer to the requesting service provider and in case of an indirect delegation via an interaction service provider, the integrity of an authorisation is not as default protected.

5. Enforceability of an authorisation: Liberty Alliance assumes that end service providers follow the conditions of an authorisation. But a customer is not able to control this. Consequently, a customer has to trust end service providers with respect to the enforcement of these conditions. In case of an interaction service provider, its specification (Kemp, Madsen, Sergent and Whitehead, 2005) proposes to create a transcript of the protocol run with all participants in order to verify the proper use of an authorisation afterwards by, e.g., an audit (Canales-Venezuela, Ellison, Hodges, Kellomäki, Kemp, Linn and Thompson, 2005).

Liberty Alliance supports a delegation of personal data of customers to proxies in order to get access on further services. However, Liberty Alliance assumes trustworthy service providers with respect to the enforcement of authorisation’s conditions. But this assumption contradicts with the assumptions in the trust model of Liberty Alliance with respect to privacy. The trust model assumes untrustworthy service providers except identity providers which are seemed to be trustworthy. Consequently, Liberty Alliance does not preserve privacy in multi-stage business processes.

Conclusion

The identity management system of Liberty Alliance enables customers to protect their privacy against threats of single-stage business processes, e.g., undesired identification, profiling, and linkability of their transactions. This is done by an access control on personal data of customers which is enforced by identity providers and data service providers. However, a customer has to trust these services that they do not share their knowledge about him without his consent.  

Regarding the use of disclosed personal data, Liberty Alliance specifies a use by authorisations. However, Liberty Alliance assumes trustworthy service providers with respect to the enforcement of authorisation’s conditions. But this assumption contradicts with the assumptions in the trust model of Liberty Alliance with respect to privacy. The trust model assumes untrustworthy service providers except identity providers which are seemed to be trustworthy. Consequently, Liberty Alliance does not preserve privacy in multi-stage business processes.

Identity Management with Partial Identities:

The iManager is the central security tool of a personal mobile device which is considered to be trustworthy. The iManager offers interfaces to the customer, to the security mechanisms, and to the applications of a mobile device. The access to personal data and to cryptographic keys is exclusively possible by using the identity manager. An application’s request to these data will be checked by the identity manager whether the customer has given his consent to the publication of this personal data in the current situation.

Architecture of

The architecture of the iManager and its interfaces is shown in the Figure 5.11. Based on a security platform, the components identity configuration, identity negotiation, and confirmation of action are responsible for managing the partial identities (Jendricke, 2002).

Figure 5.11 Architecture of iManager.

The user interface has to be comprehensible for security novices, since they are not able to verify and assess the security mechanisms of the iManager and therefore a misuse of them leads to a compromise of the security and privacy of the customer. The possibility of a misuse has to be reduced. The acceptance of the security tool also depends on its customer interface. In order to facilitate the use of a security tool, the protection goals of multilateral security (Rannenberg, Pfitzmann and Müller, 1999) have been classified in customer and system controlled protection goals by analyzing their interdependency (Jendricke and Gerd tom Markotten, 2000). This leads to a reduction of the customer interface complexity. The customer controlled protection goals anonymity and accountability are configured by partial identities and their choice in a situation. The integration of the iManager in the customer interface of the mobile device is shown in the following Figure 5.12. At any time, the customer is able to check his identity.

Figure 5.12 Integration of iManager in the graphical user interface of a personal mobile device.

The identity configuration enables a customer to choose and create a partial identity with respect to a current situation. A situation is defined by a communication partner, the current service and current partial identity. Since the anonymity level cannot increase subsequently any partial identity can not be changeable. If the customer wants to change the current partial identity, the iManager checks if the desired anonymity level could be reached with the intended change. Further implemented functionalities are: to edit partial identities, to store them in a secure database on the mobile device, and to recognise the current situation. The secure database stores partial identities and customer’s security, his privacy policies and rules for the security tools. A filter checks the data flow of the mobile device with regard to personal data. By this means, it is possible to fill a web form according to P3P with respect to a suitable partial identity and customer’s permission.

Figure 5.3 Solving a conflict by choosing the appropriate partial identity.

An identity negotiation is necessary, if a service needs more data from the customer than he wants to publish in this situation. This conflict can be solved with a negotiation between this service and the customer. A restricted automatically negotiation is possible by the implementation of P3P and consequently the comparison from the service’s and customer’s security and privacy policy. In case of a conflict, iManager informs the customer of this conflict and proposes solutions like a suitable partial identity for solving it. For example, in the scenario a customer wants to buy an electronic railway tickets and wants to get some premium points. For the premium points, the virtual ticket automat requests some personal data of the customer. A conflict occurs since the customer acts with his partial identity anonymous. The iManager proposes to use the partial identity traveller for solving this conflict. The Figure 5.13 shows this case.

The customer decides his accountability and the accountability of his communication partner for each partial identity. The component confirmation of action implements the accountability of the customer by a digital signature tool. It is used whenever a digital signature is required, e.g. for self-signing personal data. Since the customer declares explicitly his intent, he signs with his handwritten signature and authorises the digital signature tool to sign the corresponding credential. The digital signature key is selected by choosing the suitable partial identity. By this means, the technical functions of the key management will be shown in a more comprehensible manner.

The security platform consists of interfaces to cryptographic primitives, anonymity services, to a session management, a secure database, and to security services. Anonymity services are the foundation of identity management, since it enables to customer to be anonymous towards his communication partners. The anonymity service JAP (Berthold, Federrath and Köhntopp, 2000) is used for IP networks. For spontaneous networking, a library of the University of Rostock, Germany, (Sedov, Haase, Cap and Timmermann, 2001) is used. The cryptographic primitives for encryption and digital signatures are implemented by the library FlexiPKI (Buchmann, Ruppert and Tak, 1999).

Certification and Authentification by a Partial Identity

Authentification by a partial identity is based on a credential. A CA certifies the relationship between customer’s attributes and his public key pkU. A partial identity used by the iManager consists of personal as well as identifying data of the customer and pkU. The public key of a partial identity represents the corresponding pseudonym (Jendricke, 2003). A credential is implemented as an X.509 attribute certificate (Farrell and Housley, 2002). The certification and authentification process is as follows:

Figure 5.14 shows the certification process. Protocol participants are a customer with his personal end device including the iManager and a certification authority. It is assumed that the CA has authenticated its identity before the protocol start, e.g., via TLS (Dierks and Rescorla, 2006).

Figure 5.14 Certification of a partial identity.

Step 1 requests a certification of a partial identity A by the customer. The CA verifies the relationship of this partial identity to the given pseudonym of the customer (pkU). This is done out-of-band. If this relationship is authentic, the CA will create a credential consisting of the partial identity A and its identity by digital signing it with its private key skCA. Step 4 stores the resulting credential is the public directory service of the CA. Step 5 returns this credential to the customer. The customer staves it in the protected storage of his personal device and links it to the corresponding partial identity A in step 6.

Figure 5.15 shows the authentification protocol for a single-stage business process. It is assumed that the customer acts as default with his partial identity anonymous. No identifying data will be disclosed. A service provider needs some data about the customer to offer him his service. These data are summarised as partial identity b of the customer. Step 1 request the service of the service provider by the customer. In step 2, the service provider requests some personal data for his service. The iManager recognises this requests and verifies whether the current partial identity (here anonymous) allows this service provider to get access on the requested data. So, the iManager detects the current situation specified by the identity of the service provider, his service, the requested data, and the current partial identity of the customer. Since the customer acts under his partial identity anonymous, there is a conflict between the request and the current situation of the customer. This conflict is shown to the customer in step 4. The iManager also propose a suitable partial identity with respect to this situation. In step 5, the customer chooses a solution to solve the conflict which is here the change from partial identity anonymous to the proposed partial identity B. Step 6 changes the current identity to the chosen partial identity B. Step 7 is optional. The protocol continues with step 7 only if the customer has no credential for this partial identity. Otherwise, the iManager starts the certification protocol. Step 8 shows the partial identity B to the service provider by showing the corresponding credential. The relationship of this credential to the customer is shown by a digital signature with customer’s private key skPK_B with respect to the pkPI_B of this credential. In step 9 the service provider verifies the digital signature of the customer and his credential. Step 10 grants or denies access to the requested service.

Figure 5.15 Authentification of a customer in a single-stage business process by a partial identity.

Applying