Technically it is feasible to provide privacy friendly identity management, for example by using attribute based credentials (ABCs). We are currently demonstrating their applicability in practice, even on smart cards, in the IRMA (I Reveal My Attributes) project. However, the use of ABCs in the real world is still very limited. One of the factors is the lack of a business case that supports the (substantial) cost of establishing an identity management infrastructure. In this (rather long) post I will sketch the issues, and indicate certain ways in which I think money can be made in an identity management infrastructure. The analysis is sketchy, primarily because I am not an economist. I would love a discussion on this topic, to advance the ideas in this post further.
Identity management systems
When we consider identity management systems from a broad perspective (and not just limited to providing authentication and single sign on), such systems allow a user to reliably prove certain characteristics (called attributes) about themselves to others. Typically, these attributes are used by businesses to make a business decision during a transaction between the user and the business. A common example is verifying the age of a customer before selling alcohol or cigarettes. But more complex examples are certain possible, like verifying whether a user is a legitimate representative of a company with a certain creditworthiness, or verifying that the user is a doctor that is allowed to prescribe this medicine at the requested dose or quantity. In the realm of identity management, the business relying on these attributes to make a business decision is called a relying party. In very generic terms, a relying party protects access to a resource and provides access to this resource depending on the credentials a user can show.
A simple approach to identity management is to create an identity provider that has accounts for all users, and that stores all attributes for these users in those accounts. To learn the attributes of a user, the relying party asks the user to sign in to the identity provider, after which the relying party will ask the identity provider about the user attributes directly. This works and has been implemented. It is also quite straightforward to make money in this model, as the identity provider is involved in all transactions on-line. It is the spider in the web. It can ask a small fee for each attribute requested by the relying party. The relying party is typically willing to pay for this, as the attribute allows him to automate his business processes and makes them more secure. However, this architecture for identity management is a privacy nightmare.
Privacy friendly architectures for identity management do exist, for example using attribute based credentials. In these systems, credentials are secure containers that store the user attributes. Users obtain such credentials from a credential issuer, that can vouch for the validity (for this user) of the attributes contained in the credential. The credential (being a secure container of the attributes) allows the user to prove possession of the attribute to the relying party. Privacy is guaranteed by making the proof involving a credential unlinkable to other proofs involving the same credential, or to the issuing of the credential. Note that the attribute provider is not involved in the proof of possession of a credential. Moreover, using the technique of selective disclosure, the user can choose to reveal only a selection of the attributes contained in a credential.
When using attribute based credentials, the user is the spider in his own little web. The question then is how to make money as the provider of (a service within) such an identity management infrastructure.
Before answering this question it is important to realise that typically three more parties play a role in an identity management systems. First and foremost, there is the scheme authority that lays down the architecture of the system, and governs its operation. It is responsible for ensuring the system is useful, economically viable, secure and respects privacy. The scheme authority, for instance, decides which attribute providers and relying parties are allowed to use the system (and revokes their access if they fail to comply with the rules). Typically, relying parties need to authenticate and provide the appropriate certificates to the user in order to read out certain attributes. This relying party authentication (traditionally called terminal authentication) prevents relying parties from sneakily collecting all attributes of a user.
Moreover, there are so called token issuers (for lack of a better name) that provide the security tokens (typically smart cards) that users use to securely obtain, store, and use credentials.
Looking at this from a slightly higher level of abstraction, we can distinguish the following classes of roles.
- Providers (Credential Issuers, Token Issuers) that offer identity management functionality.
- Users (User, Relying Parties) that benefit from the functionality offered by the providers in the identity management scheme.
- Governors (Scheme Authority) that govern the identity management scheme and are responsible to maintain the trust and value of the scheme.
Additionally, there may be one or more service providers that offer services that make it easy for attribute providers or relying parties to connect to the system by offering tailor made services. For example, a service provider may offer a relying party to do the validation of credentials in its place, and only return whether the credentials verified correctly. (This does incur a privacy risk if a service provider serves many different relying parties, and the attributed revealed are identifying. In this case, the service provider learns the visiting patterns of users over a large set of relying parties.)
Initial analysis of business issues
The primary value of the identity management system is determined by the (perceived) trust in the system by all parties involved. It is the main responsibility of the scheme authority to ensure this (by proper rules and enforcement of these rules). As a consequence, the level of security provided by the token providers and attribute providers must be high, which comes at a cost. (Relying parties primarily cause damage to themselves if they fail to reliably verify credentials, although repeated incidents will have an impact on the overall reputation of the scheme.) This cost must be earned back to justify the investment.
Users and relying parties are the main parties that benefit from an identity management system. Relying parties now have a secure way to verify attributes of their customers. This may solve legal compliance issues (the need to verify age for certain types of business, for example), lead to new business opportunities, and streamline existing business by reducing risks due to uncertainty. As a consequence, relying parties may use the expected benefits to be obtained for their normal business as a factor to justify the investment in an identity management system. Similarly, users have a privacy friendly and secure way to present attributes. This increases the online user experience. Moreover, attributes may be used to protect access to user assets stored at relying parties, making them more secure. However, it may be hard to convince users to actually pay for tokens or getting credentials. They may perceive this as an artificial barrier, an extra cost incurred for accessing a service that they previously did not have to pay. On the other hand, citizens are used to paying a significant amount for passports and physical identity cards. 
The other system entities, and especially credential issuers, have no external business needs to join an identity management system (it does not enable them to do the business they are already engaged in, except if they are a relying party as well). They may of course see a business opportunity within the identity management system itself, but this is a different driver. In particular, benefits obtained outside the identity management system are not foreseen and therefore cannot be used to justify an investment.
Because relying parties allow access to an asset depending on the credential a user can show, credential issuers hold, in fact, the keys to these assets. This makes them as responsible for protecting these assets (through proper issuing of credentials) as the relying parties. This raises the issue of liability if something goes wrong. If access to an asset is given because of an improperly issues credential, the relying party is not at fault. But if we want to make the issuer liable, then the risk they run when their credentials are used to protect very valuable assets becomes high. As a result, the cost of issuing credentials becomes high as well, potentially raising the cost of a credential beyond reasonable proportions. The extent of this effect needs further investigation.
Identity management systems (like credit card systems) are a two-sided market (or network) with cross-side effects. Such markets have two types of parties that provide network advantages to each other: the value of an identity management system for the users increases with the number of relying parties, whereas the value for the relying parties increases with the number of users. The number of users increases with the number of tokens and attributes providers they can use to connect to the system. Such markets run the risk of the two sides waiting for each other to grow. To maximise the growth of such a two sided market (with cross side effects) the system must be open. It is especially important that a free and open market of service providers is established that make it easy to set up and connect attribute providers (to increase the user side) and relying parties.
Possible solutions
Below I briefly sketch two (of the possibly many) ways to make a business out of privacy friendly identity management.
Providing identity management services
In the German eID system, so called eID services exist that handle the verification of card attributes on behalf of the relying parties. Users visiting the relying party are redirected to the eID service, that subsequently runs the identity management protocols to determine the user attributes. After a successful run, the eID service returns the user attributes to the relying party using a very simple protocol. This makes it very easy for relying parties to incorporate the German eID card in their current web environment. The eID service can charge a fee for each credential verified.
The German approach is a very good way to kick-start the uptake of eID by relying parties. But it incurs a privacy risk, as the eID service sees all attributes it verifies, and sees for which relying parties these attributes are used. This allows the eID service to link users to relying parties. This can be mitigated by requiring that the eID service is stateless and does not keep any logs of the interactions it is involved in. This should be fiercely monitored by the scheme authority. Also, the scheme authority should stimulate that many different eID services exist.
Another approach is to in-source the verification of credentials to the relying party. This essentially boils down to moving the server that runs the eID service within the relying party premises. This ensures that different relying parties run a different instance of the eID services, greatly reducing the privacy risk. In terms of business opportunities, the eID server can be sold as a plug-and-play device that requires little maintenance. Additional maintenance contracts (guaranteeing updates when new versions of the identity management system are released, or offering the addition of new eID standards when they appear) can also be sold. Alternatively, a licensing scheme can be agreed on, where the fee depends on the number of credentials verified with the locally installed system.
Using the smart card as a purse
The main problem of a user-centric identity management system, like those that are based on attribute based credentials, is that there is no direct link between the credential issuer (that provides value) and the relying party (that consumes this value). This makes it hard to force the relying party to pay for the use of a credential. However, this can be mitigated by letting the user be the go-between. An electronic purse on the same smart card that is used to store and show the credentials can be used to receive a payment whenever a credential is shown at a relying party, and pay with that money the next time a credential is requested from an issuer.