rp.name, user.name and user.displayName length limit does not state binary encoding

[emlun]

The definitions of PublicKeyCredentialEntity.name and PublicKeyCredentialUserEntity.displayName state that

Authenticators MAY truncate a name member’s value so that it fits within 64 bytes [...]

and

Authenticators MUST accept and store a 64-byte minimum length for a displayName member’s value. Authenticators MAY truncate a displayName member’s value so that it fits within 64 bytes. [...]

but do not state what binary encoding the 64 byte limit applies to. Both reference § 6.4.1 String Truncation which states that

[...] truncation SHOULD also respect UTF-8 sequence boundaries or grapheme cluster boundaries [...]

so presumably UTF-8 is intended, but again this is not explicitly stated - just that the truncation should respect UTF-8 considerations. CTAP2 explicitly states that UTF-8 is used, but not all authenticators use CTAP.

In fact IDL DOMStrings are explicitly sequences of 16-bit code units, which are more naturally represented by UTF-16 or UCS-2. So it could be argued that the length limit of name and displayName varies depending on what encoding the authenticator happens to use. This makes it practically impossible (in theory, even if in practice most probably (?) use UTF-8) for an RP to determine if a user input is likely to be truncated or not.

Proposed Change

The length limit for PublicKeyCredentialEntity.name and PublicKeyCredentialUserEntity.displayName should explicitly state the binary encoding the limit applies to. For example:

Authenticators MAY truncate a name member’s value so that its UTF-8 encoding fits within 64 bytes [...]

and

Authenticators MUST accept and store a displayName member’s value whose UTF-8 encoding is 64 bytes or shorter. Authenticators MAY truncate a displayName member’s value so that its UTF-8 encoding fits within 64 bytes. [...]

[Firstyear]

Seems like a reasonable change to me :)

[aphillips]

The I18N WG discussed this in our teleconference of 2023-12-14 and has promoted this to a "needs-resolution" item. We agree that the description of truncation needs to clarify about the character encoding (not just the length).

The discussion of truncation in the current document appears to assume UTF-8 and that would be appropriate to specify, if it were limited to (say) a JSON file. However, it is possible to interpret the authenticator's length restriction to mean some sort of local storage in some arbitrary encoding.