kadena-io
Create KIP-0023: Account management with Passkeys
Abstract
We propose to use WebAuthn signatures as an alternative option to the current ED25519 signatures to allow users to approve for transactions processed through Chainweb Node and Pact smart contracts.
Motivation
WebAuthn allows for users to use a hardware powered device to store keypairs securely. Users will be able to interact with those stored keypairs only by initiating a sign request from the registered web domain. The private key never leaves the device and the user never enters a password. This brings the user more security and convenience simultaneously.
In comparison to current wallets, the wallet developers have no access to the private keys. The user does not have to write down their mnemonics or even enter their password to decrypt their privatekeys.
edit 2024-08-06: Updated the design to use r:accounts. This allows us to replace the need of 2 complex smart contracts with just a single straight forward table holding credential pair and leverage the existing security features of an r:account. This allows other smart contracts to interact with accounts governed by SpireKey with no additional code as this is no longer governed via a smart contract.
How would the recovery flow look like in case I lose access to the hardware device that I authorized?
How would the recovery flow look like in case I lose access to the hardware device that I authorized?
This is a problem that used to exist with "pure webauthn". With the arrival of Passkeys, we are able to use 3rd party key storage to handle those keys. By default users will use their respective OS provided storage, i.e. Google/Apple's solutions, but users can opt in for 3rd party storage like Bitwarden or Lastpass.
Additionally the smart contract can register multiple devices, which would allow for example a backup yubikey to be stored safely in a vault.
Couple of questions/concerns/thoughts on this subject.
I have a slightly different idea/use case for integrating this as on chain multi-factor with a multisig key. In the sense I'd like to be able to generate smart wallets in multiple ways. The first way is for twitter users to hit interact with our bot and do #RegisterWallet, I'm handling the wallet generation and mapping it back to twitter oauth. The second is simply using pact+JS to generate as I am today. Then with this webauthn, we could register multiple devices(like a business approval workflow use case), so it requires 3 sigs to execute a stored transaction. Is there any harm in approaching this as a solid MFA that's on chain and we can handle registering devices through a portal linked to the wallet?
The second thing I'm still trying to wrap my head around is recovery services and how people are potentially exposed in batches from a breach. That part is still a bit hazy to me and of course, will need to be well covered/documented by each project that supports this.
I'm excited to see where this goes, definitely want the ability to use something like yubikey to store a backup key. There are secure services that offer products to help vault yubikeys, might be worth trying to bring one of these into the ecosystem?
@daplcor
Couple of questions/concerns/thoughts on this subject.
I have a slightly different idea/use case for integrating this as on chain multi-factor with a multisig key. In the sense I'd like to be able to generate smart wallets in multiple ways. The first way is for twitter users to hit interact with our bot and do #RegisterWallet, I'm handling the wallet generation and mapping it back to twitter oauth. The second is simply using pact+JS to generate as I am today. Then with this webauthn, we could register multiple devices(like a business approval workflow use case), so it requires 3 sigs to execute a stored transaction. Is there any harm in approaching this as a solid MFA that's on chain and we can handle registering devices through a portal linked to the wallet?
The WebAuthn generated public keys can be used in keysets, i.e. you could create a keyset consisting of:
{ "keys" :
[ "webauthn-key-a"
, "webauthn-key-b"
, "webauthn-key-n"
...
]
, "pred" : "keys-2" // or any other pred like a self implemented pred that requires 33% of keys to sign or 3 or whatever your requirements
I think from your backend you could perform a local call with preflight=true to validate if certain capabilities can be brought into scope (i.e. 3 sigs have signed) to assert "consent" and if you want it to be logged, send the tx and use the tx hash as token? Something along those lines. I have not played with this idea too much, so take it with a grain of salt.
The second thing I'm still trying to wrap my head around is recovery services and how people are potentially exposed in batches from a breach. That part is still a bit hazy to me and of course, will need to be well covered/documented by each project that supports this.
I'm excited to see where this goes, definitely want the ability to use something like yubikey to store a backup key. There are secure services that offer products to help vault yubikeys, might be worth trying to bring one of these into the ecosystem?
So yubikeys should be supported by this standard right out of the box. Their backup system is then working as per their specification. With regards to how Google, iCould or BitWarden stores the keys in the cloud is not something I've researched (yet). I believe for most users those services are good enough, specially if used in combination of services/multi devices.
If I understood Yubikey's solution with Hashicorp's correctly, it allows for a similar setup to the Google/iCould/Bitwarden but then stored on a private server. If that understanding is correct, it implies that the storage of such vaults can be extended by other parties in the future without impact on the implementation proposed.
