Slashdot Mirror
Can We Fix Federated Authentication?
Bruce Schneier writes in his blog of a "New paper by Ross Anderson: 'Can We Fix the Security Economics of Federated Authentication?': There has been much academic discussion of federated authentication, and quite some political maneuvering about 'e-ID.' The grand vision, which has been around for years in various forms but was recently articulated in the US National Strategy for Trustworthy Identities in Cyberspace (NSTIC)."
The basic problem is that a lot of people look at the possibility of being the go-to Internet identity service as being a huge money raiser. There are big network effects - you need a critical mass of websites so that anyone who wanted to do anything online would have to sign up for your service, and a critical mass of users so that any website that wanted to be quick and convenient would have to sign up for your service.
But once that critical mass was achieved, that's when the big fun begins, because you now as the established middleman have 4 potential sources of revenue:
1. Fees from each website that wants to use your service to verify identity.
2. Fees from each user that wants to use your service to identify themselves.
3. The sale of user's personal data to advertisers. (In the "achieving critical mass" phase, of course, they'll put in a privacy policy that says that they won't do this, but once they have enough users to dominate they'll quietly change the policy.)
4. Advertising on the website that you use to sign up.
And because you're the tool everybody is using, every new user or website pretty much has to use your service or risk being out in the cold.
A lot of companies have tried to get themselves in this position: Microsoft took a stab at it, Facebook and Twitter are still pushing for it, etc etc.
I am officially gone from
From the article:
No, it has mostly failed not because of lack of incentive but simply because *I* want to be the controller of my individual identity online--not some third-party or government sponsored gatekeeper.
We do NOT need this and I wish we'd stop wasting time, money, and effort on something that will always fail. Even if it is adopted it will have been an enormous waste being that those problems it's meant to solve will be circumvented by those who do not want it solved.
Lets just use facebook connect and call it a day!
The problem with these such systems is that people begin to trust them far before they should. I am NOT a fan of single signons for ANYTHING. Yeah it's a pain to know 4 different passwords, but if one of these federated providers is compromised, then EVERY company who uses them is ALSO compromised.
Gorkman
It would be nice if I could go down to the Secretary of State / DMV and obtain a digital ID certificate.
Until the government cancelled your ID or required it for everything you do online.
We really, really don't need government-mandated 'Internet passports'.
I wonder why it couldn't follow the same type of structure as a notary public... The level of trust and accountability is already in place there, and crypto allows for easier revocation than paper, so it seems like it would be an easy way to organize.
I studied this problem while working for a major US federal agency that would have found it very useful to have a trustable electronic ID for every US citizen a few years ago. When I studied it, I pointed out possible risks that the public might perceive in this scheme. These included the idea that the US federal government could easily link all federal records for an individual together using such an ID, the US federal government could require all transactions with the US federal government to be made under this ID, and so on. In other words, it would be a key aspect of putting together a surveillance state. I didn't think (then) that most people would go for it.
Things may have changed, now... if enough people in the US are fed up with having separate identities and credentials for each on-line service they use, either socially or for business, they might be willing to let the US federal government take on the role of proofing identity. US citizens already accept that role with the standard state-issued government ID (a driver's license) and the standard federally-issued ID (the passport) that is required for virtually all significant identity-proofing transactions. Would they accept it for electronic transactions as well?
Of course, the difference with the current system is that the records of using the identity-proofing service (showing a driver's license or passport) are only in the hands of the people to whom we prove our identity. Under an electronic system, unless it is designed to preclude centralized logging, the US federal government would have a record of every time the ID was used. Yikes?
Authentication can be defined as the process of proving an identity. One question to ask is what identity is being proven? Does the concept of identity even have meaning outside of a relationship between two parties?
We like to believe that we each are ourselves, which is our sense of identity. But who are we, anyway? We could define our identity as being the child of our (presumably two) parents - but this just pushes the problem off one generation - what is the identity of our parents? This could be taken back as far as necessary to establish an identity chain that would make it unlikely to find conflicts. We can also define our identity as being the individual born in a certain location at a certain date/time, and we feel this is probably unique because it is unlikely that there were more than one individual born at the same date/time in the same location (assuming the location is localized enough). But are these identities really meaningful? Are they what is really necessary?
In most circumstances, its not who you are that is important, but your relationship with another party that matters. For example, my college didn't necessarily care who I was while I was in attendance there, but rather that the person who took all of the courses and exams, building up an academic record, was the same person to whom they granted a degree upon my satisfactory completion of a particular course of study. In some sense, the US IRS doesn't care who you are (the child of Julius and Ethel, for example) but rather that the single individual who made income from a set of income sources paid the taxes that they owe based on current tax law for that income. And the US Social Security system cares mostly that the individual who paid a certain amount on Social Security fees over their lifetime for income earned is the same person to whom they are cutting a Social Security check in retirement. And so on...
Is it really meaningful to seek a single ID and authentication of that ID for use with numerous parties, who are really only interested in establishing your relationship to a particular credit account, or taxpayer ID, or student it? What risks might be involved in constructing such a singularly important ID?
Instead of trying to get one identity to rule them all, why not go with the approach that has worked for thousands of years? It's capability based security, but you're likely not heard that term used in the context before.
In the past, if you owed someone $19.95, you would hand a $20 bill, and wait for change. In this type of transaction, the most you can lose is the amount you pay. In this case, an $20 bill is a capability token.
Sometimes you want to stop or reverse a transaction. To do this, you need to revoke a capability. With cash, you can simply get your money back. Once this is done, there are no trust issues after the fact. It's nice and simple.
The credit card model on the other hand has you handing your entire credit capability to the merchant. If you want to revoke it, you're out of luck in terms of a single transaction, you have to TRUST the merchant, and all of their employees, from that point forward to do the right thing. You also have to trust all of the other merchants and their staff as well, accumulating a large pool of people and computers, until the token expires or is revoked. Revoking the capability usually entails a few days of outage as well.
With computers and the internet, a username/password system really doesn't prove identity, but it is a bit more secure in that you can have many different capabilities instead of a single concentrated pool of mis-trust. (Assuming of course you don't use the same username - password pair in more than one place) Revoking an capability in this case involves different procedures for each and every one, there isn't much uniformity to the process.
OpenID was a good idea in that it let you get away from handing over everything, and got us started on the road to capabilities, but it doesn't go far enough in that direction.
Most other approaches to federated identity involve a similar ever growing pool of people and machines you have to trust, with the subsequent amount of grief when the identity capability has to be revoked. When viewed from the capabilities perspective, this isn't desirable.
Isn't it better to issue individually revocable capability tokens? There's no reason not to have the phone talk to the actual service that does the work. The private keys, etc... should never be carried around on one's person, nor stored in a system used for other things on the internet.
In summary:
We need to stop thinking in terms of identity when considering permissions, and start shifting to one of capabilities instead.