[CAIP-122] Why only ASCII?

[yaronf]

The statement element is restricted to ASCII only. This is strange because this element is supposed to be displayed, and there are huge communities of users who interact in languages that do not fit into ASCII. Moreover, any IETF standard that specifies user-visible messages must allow for standardization.

I understand the security problem with Unicode Homoglyphs. But I don't think it really applies here, and in fact the social engineering implications of a free text element are much more severe than that.

[ukstv]

@yaronf CAIP-122 is a multi-chain successor to EIP-4361, with explicit statement about i18n:

After successfully parsing the message into ABNF terms, translation MAY happen at the UX level per human language

The real reason is that having multiple languages opens up a can of worms wrt to particular wording in national languages. It adds to the struggles of adoption (dictionaries per language, using a language field to validate a signed message), and adds little to the end goal: having a SIWx prompt properly localised in (add by) a user's wallet.

[yaronf]

I see where this solution is coming from, thank you. But IMHO, this replaces small complexity on the service side with large complexity on the wallet side, which is now expected to translate an arbitrary free text prompt into the user's language. It also opens up interesting threat models.

The "standard" solution would look like:

   "statement-en": "English text",
   "statement-es": "Spanish text"

with the wallet picking its local language if available, or a default one. This could even be backward compatible with existing solutions by adding these elements. (Language tags are standardized of course.)

[kdenhartog]

Yeah, unfortunately EIPs don't have any sort of i18n horizontal review so this wouldn't have really been considered about if what's described is the right approach. To date, most wallets just display the statement that's sent over by the site so if the site chooses to address i18n solutions then it will work otherwise the wallets aren't going to do translations and thereby not address the concern.

I see your point, and ideally this should have been addressed, but given much of the web3 communities are new to standards development processes they'll likely just have to relearn why this horizontal processes exist in most other SDOs.

Luckily I don't believe EIP-4361 nor CAIP-122 have been finalized so let me see if they'd be open to modifying it so that this can be handled via the server side since they are the one who produce the statement that's displayed in the wallet anyways.

[bumblefudge]

PRs welcome?