MSC4464: verifiable links in profile

[dozro]

Rendered

Follow-up for MSC4462

[turt2live]

Implementation requirements:

• Server
• Client

[DidiDidi129]

If it’s a work in progress should u mark as a draft for now?
Edit: Nvm I think it was a draft earlier but not anymore

[DidiDidi129]

I’m a little bit concerned that this would be used by bad actors for impersonation attacks

Eg they could spin up a homeserver without the requirements you outlined and make their profile link to any account they want.

[dozro]

I’m a little bit concerned that this would be used by bad actors for impersonation attacks

Eg they could spin up a homeserver without the requirements you outlined and make their profile link to any account they want.

@DidiDidi129 Since the verification is handled via the Client-to-Server (C2S) API rather than a Server-to-Server (S2S) protocol, the validation logic resides within the user's own homeserver.

Consequently, the security of this implementation relies on the integrity of the specific homeserver the user is registered with. While the trustworthiness of public homeservers is a valid point of discussion, the specific impersonation vector you mentioned, where a malicious actor spins up a rogue homeserver to affect others, is not feasible here, as their server would have no authority over the victim's verification process.

Note: Please use threads (reviews) for further technical discussions to keep the PR history organized.

[DidiDidi129]

I’m a little bit concerned that this would be used by bad actors for impersonation attacks

Eg they could spin up a homeserver without the requirements you outlined and make their profile link to any account they want.

@DidiDidi129 Since the verification is handled via the Client-to-Server (C2S) API rather than a Server-to-Server (S2S) protocol, the validation logic resides within the user's own homeserver.

Consequently, the security of this implementation relies on the integrity of the specific homeserver the user is registered with. While the trustworthiness of public homeservers is a valid point of discussion, the specific impersonation vector you mentioned, where a malicious actor spins up a rogue homeserver to affect others, is not feasible here, as their server would have no authority over the victim's verification process.

Note: Please use threads (reviews) for further technical discussions to keep the PR history organized.

Ahh yes that makes sense. Sorry for my comprehension issues lmao