D3.8: Study on protocols with respect to identity and identification – an insight on network protocols and privacy-aware communication

Title: USER-CENTRIC IDENTITY MANAGEMENT

User-centric identity management

An important aspect of the right of privacy is the right to control the way personal data about oneself is collected and used. The substantial need for privacy protection is recognised by current legislation concerning the automatic processing of personal data. The Directive 95/46/EC of the European Parliament and of the Council “on the protection of individuals with regard to the processing of personal data and on the free movement of such data” (EU-DPD 1995) creates a legal framework that has to be followed by all member states of the European Union. 

In traditional identity management systems identity information is hosted and managed by an identity provider using for instance directory services (Wikipedia: Directory service 2007). This has various advantages from the service provider’s point of view, for instance being cost effective and easily scalable. However, by applying such an approach the user loses some control over his identity information. Recently, this has resulted in the emerging trend of user-centric identity management (Jøsang, Pope 2005). In user-centric identity management the user is put in the centre of interest by giving him control over his identity information. In particular, this means that the user himself decides which information should be forwarded and revealed to a particular service provider. This has the obvious advantage of better protecting the privacy of the involved user and gives the identity information back to who it belongs. The major drawback of a user-centric approach is that the user is in charge of storing and maintaining his credentials. Another drawback is due to the fact that this is a relatively recent phenomenon. As a consequence, the existing identity management standards offer only very basic support for user-centric identity management.

This survey into user-centric identity management and their support in federated identity management standards, such as SAML, Liberty Alliance, and Shibboleth is divided into four parts. In the first part we recall the functionality of anonymous credentials (also called private credentials or minimal disclosure tokens) as the most relevant cryptographic technique for user-centric identity management and discuss a change in terminology. In the next two sections we investigate the state of the art of XML security and federated identity management by looking at the most widely used (industry) standards in the field. In the last section we sketch a path for reconciling the existing federated identity management solutions with a more user-centric approach. In our opinion truly user-centric identity management can only be deployed in several phases, through stepwise deployment of new privacy enhancing technologies in the existing technological environment. 

Part of the work on XML standards and credentials is based on a previous study on privacy enhancing techniques done for the Belgian IBBT E-HIP project (IBBT 2007). 

Anonymous credentials or minimum disclosure tokens

Federated identity management is about the mechanics of identity and its power relations. It is about exchanging data and establishing the validity of this data. A large part of it deals with compatibility between different systems and standards compliance.

The social dynamics that deal with determining who has the power or the customers confidence to hold identity information are outside of the scope of existing technical solutions for federated identity managements. So are the checks and balances that ensure that the dissemination of this information to other organisations follows the rules set by law or by the individual affected. The whole system is fundamentally based on trust in entities that are out of the immediate reach of the user and the technologist. 

Unfortunately the attacker to privacy is not restricted in a similar fashion. Recorded data can be stored indefinitely, and powerful search and analysis tools can be used to construct a detailed picture about the user from many small puzzle pieces. 

For protecting privacy, the goal set by cryptographers is to release as little unwanted information as necessary while still being able to execute secure transactions. In particular the reconstruction of the detailed picture from the small puzzle pieces should be prevented. 

The best metaphor for this approach is that of a city (before the time of surveillance cameras and efficient face recognition software). Surrounded by millions of people, involved in a network of social activity, it was unlikely that any action outside of the immediate private sphere went unobserved. Someone was bound to see it, but contrary to small towns or small to medium sized companies there was little chance of information and rumours spreading. 

The main feature that allows for this anonymity of the big city is something that does not exist in the digital world: ambiguity. If we see a complete stranger we may not be able to recognise him again later on. We know people in a certain context, e.g., as a regular customer to our shop, or as having certain roles: teacher, nurse, etc. It is when we start using the power of words that we start attaching names to people. At times we only know people by their first name. We meet them in a social context, and there is a long process of building up trust and mutually exchanging information. If we feel uncomfortable, we have the possibility to back off and escape into the crowd of other people, back into anonymity. 

There is a strong tendency to anthropomorphise the Internet or as it is sometimes called the cyberspace, that is to use simple abstractions and to ignore the technical implications of what we are doing. These abstractions are useful, but they become dangerous when analysing the security properties of a system. When information is available in bits and bytes there is no ambiguity. Once an identifier or label has been attached to a piece of data, it is there, readable and searchable until it gets removed. We call a label that is used as replacement for a person’s name a pseudonym. Not surprisingly persons that were subject to wide public attention such as writers or political figures already used pseudonyms in the pen and paper world to protect their privacy. We study the use of unlinkable user-generated pseudonyms as a replacement for the vagueness found in the real world. 

Pseudonymity and anonymity

Anonymity can be defined as: “… the state of being not identifiable within a set of subjects, the anonymity set.” (Pfitzmann, Hansen 2007) Furthermore the authors define pseudonyms: “A subject is pseudonymous if a pseudonym is used as identifier instead of one of its real names.” In the digital world pseudonyms are bit strings that are unique in a certain context. Depending on the scope of the context we can define different pseudonym types: 

1. person pseudonym: Is a substitute of the holders name.

2. role pseudonym: The holder uses this pseudonym only in a given context while he acts in a certain role.

3. relationship pseudonym: The holder uses this pseudonym only for a single relation.

4. role-relationship pseudonym: The holder uses this only in a certain role and relation.

5. transaction pseudonym: The holder uses this only for one transaction.

These pseudonyms form a lattice according to the amount of information they reveal about the linkability to their holders. This lattice is shown in Figure 23 (cf. Pfitzmann, Hansen 2007).

Figure : Pseudonym types

In wide area networks – such as the Internet – every transaction leaves a data trace. Without protection measurements these traces contain data like who accessed which data/service at which time. This information is revealed, even if the data content itself is encrypted. Already in a closed environment like a company the protection of the network against externals is a necessity but it is more difficult to protect sensitive transaction data against an internal attacker. For example in a hospital, the network administrator should not be able to access a patient’s personal data nor should he see who has accessed this data when. Similarly only the information that a user is requesting a certain service may put her privacy at risk. 

If one wants to integrate databases in a federated manner the problems mentioned above are amplified. Access control mechanisms and basic encryption schemes can protect sensitive databases against external observers. If aggregated data is to be made public, data anonymisation techniques can be used to protect the privacy of individuals who contributed to the results. 

With the help of pseudonyms we can do more. By revealing only the most necessary information, we can protect sensitive data even against too curious service/infrastructure providers. If pseudonyms are unlinkable the privacy attacker cannot construct the complete picture from the information he collected about the pseudonyms. 

Pseudonyms help to protect a user’s privacy; they also change the way conventional security properties like confidentiality, integrity and availability are guaranteed. These properties are often based on a long term relationship between the user and the organisation that wants to enforce the properties. If pseudonyms are used, the organisation needs to establish the access rights of the user for every pseudonym separately. It is not who you are, but what you are that determines the rights of the user. In this sense, the introduction of pseudonyms forces the security engineer to think more deeply about the connection between identity and security. It was already noted that this connection is one of the hard problems in network security engineering, even if only conventional security properties and mechanisms are considered: 

Identifying a person by a unique identifier is not as simple as it may seem. Social security numbers and credit card numbers get stolen (Weinstein, Neumann 2003). Digital certificates have their weaknesses: Companies or persons can have the same or similar names. Certificate authorities generally disclaim any liability and any meaning to identity certificates. These problems are elaborated in more detail by Ellison and Schneier (Ellison, Schneier 2000). Consequently, the use of unique identifiers alone, while allowing tracking and profiling, does not provide adequate security. 

In order to achieve accountability we need to connect identifiers or pseudonyms to authentic and certified information. Instead of identifying themselves, users show information and evidence of the correctness of this information under a pseudonym. 

In the following section we show how to achieve this in a privacy-friendly way. 

Using credentials

Giving users protected documents which allow them to prove statements about their relationships with public and private organisations is an alternative to keeping large centralised user records. Paper world examples of such documents are passports, driving licenses, and money. Further examples include credit cards, health insurance cards, cinema and public transport tickets, club membership cards, and game-arcade tokens. 

Some of these documents can be easily forged while others are protected by special physical properties and the law. Documents providing information about the owner and his relationship with other entities which are protected against forgery are called credentials. Credentials are issued by organisations that ascertain the authenticity of the information and can be provided to verifying entities on demand.

A common example is the ID, be it a passport, a driver’s license, or some other identification card. An ID usually contains the essential personal information about its owner and is certified by the ID issuer. In certain situations it may be advantageous to reveal only parts of the information contained in a digital ID card, e.g., some lower limit for the person’s age or the fact that the person is capable of driving a car. 

Credentials can have several security properties and can be equipped with optional features in order to address the three main concerns of identity management: to protect the business of companies, to ensure the sovereignty of an open society, and to ensure the privacy of individuals: 

1. Firstly, and foremost, they have to be unforgeable to guarantee that all the information transferred is vouched for by their issuer. This also includes consistency in the sense that colluding users cannot combine credentials. 

2. Secondly, they should reveal only what the parties involved in the transaction agreed upon. This also includes relationship information. We discuss below how this property is connected to anonymity and the use of pseudonyms. For this we will split up this property into three sub-properties. 

Since David Chaum (Chaum 1985) first defined the concept of digital credentials and pseudonyms, a lot of thought has been invested into giving individual users the best amount of privacy and protection against abuse while still providing companies and the society at large with the required security features to protect businesses and societal goals against misuse by individuals.

The anonymous credential system proposed by Chaum is sometimes also referred to as a pseudonym system (Lysyanskaya et al. 2000). This stems from the fact that the credentials of such a system use the psedonymity paradigm to control linkability. Credentials are obtained from and shown to organisations using different pseudonyms which cannot be linked. In certain extraordinary situations trusted organisations might be authorised to link two pseudonyms or even to reveal the identity of the user. This procedure is called anonymity revocation.

The introduction of pseudonyms (Chaum 1985) is a useful extension to anonymity. Pseudonyms allow users to choose a different name with each organisation. Generally these pseudonyms cannot be linked without the help of the user. Nevertheless certain statements about the relationship of a user with one organisation, under a pseudonym, can be shown to another organisation that knows the user only under a different pseudonym (Lysyanskaya et al. 2000). While pseudonyms allow organisations to create accounts for individual users, organisations cannot determine the real identities of their customers.

The extent of influence law enforcement will have on credential systems is still a matter of debate. Key escrow has been discussed in the nineties as a possibility for allowing law enforcement authorities to eavesdrop on encrypted connections (Abelson et al. 1997). Anonymity revocation serves a similar purpose by revoking the anonymity of communication and credentials and may face similar resistance. While the cryptographic techniques for identity revocation already exist (Camenisch, Lysyanskaya 2001), implementing the required trust infrastructure and getting the necessary support from all parties involved is not an easy task. However, if the only alternative to anonymity revocation and trustee based tracing is to have no anonymity at all, the wisdom of fighting these privacy restricting technologies becomes doubtful. This however does not remove the need for privacy activism, as each restriction of privacy should be judged on its own ground to avoid a domino effect.

We formalise the properties required from a credential system using data structures and algorithms. We will also show conventional PKI algorithms that can be seen as a special case of anonymous credentials. 

First we note that a credential cred is a secret entity that is known only to a user. Similarly pseudonyms consist of a public part pseupk and a secret part pseusk. All of these datastructures are created through interactive protocols, to which both sides contribute randomness, and information computed in other algorithms. As is the case in most cryptographic algorithm, the first thing parties do is to generate keys: UserKg generates the users secret and public key (skU, pkU) and OrgKg generates the keys (skO, pkO) of organisations that want to issue or verify credentials.

Sign(sk, m)     
Both the secret keys of organisation and users can be used as conventional signing keys. This allows users to sign messages under their identity. It is also possible to sign using the pseudonym secrets pseusk. The output of the algorithm is the signature s.

Verify(pk, m, s)     
verifies a signature on a message with respect to a specific public key, or the public part of a pseudonym.

IssueCert(skO, attrs)    
An organisation can use its key to sign attributes in order to create a conventional certificate cert. For an identity certificate the public key of the user pkU and the user’s name would be one of the attributes. The certificate consists of a signature s and the attributes and can be verified by treating the attributes as the message using Verify(pkO, attr, s).

The issue protocol may be interactive to allow for a proof of possession, i.e., the user has to show that he actually possesses the secret key skU corresponding to the key pkU. In order to allow for the full power of anonymous credentials we require interactive protocols in which users and organisations input different data and interact in multiple rounds of communication. We write an interactive protocols Prot as ProtU(input) « ProtO(input).

RegisterNymU(skU, unique?) « RegisterNymO(unique?) In order to create a pseudonym pair pseupk/pseusk the user uses her master secret. The organisation does not learn anything about skU. In particular, it cannot link the transaction to the user’s public key pkU. The unique? flag allows restriction of pseudonym creation to one pseudonym per organisation. Each user can only register one unique peseudonym with each organisation. Unique pseudonyms and normal pseudonyms can coexist in parallel.

IssueCredU(pseusk, pkO, issuespec, userattrs) « IssueCredO(skO, pseupk, issuespec, orgattrs). Using this protocol a user can obtain a credential that fulfills a certain specification from an organisation.

The credential will contain the user chosen attributes userattrs, as well as the organisation chosen attributes orgattrs. The first are only known to the user. In addition to the attributes, the specification may describe features of the credential, e.g., that it should be limited to a certain number of shows, or should allow for certain types of revocation or tracing. Some of the features may require additional hidden attributes to be added to the credential. These attributes may be chosen jointly at random with both the user and the issuing organisation contributing randomness. The user’s output of the protocol is a private credential cred that consists of the attributes, a reference to the issue specification and a special type of signature known as a CL-signature. Note that big parts of cred are only known to the user, and that the credential contains the pseudonym and the user secret it was issued to, either by reference or by value.

ShowCredU(pseuskV, pkOI, showspec, cred) « ShowCredO(pseupkV, pkOI, showspec) This protocol allows a user with pseudonym pseuskV to show a credential fulfilling a show specification to a verifying organisation. pseuskV is the pseudonym at the verifying organisation and does not necessarily correspond to the pseudonym the credential was issued to. The show specification needs to be compatible with the issue specification. It contains a description of which attributes have to be revealed, but can also describe functions over multiple attributes or boolean expressions of different options that are to be shown. So, one can prove that one is of a certain minimum age and that the credential is not yet expired. The show specification also describes the credential features that are required. The result of the credential show is an assertion containing statements about the user and a proof that guarantees that the user is in possession of a credential such that these statements hold true.

The assertion can also contain statements about committed or encrypted data, e.g., that a certain binary object contained in the assertion is the encryption of the user’s name, or a commitment to certain values of the user. 

Discussion

Users are not forced to always use the same secret key, however they can only show credentials together, if all of the pseudonyms they were issued to were derived from the same user secret. In order to avoid users with multiple master secrets one can establish a root organisation that only issues a root credential to unique pseudonyms after verifying the real identity of the user. Organisations that want to avoid single users with multiple secret keys (so called Sybils), can require the show of a root credential before doing anything else. Now the only entity that can introduce Sybils is the root organisation itself. 

The show credential protocol given above always shows credentials with respect to a pseudonym. This is not strictly required. The protocol can use a pseudonym created on the fly, or the ShowCred protocol could be simplified to require no pseudonym as input at all. While the model of most existing credential systems is slightly more restricted, it can easily be seen that it can be relaxed to allow for the full lattice of pseudonyms described above:

1. The user’s public key can act as a person pseudonym.

2. A user could derive role pseudonyms from his secret key and use it with different organisations whenever he wants to act in a certain role.

3. Unique pseudonyms are organisation wide relationship pseudonyms.

4. Normal pseudonyms used only in a specific role are role-relationship pseudonyms.

5. By creating a new pseudonym for a new transaction the user establishes a transaction pseudonym.

A restriction of the current interface is that the assertion obtained by ShowCred only contains statements about one credential. This makes it impossible to express statements such as “the user has either a passport or a driver’s license and we have an encryption of her name”. Using general zero-knowledge techniques this is however possible. As a way to express this using the given API we propose to use meta-assertions. The user does a show of both a passport credential and a driver’s license credential using a special show description that forces the user to either show the real credential and encode 1 in an additional commitment, or to show a fake credential that he made up by himself and encode 0 in the commitment. This results in two different assertions. The CombineAssertions protocol takes several assertions as input and allows the user to prove statements according to a meta show specification about it. In the example above the user would prove that the sum of the additional commitments is bigger than 1 or different from 0.

Security properties

As discussed, not only the content of transactions should be protected, but also the communication relations, i.e., who communicated with whom. Clearly anonymous credentials do not protect the identity of their owners, if this information is already given away through other channels, e.g., through the user’s IP address, or through a picture recorded by a camera. Anonymity may not even be desired in all cases where anonymous credentials are used. For instance, the parties may know beforehand to whom they are talking, but may want to conceal this information from a third party. This is, for instance, often the case with anonymous e-cash, as it is with real money. The parties may also want to perform a transaction, but want to avoid the case that later on anyone can prove that the transaction took place. While credentials are not the only tool for achieving this, traditional certificates have none of these properties. Consequently, as anonymity is often not even in the picture, the term anonymous credential is often misleading. Different terminology such as private credential, private certificate, minimal disclosure proof, minimal disclosure token, and so on were used in the literature. 

In particular we require such a primitive (whatever its appropriate name) to have the following privacy properties: 

1. Issue unlinkability: The issuer should not be able to link the issuing of a credential to its use. 

2. Show unlinkability: The uses of a credential should not be linkable among each other, nor should multiple credential shows under different pseudonyms allow linking of the pseudonyms to their owner. Often the two unlinkability properties are subsumed under one property. 

3. Minimal data disclosure: Credentials should not reveal more information about their attributes than specified in the show specification. Some credentials may only transfer a single bit, e.g., club membership. Most of the time however credentials vouch for different attributes of the user, of which only some algorithmically derived values are revealed in the assertion. Depending on the functionality of the system this derivation may be arbitrarily complex. Minimal data disclosure requires that no information besides that is revealed in a show. 

Idemix

Idemix (Kohlweiss 2002) is a practical implementation of an anonymous digital credentials infrastructure which can help to achieve this goal. 

The idemix software is currently divided into different layers. The mathematical abstraction layer can be seen as its own layer, but primarily there is the protocol layer, and the credential system protocol layer. These layers are also represented by their own packages: protocols and credsystem. 

The credsystem package provides a high-level view on anonymous credentials with pseudonyms. Users can obtain private certificates, i.e., credentials, and can create proofs about them. The proofs are all with respect to one pseudonym, but can cover multiple certificates. A proof corresponds to an assertion that is expressed in XML but can also involve binary objects such as commitments and encryptions. 

The protocols package should provide the cryptographic protocols for achieving this high level goal. At the moment it contains protocols for obtaining and showing individual credentials, and some zero-knowledge proof techniques for proving properties about commitments. Due to the lack of documentation it is currently preferable to use the protocols package alone, especially if one does not require a full-fledged credential system. 

XML standards

With the rise of web services, XML has become the de facto standard to represent messages, exchanged between the components of those services. An XML syntax to transmit the result of security primitives and protocols based upon those primitives followed in a natural way, with the main advantage that they could offer end-to-end security instead of point-to-point security. In this section we describe those XML languages and the protocols that emerged from them.

XML Digital Signatures

XML Signatures (Eastlake, Reagle, Solo 2002) are more closely related to standards like PKCS#7 (RSA 1993), that define messaging syntax, than to raw cryptographic signature algorithms. The XML Signature standard defines how to relate source documents to their cryptographic signature by using XML. Additionally the XML Signature document can encompass cryptographic keys and certificates, e.g., X.509 certificates. 

XML Encryption

XML Encryption (Eastlake, Reagle 2002) describes a standardised syntax for including encrypted data in XML documents. The encrypted data can be an XML element, the content of an XML element, or a whole document of a specified MIME type. XML Encryption is to confidentiality what XML Signatures are to authentication and non-repudiation, a standardised way of writing things down that in no way restricts the user of the standard in his choice of encryption algorithm or key material used. 

WS-Security

The WS-Security standard (Nadalin et al. 2004) describes a set of SOAP extensions used to provide message integrity, message origin authentication and message confidentiality. WS-Security operates at the application level and thus is used to provide end-to-end message security and not just transport-level security (e.g., SSL/TLS). WS-Security gives the application the possibility to make the security decisions with a higher granularity, for instance allowing access to a certain web service method for an entity while denying access to other web service methods from the same entity. For instance a company might decide to offer certain functionality to the public while some sensitive functionality is only offered to partner companies.

WS-Security consists of a set of standards that specify how to protect the authenticity and confidentiality of SOAP messages. Message integrity and origin authentication of the SOAP message is realised by using XML digital signatures to ensure that messages originated from the appropriate sender and have not been modified whilst in transit. The confidentiality of the SOAP message is accomplished using XML Encryption to ensure that the sensitive parts of the message are not visible to eavesdroppers. The low level details for digital signature and encryption are handled by the XML Digital Signature and XML Encryption standards respectively. The WS-Security standard defines a higher-level syntax to place security information into SOAP messages. The security relevant information is placed in the SOAP message header. 

WS-Trust, WS-MetadataExchange, WS-SecurityPolicy

While the XML standards, mentioned above, are basic components in web services and XML documents, WS-Trust (Nadalin et al. 2007a), WS-MetadataExchange (Ballinger et al. 2006) and WS-SecurityPolicy (Nadalin et al. 2007b) are mainly used in the Identity Metasystem as proposed by Microsoft together with others. For completeness, we introduce them here - the descriptions were taken from the standards’ documentation.

1. WS-MetadataExchange: Web services use metadata to describe what other endpoints need to know to interact with them. Specifically, WS-Policy describes the capabilities, requirements, and general characteristics of web services; WSDL (Web Services Description Language) describes abstract message operations, concrete network protocols, and endpoint addresses used by web services, and XML Schema describes the structure and contents of XML-based messages received and sent by web services. To bootstrap communication with a web service, the WS-MetadataExchange specification defines three request/response message pairs to retrieve these three types of metadata: one retrieves the WS-Policy associated with the receiving endpoint or with a given target namespace, another retrieves either the WSDL associated with the receiving endpoint or with a given target namespace, and a third retrieves the XML Schema with a given target namespace. Together these messages allow efficient, incremental retrieval of a web service’s metadata.

2. WS-Trust: WS-Security defines the basic mechanisms for providing secure messaging. WS-Trust uses these base mechanisms and defines additional primitives and extensions for security token exchange to enable the issuance and dissemination of claims about a subject, as bound to X.509 certificates, Kerberos tickets, or even password hashes within different trust domains. In order to secure a communication between two parties, the two parties must exchange such security tokens (either directly or indirectly). However, each party needs to determine if they can “trust” the asserted claims of the other party. In WS-Trust, extensions to WS-Security are defined that provide methods for issuing, renewing, and validating security tokens and ways to establish and assess the presence of, and broker trust relationships.

3. WS-SecurityPolicy: WS-Policy defines a framework for allowing web services to express their constraints and requirements. Such constraints and requirements are expressed as policy assertions. WS-SecurityPolicy defines a set of security policy assertions for use with the WS-Policy framework with respect to security features provided in WS-Security, WS-Trust and WS-SecureConversation. WS-SecurityPolicy takes the approach of defining a base set of assertions that describe how messages are to be secured. Flexibility with respect to token types, cryptographic algorithms and mechanisms used, including using transport level security is part of the design and allows for evolution over time. The intent is to provide enough information for compatibility and interoperability to be determined by web service participants along with all information necessary to actually enable a participant to engage in a secure exchange of messages.

Identity federation standards

There are currently two XML standards for identity federation which are supported by different organisations: 

1. The Liberty Alliance is a consortium of around 150 companies supporting mainly an XML dialect called SAML (Security Assertion Markup Language). 

2. Microsoft, IBM and VeriSign are supporting WS-Federation. WS-Federation is part of a more general specification of web services and partially overlaps with the approach of the Liberty Alliance due to the fact that various companies using the WS approach are also member of the Liberty Alliance. 

It is still an open question which of the two approaches will finally get accepted by the community or if an integrated solution will be developed. Until then, organisations which are planning to establish an identity federation should agree on one of the two standards to decrease system complexity and avoid an additional source of error.

SAML

SAML was developed by the Security Services Technical Committee of OASIS. It is an XML-based framework for communicating user authentication, entitlement, and attribute information. This is done by making assertions regarding the identity, attributes, and entitlements of a subject (e.g., a human) to other entities, such as a partner company or another enterprise application. SAML can be extended by other standards, and this has happened through the Liberty Alliance Project and the Internet2 Shibboleth project. 

Two main flavours are currently in use: SAML v1.1 was established in September 2003 and is the current basis for the Shibboleth project. From within the Shibboleth project, suggestions and improvements were taken up, together with comments from the Liberty Alliance’s Identity Federation Framework, to form the improved SAML v2.0. At the time of writing, this version is supported by the Liberty Alliance project. 

SAML can be used in three major ways: 

1. Web single sign-on (SSO): In web SSO, the user logs on to one web site and can access other web sites later on with the identity provided previously, without re-authenticating. This assumes an underlying trust relationship between the web sites’ providers.

Figure : Web single sign-on

1. Attribute-based authorisation: Similar to web SSO, but authentication to third party web sites happens by passing statements about the user, not necessarily his exact identity.

2. Securing web services: When used in combination with SOAP, SAML can be used to transfer information about interacting users in web service transactions. This is specified in the OASIS WSS TC and used in Liberty Alliance’s Identity Web Service Framework (ID-WSF).

The term federation is used when Web SSO is applied with different identifiers or user accounts. Federation refers to the establishment of a business agreement, cryptographic trust, and user identifiers or attributes across security and policy domains to enable more seamless cross-domain business interactions. 

SAML is a platform-independent tool to achieve this. 

SAML components 

SAML is specified in terms of assertions, profiles, bindings and protocols: 

Figure : SAML components

1. Assertions are the XML snippets in which SAML statements are contained. There exist three types:

1. 1. Authentication assertions hold claims that a certain subject was authenticated using a given method at a given time. 

   2. Attribute assertions bind certain attributes to a given subject 

   3. Authorisation Decision assertions contain a request to grant or deny a certain subject access to a certain resource. 

1. Protocols: The SAML standard describes some request/response protocols to allow the exchange of SAML assertions. Service providers can request registration, mapping or termination of name identifiers, request assertions from SAML authorities and authentication assertions from identity providers, request simultaneous logout for a collection of related session, etc.

2. Profiles of SAML specify constraints and/or extensions to make SAML work in a specific context. One of the first profiles for SAML was the Web SSO profile, which describes how SAML statements are communicated between the identity provider and the service provider to enable single sign-on for a browser user.

1. Bindings map SAML protocols to standard communication protocols. Common bindings are the ones to SOAP and HTTP (using redirection).

More details on SAML v2.0 can be found in the core standard document (Cantor et al. 2005) and the Technical Overview of SAML (Ragouzis et al. 2006).

WS-Federation

WS-Federation was developed by IBM and Microsoft with the help of RSA-Security, BEA Systems, and Verisign. It is a specification but not a standard and forms part of the WS-* line of specifications. As such it is based on other WS-security specifications, in particular WS-Security and WS-Trust. It extends WS-Trust by introducing identity providers as special Security Token Services (STS). By involving identity providers WS-Federation allows different security realms to federate by allowing and brokering trust of identities, attributes and authentication between participating web services. 

The use cases of WS-Federation are very similar to those of SAML. The more stringent focus and restriction to WS can be seen as the main dividing line. 

1. Securing web services: This is the main use case of WS-Federation.

2. Single sign-on: WS-Federation allows single sign-on for distributed web service architectures.

3. Attributes and pseudonyms: Attribute-based authorisation is similar to SSO, but authentication to third party web services is done based on information about a user’s pseudonym or attributes. WS-Federation defines attribute and pseudonym services to provide this functionality. Attribute services should provide service providers with additional information about a subject (constrained by the subjects access control and privacy policies), while pseudonym services allow binding of persistent local pseudonyms to otherwise anonymous subjects.

While otherwise kept very generic, the specification of the WS-Federation defines two different profiles for clients: 

Passive clients: A passive client does not know that he is used in a federation. This could for instance be a web browser which secures its connections with SSL (Secure Socket Layer).

Active clients: An active client knows about the federation system and thus can take advantage of the federation protocols to achieve an increased flexibility, security and productivity.

More details on WS-Federation can be found in the core specification (Nadalin, Kaler 2006) and a technical overview of WS-Federation (IBM, Microsoft 2003). 

SAML, WS-Federation, and pseudonyms

Both SAML and WS-Federation support identity provider managed pseudonyms. In this way service providers may know users only under different pseudonyms. While this makes it harder for colluding service providers to collect information about a user, it gives more power to the identity provider. This was discussed in the increasingly active identity management blogosphere, e.g., in (Brands 2005). For instance an identity provider may “steal” some of a user’s pseudonyms and link them to a different user. 

Credentials and federated identity management

Until recently the necessary cryptographic mechanisms had not been fully implemented. The recent creation of an Idemix open source initiative as well as other attempts to make anonymous credential systems real for the first time created the possibility for developers to use credentials in real system. However, there are still many steps to take from the vision of privacy-enhancing identity management (as conceived by Chaum) to its realisation. The PRIME project looked at all of these steps in more detail. The main contribution of this ambitious European research project is to gain an understanding of the dependencies between the different components in such a system. These dependencies are reflected by an identity management architecture, and by an integrated prototype (Andersson et al. 2005, Leenes, Schallaböck, Hansen 2007).

PRIME

In short, having anonymous certified data is not enough. These data also need to be used. An important missing component that needs to be added to anonymous credentials is thus attribute based access control. Such a system takes the certified attributes provided by a credential system and uses them to make access control decisions. In order to achieve accountability, such systems may also require an encrypted version of the requestor’s identity that can only be decrypted by a special trusted authority, or a quorum of parties. This allows for conditional anonymity. The complex rules that govern who can access what after having given away which information are defined in policies. Policies can also stay attached to data after it has already been released. 

User interface component

As there is a natural degradation from full anonymity to full accountability which depends on the gradual release of more and more attributes, checks and bounds need to be provided to users to allow them to control the release of their personal data. This is called negotiation. Depending on the user’s relationship with an organisation she will be willing to release more or less data. This raises many user interface question, as the amount of extra complexity users will tolerate to manage their identities is limited. In fact applications should not get more complicated, but should be redesigned to provide the same usability with added privacy. 

Federated identity management

Another line of research looks at interoperability issues between conventional identity management infrastructures and anonymous credentials. The en vogue identity management paradigm that is currently hyped by the industry is federated identity management. It uses only conventional cryptographic techniques, has clear basic principles, and an already large product and standards portfolio. Still, the interoperability issues between different vendors and different domains define it as a moving target. This makes the integration of anonymous credentials and federated identity management a challenge from an engineering if not from a research perspective. 

In federated identity management, we have an online request for identity information by the service provider (sometimes also called dependent party) the request is redirected through the user’s client, most often this is a web browser, and the identity provider answers with an assertion signed using conventional signatures. 

Most of the work for reconciling federated identity management with anonymous credentials hooks in at this conventional signature on the data provided about the user by the identity provider. Obviously the identity provider can recognise his own signature. This allows insiders to link transactions. More seriously, most of today’s identity federation protocols require the user to explicitly tell the identity provider which services they want to access. 

In order to achieve unlinkability the user obtains anonymous credentials from his identity providers. These credentials allow the user to do authorised transactions without communicating online with the identity provider. While we want to change the flow of communication, we do not want to change the standardised message formats defined by federation standards such as WS-Federation of the Liberty Alliance protocols (Liberty Alliance 2007). Thus, in order to achieve full unlinkability, the user himself has to create a fresh new signature every time he proves a statement about himself in an assertion to a service provider. On the other hand the signature must be restricted to certified statements that are consistent with the user’s credentials. In short, what (Camenisch, Gross, et. al) and (Camenisch, Kohlweiss, et. al) say about this topic is that:  

1.  the XMLDSIG standard which is used for this purpose needs to be extended

2.  the assertions proved by a credential need to be expressed using XML syntax, and  

3.  the assertions made by the credential need to be translated to the assertions expressed by identity providers.

(A) can be achieved in two ways: Firstly, by using the signature proof of knowledge corresponding to a credential show directly as a signature in XMLDSIG. Instead of using XMLDSIG with DSS or RSA one would use non-interactive proofs of knowledge. Secondly, by using the credential to create and thus in some sense certify a fresh signing key, which will be used in the XMLDSIG, while the signature proof of knowledge of the credential acts as a certificate for the freshly created signing key. In WS-Security terminology such a generalised certificate is referred to as a security token (Dournaee 2002).