Here I describe my understanding of how a federated identity management system will work. These are systems that are currently being developed by a range of organisations in order to rationalise the hundreds of different passwords, cards, and miscellaneous bits of ID that are plaguing people nowadays - especially online.
As more and more systems come online which require some form of authentication, people have less and less time to spare to take care of their identity. People write their passwords on a piece of paper, or make all their passwords the same. As a result, identity theft is exploding.
The federated identity management system is supposed to make it much easier for ordinary people to maintain good security practices, and protect their own privacy, while simultaneously supporting an explosive growth in the number of systems requiring authentication, and dramatically improving the security of existing systems.
Update 2007-03-17:
A few weeks ago, it emerged that Microsoft will be supporting OpenID. OpenID has been floating around for some time, and I'd always written it off as being on the extreme open-source fundamentalist end of the spectrum. My money was on The Liberty Alliance, or something from OASIS eventually emerging as the de facto standard. But with Microsoft behind it, OpenID should come out on top. And this is a very good thing, because OpenID appear to have the interests of users at heart, not the interests of the Internet industry.
From what I can see of OpenID, it will work pretty much as described here. The main difference is that they have a much more flexible approach to what constitutes an "identity", and they don't seem to be as advanced along the path of chaining identity servers together. But things seem to be moving along very well indeed.
In the newer approach to online authentication, individual websites will no longer be responsible for dealing with passwords, PINs, and other authentication methods. Instead, they'll "outsource" this to specialised websites called "Identity Providers".
Let's say I want to buy something from Amazon.com, and I've never used Amazon before. Amazon will want me to set up an account. However, instead of giving me the usual "Please enter your name, address, email, ..." screen, it'll just present me with links to various identity provider companies that I can use. I'll look down the list looking for an identity provider with whom I have an account. In this case, I see "Veritanium Account Management", a company with whom I registered earlier.
When I click "Veritanium Account Management", Amazon will redirect me to Veritanium's website. Along with the redirect is a little packet of information from Amazon telling Veritanium:
When I get to Veritanium, it'll first ask me to log in. It'll then show me the request from Amazon in a user-friendly format, and allow me to grant permission for the information to be sent to Amazon. Some fields will be stuff that Veritanium already knows about me. Some fields, such as address, might have numerous options, and I have to select which one. Some fields will be optional, and I can choose whether or not to send them to Amazon.
When I click "approve", Veritanium sends Amazon a packet of information giving the appropriate personal information, along with a "pseudonym". A pseudonym is a random number that acts as an identifier for me between two systems. Whenever Amazon and Veritanium talk to each other about me, they'll refer to me by my pseudonym, not my name, account number, or anything else. I'll have a completely different pseudonym for communication between Veritanium and eBay, and between Veritanium and HSBC, and so on. If I have multiple accounts with Amazon, each will have a different pseudonym, and Amazon need never know that they are the same person. This protects my privacy, and prevents multiple different websites "colluding" by swapping information about me behind my back.
Two weeks later I go back to Amazon and click on "log in". Amazon will probably have set a cookie so it knows who I am (or who I claim to be). It'll therefore redirect me straight to Veritanium's login page. Once I've logged in, Veritanium will send a message to Amazon saying that I just logged in, and my browser will be sent back to Amazon.
Side note: I've just been looking through the Liberty Alliance documentation, and the step above where Amazon presents a list of identity providers would work a little differently. The Liberty Alliance tries to make things easier for the user by having the names of the identity providers I have accounts with stored in a special cookie. Amazon can read that cookie and redirect me automatically to Veritanium. I don't like that system, because it provides too much information to phishing websites, which they can use to tailor phishing emails to me. For example, an IBM employee would have an IBM employee identity provider. Knowing that, you can guess that he probably has an account with IBM's health insurer, IBM's stock option manager, and so on, as well as being able to make a fair stab at guessing his business address. I think this is a flaw in the Liberty Alliance spec, but not a serious one. It should be possible to opt out of this "service discovery" system, in which case their system reverts to looking exactly like I describe above.
Another side note: The example used in the Liberty Alliance documentation describes two e-commerce sites (an airline and a car rental company) chaining together directly, whereas what I described above is a specialist identity company chained to an e-commerce site. As these systems start to be introduced, I can imagine that companies like Amazon and Expedia might take the lead, but I'd expect that in the long run, people would want to trust their identity to specialist companies, or more trustworthy institutions like banks.
What happens if I get to Amazon, and I don't have accounts with any of the identity providers listed? Well, obviously I'd choose one and set up a brand new account with them. But the system can work more cleverly than that, because it should be possible to chain identity providers together. Let's say I don't have an account with Veritanium, but I do have an account with Identishure. When I get to Veritanium's website, I don't have to click "Setup new account". Instead, I can click "Retrieve identity from other identity provider". When I do so, I get a list of identity providers that Veritanium trusts. Veritanium is now in the role that Amazon was in before. Veritanium wants to know my name, address, email, bank account and so on. Like Amazon, it redirects me to Identishure's website, along with a packet of information about what information it wants. Once I've given my password to Identishure and approved the transation, Identishure sends the data off to Veritanium and redirects me to Veritanium's website. However, as soon as that happens, Veritanium immediately sends the information on to Amazon and redirects me again to Amazon's website.
From now on, Veritanium acts merely as a proxy between Amazon and Identishure. Identishure has no idea I've got an account with Amazon, and Amazon has no idea the information it's getting actually comes from Identishure. When Amazon wants me to authenticate myself with a password, it's Identishure who actually handles it. Veritanium can then truthfully tell Amazon that I authenticated myself with a password, even though Veritanium never actually saw it. If I change my address on Identishure, that information automatically gets passed on to Veritanium, who then passes it on further to Amazon.
In this way, websites like Amazon don't need to support every single identity provider under the sun. A smaller website could get away with only supporting one. Just as long as that identity provider provides a few options for chained identity providers, and as long as those identity providers provide further chaining options, it will potentially be possible for any individual user to link together all the websites they use however they want, into one big single-signon system.
Each identity provider in this network acts as a valve controlling the flow of my personal information around the internet. At each one I can choose which of the websites it controls will get access to what information. I can at any time decide that Amazon should no longer have access to my up-to-date address, and turn off that valve. To go further, it should be possible to send messages like "please delete my address from your system" to any account. There should be supporting codes of practice, and preferably legislation, to ensure that websites comply with these requests.
Furthermore, each identity provider acts as an audit tool. They maintain lists not only of all the people who currently have my details, but also historical records of everyone I've ever given details to. If I get unexpected junk mail in my letter box, it should be possible to figure out how my address "leaked", and get it removed from whichever mailing list it ended up on.
One common requirement for online systems is that an email address is provided, so they can communicate with the user. However, as we're finding, giving out your email address to dozens of websites of dubious provenance is a guarantee of tons of spam in your inbox. It's now clear that email addresses need to be protected almost as carefully as credit-card numbers.
The identity providers could quite easily solve this problem by acting as anonymising relays. When Amazon wants to send me an email, it wouldn't send it to my email address. Instead, it'd send it to my identity provider, using my pseudonym as the address. The identity provider would then send it on, with the headers munged so that when I reply it will also be relayed through the identity provider. With this method I will be able to selectively grant or revoke the permission of websites to send me email.
This feature isn't currently specified in the Liberty Alliance documentation, but it could easily be implemented as an extension, without requiring special handling by service providers like Amazon. The identity provider (let's say Veritanium) simply tells Amazon that my email address is 00406666@veritanium.com. Email from Amazon then gets automatically rerouted to my real address.
Another useful requirement for many websites is the ability to ensure that each human being has only one account. For example, a web poll would be much more useful if it could prevent people registering multiple times and voting with each account. Or a web forum might want to ban disruptive users, without the possibility of them simply re-registering under a different name. Current solutions to this problem involve users giving away far more identity than is really required, for example by giving credit card numbers or social security numbers. Since these identifiers are so valuable to thieves, they need to be protected by high quality security systems. Such highly secure systems are often out of reach for small independent websites.
The federated identity system can guarantee uniqueness, provided that the website is prepared to lock itself to one particular identity provider. That identity provider would have to in turn require users to submit enough identity information to guarantee their uniqueness; probably name, address, and date of birth.
There are many dangers with this approach. One of the chief benefits of the federated identity management system is that it gives users the freedom to switch identity providers whenever they want. This leads to a fluid market, encouraging innovation and good customer service. But as soon as a service provider locks itself to one identity provider, users no longer have this option. Instead, users who are unhappy with that identity provider's service or policies have to lobby the service provider to switch to someone else. This is likely to be difficult, and even if it works, the switch will be disruptive.
Worse still, users might find themselves having to register with every identity provider. "Uniqueness guaranteeing" is likely to be a very specialist industry, with only a few players. If a user registers with, say, 30 websites, they are likely to find themselves forced to register with every one of those specialists, because each one will be required in order to use at least one of those 30 websites. So there will effectively be no competition for users at all. Meanwhile, every one of these providers will have name, address, and date of birth information for almost every internet user. So a uniqueness provider will be a tempting target for hackers, but have no real incentive to protect its users.
All that can be done here is harm minimisation. First of all, uniqueness providers can be chained together just like other identity providers. So identity provider Identishure knows my address and date of birth, and thus that I'm unique. Identity provider OpenIdent chains to Identishure, and the only thing it knows about me is that I'm a unique person on Identishure. I can use OpenIdent every day, and it can have relatively lax security, without there being any danger of my address or date of birth being exposed. Identishure might still have a monopoly, in the sense that they have practically every user in the world registered with them, but very few websites would use them directly, which makes things somewhat safer.
Alternatives to uniqueness requirements should be used wherever possible. For example, a user forum may have such a big problem with spammers and trolls that it needs to require people to be unique, so they can be banned when they cause trouble. But an alternative approach would be to require users to earn karma points, by having fellow posters rate their posts. Users with low karma would have their posts passed through moderators until they've accumulated enough karma to have their posts go through automatically.
Another technique would be to provide a small number of choices. So you might allow people to post if they are unique either on Identishure or on OpenIdent. A spammer or a troll would thus have two chances, but no more than that. Meanwhile, Identishure and OpenIdent would still have to compete for users, giving them an incentive to do a good job.
The Labor government in the UK is currently trying to implement a universal identity scheme for all citizens and residents. This scheme violates many of the principles outlined at the start of this essay; because the identity register is centralised, it presents a tempting one-stop-shop for identity thieves, while the fact that it has to be accessed by every government department and tens of thousands of private companies makes it very vulnerable. It's interesting to analyse how the federated identity management system could obviate the need for this scheme.
As far as strong guarantees that the information provided by a citizen is actually correct goes, this is well covered by the role of the primary identity providers. People would already have a strong incentive to do this themselves, to guard their own daily lives.
The hard part is guaranteeing uniqueness. For example, you want to prevent someone registering with different providers under slightly different details, and using those identities to register for the dole twice.
To do this, a government identity register could be set up that depends on several approved primary identity providers run by private companies. In order to register with the government, I would need an account with at least one of these, and I would also be legally obliged to declare all accounts I have on the others. After downloading my personal details from my nominated identity provider, the government identity register would then have special permission to search for matching records on all the others. If the government finds any records that I haven't already provided, I would have a chance to explain them or add them to my application. If not, the government would discard the data it used to perform the lookup, and retain only my pseudonyms.
Using this method, the government is able to guarantee my uniqueness, without having to retain any personal details. Thus, they are no longer a target for hackers. I'm stuck with the government's identity provider, but I do at least have the freedom to choose my primary identity provider, and since that's where my personal details are stored, that's the important thing.
Note that the above system is purely used to establish uniqueness, not to supply data. It's used by organisations like the tax office to ensure that pseudonym 07733332 represents a person who has never been registered at the tax office under any other pseudonym. In order to find out information such as my name, address, and so on, they would use a normal identity provider, no different from Amazon.com or Expedia. Personal information flows into the uniqueness provider, but never out of it. This greatly limits the danger of it being hacked.
I've hinted at these factors before, but it's worth diving into the "who pays?" question further. If all my personal information is going to be held in one central server, I'm going to want that server to be damn well protected, with professional developers, long software development cycles, and thorough testing. I'll cheerfully back that up with my cash too. Different charging schemes can be imagined: either flat fee subscriptions, or per-transaction fees.
Furthermore, I'll feel far more comfortable about the security of these systems if there isn't very much traffic going through them. The more I use these systems, the easier it is for an attacker to hijack my requests, or slip an extra one in unnoticed.
Finally, when I access this central server, I want tip-top authentication schemes, including not just passwords, but smartcards, probably fingerprints, and in fact if I have to physically turn up at an office so they can verify that I look like my photo, so much the better.
The effect of these three paragraphs can be summarised as: I want it to be really really expensive to use my account.
However, for many applications this would be terrible. I don't want to have to go to Veritanium's central offices every time I want to post a comment on someone's blog, and I certainly don't want to have to pay a fee for the privilege.
I would envision that any number of open source, free to use identity providers would spring up on the net, but I'm not sure to what extent I would trust them. They certainly couldn't afford to provide the high level of security I described above.
The federated approach allows a wide range of different identity providers to coexist, competing for different markets. As a consumer, I'd use my high-security account for applications where it's necessary, medium-security accounts when I want to save money and it's not so important, and low-security accounts when I don't want to pay anything at all.
The various identity providers would form a tree. At the root of the tree are the primary identity providers, which are expensive, heavily protected, and infrequently used. In fact, these identities would never be used for end-user applications, but only to identify myself to other identity providers. It's possible to imagine these systems (which may not even be connected to the internet) eventually replacing things like passports and birth certificates as the primary repository of identity.
Information (such as names and addresses) then flows out of the primary identity providers to secondary identity providers. These are somewhat less well protected, and used somewhat more frequently. They might be protected by passwords, smartcards , or other things that I'm prepared to use day-to-day. They can also store much more information about myself, such as information about my education, friends, personal preferences and so on. These secondary identity providers probably wouldn't be free, but would be reasonably cheap to use.
A third level of tertiary identity providers would be the ones that actually are free. Very little personal information would be stored on, or available to, these. They might not be protected by their own password at all, but rather rely on password authentication from the secondary identity providers.
The final level is the actual service providers, like e-commerce sites, user forums and so on. Those that are sufficiently trustworthy would communicate directly with the secondary identity providers, while the others communicate with the tertiary identity providers.
One thing to note is that identity providers wouldn't just charge end users, but also service providers and each other. That is, Veritanium might charge Amazon a fee for accepting authentication redirects. This means that commercial pressure comes not just from the user side, but also from the service provider side. Many free user forums wouldn't be able to afford any commercial identity provider at all, and so the existence of at least some completely free identity providers is crucial.
For firewalling purposes, I would prefer that various subtrees are kept completely independent from each other. However, it isn't necessary that every identity provider is completely independent from each other. I might well have an account with a company that provides a very secure primary identity provider as well as including an account with a secondary identity provider. A service provider like Amazon.com might well provide its own identity server as a free bonus.
All in all, I think there's a huge commercial market here, which should be able to fund a great deal of technological innovation and new value-added services. But despite this large flow of funds, this would still be a great deal for both users and service providers, saving a great deal of development time while simultaneously giving far greater privacy protection than is currently possible. And there would still be plenty of scope for free, open source software to form a crucial part of the system, while co-existing perfectly harmoniously with all of the commercial activity. Unlike the OS wars, there's no reason for anyone to adopt an extremist open-source or capitalist philosophy here.
There's already a lot of work being done in this area, in particular OASIS's definition of the SAML format for exchanging authentication assertions, and the Liberty Alliance's work to standardise identity provider protocols and personal information schemas. Since these organisations are backed by just about every big high-tech firm, with even Microsoft phasing out its own passport technology in the face of the size of the standardisation push, it's fair to expect that these technologies will successfully be implemented and deployed.
Still, that doesn't really guarantee that these systems will live up to the potential I've been fantasising about above. I've never heard anyone marketing anything like this to consumers except Microsoft with their passport technology, and like I say they're now busy backing away from that.
Meanwhile the war against terror has inspired governments to push ahead with various draconian and ill-conceived authorisation schemes, including US-VISIT and the UK ID card scheme. These schemes completely ignore most of the requirements I've set out, especially privacy. If the schemes go ahead, industry will probably standardise to them, and we'll have lost the opportunity to implement a system that respects personal liberty and privacy.
To give this kind of thing a real push, I'd like to see one industry take the lead and implement this stuff in the consumer space, demonstrating such big advantages that these systems will be demanded by the public, rather than being thrust upon them. It's crucial that any early implementers are able to go into this with big resources and a strong reputation to protect, so that they can avoid the normal technological pitfalls. Implementing federated identity systems is particularly dangerous, because a trivial bug could result in hudreds of thousands of people's identities being spread all over the internet in a matter of seconds. Such a public humiliation could tarnish the whole technology effectively forever. It has to be done right the first time.
IT companies are therefore the last people who should be pushing this. Everyone knows that big IT is a disaster area of technical failure, budget overruns, and broken promises. Allowing Microsoft, Sun or IBM to take charge of the early implementations would be like hiring Mr Squiggle to run the Apollo program. To be fair to them, they'd probably get the job done the quickest, but in this case I think it's more important that it's done right than quickly.
The government would be another option, but if we're talking technical failure, budget overruns, and broken promises, then government IT is the very worst of the lot. The government sounds like a good idea because:
However, the government record on big IT projects should rule them out for any project where consumers actually want to see a visible result within their own lifetimes.
My favoured option would be the banking industry. They're the ones who end up paying the most for identity theft, and therefore the ones who are most threatened by the phenomenon of people spreading their identity all over the internet. They already have sophisticated, trustworthy authentication and authorisation systems that can form the platform for implementing new extensions. They already run extremely sensitive websites used by millions of users every day. They exist in a very competitive marketplace. And consumers strongly identify them with bureaucratic pain, so any bank that makes a move to make people's online life simpler would get a nice little PR win.
In this section I'll describe how a more-or-less average (albeit somewhat paranoid) user, Alice, could take full advantage of a mature federated identity network to protect her privacy and defend against identity theft, while still allowing her to smoothly navigate around all the online systems she uses without having to spend a significant amount of time managing her various accounts, and without having to memorise a vast long list of passwords. I've tried to cover as broad a range as possible of different use cases and commercial models.
Alice uses the following service providers (mixture of real and fictional):
These are shown on the following diagram - you should follow this diagram to make sense of the text:
We'll start at the primary identity provider level. For maximum security, Alice has three separate primary identity providers: Veritanium, HSBC, and Rottweiler. Even if one of them is completely compromised and someone steals her identity, changing the name, address, fingerprints, and photo to look like someone else, Alice can still identify herself to the other two and get things sorted out. Rottweiler and HSBC are UK companies, while Veritanium is based in the US. She's broadly divided her various accounts between financial (HSBC), government (Rottweiler), and everything else (Veritanium).
Rottweiler is her most secure account. To authenticate, she goes to one of Rottweiler's branch offices (her nearest one's in Ealing) and has a retina scan and a fingerprint scan. They also check her Rottweiler smartcard, check that she looks like her photo, and ask her for her passphrase ("The sound of the thirty-seventh underground Torvald dogs exploding"). If she fails any of those they have a backup authentication mechanism, where they give her an interview with a trained consultant who has a list of a dozen pre-prepared personal questions to ask her ("What's your mother's maiden name? How long is your grandmother's hair? What colour fur did your first pet have?"). It's a pain doing all of that, but she only has to do it when she changes address.
HSBC is almost as strict. They actually have her DNA sample, but this is only used as a "foolproof" backup in case of suspicion. Apart from that it's similar to Rottweiler, with fingerprints, smartcard, photos, and passphrase. Like Rottweiler, she has to physically turn up at their offices, although there's an HSBC just round the corner from where she lives so it's not too bad. She chose HSBC partly because of the convenience of having a branch nearby, but mainly because the service is free for existing customers.
Veritanium doesn't use DNA or retina scans. She uses them completely online, using a box that plugs into her computer and scans her fingerprints and her smartcard. If she thought that her account had been compromised, she'd phone them and get her account frozen. Then she'd have to go into their London offices and go through the usual passphrase and photo rigmarole to get it unfrozen again. But they're the most trusted identity provider for working online, and having a US account sometimes makes life easier when working with other US companies.
Note that if her Veritanium account was utterly compromised, such that the attacker got all her information: photos, fingerprints, passphrase, the works, then that attacker still wouldn't have enough information to get into her Rottweiler or HSBC accounts. If one of the Rottweiler or HSBC accounts were compromised, that wouldn't be enough to break into the other, although it would be enough to get into Veritanium. Alice likes that because she knows that even though HSBC and Rottweiler are fairly trusted names, IT is still IT, and you just can't rely on it.
Just to summarise, so far Alice has three passwords to memorise, from the three primary identity providers.
The HSBC account I've been talking about so far is her primary identity provider. HSBC also provides her with an account on a secondary identity provider. This account is protected with her smartcard and a password. HSBC usually recommends that you use fingerprint protection as well, but Alice finds that her fingerprint scanner doesn't always work reliably, so she's taken the option of slightly laxer security here. She uses HSBC's secondary identity provider for authentication to her HSBC accounts. She also uses it as the identity provider for her Legal and General and National Mutual accounts. Each of those organisations has their own identity provider system, but Alice has asked them to redirect authentication requests to HSBC. That way, she's got two fewer passwords to memorise.
Her second bank account, managed by Citibank, is what she uses when she's travelling, and is also there in case she needs to block her HSBC accounts if her identity is stolen or something. As such, the Citibank identity provider gets her essential details directly from HSBC's primary identity provider, instead of the lower-security secondary identity provider that Legal and General and National Mutual use. Citibank also has rather stricter authentication, with its own password and smartcard.
The government meanwhile has its own identity system. This is used by all government departments. Note that this doesn't mean that there's a giant government database with all Alice's personal details on, accessible to any civil servant. On the contrary, the Inland Revenue has its own database completely separate from the Home Office. If the Inland Revenue wants to know Alice's current immigration status, it sends the request to the Home Office indirectly, via the identity system. Alice has to approve the transaction before the information is actually handed over to the Inland Revenue - which she'll do if she wants her tax return! Alice has a single password and smartcard to guard access to the government's systems. The government's system gets information about her name and address from her Rottweiler account. It also holds some extra information about her - her marital status and dates of immigration, for example.
For some applications, government departments require applications to be made in person, so they can verify signatures and photo ID. With the new systems, they can still maintain that level of security without actually running their own offices. Instead, they outsource that responsibility to Rottweiler. When Alice applies for a drivers' license, she fills out the form online, but sends it to Rottweiler. She then turns up to Rottweiler's office and signs for it. Finally, Rottweiler sends it to the Drivers and Vehicles Licensing Agency with confirmation of the level of security it passed. This gives the government a much greater level of security, but they don't need to employ expensive bureaucrats for the menial job of looking at signatures. Effectively Alice is paying that charge out of her own pocket, and at her own discretion. Alice gets the benefit of being able to choose any identity provider she likes (within a subset of government-approved providers), so she can choose a company that has an office near her home. Everyone's using the same standard protocol, so it's easy for Alice to move her business to another company if she's not happy with the service. From Alice's point of view, bored bureaucrats sitting in front of queues in dingy offices have been replaced with a website and her bank's local branch office.
So now we've got three more passwords: HSBC's secondary identity provider, Citibank, and the government. That makes a total of six.
Alice has two more secondary identity provider accounts with Veritanium - one for work, and one for e-commerce sites. Each is protected by a password. Alice's employer, Logitech, runs its own identity provider system for all its employees. Alice doesn't use a password for this system, instead asking it to redirect queries to her Veritanium account. Logitech can easily verify that Veritanium's security is at least as good as their own, so they're happy with this arrangement.
The same account also managed her old job, at TicketsOnline.com. TicketsOnline doesn't even run its own identity provider, instead outsourcing the job to Oracle's business division. Alice used to use them for lots of other stuff too, but now she's moved over entirely to Veritanium, and has redirected her old account to authenticate there instead. Since Alice doesn't work at TicketsOnline any more, she's disabled their ability to find her current address and phone number. If they want to get in touch with her, they can email her through the chain of identity providers. Alice never loses track of old accounts that she's forgotten about, and can cancel them whenever she wants.
Since Veritanium is a pretty well-known site, all of Alice's e-commerce accounts (Amazon, eBay, Expedia) are happy to use it for authentication. She still likes to keep separate identity providers for work and shopping at Veritanium, because she buys lots of stuff online, and you never know when someone's going to see your password when you're in an internet cafe in Istanbul.
Many of the websites I've described so far need to access Alice's bank account, either to pay in (employers, Inland Revenue) or out (e-commerce, TV Licensing Bureau). They pass these requests up to their respective identity providers, from where Alice connects them to her HSBC secondary identity provider. When she logs in to that account, she can call up a full list of everyone who pays money into or gets money out of her account, and all of the outstanding requests they have. She can then go through them one by one and authorise them. The secondary identity provider talks to her bank account to authorise the transactions (Alice does have to have enough money!), and then sends the confirmation back through the identity chain to eBay or whoever asked for it in the first place. HSBC's secondary identity provider is therefore rather heavily customised for dealing with financial transactions, although it's still a fully functional general identity provider that could be used for anything, and Alice could still use an independent identity provider for this purpose if she wanted.
This is the only place where Alice's three independent hierarchies talk to each other. To minimise the security risk, this kind of "backchannel" contact only goes through secondary identity providers. E-commerce sites like Amazon need never know which banks Alice uses - they just take Veritanium's word for it that the money is on the way from somewhere. This is similar to how PayPal works now.
Alice has yet another secondary identity provider hanging off her Veritanium primary identity provider account, with a company called Identishure. Identishure is a pretty cheap but high bandwidth provider based in the US. Alice uses them as the foundation of her "everything else" internet use. Identishure provides an internet directory service, with which Alice's friends can keep up to date with her address and telephone number. There are also a couple of e-commerce sites that connect to Identishure's website. Her British Airways frequent flyer club, and the "Nivea free sample club", both send her stuff in the post, so she keeps them up-to-date with her postal address via Identishure.
To keep our tally up-to-date, Alice has three more passwords to remember: her "work" Veritanium account, her "e-commerce" Veritanium account, and her Identishure account. That makes a total of nine, and that's all the passwords Alice has. Three of them, from the primary identity providers, are only very rarely used, meaning that Alice has six passwords she uses day-to-day. That's both reasonable to remember, and pretty secure.
Alice is subscribed to a bunch of email lists. You can't trust the people who run email lists to pay a lot of attention to security (they've got better things to do), so Alice has a separate identity provider account with OpenIdent to "firewall off" the email lists, ensuring that no-one can track an email account back to Identishure, or further. OpenIdent is a free, open source identity provider.
Finally, Alice has accounts on a bunch of web forums. To guard against spammers, trolls and the like, these forums require Alice to establish her uniqueness. Identishure is a uniqueness server, but charges Alice 50c for every uniqueness query. Therefore, Alice chains that account to OpenUnique, a free to use open source uniqueness server, which is recognised by all the web forums.
So there you have it. Nine passwords, a few smartcards, and a fingerprint scanner. This is enough to protect Alice more than satisfactorily in a range of applications from the Girls Aloud web forum right up to security that James Bond would have been proud of. No matter how many online accounts Alice accumulates (and I've got over 60 at last count), she'll still use them all with just six passwords.
This addendum needs to be properly incorporated somewhere. But this scenario of a criminal justice system rendered useless by pervasive ID is worth thinking carefully about.