Looking Forward — SocialKYC
self-owned, trustworthy social account credentials…now what?
Written by Paul Pomerleau — Developer Relations at BOTLabs GmbH, the company that initially developed KILT Protocol.
SocialKYC recently launched. In short, it’s a service that lets you get credentials which validate that you own various social accounts. Right now that means email and Twitter…although I hear rumours that Discord and GitHub are coming soon. Cool, so I have these credentials, why not just use my account directly? Because by using credentials to prove your ownership of an account you protect your data, break data silos, increase trust, portability and value.
Protect Your Data
When you share your credential, you can decide not to disclose the details. This is called selective disclosure. For example the Clan KILT raffle asked for email or Twitter credentials to trust you’re not likely to be a bot. This is enough, so it doesn’t need to know your details. But it could ask for opt-in disclosure (it doesn’t, but it could) in order to count the entries that are also registered to the newsletter or follow @KILTProtocol. This puts you entirely in control and whatever you choose, no trust is lost.
Websites typically ask for email and password, but what happens if the database gets hacked? Data stores from multiple sources get compromised, hackers build data sets over time and build more complete pictures of you, the mark. But do sites really need email and password? The email often serves as a persistent identifier, and the password proof of ownership. With SocialKYC we can use credentials to ensure requirements, and leverage DIDs and server side secrets to generate site unique user ids. Services would get a persistent identifier unique to the user, proof of ownership and as a bonus, added trust if they want by verifying additional credentials. And if this database gets compromised? If data is a hacker’s ammunition, this just gives them blanks.
In recent years “sign-in with XYZ” has provided both developers and users convenience for signing up and signing in. What happens here is that you allow a third party access (if enabled) to your XYZ account. But you also allow (if enabled) data from the third party to feed back to XYZ. Now yes there’s more concern with user privacy these days, and yes for the most part services are compliant with giving users choice to share or not. But these are businesses and their business is data… your data, and you’ve ever tried to navigate user agreements and privacy settings, choice and data protection isn’t exactly at the forefront of the UX. SocialKYC does exactly that, it puts choice and data protection at the forefront of the UX. A service will use sign-in with XYZ because they trust their registration process. With SocialKYC none of that trust is lost but the data feed between the two parties is severed. Congratulations, your data is free.
SocialKYC credentials are just trust transferred from other accounts… so same trust right? Maybe for one credential, but not so for many. “A single twig breaks, but the bundle of twigs is strong. — Tecumseh”. How much would you trust that the owner of an email address is human? Now how much would you trust that the owner of an email address, Twitter account, GitHub account and Discord is human? But it goes further, what if you need to know that the owner is an employee? What about requiring disclosure of corporate email, GitHub and public Twitter. The system could verify the email domain, check the GitHub username and for good measure make sure the employee is following the corporate Twitter before authenticating. Then using some DID hash identifier (or some better approach), the user can get a session and the disclosed details used for authorization are discarded.
The utility of your socials increases as credentials for two reasons, portability and economic leverage. Social web2 credentials aren’t inherently portable. Right now, where can you use your Twitter? Twitter itself of course, then with services that integrate sign-in with Twitter. In other words it’s limited to a small subset of web2. Credentials on the other hand… simple maths. Okay not so simple maths. But it can be used anywhere you can prove ownership of the DID via cryptographic proof. Yes we need tools to manage these handshakes, but anyone can build them for any of our social worlds. Brick and mortar yup, web2 check, web3 sure, metaverse absolutely. Online, offline, off-chain and on. The identity is yours, it goes where you go.
When you consider a social network with a central data silos… who gets the economic value and leverage? They do; of course they have the data. With SocialKYC who has the data? You do; So who gets the economic value and leverage? Exactly. Business, employers, nonprofits… all these entities don’t want to connect with the social network, they want to connect with YOU. But the network has your data, so connecting with it is the next best thing. So these entities pay the data silo to run their algos and hope to reach their intended demographic. With SocialKYC they don’t have to hope, they can verify, and instead of paying the silo for the right to push unwanted ads, they can offer you the value. And you can seek them out based on your wants and needs and form a real relationship. Conversion rates, click-thru rates, views and shares are good, cash-in hand, real ROI and lifelong customers are better.
I can imagine web2 login alternatives for easy data compliance, email sign-in at local membership clubs with discounts for social followers, e-sports tournaments based on university emails, corporate email smart locks, value driven advertising and a million other things we haven’t thought of. So now what? Who can say, but I’m optimistic and the possibilities are endless. Now it’s up to us the decentralised community to build it to its needs. Check out our community Trello workspace to find inspiration, vote and discuss ideas: join our Discord, a DAO-inspired community, focused on outcomes and impact. We meet every Friday to mobilize, educate, inspire and build. KILT Protocol is purpose built for identity and credentials; an infrastructure layer for trust, and it’s yours to shape…time to claim independence.