Rules for IDN (punycode) handles in applications

[drash-course]

This is a parallel discussion to bluesky-social/social-app#7043 "Add support for IDN (punycode) handles" in the Bluesky app.

ATProto describes how to deal with IDN (punycode) handles, but leaves the choice of how to display them up to the applications. @surfdude29 pointed out that a discussion may need to happen at the protocol level to decide how this should be handled. In particular, how does the protocol and applications share responsibility on how to deal with / mitigate IDN homograph attacks.

For example :

1. The de-facto web position : it's up to user-facing apps to filter what they deem problematic, and each app has their own strategy and implementation. ATProto treats handles uniformly as ASCII and plays no part. Ultimately, it's the responsibility of registrars to avoid such cases.
2. ATProto will define the security goals and non-goals for the protocol and for applications. Applications that wish to display IDN handles will follow the goals prescribed, can ignore non-goals, and will come up with their own implementation.
3. ATProto will prescribe a specific implementation that applications should use to decide which handles are "safe" to be displayed in their unicode forms, and which handles are "unsafe" and must be displayed in their raw punycode form.

Option 1 would be the simplest (nothing changes in today's specs) and the most web-like. It may cause some apps to display a subset of handles in unicode form, while other apps display those handles in punycode. It leaves apps with the most freedom, (a) deciding if they want to support IDN handles or not, (b) defining the security goals / non-goals for themselves, and (c) maintaining their own mitigations for IDN homograph attacks.

Option 2 has ATProto take responsibility for (b) defining the security goals / non-goals for IDN handle support. It leaves up to applications (a) deciding to support IDN handles or not, and (c) writing the specific implementation to meet the goals outlined in the spec. If Bluesky (the app) decides to support IDN handles, their implementation can serve as a de-facto reference implementation for (c).

Option 3 is the most burdensome for ATProto, taking on both the (b) and (c) concerns. I don't think this is optimal for security though, given that you need to give some leeway to applications to respond quickly to new threats. The upside is that if you have a very solid implementation, it can be the most secure option. You can also start with option 2 and move to option 3 later when you feel it would be beneficial.

Hopefully my rambling wall of text makes some sense, and ATProto can position themselves on the options or come up with a better strategy.

[bnewbold]

I think to some degree we'd like to defer this even higher up to social web best practices. Eg, I think the best venue for this discussion would be an IETF "best current practice" (BCP) document, or a W3C recommendation document. Which would complement or deprecate earlier work on this subject.