DAP spec open to impersonation via use of UTF-8

[aparkersquare]

I think there is a high risk for impersonation of DAPs if the handle and domain can use arbitrary UTF-8.

Restricting the handle to ASCII would preclude the use of "real names" for a very large percentage of the world's population.

Similarly, the domain part of a DAP should support practical domains, which already support IDNs

How can the DAP spec be changed to help mitigate these risks?

[aparkersquare]

punycode is one (partial) solution to these types of issues for domain-name spoofing.

Consider this DAP @jack/cash.aрр, which uses cyrylic characters to impersonate a CashApp domain name. When converted to punycode this shows as @jack/cash.xn--a-5tba, exposing the impersonation.

Can the DAP spec be limited to ASCII, and apps use punycode to convert customer-entered DAPs to punycode?

This still relies on the converted punycode to be displayed to the customer (this is done in the address bar for domain-names). I'm not sure there is an equivalent for DAPs.

[aparkersquare]

For reference, see ENSIP-15: ENS Name Normalization Standard for how Ethereum Name Service attempts to combat this.

Note that ENS uses namehash to convert the name to a hash, and the hash would be different given an attempt to impersonate a known name. See #43 where I suggest using a visual representation of a hash of the DAP (or the resolved DID), which might function similarly. Perhaps we need to consider both these issues together.

[aparkersquare]

I just noticed the DAP spec does mentioned control characters being disallowed

https://github.com/TBD54566975/dap#local-handles

Character Exclusions: The local handle must not include unicode control characters or punctuation characters.

I'm not sure if that mitigates the risk fully.

[aparkersquare]

Some other considerations for impersonation

• similar looking characters (even with just plain ascii) depending on display font
  • e.g. 0 / O and l / 1
• lower/upper case
  • "jack" / "Jack"