Re: [webauthn] Add considerations for string truncation. (#1205)

> Although I understand allowing it, I'd suggest saying instead:

Done.

> The comment about grapheme clusters is okay, but I would suggest referring to one of our references.

Happy to take suggestions about what to reference here.

> The text about "understanding string encodings and Unicode character properties" might be better as just "understanding character encodings".

Avoiding truncating a grapheme cluster would require Unicode property tables, I think?

> I'd recommend the use of UTF-8 explicitly. Imposing additional checks, including the check for isolated surrogate code points, seems like overkill.

Webauthn doesn't require the use of any specific authenticator transport and Chrome already supports transports that use UTF-8 and UTF-16LE, so we can't require UTF-8. However, UTF-8 will be common and we need to ensure interoperability. It might be the case that eliminating surrogate code points in UTF-8 is so obvious that it's redundant to specify it here, but it wasn't completely obvious to me. On the other hand, if one writes UTF-8 with surrogate code points to an authenticator, Chrome will not interoperate with it because it considered that to be invalid UTF-8. Thus the desire to highlight that aspect of the UTF-8 spec.

> I don't know how to square replacing "any partial code point at the end with U+FFFD" with the fact that U+FFFD is a 3-byte sequence.

This is platform behaviour in the face of a truncated encoding. Some decoding libraries will replace invalid code point encodings with U+FFFD.

-- 
GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1205#issuecomment-488723603 using your GitHub account

Received on Thursday, 2 May 2019 15:41:23 UTC