(>’-’)> Kirby
a single-line web3 abstraction and bottom-up identity solution
Problem
First, identity is an unsolved problem in blockchain. Most organizations aim to solve it with a top-down solution. We are finding that identity seems to form in “pockets” in the web3 space and a top-down overarching identity solution doesn’t seem to be the right approach.
Second, onboarding is rough. A user must download an extension, have ETH, understand gas, etc. We need a way for users to start interacting in a cryptographically backed fashion on page load with no prior knowledge. Finally, when they are incentivized to upgrade their security, they should have a web3 provider that best suites them.
TL;DR: I’m helping Civil and Consensys build a web3 abstraction and bottom-up identity solution for the Ethereum ecosystem that developers can incorporate in their website with a single line of code. You will get instant onboarding, web3 provider optionality for their users, and super simple attestation signing/verifying/aggregating. I need your feedback!
Instant Onboarding
With a single line of code, a developer can bring in the Kirby package. On page load, an ephemeral key pair (burner!) is generated inside a child iframe for a user and the developer can begin signing messages and storing/validating off-chain attestations. This system could also be used to sign meta transactions for on-chain interactions.
Logging in with Ethereum will as easy as kirby.sign(“login message”)
The end user won’t need ETH, won’t have to understand gas, and will be in full control of their identities and how they relate. They will use an Ethereum key pair to cryptographically sign a message. Then, when the user is ready to upgrade their security, they can choose from providers:
Web3 Provider Optionality
Many different web3 providers are emerging in the Ethereum ecosystem and we need to allow users and developers the optionality to choose which is best to suit their needs. First, we will use something like eth-provider to detect if they already have a preferred injected web3 provider. Then, we’ll check cookies for any stored preferences. Finally, we’ll revert to web3connect:
The web3connect package allows us to bring in all major providers including MetaMask, Portis, Fortmatic, Wallet Connect, etc. After using the default ephemeral key pair, a user can “upgrade” their security to a web3connect provider. An attestation would then be signed to connect the two accounts and a record is added to the DID identity store.
Bottom-Up Identity
It is important that identity is created on a per-service basis first and connections/permissions can be built up and owned by the user.
To this end, the identity servers or attestation storage system will need to be distributed; many different organizations can run their own or we could even put it in 3Box! At first we will probably default to a single instance, but developers and users will have the ability to select where their identity exists.
These DIDs are used to associate accounts with each other but also provide authentication and verifiable credentials. It’s paramount that the user owns their own data but can give permission to an organization like Civil to build aggregate identity on top of groups of claims.
Simple/Powerful Web3 Abstractions
Our goal is to provide an EIP1193 compliant web3 ethereum-provider to the developer, but also a handful for easy-to-use abstractions for signing, verifying, sending tokens, watching for events, and general smart contract interactions.
Architecture
This one-line package will bring in a child iframe that can communicate through the postMessage interface. There are a couple packages that demonstrate how to make web3 interactions through iframes and we will use them as reference implementations. Civil has also written some code that might help.
Inside the iframe we can route requests in three different ways:
Validation/DID
If the developer is wishing to authenticate, validate an attestation, or authorize an organization, it will load from the ID server/storage.
Reads
If the request is a simple web3 read, this can go directly to Infura or other web3 infrastructure.
Writes
If the request is to sign or send a transaction, the ephemeral key pair will be used at first. As the user upgrades, these requests will be passed to their chosen provider from web3connect.
Packages
You’ll notice in our repo that there are a number of extensible packages with the following architecture:
Of course, initially, a developer will just be bringing in the SDK and calling functions on it, but eventually, you can start thinking about adding your own branding and functionality to the child iframe itself.
First Implementation
The first implementation in the wild will be by Civil. The Kirby SDK allows Civil to provide a consistent web3 experience to any of the publishers on their Registry.
Security
It is important that the third party website (parent iframe) doesn’t have full access to Kirby (child iframe). The ephemeral key pair will be stored in local storage, so if multiple sites are using Kirby we will have to create an authentication scheme to prevent any cross-site attacks.
When talking with RicMoo he mentioned that the parent should probably bring the child in with some sort of auth token in the url. I think this probably has something to do with Content-Security-Policies. Still researching!
Private Key in Local Storage!?!
Yes! We are keeping an ephemeral “signing” key in local storage. This is an obvious attack vector but we believe that instant onboarding is worth it. The private key will only be used to sign attestations and won’t hold any value. It can even be burned or removed from a user’s identity if they so choose. The goal is to give a user a method to cryptographically prove their actions and to control their own data on page load without any previous knowledge of Ethereum.
Once a user has earned value or created a narrative behind this insecure key, they will upgrade to a better form of signing and burn the ephemeral identity. These “burner” key pairs will always be created on page load like a session and the user has full control of linking ephemeral actions to their colder identity.
Open Source & Open To Feedback
This document is incomplete and we are open to any and all feedback on how to correctly implement this to be as effective as possible for the Ethereum ecosystem.
My hope is that a new developer could bring in one line and have a simple “sign in” system as a hello world. Their users would be instantly onboarded with a key pair, have the option to upgrade, and be connected to Ethereum.
Please reach out directly to @austingriffith on Twitter or Telegram!
Our code repository is: https://github.com/joincivil/kirby
THANKS FOR THE GREAT ADVICE FROM:
Pedro Gomes, Moody Salem, Brian Ethier, RicMoo, Pelle Braendgaard, Rouven Heck, Jonny Howle, Matthew Iles, Dan Kinsley, serapath, Jordan Muir, and of course @Mitch_Kosowski#GreatestTraderOFALLTIME💪😎
