Message Summary Received on First Week

• webauthn lacks a lot of support currently in the frontend stack. In order to create this in-a-box platform, you’re going to have to write a decent amount of custom code in order to even support and sign webauthn transactions. You won’t be able to use existing wallet abstractions at this point in time to do that signing.

I am willing to work on this even if there are no established libraries I can use. I will try to make the most of webauthn and eosjs-ecc libraries. Perhaps I can disect some signing code in the middle and insert the part from the webauthn somehow. We’ll see. Anyway, I will document my progress and dead-ends I get to.

• The security of the box itself also need to be rock solid, with no attack vectors present. The server itself should not be hosting any private keys to automatically sign transactions on behalf of the accounts under control of the custodian, or it’ll create a tempting target for any malicious actor who may realize what that server is hosting.

I totally agree. No private keys should be anywhere near this project, not at the server, not encrypted, not in any form or shape. The private keys are in a secure hardware module on the user’s phone, that’s what webauthn is all about. The other keys belong to the website owner and are his responsibility and will be on his wallet of choice, not on the server. The server doesn’t automatically sign anything. It just coordinates passing transactions around between the new user wanting to create an account and the web site owner who creates the account for them. Only public keys are passed between them.

• It’s been said the users onboarding this way have to have implicit trust in whoever runs the box, but they’ll also have to implicitly trust the UI itself as well. When signing webauthn transactions, there’s no verification step to ensure you’re signing the transaction you intend to sign. You have to trust that the website UI itself is telling you what its signing when you go to approve it. If the UI itself is modified/hacked/changed by owner, the end user may have no idea and could be convinced to sign any type of transaction without realizing it.

The website owner will not make a malicious change to the website to trick the users, the users are trusting him, these should be family and friends, not strangers. There will be text explaining that prominently displayed on the mini website. The other potential issue is with a third party changing the website to something evil. I don’t know what to say. Perhaps someone from the community wants to chime in? What if there is a third party tool that the user can send the requested transaction to view it in a human readable format before signing?

• The migration between the webauthn onboarded experience and a real wallet won’t be simple. There’s no protocols (yet) to easily request a key from an external wallet and inject them into a web UI like this. The user will have to generate the key pair(s) in an external wallet and somehow relay them to the box. The owner of the box will then need to issue the transaction to allow the user to migrate off the box and into a self-custody solution.

Initially the creation of a webauthn account will be manual as well. The user will send a message to the website owner requesting him to create an EOS account with his chosen account name and public key created by the webauthn, so migrating out / graduating to a “regular” EOS account simply means asking the website owner to replace the webauthn public key with another public key created on another wallet. And possibly changing the owner key too while they’re at it.

• There’s no interoperability at all for the users who were onboarded into a box-environment. The only app they’re going to be able to use is the box’s UI, they won’t be able to interact with EOS in any other way until they migrate to a real wallet. They will be at the mercy of the box operator and the interfaces it provides.

Yes, that is correct. Ease of use has its costs.

• There are also concerns about legal/regulations - which we may not care about but is good to highlight for people considering running a box of their own. Whoever is running the box, and has those owner keys to those accounts, may in some regions be the legal custodian of any tokens deposited/withdrawn from the accounts onboarded through the box.

Interesting, I have no knowledge of the legal implications. I would argue that these accounts are for easy onboarding for family and close friends and they shouldn’t put their life savings there, just some pocket money to experience what EOS is all about. The site owner just keeps control of the owner keys for recovery purposes since webauthn doesn’t have a way for you to regain access to an account if your phone is broken or stolen, nothing more.

The EOS-in-a-Box project is not intended for commercial use. I don’t want it installed on a website server managing a million accounts or even one thousand. I think this is more suitable for 25 people and should be installed on many sub domains. The website owner will need to manually create the accounts for his small circle of trust and he will pay for the initial resources in EOS. The new users can of course pay him but that will be out-of-band, meaning they can pay in cash or by any other means they want. This project will not have integration with credit cards or any such service. I don’t want to even collect emails and phone numbers or names of the users creating the new accounts. They can have a somewhat anonymous experience, other than the fact that they are publickly tied to the website’s owner account via the owner key.

Thanks to Aaron Cox of Greymass for most of the points discussed above.

After a week, here is the plan

It is subject to change and I will write weekly updates.
The idea is to use cycles of 2 weeks where every 2 weeks there will be a new version with additional features and capabilities.
Each cycle will start with a short internal planning of the cycle, followed by coding and near the end of the 2 weeks cycle, there will be time for testing and stabilizing.
If course there will be shorter cycles in between but these are internal and not so public.

The github repository is called eosinabox and is open from the start, but not always up to date with my latest code. Don’t expect much in the first few cycles, it will be ugly and that’s on purpose. I want to focus on the mechanics of it.

The code is open source and MIT licensed so anyone can take it and modify it and call it their own if they want.
The plan is on the README file of that repository and I am copying the initial draft here for reference. It will change and the changes will be updated in the repository, not here.

Some things might accelerate while others will be delayed. I probably forgot some important aspects and will include later, for example:

1. PWA features like “Install to Home Screen”
2. Some type of reporting to the site owner if all is well, and if any API is always failing to respond.
3. Global error handling which will report to a centralized server, with the option to opt out or in, not sure which should be the default. Perhaps initially the default should be that any installation reports errors unless the site owner specifically turns this off and switch to the opposite later on.
4. Some type of rate limiting, to protect the server from harrassing the blockchain API nodes
5. Again, alert the site owner and perhaps the central error handling about suck a situation.
6. Share and share target to make it easier to send and receive transaction requests to be signed. Perhaps that is too risky if the user doesn’t understand? Maybe add a screen explaining before presenting the fingerprint signing.

So here is the dev plan, copied from the README:

Design principles

• Simple code, less layers between code and the website owner, no need to be an expert in:
  • typescript
  • react
  • route libraries
  • esoteric css compilers
  • Database
• No database, not saving user’s name nor email nor phone number,
  • No backup needed
  • No private info needs to be kept secure
  • No GDPR or other regulatory compliance needed
• Warn website owner in README and on the front page of the site, and warn the user requesting an account with the help of the website owner
• Warning should include: Don’t put a large sum of money in tokens on this wallet, you might lose access forever.

Plan (will be fine tuned as time progresses)

Week 1-2

• define requirements and capabilities and order of development in broad lines
• start implementing and git push, so there is something to show on github at the end of each 2 week cycle
• dead simple hard coded config, input fields and buttons, jQuery front end, simple backend
• proof of concept, check account name, taken or available
• user wants to create a new keypair using webauthn? do it!
• check on server if valid attestation
• perhaps if account exists, ask user if this account is managed by the site owner?
• perhaps have a simple PIN so only friends of the site owner have access? PIN in a setup file on the server?

Week 3-4

• allow the user to transfer EOS using the mini website as a wallet
• allow transfer of any “standard” token
• “share” feature, send to web site owner the info - account name and pub key and what the user wants, either create a new account or change keys since user changed phones.
• split flows to:
  • I want to create a new account
  • I want to regain access to my account with a new phone
  • I want to add another phone to my account, so either phone can be used (future)
  • I want to add another phone to my account, so I will need to approve a transaction from both phones (future)
  • I want to logout, please forget my account on this phone
  • I want to transfer EOS to another account
  • (future) sign any transaction (wallet capabilities)

Week 5-6

• beautify with react & some css
• use sockets for push notification from server to phone
• streamline the pages
• continue implementing the features from the previous cycle

Week 7-8

• integrate with eospowerup.io ?
• integrate with EOS block explorers? several?
• config json with different chains, let owner customize the site
• integrate with EOS wallets to make it easier for site owner to create accounts and replace active keys to help users regain access
• define recommended standard msig owners, perhaps with delays? some without delays to cancel unstaking and replace keys to help user save his account from attacker
• continue implementing the features from the previous cycle

Relationship between WebAuthn and Blockchain

WebAuthn is relatively new, Apple supports the technology for less than a year now. Android was an earlier adopter and many modern phones have the hardware required for the whole system to work. Biometrics data is not shared with the server, it stays on the phone’s special hardware which creates key pairs bound to specific website domains. The private key never leaves the hardware which is separate from the regular computer of the phone. It is limited to only send out the public key or create signatures using the private key.

EOSIO chains and EOS in particular have a powerful set of permissions. The minimum and not recommended way to create an account is to use a single keypair for both the activ and owner permissions. Let me backup a bit and explain in my own words the concepts involved. I think the names of the keys is not ideal. A better model would be an email address and a password. You tell everyone your email address and keep the password safe. If your password leaks, someone can pretend to be you and send email on your behalf. In the blockchain world, if someone knows your private key they can send the coins out of your account.

EOSIO has 2 sets of keys and locks, the owner is the one with all permissions and is unrestricted. With it you can do anything including sending coins out of the account and changing locks. The active key can do everything except for changing keys. It is recommended to use the active key for everyday actions and keep the owner key offline in a more secure place.

EOSIO lets you also use other accounts as owner or active permissions, time delays and a group of several keys with a minimum threshold to make an action. So for example, I can set up my active key to require a minimum of 3 and have this list of keys:

+1 mydad@active
+1 mymom@active
+1 mybrother@active
+3 myPublicKey

So I can do anything on my account as usual or if I’m in a coma, my father mother and brother can get access to my money. But that is not very reliable, what happens if one of them loses their keys? I need to add more people to allow for some flexibility. Maybe add:

+1 mytrustedlawyer@active
+1 mybestfriendforever@active

But too many people is also not so good, what if some of them collude to steal my money? I can set up a combination of permissions that will use time delay with the other people so I will have time to cancel and change the keys before it is irreversible. How about adjusting the minimum threshold to 5:

+1 mydad@active
+1 mymom@active
+1 mybrother@active
+1 mytrustedlawyer@active
+1 wait 7 days
+5 myPublicKey

There are better combinations, I will write about it later.

Webauthn is a very convenient way to manage keys and there is a cost to this convenience. It is tied to me obviously, to the specific phone I’m using now - not my phone number and to the specfic website domain name. So we can have a mini site template package which is easy to deploy to any web server and it will never handle private keys, the website owner and admin will tweak teh appearace of the site to make it his own and fill some technical details like his EOS account and/or the owner public key for the people he invites. Once the invited friend goes to the website, the web site will ask the user’s phone to create a new key pair which will prompt the user to put his finger on the reader or use faceID. Then the phone will create a new key pair, store the private key in the secure hardware and send the website the public key. The website will make some checks that are recommended in the Webauthn standard to make sure the public key it received is actually coming from a biometric hardware ssytem on the phone and if all is well, it will create a new account for the user with the user’s chosen account name, the active key will be the webauthn public key and the owner key will be the website’s settings. The website owner pays for the 3KB RAM needed to create the account and sends some EOS so the account is not empty. The website owner and the new account owner can exchange USD or any other legacy coins between them outside of the website. No need to complicate this with credit cards/PayPal or anything else since they know each other in real life and trust each other.

Now the user has a first citizen EOS account if the mini site acts as a wallet and can handle requests for signing by the UI or using special HTTP GET messages with some parameters. The mini site will ask the phone to sign the hash of the transaction, the user will confirm with his biometrics and the website will take the signature and turn around to the blockchain nodes, and send the transaction with the signature where the blockchain will verify and approve the transaction.

If the user loses their phone or it gets stolen, the user needs to ask the website owner for help in regaining access through a new phone. There will be a process similar to opening a new account where the webauthn asks the user to create a new keypair on the new phone and the website owner, will be able to change the public key for the user.

The user may elect to leave the system and graduate to an independent account with other key management system, the website owner can once again help by approving replacing the keys to whatever the account owner wants.

If I made any inaccuracies, you know how to reach me, Ami Heines, also for the more advanced EOSIO experts, what prevents such a system to work with any EOSIO chain, even without enabling WEBAUTHN_KEY?

Repurposing the eosinabox name for something better

I was elected the “leader of the board” by a random number generator, so I got the 2000 EOS funding. I plan on using that to create a minisite template which will be easy to deploy on a web site domain.

Each website owner will be need to be experienced in crypto wallet, specifically on EOSIO. Should be comfortable with knowing the difference between the owner and the active permissions and why it is a good idea to keep these separate. The website owner will be able to invite people who trust him to open a new EOS account using their phone on the website using just their biometrics - their fingerprints or faceID.

Behind the scenes what will happen is that the website will interact with the user’s phone using webauthn so the phone will create a new key pair on the secure hardware in the phone. The User’s phone doesnot send any biometric data to the web site, just a new public key. The website will create a new account on the EOS main net (and this can easily be changed to any other EOSIO chain). The newly created account will be paid for by the website owner, 3KB RAM which is needed to open an account is currently less than 0.1000 EOS or less than $0.40 USD. The user can then verify that the account actually exists using any blockchain explorer. The Active key will be the public key created by the WebAuthn process and the owner key will be the active key of the owner of the website or in a more advanced setup, any combination of additional users, public keys and time delays.

The new account owner will be able to sign transactions using his fingerprint or faceID and will enjoy the convenience of not needing to take good care of any secret keys. The dreaded 12 word list on paper will be spared from him.

If/when the user loses access to his phone, either it is broken, lost or stolen, no one else can access his funds since they need his biometrics too. In order for him to regain access to his account, he buys a new phone and asks the website owner for help in changing the active key to his new phone’s WebAuthn created one.

Need to elaborate on the possible schemes for the owner keys, perhaps a group of friends can have several such sites and a 3 out of 6 of those web site owners can help any member of one of the websites to regain access to their account.

Another risk is that the way the WebAuthn standard works is that the key pair is tied to the domain name. If the website is not accessible, all the users who enjoyed the convenience of an EOS account through that site are locked out. They need the help of whoever controls the owner key to change their active key to something else.

In conclusion

This will be an interesting additional option to help on-board new users. The tradeoffs should be obvious to any one who chooses to participate. Perhaps there will be a smart contract with “approve that you read the agreement” but it should be minimal and more aligned with a recadian contract clause and not the traditional sign up forms where a fairy dies every time someone clicks the checkbox next to the words: “I read and agree to the terms and conditions of this website”. Perhaps something along the short and informal lines:

1. I personally know and trust the owner of this website
2. Convenience comes with risks, I will not blame anyone if/when I lose my cryptos