FIP: Auth Addresses

[varunsrin]

FIP: Auth Addresses

Title: Auth Addresses
Type: Implementation FIP
Authors: @v, @horsefacts , @sanjay

Abstract

Introduces auth addresses, a new key type in the Farcaster Key Registry that allows an Ethereum address to authenticate on behalf of a Farcaster user. This enables secure, multi-client access for users with smart wallets or multiple devices, without sharing custody credentials.

Problem

A user’s custody address holds their fid and is used to authenticate using Sign in With Farcaster into apps that rely on Farcaster identity. If a user wants to use multiple clients, they copy their EOA seed phrase into the the other app and can use it simultaneously. This breaks down when clients start using smart wallets where there is no easily transferrable seed phrase.

Specification

Introduce a new concept, auth addresses. Auth addresses are Ethereum addresses which are allowed to sign in on behalf of a Farcaster user. Until now, this could only be done by a custody address.

A custody address can add any Ethereum address as an auth address to the Key Registry. A new key type will need to be added to the registry to allow for this. Once this is performed, all apps performing Sign in With Farcaster should accept a signature from this address as valid for the associated fid.

A custody address can also revoke an auth address at any time. Apps must ensure that the key is currently present in the registry before authenticating. According to the rules of the Key Registry contract, revocation is permanent.

Assume that Alice uses Warpcast today and wants to add Coinbase Wallet as another client. Coinbase Wallet generates an ECDSA auth address and an Ed25519 signer key. It then requests a single transaction which adds the auth address and the signer to the Key Registry. Once this is complete, Coinbase Wallet can use the auth address to sign into apps and the signer to sign casts.

Farcaster Connect FIP should also be extended to support requesting these key pairs.

Key Type	What it can do
Auth	Sign in with Farcaster to clients, mini apps, and third party apps
Custody	Transfer fid, change recovery settings, add/remove keys, change fnames, sign mini app metadata, plus everything an auth address can do

Rationale

• Should we allow these ECDSA auth keys to sign casts and messages?
  ECDSA signatures are ~10x slower to verify than the Ed25519 signatures we use today, which would create a bottleneck. A new client can ask the user to add an ECDSA auth key and an Ed25519 signer in a single transaction which minimizes any overhead for the user.

• Should auth keys be Ed25519 keys like signers instead of Ethereum addresses?
  FC users and developers have learned to treat ECDSA keys like they control money (keep client side and user controlled) and to treat Ed25519 keys like api keys (keep server side). This change requires users to treat some Ed keys like api keys and others like they control money, which causes confusion and doesn’t add any benefit over ECDSA keys.

• Should Farcaster users have a single wallet where each client has a signer?
  This has one major downside over the current approach which is that each wallet automatically has access to the user’s fid. The benefit of this approach is that auth keys can add signers and authorize other accounts.

Implementation

We can enable auth addresses with no changes or new deployments to the existing Farcaster contracts.

Key Registry

We will introduce a new KeyRegistry key type 2 that reuses the existing SignedKeyRequestValidator:

keyRegistry.setValidator(
  2, 
  1, 
  IMetadataValidator(address(0x00000000FC700472606ED4fA22623Acf62c60553))
);

The existing validator checks that keys are exactly 32 bytes. Since Ethereum addresses are 20 bytes, auth keys must be left padded to 32 bytes. This is the same convention used by Solidity abi.encode().

For example, the address 0xe36d2f95a9b69df60dbf029bf7c4fa7d1ff56b90 pads to 0x000000000000000000000000e36d2f95a9b69df60dbf029bf7c4fa7d1ff56b90:

➜ bytes memory authAddress = abi.encode(address(0xe36d2f95a9b69df60dbf029bf7c4fa7d1ff56b90))

➜ authAddress
Type: dynamic bytes
├ Hex (Memory):
├─ Length ([0x00:0x20]): 0x0000000000000000000000000000000000000000000000000000000000000020
├─ Contents ([0x20:..]): 0x000000000000000000000000e36d2f95a9b69df60dbf029bf7c4fa7d1ff56b90
├ Hex (Tuple Encoded):
├─ Pointer ([0x00:0x20]): 0x0000000000000000000000000000000000000000000000000000000000000020
├─ Length ([0x20:0x40]): 0x0000000000000000000000000000000000000000000000000000000000000020
└─ Contents ([0x40:..]): 0x000000000000000000000000e36d2f95a9b69df60dbf029bf7c4fa7d1ff56b90

Constructing signature metadata for auth keys remains the same as for key type 1: the requesting app or entity provides a typed signature over their fid, the key bytes, and a deadline timestamp.

Snapchain

Snapchain will automatically ingest Key Registry events for the new key type and store auth keys by fid. We'll need to expose new APIs to retrieve this data.

Sign in With Farcaster

Update Sign in With Farcaster to accept signatures from both FID owner or auth address.

Relying parties may choose to accept SIWF messages signed by auth addresses in addition to custody addresses.

To verify a SIWF message supporting auth addresses, the relying party must:

1. Attempt to verify the message as an auth address signature:
   1a. Verify the SIWF message as a SIWE message. If valid, continue to 1b. If invalid, proceed to 2.
   1b. Call KeyRegistry.keyDataOf(signer FID, padded auth address)
   1c. Ensure this call returns KeyData(KeyState.ADDED, 2). If so, accept the signature. If not, proceed to 2.
2. If auth address verification fails, verify the message as a custody address signature according to current SIWF verification rules.

Relying parties that accept an auth address signature must also accept a custody address signature.

See the reference implementation in auth-client for an example.

Clients and third party apps

Warpcast will extend the existing "signer request flow" to enable auth key requests and batched auth key + app key requests. The existing Bundler contract can add multiple keys at registration time.

Apps using third party auth tools like Privy will need to update to allow authentication from auth addresses.

Applications that read or depend on Snapchain events may need to ensure they correctly handle new events with keyType=2.

Apps that provide SIWF as a service should allow clients to opt in to auth key SIWF signatures.

Considerations for clients and developers

• Apps requesting an auth key should ensure they correctly pad the address to exactly 32 bytes.
• Revoking an auth address is permanent according to the rules of the Key Registry. Apps and users should be careful when adding and revoking auth addresses. Apps should make it clear that auth keys are unlike verified addresses, which can be added and removed at will.
• Transferring or recovering an FID will not automatically revoke its auth keys (just like transferring an FID does not automatically revoke its signers). Users who purchase or receive an fid from an untrusted party should first verify that its auth addresses are revoked.

Release

See Auth Addresses Implementation.

Appendix: FAQ

• Should auth keys be able to add signers?
  This would be ideal, but not possible in the onchain Key Registry. We plan to move key management to snapchain this year so we could move it when that happens.
• Can one auth address be added to multiple fids?
  Yes, and in fact this may be desirable for some use cases, like shared accounts.
• Should this replace verified addresses?
  A verified address is an Ethereum or Solana address that is provably controlled by the user. The proof is established by counter-signing a message with a user’s signer and the address being verified. This allows any app to be able to verify addresses which poses a slight security risk but has a simpler UX since it allows signing from web browsers. It’s not clear that we should deprecate these yet at least until using wallets from browsers becomes easier.
• Should we support Solana addresses?
  In theory, this should be fine since apps can verify any arbitrary signature. In practice, it may mean a little more overhead for the app developers. We assume for now that all auth addresses are Ethereum addresses.

[sidrisov]

if auth address is added, does it mean people don't need to use Sign in with Farcaster, but simply go with Sign in with Ethereum?
or at least SIWF library checks if user has added auth address and suggest to auth through a wallet instead without a need to communicate with relay server.

This would definitely make life easier on desktop.

[varunsrin]

SIWF is just a wrapper around SIWE to make requesting signatures and delivering them to apps easy. The core auth always came from a SIWE signature.

[vrypan]

This is a very elegant solution, V!

What will a custody addr be able to do that auth addrs won't? (except add/remove auth addrs and I guess (?) set the recovery address)

[varunsrin]

• transfer fid
• set recovery address
• add/remove things from the key registry (auth addrs, signers)

[vrypan]

I think the UX would be better if an Auth addr could remove itself. This is the case where an app wants to offer a "Revoke access to farcaster" feature (which apps should offer, imo), without using an other app.

[vrypan]

Will there be a corresponding OnChainEvent for these addresses?

[varunsrin]

only if snapchain needs to be aware of them. as of now, it doesn't.

[horsefacts]

there would be standard KeyRegistry events for the key adds, though.

[vrypan]

Oh, ok, this is what I was looking for.

[andrei0x309]

Looks ok, basically this will allow smart wallets to do SIWF, but won't be limited to smart wallets, anyone could use to enable SIWF for other EOA in theory, probably there should be some limits, like MAX 5-6 Auth addresses(add/delete), and since this AUTH address has high security, there should be an additional contract on OP, don't see why signers would need to be on OP and this would not.

Either signers will also be moved on FC network, otherwise, if signers will not be moved from OP, then this should also sit on OP, the implementation of such a contract should be pretty simple, but will also require synk from hubs like is now with signers, preferably for lower cost OP is ditched and you have an explorer and signers and auth signers would be part of FC network, at that point also a public explorer should exist, to be able to view such actions like adding/removing signers at least for a certain timeframe 1 year or something.

[manan19]

It then requests a single transaction which adds the auth address and the signer to the Key Registry

Are both keys registered as a single atomic entry? i.e. approval seems to be atomic but will the revoke also be atomic?

Not keeping the revoke atomic will result in the need to handle the edge case where one is revoked but the other is still approved.

[horsefacts]

I don't think atomicity matters here except for convenience. App keys and auth addresses can change independently.

[christopherwxyz]

I'm trying to understand the flow of success here. Hopefully I'm understanding it right.

Alice signs up for Uno but already has an account with Base app. Uno makes a request to add an auth address from Base using a signed typed message. Uno also adds a Ed25519 public key signer to the request. Uno sends Alice to Base. Alice authorizes with Base. Base adds the auth address using that EOA's public key and Ed25519 public key. Base sends Alice back to Uno. Alice is able to share with the network freely.

Critical requirements for an additional client would be:

1. Ability to add a signer.
2. Ability to revoke a signer.
3. Ability to transfer FID (e.g. if a client shutsdown or is compromised).
4. Ability to add additional auth addresses (i.e. self-recovery).

[vrypan]

Are Uno and Base two Farcaster clients? "Alice" is an other client used by user Alice?

(We need some standard names for these things, they are starting to become confusing, especially when we mix users, clients, wallets, frames.)

[christopherwxyz]

Yes Uno and Base are independent clients.

Alice is any user that wants to use a second client.

[andrei0x309]

Auth addresses are for something else and not meant for sign-up.

At the moment any address can sign up and add signers etc, relatively easily, with any wallet, the only requirement is for the wallet to not already own an FID.

Concepts 3 and 4 are beyond words, because the user must be in control of FID at all times, for example, the first thing I did was to switch my recovery from the Merkle proxy contract to my own controlled address, and transfer can be done only by custody address.

A client doesn't even need the custody account like Warpcast does, whenever it needs the custody key it could just forward the TX/sig request to the user-preferred wallet, which can be any EVM wallet, forcing the custody key in Warpcast wallet was "for better UX" at the cost of decentralization.

At the moment, the custody PK is used in these scenarios:

1 User adds or removes a signer
2 User would transfer FID( not the case because no clients have that feature)
3 User would sign in with farcaster ( here is the purpose of this Auth Key FIP)
4 User would change his recovery ( again no client provides that can be done using wallet)
5 Potentially in the future for access to DMs( again also related to this FIP)
6 Is also used to generate Warpcast auth token but this was a client choice and does not relate directly to protocol as it wasn't a necessity and the auth mechanism could have been different once the client is in control of a signer auth mechanism can be anything you want
7 It is also used more recently in JFS as a mechanism of signing JSON, with custody key, not particular useful without adoption but is used to associate domains of frames with FIDs

Hope this info helps you.

[varunsrin]

@christopherwxyz your description is generally right. i'm not sure i understand what exactly you mean by the last section. Are you saying that Base (which has the custody / fid) needs to guarantee this? Or that Uno (which has the auth address) should be able to do this?

Critical requirements for an additional client would be:

Ability to add a signer.
Ability to revoke a signer.
Ability to transfer FID (e.g. if a client shutsdown or is compromised).
Ability to add additional auth addresses (i.e. self-recovery).
3 and 4 are challenged because we don't want users to get their FIDs rugged? Trying to understand the hesitation.

[christopherwxyz]

@christopherwxyz your description is generally right. i'm not sure i understand what exactly you mean by the last section. Are you saying that Base (which has the custody / fid) needs to guarantee this? Or that Uno (which has the auth address) should be able to do this?

Sorry, my notes. Forgot to remove before commenting :)

[ericbrown99]

For mini app devs, can the Auth Addresses also be used to sign the farcaster.json file?

[andrei0x309]

Technically, it can.

I don't know if it makes sense or not, it would complicate things a bit because you would also have to change the manifest of the mini app to specify what address was used to sign, so you can verify.

It's possible, but IMO having ownership of the FID for a mini app is not a big ask, you can make a dedicated account for any app anytime, a FID can be in any wallet as long as it doesn't already have one.

This Auth address FIP is mainly for SIWF.

[ericbrown99]

Got it. Some additional context:

We've found that most devs aren't creating new FIDs to build mini apps, especially during the exploration phase. They use the FID they already created when they signed up on Warpcast.

We've also found that, in addition to the friction of exporting private keys, existing devs are very wary of exporting their custody account's private keys to another wallet in order to simply build a mini app.

This means that as of today, developers are centralized to using Warpcast dev tools unless they're willing to and comfortable with export their keys.

This has led to a lot of developer confusion and Auth Addresses is an opportunity to solve this problem and provide significantly improved DevX for builders while also allowing for decentralized developer tooling that isn't tied to any client.

[andrei0x309]

Great, I agree.

If it helps, then I think it should be added.

I want to add that any web3 dev should be able to handle their own keys.

In fact, I think Warpcast not allowing people to use their own wallet to sign up and creating an additional account is a disservice to web3 natives.

At this point, if you want to own the fid with a specific address, you can only have these avenues:
1 Sign up with a client that allows you to use your own address(not too many such clients)
2 Sign up using Warpcast and then transfer your FID to the preferred address
3 Write your own Tx to sign-up

It is not safe to keep your seed in an app or wallet. First thing, after you have a seed, is to store it somewhere encrypted, so in case of app/wallet failure due to any reason, you don't lose access.

Like I said, if you feel this is important, I can write a proposal for you to see if it goes anywhere.

Technically, this modifies other parts of the stack that aren't directly linked to the protocol; this is more of a mini-app feature request.

[compusophy]

any sense in auto-expiration? just handle that on the SIWE side?

concerned that most users have don't know how to revoke existed signers and are accumulating long tail risk

would like to give my warpcast auth address a 30-day approval to SIWF on my behalf

[horsefacts]

Sub-proposal: Reinstatable auth addresses

Problem

An undesirable property of the design above is that auth address revocation is permanent according to the rules of the Key Registry contract. Each key added to the registry must be unique and can only transition from ADDED to REMOVED, and never back.

This means revoking an auth address has permanent consequences. For example, if a user revokes their auth address corresponding to Warpcast Wallet, they would permanently lose the ability to sign in to mini apps on web. This is not great!

Proposal

Use the high bytes of the 32 byte padded auth address to encode a key "index" along with the 20 byte Ethereum address.

Instead of 12 empty bytes of padding, we can instead define an auth address as a numeric index plus 20 byte address:

concat(12 byte index, 20 byte address)

or in Solidity:

bytes.concat(bytes12(uint96(index)), bytes20(address(authAddress)));

For example, the auth key for index 1 and horsefacts’s Warpcast Wallet would be:

0x000000000000000000000001e36d2f95a9b69df60dbf029bf7c4fa7d1ff56b90
  |-----12 byte index----||-----------20 byte address------------|

SIWF messages could then provide this index in a farcaster://signer/auth/<index> resource or elsewhere in the message:

https://example.com wants you to sign in with your Ethereum account:
0xe36d2f95a9b69df60dbf029bf7c4fa7d1ff56b90

Farcaster Auth

URI: https://example.com/login
Version: 1
Chain ID: 10
Nonce: djyP0B2JUD8RFuI3J
Issued At: 2021-09-30T16:25:24Z
Expiration Time: 2021-09-30T16:35:24Z
Resources:
- farcaster://fids/1234
- farcaster://signer/auth/1

Relying parties can read the index from the resource and reconstruct the auth key to verify the message. To reinstate a revoked auth address, the user or requesting app may increment the last index to generate an unused unique key.

We don't necessarily need to do this now: we can extend the existing proposal above with this design at any time. In a sense, the currently implemented verification uses an implicit “index zero.”