Empty strings are not valid RFC 8266 Nicknames

[zacknewman]

The enforcement rule for the Nickname Profile in RFC 8266 expressly forbids empty strings:

After all of the foregoing rules have been enforced, the entity MUST ensure that the nickname is not zero bytes in length (this is done after enforcing the rules to prevent applications from mistakenly omitting a nickname entirely, because when internationalized strings are accepted a non-empty sequence of characters can result in a zero-length nickname after canonicalization).

This seems to contradict the recommendation for RPs to set PublicKeyCredentialUserEntity.displayName to the empty string when "no suitable or human-palatable name is available" while simultaneously recommending RPs and clients enforce the rule:

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.

Clients SHOULD perform enforcement, as prescribed in Section 2.3 of [RFC8266] for the Nickname Profile of the PRECIS FreeformClass [RFC8264], on displayName's value prior to displaying the value to the user or including the value as a parameter of the authenticatorMakeCredential operation.

Should the spec be changed to state rule enforcement SHOULD only occur when displayName is not empty? I was personally bit by this omission in the RP library I am writing.

[emlun]

2024-05-15 WG call:

• This seems like an accurate observation.
• This was changed in PR #1932.
• Empty values tend to lead to interop problems, we should revert that part of #1932.

[selfissued]

OpenID Connect also forbids empty strings as claim values in an attempt to preempt some interop problems. There, https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse says:

If a Claim is not returned, that Claim Name SHOULD be omitted from the JSON object representing the Claims; it SHOULD NOT be present with a null or empty string value.

We should do likewise.