FIP: Associate FID to domain

[Hmac512]

Title: Associate FID with Domains - Implementation FIP

Authors: @eulerlagrange

Note: This proposal is still in the early stages and subject to refinement.

Abstract

This proposal aims to address the issue of potential impersonation and scams within the farcaster community by enabling domains to associate one or more FIDs with themselves. By doing so, users can clearly identify authorized representatives of specific domains. As farcaster continues to grow, the risk of malicious actors increases, and it becomes crucial to find a solution to this problem.

Problem

As of 07/27, the fname @metamask is available, leaving room for someone to register it and impersonate Metamask support. While a MM impersonation might be detected quickly, smaller projects might not have the same level of vigilance, making them more susceptible to scams.

Existing platforms like Discord, Telegram, and Twitter have not yet provided an effective solution to this problem within their UI. Usually you have to cross reference the identity you’re talking to with a web page or pinned message.

To mitigate this, the proposed FIP seeks to establish a verifiable bidirectional association between FIDs and domains.

1. The domain can associate with one or more FIDs.
2. A FID can sign a message to indicate their association with a domain.

Bidirectional association is crucial to ensure that a user's FID cannot be linked to an inappropriate or offensive domain without their consent.

Solution

Domain Side

The suggested solution involves utilizing the .well-known path to store a JSON object containing the associated FIDs for a domain.

Example JSON document hosted at https://eulerlagrange.com/.well-known/farcaster-configuration.json:

{
  "fids": [
    {
      "fid": 123,
      "role": "Support"
    },
    {
      "fid": 456,
      "role": "CEO"
    },
	...
  ]
}

The JSON object includes the following fields for each associated FID:

• fid: The identifier associated with the representative.
• assertion: A statement authorizing the domain to list the FID as a representative.
• role: The role of the representative (e.g., customer support, admin).

By using this approach, web3 projects can implement a secure method for verifying domain representatives, thus minimizing the risk of scams and impersonation within the community.

User Side (Registration)

A user who wants to be associated with a domain also needs to take some action. It's pretty much the example same flow as setting an ENS as your handle.

After finishing the screenshotted form, the client will make a request to /.well-known/farcaster-configuration to make sure that the domain config is setup correctly. Then a message will be signed and sent to the hubs.

Each hub can also resolve ~/.well-known/farcaster-config to make sure that the domain is registered correctly.

User Side (Client)

The clients can also locally verify the domain association is valid.

A simple mockup of what that would look like in the UI:

[Hmac512]

Instead of trying to generalize this proposal from the beginning, I am wondering if we can simplify the scope for a V1.

Adding a farcaster-config to .well-known has a lot of possibilities associated with it moving forward.

We can start out by just being able to search a URL, and being able to the see the accounts associated with it.

[varunsrin]

I like the idea a lot, agree with trying to identify the smallest possible v1 scope.

Perhaps the first goal should be - create a 1:1 association between a url and an fid that can be lazily verified.

[Hmac512]

I feel like the way to start is to:

1. Have the user sign a message saying they want to associate a domain to their FID, the client can verify the .well-known is setup correctly, but hubs do not.
2. Indexers will have to look for msgs from 1 and can check .well-known is accurate before they expose it over their APIs.
3. Frontend clients will always verify the .well-known path before showing anything in the UI.
4. If you search a domain, the client will fetch the .well-known and use the response to send the request for particular fids.

This is a weak form of association within the p2p system. Can be improved, but it avoids anything too complicated in the hubs. It is more of a UI/UX feature than anything else.

[gabrielayuso]

I'd prefer a solution that uses the DNS TXT record instead of URI to a JSON file. (Could support both).

Not everyone that owns a domain has it pointing to a server where they have control of the paths and files but all DNS registrars should support adding custom TXT records.

It should be easier for non-technical folks to buy a domain and google how to add the custom TXT record without even needing to point the domain to a web server.

[varunsrin]

I'd be supportive of this -- do you have a proposal for what TXT record should contain?

[alex-grover]

This is how the ENS DNS registrar works.

Is there a need for a more complex implementation at the protocol level at this time? Allowing a website to use ENS to make their handle the same as the website (eg @farcaster.xyz) will solve a lot of the impersonation issues and I’m not sure adding other arbitrary account representatives will help that much more.

[Hmac512]

For just domain ownership txt records are certainly better.

In the long run I think domains will want more functionality where a .well-known would make sense. It can be left until later though.

Will change to use txt records.

[vrypan]

I'm trying to understand if this will actually solve the problem (or which problem it may solve).

Let's take the example given in the FIP. User vitalik, posts a scam link to eth-merge.airdropp.it. They have linked their profile with the domain vitalik.eu. How does this help the average user?

On the other hand, we may have a user saying that they represent coca-cola. In this case, the association with coca-cola.com does indeed give them credibility. However, I think that in most cases, for large organisations, it is very hard to setup the association as described in the FIP. I think that eventually this association will be expressed by ENS subdomains just like it's expressed by corporate emails, so a more practical solution would be to allow ENS subdomains for usernames: if I use vrypan.coca-cola.eth, then you know I'm associated with the organisation (and they will revoke this association as soon as it's no longer valid).

[Hmac512]

For one, having a domain associated with an fid will make the UX better in some places.

The clients can support searching by domain, or deeplinking from somewhere else to open directly into a companies profile.

This proposal does not completely solve the issue of scams/impersonation, but it offers a simple UX to check some account is legit.

On Twitter it happened where people impersonate public companies to try and manipulate the stock price.

Lastly, there is a lot of room for more features down the line for fid->domain association. Like domain specific channels. It all starts with associating domains to channels.

I don’t think farcaster should be over reliant on ENS as only the web3 community cares about ENS. If you want to grow the network beyond web3 then we have to make it easier for normies to operate in the ecosystem.

[vrypan]

I'm not saying that it won't have some positive impact. I'm not even against it. I'm just trying to understand if adding this specific improvement is worth implementing a protocol change which will probably come with increased complexity, possible security issues and additional resources requirements for the hubs.

For example, requiring a hub to pull an arbitrary URL and parse it opens a potential security hole. It also introduces some dependancies (for example a DNS resolver) that hubs did not explicitly have until now. It will also add an element that is complex (because it interacts with arbitrary URLs) that will need constant support and updates and edge cases: HTTP retries? How many? For how long? Periodic checks? HTTP redirects? Other HTTP response codes? None of this is unsolvable, thousands of projects have dealt with it in the last 20+ years. But is the benefit worth it introducing all this to the FC protocol?

So, this is what I'm actually trying to assess: Is it worth it?

[Hmac512]

In this proposal I say that verification of whether the domain is setup correctly is done at the client.

I agree having hubs do it adds a lot of complications.

[vrypan]

Maybe I was carried away by the line that states hubs could also verify the association.

If it's something implemented by apps like Warpcaster, the impact is much lower and it's also up to each app to decide if they want to implement it or not and my arguments are much weaker.

However, if it was up to me to decide, I'd go with a web3 solution, even if right now the addressable audience is much smaller. After all, setting up FC requires a wallet which is also a barrier to entry for many users -but we expect that it will eventually get lower, don't we?

Again, if this is something to be implemented on the app layer, well, it's up to the app devs and it does not impact the protocol.

[Hmac512]

There is nothing preventing us from doing both the web3 and web2 versions of this simultaneously ;)

[horsefacts]

I'm very supportive of some form of domain verification. As the proposal describes, it mitigates spam and scams, and will be useful as we open up registration.

Given that FIP-4 fnames are ENS names, I think it might be a cleaner overall design to manage these associations at the name level, using ENS. It's definitely a valid concern that normies don't use ENS, but normies who use fcast.id fnames do. Here's one possibility.

Onchain Names

ENS supports importing DNS domains, using a TXT record as proof of ownership, similar to the verification approach suggested here.

The existing FIP-4 spec requires that L1 fnames end in .eth, but I think it should be possible to relax this restriction and allow domains registered with the ENS DNS Registrar, like farcaster.xyz, as fnames, so an account could appear as e.g. @farcaster.xyz or @metamask.io. Even without changes to the spec, it should be possible to validate ownership of an ENS-managed DNS domain as long as it's owned by a verified address linked to the account.

Pros:

• Minimal changes required to support verification.
• Inherit the security of ENS DNS imports.

Cons:

• Importing a DNS domain to ENS requires an expensive one-time L1 transaction.
• Some TLDs that do not support DNSSEC cannot be imported to ENS (link).
• Domains using DNS providers that don't support DNSSEC can't be imported to ENS and verified.

Offchain Names

Offchain names like @horsefacts.fcast.id could use one of the verification methods described above (I lean towards the TXT record design) to verify a domain association. Although these domains would not be imported to the ENS DNS registrar, we could follow a similar scheme. For example, to associate my domain terminally.online with my offchain fname, something like:

1. Set a TXT _ens.terminally.online a=0xabc123 record (this is the same format as the TXT record required to import a domain to ENS), where the address 0xabc123 is a verified address linked to my fid.
2. Sign a message from 0xabc123 authorizing the association and generate a digest sig.
3. Set a TXT xyz.farcaster.verified-domain terminally.online=sig record on the offchain ENS domain.

Steps 2 and 3 could be managed by the fname server.

To verify domain association for an offchain fname, clients would read the verified DNS domain from the ENS/fname TXT record, resolve the DNS domain and get the linked address from the DNS TXT record, and finally validate the signature against the linked address.

Pros:

• Mostly managed with offchain records.
• DNS record is similar to the ENS scheme.

Cons:

• Requires changes to the fname server to set TXT records.
• Requires changes to the fname resolver contract to resolve TXT records.

[jefflau]

Importing a DNS domain to ENS requires an expensive one-time L1 transaction.

ENS is close to deploying an offchain DNSSEC registrar, which would reduce this cost to 0. It's currently being tested on testnet