Currently all strings of the library are represented with Text, but that doesn't take into account that some fields of the WebAuthn spec have additional requirements for such values, specifically
Relying Parties SHOULD perform enforcement, as prescribed in Section 2.3 of [RFC8266] for the Nickname Profile of the PRECIS FreeformClass [RFC8264], when setting name's value, or displaying the value to the user.
When inherited by PublicKeyCredentialUserEntity, it is a human-palatable identifier for a user account. It is intended only for display, i.e., aiding the user in determining the difference between user accounts with similar displayNames. For example, "alexm", "alex.mueller@example.com" or "+14255551234".
The Relying Party MAY let the user choose this value. The Relying Party SHOULD perform enforcement, as prescribed in Section 3.4.3 of [RFC8265] for the UsernameCasePreserved Profile of the PRECIS IdentifierClass [RFC8264], when setting name's value, or displaying the value to the user.
Relying Parties SHOULD perform enforcement, as prescribed in Section 2.3 of [RFC8266] for the Nickname Profile of the PRECIS FreeformClass [RFC8264], when setting displayName's value, or displaying the value to the user.
The DOMString type corresponds to the set of all possible sequences of code units. Such sequences are commonly interpreted as UTF-16 encoded strings [RFC2781] although this is not required.
Nothing in this specification requires a DOMString value to be a valid UTF-16 string. For example, a DOMString value might include unmatched surrogate pair characters. However, authors of specifications using Web IDL might want to obtain a sequence of Unicode scalar values given a particular sequence of code units.
The USVString type corresponds to the set of all possible sequences of Unicode scalar values, which are all of the Unicode code points apart from the surrogate code points.
:warning: Specifications should only use USVString for APIs that perform text processing and need a string of Unicode scalar values to operate on. Most APIs that use strings should instead be using DOMString, which does not make any interpretations of the code units in the string. When in doubt, use DOMString.
This means that Haskell's Text is really USVString, however USVString is only used for the rpId field and extension inputs, everything else uses DOMString. This might be tricky to solve, because the aeson library uses Text underneath for strings.
Special string handling
Currently all strings of the library are represented with
Text, but that doesn't take into account that some fields of the WebAuthn spec have additional requirements for such values, specificallynamedisplayName:DOMStringvsUSVStringThere's also the problem regarding
DOMStringandUSVString, both of which are currently represented asText:DOMString:USVString:TextThis means that Haskell's
Textis reallyUSVString, howeverUSVStringis only used for therpIdfield and extension inputs, everything else usesDOMString. This might be tricky to solve, because the aeson library usesTextunderneath for strings.