Add a new claim, "preferred_username".
preferred_username string Shorthand name that the End-User wishes to be referred to at the RP, such as
"janedoe" or "j.doe". This value MAY be any valid JSON string including special characters such as "@", "/", or whitespace. This value MUST NOT be relied upon to be unique by the RP. (See § 220.127.116.11) email string The End-User's preferred email address. This value MUST NOT be relied upon to be unique by the RP. (See § 18.104.22.168) }}}
== 22.214.171.124 Claim Stability and Uniqueness
The user_id claim is the only claim which a client can rely upon to be stable, since user_id claim MUST be locally unique and never reassigned within the Issuer for a particular End-User as described in § 2.1.1. Therefore, the only guaranteed unique identifier for a given End-User is a combination of the Issuer's identifier and the user_id claim, and other fields such as preferred_username and email MUST NOT be used as unique identifiers for a given End-User.
All other claims carry no such guarantees across different issuers in terms of stability over time or uniqueness across users, and issuers are permitted to apply local restrictions and policies. For instance, an Issuer MAY re-use a given preferred_username or email address claim across different different End-Users at different points in time, and the claimed preferred_username or email address for a given End-User MAY change over time.
I believe that this language allows IdPs that want to do so to tie preferred_username directly and uniquely to user_id (since some will), but it doesn't force them to and it cautions RPs away from relying on that across IdPs.