Jud Valeski had a notable observation about how potentially powerful an OS level namespace and single sign-on capability could be for internetworked applications:
Everyone’s talking about the power of Twitter and Apple’s native single sign-on model in iOS 5. While this is a phenomenal coup for both Twitter and Apple, it’s only the tip of the iceberg. Having a widespread, networked, account namespace (Twitter) baked in at the operating system level is one of the few things that can truly revolutionize the network again.
I am certainly not going to be one to criticize this desire at all. But (of course there’s a “but”), I have no real reason to believe that a big company team-up is going to actually enable this desire. The history of big software companies’ attempts at some kind of unified, distributable identity is littered with bungles, with everything from Passport to Apple’s own MobileMe.
There, is of course, the big advantage that there are already a lot of integrations and knowledge about Twitter auth and users, but is that enough?
I’ve always thought that “user-awareness” was incredibly key to making applications powerful and much more user-friendly, but I don’t write about it enough. So, here goes the following…
I still think the solution to this “who is the user/omfg passwords everywhere” nightmare has to be something that provides “connectedness” and an extra layer of security that is used pretty rarely at the moment.
What does that mean? Glad you asked. I think it looks something like this:
- A user connects to an Internet service (through a browser, mobile app, desktop app, anything).
- A hashed key is provided to the service along with that request. The hash initially blinds the service from the user’s identity.
- The service sends the hash off to a third party.
- The third party then contacts the user, most likely through a mobile app: “The service MyHotNewThing wants to connect with your information, do you want to share the following info?…”
- The user says Yes (or No and the process stops and the user gets a “not logged in” view of the service), makes any customizations to what info they want to share with the service, and the third party then provides a key to the service that allows them to access the user’s information.
- The user is logged in to the service and any approved content or other connections(!) are also now available to the service.
Boom. It’s a bit similar to OAuth, but not the same: No browser required, no bouncing through URLs, no confusion about who is asking for what.
A few additional key points:
- Those hashes have to include, behind the scenes, devices. In normal language this means something like “User X has approved access to Service Y from Device Z.” Now, implicitly, the user is probably approving this for all the user’s devices, but all of those keys are different. This lets a user completely disable access from a (stolen, lost, broken) device for everything in one action. It also lets the user disapprove access from an unknown (hacker) device.
- This also makes all the keys and hashes different for the triple combo of service/user/device as opposed to most current schemes, which are just service/user.
- By handing off the approval process to a third-party this opens the door to things like social authentication (my friends trust this, so I will too) and content-sharing without conflict of interest.
Getting back to the original post, I’m not saying that possibility isn’t there, but I don’t see the big players thinking about this problem in this way.
Thoughts?
