Sovereignty of Identity - A Primer
The continuous emphatic design endeavour has made internet usage synonymous with convenience. Somewhere in this process of enabling platform adoption, the Web2 dev community came across Single Sign-On - a way to ease logging into platforms. While this made onboarding convenient, it also gave centralized identity providers immense grip over user data, and web3 is trying to change that narrative by providing better onboarding and more control.
Single sign-on is a method of logging in that lets users enter their login credentials (username and password) just once and automatically be logged into multiple websites or applications. Single sign-on is one element of identity and access management (IAM), which is the entire set of tools and protocols governing how users log in and access data.
The most widely known customer-facing example of single sign-on is Google’s G Suite. Users log in to their Gmail accounts and are automatically logged in when navigating to Google Docs, YouTube, or any Google service.
SSO is a part of the broader concept of federated identity management, which allows someone to use a single identity across multiple systems. SSO refers specifically to a single login giving users access to multiple properties that are still part of a single organization.
Social login, also known as social sign-in or sign-on, uses social networking sites to facilitate logins on third-party applications and platforms. The process simplifies sign-in and registration experiences, providing a convenient alternative to mandatory account creation.
1. Facebook: Facebook Login provides a balance of convenience and privacy. While organizations using Facebook Login ultimately decide what information they request from users, Facebook’s review process requires that developers provide users with a large number of permission customizations. With these permissions, users can control the degree to which they share various types of information with third-party organizations.
2. Google: Google Sign-In allows users to access other websites with their Google accounts. There are almost 4 billion people with Google accounts today, making it compelling for devs to include ‘Sign-In With Google’. Developers can access the user’s public profile, age range, and friend list and have the ability to read and write to the user’s public feed. Users can customize the information they share during authorization. Still, Google’s social login solution currently doesn’t allow for subsequent alterations without disconnecting and re-authenticating it with each third-party website.
3. Apple: In 2019, Apple introduced a new way to sign up for accounts in apps and websites, called “Sign in with Apple.” Every time one signs in with Facebook or Google, their personal information is shared so that companies can track anywhere else they might be using it. The data includes the user’s email address, profile photo, and name. If it’s a Facebook login, a site may ask for even more, including your birthday, page likes, photos, and friends list.
Apple claims that it shares as little information as possible, collecting just the username and email address and that it does not track users’ activity in an app or website. Also, when one signs in using the Apple button, they get an option to create a disposable email address so that they never share their actual email address with the app or website. The user can choose to forward emails on the disposable ID to their primary Apple ID and can also revoke access at any point.
Why Use Social Sign-On?
Social media usage is not slowing down anytime soon, nor is the use of SaaS apps and services. It’s safe to assume that more and more vendors will be opting for social logins.
Streamlined sign-up: Third-party web page logins via Facebook or Google accounts typically involve clicking just a few buttons. This creates a much faster path to access sites and apps than filling out registration forms.
Less password reliance: The idea of remembering yet another password puts users off registering for additional sites. Social login means users don’t have to create and keep track of more credentials, lessening password fatigue and login failures.
Service Provider’s PoV
Smarter user improvements: When users choose social login options for various applications, organizations gain access to data from multiple stores, which helps to create a more comprehensive customer profile. Site owners can analyze data from that platform to establish user preferences and create customizable user experiences and build features that are in demand.
Increased verification: Social login provides an additional layer of verification to confirm that access attempts are from real and trustworthy users. This type of authentication also requires confirmation from the chosen social platform, incorporating yet another line of defence against spam or otherwise harmful logins.
Free to implement: Integrating social media logins means using APIs for each corresponding social platform, like Facebook Login and Google+ API. While some APIs limit the resources that third-party apps can use without paying, it’s typically free to use these APIs and support a range of social logins.
But convenient as it may be, there are security implications. Hence, it may be wise to supplement it with multi-factor authentication (MFA) to stay on the safe side and keep user data safe. A good security line would include using Two-Factor Authentication(2FA) services like Google Authenticator, Microsoft Authenticator and Authy and using password managers like LastPass or 1Password to manage multiple passwords securely.
1. Privacy & Compliance: Sign-in options include tracking scripts that allow websites to add valuable features like share buttons and enable social logins. But the scripts often double as trackers meant to record site visits and build profiles of users. Trusting all of your login information to a single company doesn’t feel like the best idea because its susceptible to attacks—like back in 2018 when Facebook disclosed a breach of 90 million accounts.
Also, it might become difficult for users to retrieve their profiles on platforms where they’ve used social sign-on but have stopped using or deleted their profile on the sign-on service provided, i.e., deleted account on Facebook or moved out of the Apple ecosystem. Interestingly, users might still be feeding their data to these platforms even after they’ve stopped using their service. Thus, having centralized identity providers isn’t the ideal way out here.
2. Siloed Identity: One of the most under-utilized concepts of Web2 is ‘Context’. Even though users’ data is stored and tracked in great propensity, the corporations tracking them can only leverage it. This, in turn, leads to multiple parties running after this precious data in the name of ‘personalization’. There is little to no community effort and collaboration to bridge these pockets of collected data and help build better and seamless onboarding experiences for users, i.e., minimizing the effort of recreating their whole identity or parts of it when they choose to shift or explore new platforms.
Social Sovereign Identity - A Dream in the Making
Social Sovereign Identity (SSI) is the promise of a better internet. It’s about users owning their data and having the ability to selectively, in specific contexts, and under their control, allow services and partners access to their data.
SSI has multiple aspects, ranging from enabling control over data to providing contextual data. The broader idea is that identity should be contextual online – that one can offer different pieces of information to prove who they are in different situations. Under such a system, many issuers would create identity attestations, and service providers or users could choose which to accept depending on the need and the correct type of data that would prove helpful. It would create something like a free market for identity verification without interfering with the use of “strong” forms of identity like government ID.
This would improve the quantity and quality of that data and the quality of goods and services. SSI also chips in to solve problems like misinformation where there is a broader cryptographic hallmark, similar to that of Twitter’s verified mark, that signals the authenticity of a profile, essentially differentiating them from fake profiles.
Fluid Payments is something blockchain systems like Bitcoin have been long working on. SSI makes them even more robust. When combined with SSI, smart contracts would not only ensure fulfilment of the contract between two parties but also provide the means to verify that the parties on both ends are the same responsible and trusted people with an accumulated social reputation they’re claiming to be.
The World Wide Web Consortium (W3C), a body for web standards founded in 1994), is currently evaluating Decentralized Identifiers(DIDs) as a candidate recommendation, meaning the forum is considering recognizing these identity frameworks as an international standard.
Sign-In With Ethereum (SIWE)
Spruce Systems, co-founded by former ConsenSys staffers, which won a recent development RFP(Request For Proposal) from the Ethereum Foundation and Ethereum Name Service, is working on ‘Sign-In with Ethereum’, which is an open standard for authentication on the Ethereum blockchain. This will allow users to use their Ethereum accounts to access web services instead of accounts owned by large corporations.
Web services such as OpenSea and Gitcoin have already taken a step by allowing users to establish sessions with their Ethereum wallets, achieving low friction and passwordless authentication all at once. By standardizing this workflow, millions of Ethereum users will use a digital identity that they fully control to access the web seamlessly.
Sign-in With Ethereum would enable users to use the service on Web3 but also Web2 platforms and also understand what information the Web2 service needs to verify and from which sources to complete the sign-in process.
While Web2 service hosts can integrate the service through authentication aggregators like Auth0
Also, platforms like Twitter, actively integrating aspects of Web3 as part of the sign-in process, can retrieve and verify claims presented by the user and aggregated by ENS, such as Web3 account balances and NFT ownership W3C Verifiable Credentials, and more.
Sign-In with Ethereum (EIP-4361) defines an open creative commons (CC) signing format for Ethereum accounts to securely authenticate with any web-based services.
EIP-4361 defines a standardized format using the augmented Backus–Naur form (ABNF) for these authentication messages that can be verified by the service you want to log into. The format follows the EIP-191 specification, which is already widely supported by many wallets. Logging in does not require a password; simply sign the message with your private key, and you’re done. The server can verify the message and generate a key to store it in a cookie.
EIP-4361 integrates with the Ethereum Name Service (ENS). If an address has a primary ENS name (also called a reverse record) set, a service could look up this primary ENS name and resolve data based on it. You could, for example, store your preferred username, profile picture, email address, or other arbitrary information in your ENS name.
This keeps you in control of your data and removes the need for web2 services to store this information about you. This could lead to a future where using authenticated, signed EIP-191 messages to log into authentication-gated apps is the standard, doing away with email/password combinations entirely.
Talking about privacy, the biggest concern with ‘Sign-in With Ethereum’ is the reuse of identifiers. What this essentially means is that if the same wallet addresses are used on a variety of DApps, including social, financial and other - they might lead to the disclosure of financial transactions of the user; as all transactional activity is stored on the blockchain and is available for public scrutiny thanks to block-scanners like Etherscan. This is a nightmare for privacy maximalists.
As more people are being onboarded to Web3, they need to be educated about the idea of using multiple or disposable wallets as a security measure. But, this is too far a promise to expect onboarded users newly with glowing curiosity and no standardized educational material to take such precautionary measures.
Spruce’s approach is about achieving appropriate information flows, not necessarily absolute confidentiality. They’re actively exploring newer ways to use privacy tools, such as using newly derived Ethereum addresses on a per-interaction basis or incorporating zero-knowledge techniques to reduce correlation.
The idea of SSI is not limited to Ethereum only, and other protocols are also working on them. While there is still a lot left to be built, here are some examples of protocol trying to contribute to this cause:
Tezos Profiles is a means to associate real-world public credentials with your Tezos account. This is specifically geared towards public credentials, or what a user wants to put out there into the public and what they already currently demonstrate publicly. These are essentially being issued as verifiable credentials linking to a user’s Tezos account, stored in a solution called Kepler.
Starting with basic profile credentials (ex., an alias, description, associated website, etc.), these were self-signed and self-attested from the user side regarding the validity of the information used. Moving on from basic profile credentials, Twitter verification has been introduced, requiring users to sign a message with their wallet and tweet a specific message. This proves that the user controls the Tezos account when the tweet is introduced.
Adding verification to Instagram account and public messaging accounts such as Telegram and Discord for artists is next on their list.
Microsoft ION on Bitcoin
Microsoft’s Decentralized Identity team has launched the ION Decentralized Identifier (DID) network on the Bitcoin mainnet. This network is a layer 2 technology similar to Lightning except that instead of focusing on payments, it uses Bitcoin’s blockchain to create digital IDs for authenticating identity online.
Open to the public after being in closed beta since June 2020; ION uses the same logic as Bitcoin’s transaction layers to sign off on identity. A public key and its associated private key verify that a user owns an ID. Any personal data (name, age, etc.) tied to that ID is stored off-chain, depending on the service. ION’s IDs are anchored to Bitcoin’s blockchain using the InterPlanetary File System (IPFS) protocol, and ION nodes can process up to 10,000 ID requests in a single transaction.
Users can create and manage multiple IDs with different keys for different services. Some of these may be used recurrently to log into services that users access daily, including email and social media, or could be used in one-off ways such as verifying concert or event tickets.
While the dream of achieving Social Sovereign Identities and more social, emphatic and communicable tribes is still far fetched, it’s a promising and optimistic start.
Stay informed in just 5 minutes
Get a daily email that makes reading crypto news informative. Have fun keeping up and getting smarter.
The dispatch is sent in time zones at 8:30 am. Choose your preferenceEastern Time Zone (UTC-05:00)USTISTGMTSST