Try to imagine a day in your life. You walk out of your home and meet your neighbour. You have to show her your passport before she even acknowledges you with a nod. You reach a bar. The barman is the same fellow you’ve been chatting with every morning for 3 years. Before he can even cheer you and brew your coffee, you have to show him your passport and give him your credit card and pin number. Finally you get to the office. Again, before being able to interact with your colleagues, you have to show everyone your passport and your office badge.

This is not how things work, right?

But it’s exactly how it works on the web. You have to type a password before using your laptop.You have to login before you can access Twitter, you have to login before ordering anything on Amazon, you have to login before using Facebook. And then, if you work in an office and don’t like to mix your job and your personal life in a single identity, you need to log out of all your accounts and log in again to your professional ones.

This is because the web today is based on logins. We are more then 10 years into the internet age and still we are identifying ourselves with usernames and password, a method that has already demonstrated to be incredibly difficult to manage for everyone, because the “good password policies” are too hard to apply for a normal person that just wants to send a photo to his grandmother.

Is the login paradigm a failure? Yes, and you’ll find plenty of evidence online. One of my favourite is this report form Trusteer (PDF) that shows how 73% of people share the critical banking username with other online services and 47% of them share both username and password. From a completely different perspective there are recurring discussions on where’s better to put the registration, because that boring detail hugely influences adoption. Check this excellent presentation by Joshua Porter on this very topic. Of course, this model served us well up until now. But this is not enough anymore.

I believe we should move away from logins, and embrace identities. Or, without getting too philosophical, move towards an interaction paradigm that looks more like real identities and less like cypher codes from Mission Impossible.

I’m surely not the first person thinking and talking about this, and even more there are lots of people out there working directly on this specific topic, taking one stance or another on how to solve the problem. There are products like 1Password and Passpack and there are also big companies like Google trying to push forward solutions, plus efforts like Mozilla BrowserID that are headed in this very direction.

This indicates two very interesting things: first this is a huge problem that’s felt by almost everybody; second, there are a lot of problems to solve before reaching our end.

What I’d like to do here is to connect all these different approaches together under a single umbrella, to help everyone head in the same direction. And this vision is excatly the shift from logins to identities.

Identity

How could we do that? Well, one step at time. The first step is quite simple, and requires an incredibly simple interface in your browser. That’s what I want to propose today, and I’d love to start a discussion, in order to create a better web for everyone. I don’t have all the answers, but I believe that this is the right way to go.

This is how I think identity should appear on your future browser version:

Did you notice the top-right corner?
This browser window, knows who I am.

There isn’t much more to add, that’s what the user has to do to login. Nothing. This browser window is logged in with your personal identity and will instruct any websites you visit accordingly.

It’s so simple that the part about the basic user experience ends here. It just works.

What’s great about this way of managing identities is that you can easily switch from one to another. Plus, you can have multiple windows open, each one with a different active identity.

Private browsing will be just another identity, not a special mode anymore, giving a clear signal that you can still browser without disclosing anything at all.

Switching from one identity to the other might be locked with a password, and it might be possible to add an option to automatically logout to Privacy mode after some inactivity time.

For convenience, let’s use a name for this identity-based approach. Identity 2.0 is taken by OpenID. So, instead of Identity 3.0, let’s use the more meaningful Seamless Identity.

How does Seamless Identity work?

As it often happens with transparent interactions like this, there is a hidden complexity underneath. There are technical challenges that connects with two topics: privacy and security.

While I know a bit of both, I’m not expert enough to have a definitive answer for a service that could potentially work for every person in the world. That’s why I’d love to have feedbacks on the model I’m describing here and build together a solid standard.

One of the API could be a JavaScript API, and could work like this:

1. By default, it exposes a low security identity token generated for a specific domain. So any website will be able to associate data with you and you alone, without any risk to lose it, since that token will be stored with the identity. I imagine that this token will be generated with a cryptographic algorithm in order to be both secure, unique and not sharable between multiple domains. In this way, nobody will be able to track your movements even if your identity is active, because each token will be unique and different (and possibly, revokable).
2. If the website wants to know more about you, it has to ask. It’s not much different than a waiter asking your name to take your booking, and it will be available at the push of a button. I think that the next level up is “email”, since too many services right now need it for things like notifications. Notice however that there could be a service attached to this identity module creating special emails that could be invalidated, protecting in this way your real email address.

It’s interesting to note however that most online services will be able to provide most of their features with just the first level token, since the important thing is to uniquely identify you. The need to provide an email address is in many cases just a byproduct of the login paradigm and its compulsory registration. Think about it: you would still be able to access the whole of Twitter, Facebook or Flickr even if they didn’t have your email, right? The important thing for these services is to know that you are really you, in order to grant access to your data.

PROS:

1. Transparent user experience.
2. Increased safety against phishing: since you never have to type anything or disclose twice your credential to a website, they can’t ask you twice without looking suspicious.
3. Your data will be inputted only once in the Identity Manager provided by the browser, and you’ll never have to type this information again. So, nobody could steal your password, email or credit card, since you’ll never type these details again. This would also allow automatic detail change the next time you visit the website. The browser runtime will protect the data for you (this is an important point of course for the browser implementation).
4. A new class of services will be enabled, and the adoption barrier will be lowered to almost zero. There will be no registration process to slow you down: you’ll open a website and you’ll be able to start using it immediately.
5. Facebook, or other identity providers, won’t be the gatekeepers of your data anymore. They could instead be cloud services offering more services on top of this identity mechanism.
6. It will allow peer-to-peer authenticated exchanges, since the identity is now in the device and not in the service you’re registered with.
7. No website will have to store your credit card data anymore, since it will be provided ad-hoc by the Identity Manager when needed.

CONS:

1. You will still have one password, the one protecting your device(s).
2. The identity will be a cryptographic information stored somewhere: if you lose it, it’s gone with all the accounts you ever created, and you’ll have to retrieve them with site-specific requests.
3. The identity needs to be transferred to every device you own.
4. If you don’t have your identity with you, there’s no way to login by default. Exactly like if you don’t have your identity you can’t buy alcohol, or you can’t get on a plane.

However the cons aren’t so bad and can be easily mitigated:

• Points 2 and 3 might be mitigated by a backend based on a standardized cloud service to store the identity. Data would be encrypted before being stored so that not even the company providing the service could access it (see Passpack as an example of how this has already been done transparently). The service would allow retrieval in case all your hardware is lost. If you think about it, it’s in some way what already happens with Android/GoogleAccounts and iOS/iCloud.
• Point 4 might be a problem for some users, but it might be less relevant since there’s a growing number of users that uses smartphones, and well, a feature like this could be ported to non-smartphones as well.
• Point 4 can also be mitigated by the services themselves, enabling different login mechanisms to allow non-identity based authentication (i.e. sending you an SMS with a token). This isn’t new, and it’s usually well developed in the best password recovery systems.

It’s worth noting an interesting detail: a lot of people are already using the browser built-in feature of Saved Passwords, or systems like 1Password. WIth these you get basically all the cons above, with a minimal advantage compared to what would be possible with Seamless Identity.

Use cases overview

What’s even more interesting is that while SeamlessID is intended and works as a replacement of logins, certain services such as banks might still require additional security systems and ask for nonce passwords. Also, the “password recovery systems” of today, will be “identity reconnect systems” just in case you need a one-time access from remotely or reset your identity connection. These will be provided as today by the services, because they will store different data (a recovery for a bank will be different from a recovery for Twitter).

That’s entirely fine. This is just a first step.

This diagram shows at a glance different use cases and how SeamlessID solves the problem easily.

As it’s now probably clear, there’s no way logins can help you in having the very first level of identity. That’s missing, because it’s too slow. It’s also one of the reasons why a lot of systems like Facebook are closed gardens: once you’re in, that first sight identity is granted. Once you’re in.

All the middle ground of identity is covered by logins as well, however SeamlessID will be simply quicker, by providing information at the click of the mouse and in a more secure way.

Seamless Identity API draft

This is a draft I thought that might enable this kind of service. It’s worth noting that while this is a JavaScript API, it’s possible to suppose that the browser could send the token inside the HTTP request header as well, thus providing this feature on systems without JavaScript. But that’s an advanced topic for another time.

It’s also worth noting that there are a lot of similarities with the Session API from Mozilla BrowserID, even if the Session API is still based on a login model instead of an identity model and seem still delegating the identity management to the website.

window.id.token

This property will provide the unique token to initiate the first level of identity exchange. As said before, this is unique within a domain.

The token could be an alphanumeric string like a md5 hash.

If the domain is blacklisted, or the user is in Privacy mode, the token property will return false.

As you can see this is similar, technically, to what already happens today with cookies, but the difference here is that now is the browser that generates the token from a private key and not the website.

This is huge, because it means that the identity doesn’t expire and the user has control over that identity.

Effectively, it means that you can trust any data created with the token, because it’s already you, and you can at a later time decide to keep that data, reset the token, upgrade the registration with the website or else.

window.id.get(<required>, <optional>, callback)

This will be a function to request the user to explicitly disclose these information. The application can request one or more fields, each one identified by its name.

For example:

window.id.get(['name', 'nickname'], callback);
window.id.get(['name', 'nickname'], ['avatar', 'country'], callback);
window.id.get(null, ['avatar', 'country'], callback);

When this request is issued, the user will see an overlay generated by the window chrome (not the page – for security reasons) asking if they want to allow that domain to access these details from that moment on.

window.id.getOnce(<required>, callback)

This function works exactly like window.id.get, with the same ability of ask for one or more fields from the Identity profile, and the same popup.

The difference is that these informations are returned to the web app only once, and every request needs to be authorized again.

Certain class of values, like credit cards, might only be available under the “getOnce” call. It might also be that this function will work only if the website is under HTTPS.

window.id.<field>

Once requested at least once with window.id.get(), each of the details will then be available directly at API level. This is useful also to handle updates: if for example the nickname changes, the system will be able to lookup it and verify it changed, updating its internal value automatically or after a confirmation.

This works well because we are talking about identities, and when some detail about you change you expect anyone you are in touch with to automatically get that update, or at least ask if you want that update to happen.

Notice also that I used “window” instead of “navigator” because the idea is that each window can use a different identity and this would make it cleared. However this is really just a detail managed by the browser engine itself. It could be “navigator” as well.

Native support

Another important thing about this approach is that identity will switch from being just multiple logins to memorize to being an operating system level feature, like the KeyChain feature in OSX.

In this way, once ready, Firefox, Chrome, Explorer, Safari, Opera and the other browsers could just provide an interface to that identity system.

This is even more relevant because for security reasons it is important to have all the interactions with the Identity Manager to be outside the website part of the screen: in this way they couldn’t fake any interaction with it (even if, as stated, you’ll have to push just one button, not type private data directly in the website).

This last thing is easy on a computer, but it’s hard on a smartphone where most of the screen estate will be used for the website. In this scenario, it will probably need to slide away like happens with the multitasking bar of iOS, in order to show the controls outside and maybe showing an image that you setup, and that a phishing website couldn’t know.

What will it mean for developers

Think about what happens today: you are developing an idea to help people do something. Today, you can’t really start if you don’t have a registration system of some kind. Even if you use a library, you have to take it into account.

Even worse, you will have to find ways to motivate enough your user to overcome the registration barrier and use your service, or create a smart system to allow your user to demo the system before registering, with all the complexity that it might mean.

With Seamless Identity the registration barrier disappears.

For your earliest prototype, you might even just take the token and work with it, without any registration or any additional detail. You will be able to test the platform and build only one code path. There’s no split between app and demo, it’s all app, working, without any barrier.

And all of this will cost you a single call to window.it.token.

Wouldn’t that be amazing?

Could you imagine all the services that could exist thanks to this?

Adoption

While I was writing this article Google published a very similar idea to handle multiple Chrome users. You can see their solution here. This is a good early confirmation that this approach is good, even if I’d put the login on the right corner because it’s where we usually expect it to be and I don’t want it to be confused with the app itself. However Google Chrome’s solution vision is limited to Chrome. What we are talking here instead is a new layer for the open web.

I think that Mozilla has the right culture, technology and freedom to move forward this shift to identities and create a standard that will be adopted by all the other browsers… and hopefully operating systems as well.

Mozilla is already working on BrowserID, and this could potentially be the backend for this kind of identity shift, and after reading this article by David Ascher now I’m even more sure of this.

There’s of course a risk: the risk that each browser manufacturer will try to create walled identities, forcing users to use only one browser forever, with no ability to switch. You can clearly see that this will basically kill this concept, and will delay the adoption of an improved identity system for more years.

It’s important, if not critical, that the identity is easily transferrable, with a one-click way to do it: “Do you want this browser to use the Identity X?”, done. Even better if it will be a OS-level library. And BrowserID is again already trying to solve this problem by federating the concept of identity.

Otherwise… it will be just a way to trade one kind of fragmentation for another. Let’s work together. This should be a standard foundation for the future web. Identity must be in your hands, not in the hands of some external entity.

Even if I believe that Seamless Identity is the correct next step, I’m not focused on this specific implementation, just on this specific user experience and the fact that the code usability needs to be excellent, but even that is open for discussion. I believe that identity needs to make a step forward in being seamless and transparent, and that’s what I want to see. If it’s delivered in a different way, that’s still great.

~

If you think about this, the switch from logins to identities will also close another gap between native applications and web applications. Today you don’t have to login to an app you downloaded on your Android or iPad, and why should you if it’s local?

Moving from logins to identities on the web will allow this seamless experience for web apps as well, everywhere, on mobile and desktop. And on mobile it will be even more powerful.

I see a huge potential.

Do you know any browser developer? Participate in the discussion (on Twitter we are using the #seamlessID tag), link this article to them. I’m sure they will be interested, and you’ll help to change the web. ;)

Convergent Evidence

1. Google Chrome Users, see how to use them — November 2011
2. Google Chrome iOS/Android auto sign-in, see how it works — Jul 2013
3. Twitter “push” auth system, see the announcement — Aug 2013
4. Mozilla Nightly introduces Containers / Contextual Identities — Jun 2016

Years later, Apple introduced something very similar – Sign in with Apple –  with a very similar API too, and some extra features like masking of the email. The only downside is that is not “standard” but from a single company, again.

Updates from the comments

1. Storage: what wasn’t clear enough probably is that this system by default stores everything in a secure space on your device. There’s no need to sync or put it on the cloud, you are in complete control. This already happens with Password Managers. If you want to think about this in a different way, SeamlessID simply makes transparent and more secure your Password Manager.
2. Device-less access: on the completely opposite side, there might be situations where you either don’t have your device, or you can’t access one. In this scenario, it’s also simple, because SeamlessID doesn’t mandate any restriction on the fact that the account might also be synced remotely. You might be able to log-in temporarly with a remote account, like a special privacy mode. The stress point here is that the browser should handle this layer of complexity, not the user. This already exists: OpenID logins, Facebook logins, Twitter logins, Google Account logins are all doing this.
3. Is it a replacement? No, not at all. Yes, this idea is designed to completely replace logins for normal usage, but logins will still be available as an alternative. Consider also that with SeamlessID in place you might still need a way to access a service without your authenticated device with you. The way will be the equivalent of the current “password recovery”, with the difference that will generate a one-time access instead of resetting the password.
4. Identity vs Identity certification: the fact that today we are using logins means that when someone says identity they often refer to “identity certification”. However, that’s a different thing: one thing is the neighbour that knows you by sight, another thing is the airport check-in that asks for your passport. That’s why SeamlessID has different access levels and doesn’t mandate any certification: it might be added, or not. The important part is automating the task so it’s not anymore the user that needs to remember that, but the Identity Manager in the browser or operating system (identity and authentication explained).