Re: [webauthn] Fix #593 - Refer to RFC 8266 for RP-controlled UI strings

First, let's try to understand who the actors are, why they might want to use internationalized strings, and what could possibly go wrong with such a usage (which in i18n is usually "a lot").

The intent of the "nickname" profile in RFC 8266 is to provide a way for people to create memorable or expressive handles for their own stuff (a nickname in a chatroom, a personal tag for a device, etc.). The nickname profile allows a nearly limitless range of Unicode characters and therefore should be employed with extreme caution. For instance, it should not be employed when handles will be entered in multiple places by multiple actors, when handles might be the basis for authentication and authorization decisions, etc. Please consider very carefully whether we want a relying party or a user to generate a PublicKeyCredentialEntity name or a PublicKeyCredentialUserEntity displayName containing characters like ∞ (INFINITY, U+221E) or ♚  (BLACK CHESS KING, U+265A). I suspect that we we do not want this, and that RPs and users do not need this. 

What RPs and users do need is a way to associate human-friendly names (not necessarily expressive handles) with themselves as RPs or users, where the names can include Unicode characters outside the ASCII range and where "human-friendly" means friendly to humans whose native language cannot be represented in the Latin script.

Thus I would strongly suggest that the "nickname" profile of the PRECIS FreeformClass from RFC 8266 is not the right construct here, and that we actually want to create an application-layer construct consisting of a space-separated set of userparts that themselves conform to the [UsernameCaseMapped](https://tools.ietf.org/html/rfc8265#section-3.3) profile of the PRECIS IdentifierClass from RFC 8265. This is a much safer approach because IMHO we do not need the expressiveness that RFC 8266 allows. See [Section 12.3 of RFC 8264](https://tools.ietf.org/html/rfc8264#section-12.3) for relevant warnings.

Second, assuming that we want to do what I suggest above (or something even simpler like a [character string](https://www.w3.org/TR/charmod/#def-character-string) if folks like @r12a and @aphillips can provide suggestions), we need to look at the mechanics of the spec text. I'll pause for breath here so we can discuss the higher-order bit and hopefully come to agreement.

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

Received on Wednesday, 9 May 2018 18:27:52 UTC