nileshtrivedi/web-identity.md

## web-identity.md

      
    Raw
  

              web-identity.md
            
          
    Light-weight Identity for the Web using Browser Sync and Push

(This is just a rough idea intended to trigger a discussion. Details need to be fleshed out for a proper evaluation.)
Signing up and logging into website continues to be painful. For a while, there were attempts like the Mozilla Persona project but those were discontinued and that has led to social logins gaining prominence, with all the concerns of centralization, privacy, surveillance etc as valid as ever. In fact, more and more websites are now adopting Google's One Tap login because the convenient UX is giving them better conversions.
However, some things have changed in recent years:

Push notifications are now widely supported in browsers. This is relevant because one of the main reasons why websites insist on user registration is so that they can communicate with the users via email or phone when they are offline.
Multi-device syncing has improved in browsers. They sync not just bookmarks, but also currently open tabs, passwords, extensions etc.
Some browsers like Brave are even bundling payment mechanisms with crypto-currencies.

I think there is now an opportunity to rethink identity on the Web - especially light-weight ones where sites are currently adopting Google's one-tap login or Facebook login etc. The 2 main reasons why websites need signup are:

Communicate to the users when they are offline. This includes both promotional and transactional messages - which means a good solution would attempt to find the right balance between what the users want and what the publishers want.
Let them claim their account from a different device, i.e. authentication.
Build rich user profiles. This is where most privacy concerns come in. IMHO, this should be possible only with users' explicit consent.

If websites are able to notify the users via browser push, the main reason for collecting email or phone goes away. Sure, we will need to give the users enough tools to filter (and perhaps archive?) their notifications but that is probably unavoidable. This may require us to make the push API a bit richer to differentiate between transactional v/s promotional notifications and constraining them appropriately. See how Chrome is building a quiet UI for push notifications.
All that now remains is synchronizing the session cookies across devices. As I said, browsers are already syncing a lot more data. With a convention (such as a standard cookie name), browsers can take the core session cookie and make it available on all of the users' devices.
This needs some work so that the push token revealed to the website is device-agnostic, but all the infrastructure is already in place. Browsers know all the devices that user has linked to their sync account, and they can route the notification to the appropriate device.
If we do this, accepting the notification access prompt is all that's needed for signing up or logging in on a website. No email or phone numbers are necessary. Users can feel safe because profiling via social logins becomes impossible. Some websites will need to send the user to a form to "Complete your detailed profile" (such as name, picture, email, phone, organization) etc. But that's exactly what we want in many cases.
This turns browsers into an identity-provider. But there's a crucial difference when compared with traditional IDPs such as Facebook or Google: Browsers have been much more pro-user than these social networks. For example, browsers encrypt all the sync data using passphrases, instead of storing them raw on their servers. The new auth mechanism above may put browsers in a position to do denial-of-service, but they or their employees cannot take over your account by stealing your cookies. A malicious browser already has full control of users' sessions anyway.
Open questions:


The push notification tokens are currently browser-specific. If you signed up via Brave, you won't be able to claim that account via Firefox. This needs some kind of cross-browser syncing to solve. I feel the benefits of easier signup or authentication might be worth this trade-off in many cases.


Notifications are currently fleeting (i.e. not persisted). If this channel starts being used for important communication that needs persistence (what email and SMS/Whatsapp provide), users might lose valuable information. But as I said, any communication channel will need to solve this anyway (and browsers have already started moving in this direction). If I allow you to notify me, the channel should differentiate between different type of messages: promotional v/s transactional, fleeting v/s permanent etc.


What if the website does not want to trust the browsers and their sync servers? This approach is intended to provide only a lightweight identity as an alternative to social logins. Think news sites, forums etc, not email providers or banks. They will continue to have their own login forms (passwords, 2FA tokens etc).