Recovery of G Accounts with Passkeys (aka G Account Signer Replacement with Contract)

[leighmcculloch]

I propose we make it possible to link a contract to a G account as a signer admin, allowing the contract to replace an existing G signer on the G account with a new G signer.

Context:

Contract accounts on Stellar are fully customisable, but wallets get access to more of the ecosystem today with a G account.

One type of functionality that some wallets want to adopt is passkeys, and specifically, the recovery processes available to pass keys on modern phones where they get backed up to Apple and Google accounts. However, to adopt passkeys is to adopt a contract account and step away from everything the ecosystem has only for G accounts.

In the past we’ve discussed the possibility of a C account being a signer for a G account. The problem with that being that the contract runtime must execute arbitrary logic during preapply checks.

G accounts can have up to 20 signers. The signers can be a variety of types, but the most common are G keys. Each signer must be sponsored with a reserve amount of XLM.

How would it work:

Wallet deploys contract that can replace the signer on a G account. The contract functionality is gated with a passkey for auth.

Wallet links the contract to the G account.

Wallet moves to a device key model, where it uses not the master key for the G account, but an additional G signer that lives only on the wallet instance / device. The device key model is the same type of model used in SEP-30.

When the wallet needs to recover access to the G account, it:

• randomly generates a new G device key signer
• engages the passkey to authorise the contract to replace the signer on the G account
• submits the tx

The wallet now has access with a new device key.

Why:

• To enable fully independent G accounts that utilise a contract for signer management, allowing recovery of G accounts using passkeys.

• The G account can be used independently for ordinary usage.

• Contract account is leveraged just for what it's really useful for in this case.

• A variety of customised recovery options can be innovated on without coupling to the problem of C account adoption as a primary wallet account type.

• The problem of who needs to sponsor the new signer does not need to come into play as long as the rule is that replacement of the signer reuses existing sponsorship. It allows wallets to use sponsorship or not, without sponsorship needing to be a complexity on the contract side and keeps the contract side complexities of implementation to a minimum.

[marcelosalloum]

IIUC, the proposal is to make a C-account the signature admin of a G-account, being able to replace the master signer of a G-account.

In the past we’ve discussed the possibility of a C account being a signer for a G account. The problem with that being that the contract runtime must execute arbitrary logic during preapply checks.

I'm taking it from this paragraph that we cannot make a C-account one of the signers, is that correct? In that case, is it an option to enable secp256k1 public keys as signers?

[marcelosalloum]

🤔 using secp256k1 directly would not enable this part though:

A variety of customised recovery options can be innovated on without coupling to the problem of C account adoption as a primary wallet account type.