[AIP-61][Discussion] Keyless accounts

[alinush]

AIP Discussion

Currently, the only way¹ to secure your Aptos account is to protect the secret key (SK) associated with it. Unfortunately, this is much easier said than done. In reality, secret keys are often lost (e.g., users forget to write down their mnemonic when first setting up their Aptos wallet) or stolen (e.g., users are tricked into revealing their SK). This makes onboarding users unnecessarily difficult and drives users away when their accounts are lost or stolen.

In this AIP, we describe a more user-friendly approach for account management that relies on the unmodified[^openpubkey] OpenID Connect (OIDC) standard and recent developments in zero-knowledge proofs of knowledge (ZKPoKs) of OIDC signatures²$^,$³$^,$⁴$^,$⁵$^,$⁶.

Specifically, we enable keyless accounts on Aptos that are secured through the owner’s existing OIDC account (i.e., their Web2 account with an OIDC provider such as Google, GitHub or Apple), rather than through a difficult-to-manage secret key. In a nutshell, “your blockchain account = your OIDC account”.

An important property of keyless accounts is that they are not only bound to the user’s OIDC account (e.g., [email protected]) but are also bound to a managing application registered with the OIDC provider (e.g., a dapp’s dapp.xyz website, or a wallet’s mobile phone app). In other words, they are application-specific accounts. As a consequence, if the managing application of an account disappears or loses their OIDC provider registration credentials, then users whose accounts are bound to this application will become inaccessible, unless alternative recovery paths are provided (discussed below).

Read more about it here:

• Full AIP-61 text : https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-61.md
• AIP PR

Footnotes

1. There are alternatives to single-SK accounts, such as multisignature-based accounts (e.g., via MultiEd25519 or via AIP-55), but they still bottle down to one or more users protecting their secret keys from loss or theft. ↩

2. https://github.com/TheFrozenFire/snark-jwt-verify/tree/master ↩

3. https://github.com/sehyunc/nozee ↩

4. https://www.risczero.com/news/bonsai-pay ↩

5. https://github.com/emmaguo13/zk-blind ↩

6. https://docs.sui.io/concepts/cryptography/zklogin ↩

[davidiw]

• Under security, this link is broken: https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-61.md#Security,-Liveness-and-Privacy-Considerations -- didn't dig into figure out why
• A resolution to a lost service is to use alternative backups such as mnemonic based keys, t-out-of-n keyless accounts, or passkeys.... this is a unique selling point of Aptos which is not highlighted in the AIP.

[alinush]

• Fixed the typo
• Will add the 2nd bullet to my TODO

[daoauth]

I am a developer eager to see WebAuthn implemented in keyless as soon as possible. Although the AIP considers WebAuthn, the actual implementation only includes Ed25519. Could this be due to the support for secp256r1? Additionally, I would like to propose extensions for WebAuthn. Would it be appropriate to continue with this here, or should I create a new AIP? I believe WebAuthn is the key to unlocking the remaining potential of keyless accounts.

pub enum EphemeralPublicKey {
    Ed25519 {
        public_key: Ed25519PublicKey,
    },
    Secp256r1Ecdsa {
        public_key: secp256r1_ecdsa::PublicKey,
    },
}

pub enum EphemeralSignature {
    Ed25519 {
        signature: Ed25519Signature,
    },
    WebAuthn {
        signature: PartialAuthenticatorAssertionResponse,
    },
}

https://github.com/aptos-labs/aptos-ts-sdk/blob/57630ebc488026c0eca4eb410a2f51386ff6855a/src/types/index.ts#L121

[alinush]

Hi @daoauth, sorry for the late response. We already support WebAuthn! See the AIP here and feel free to discuss here.

[daoauth]

I am a developer eager to see WebAuthn implemented in keyless as soon as possible. Although the AIP considers WebAuthn, the actual implementation only includes Ed25519. Could this be due to the support for secp256r1? Additionally, I would like to propose extensions for WebAuthn. Would it be appropriate to continue with this here, or should I create a new AIP? I believe WebAuthn is the key to unlocking the remaining potential of keyless accounts.

Thank you for the great news. I will actively use it.