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.

Kirby digesting all of those caloric attestations to deliver a self-sovereign aggregated identity.

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.