Support for different usernames in key registration
Key details
Basics
Logistics
Basics
Logistics
Description
The registration workflow should support any username that the IdP canonicalization does.
A lot of our users don’t even know their username. They log in with “firstname.lastname@example.com” everywhere including the IdP. The IdP technically supports username/password login with the username, too, but few people use it. Internally the IdP canonicalizes the user to their username rather than the long-form “firstname.lastname@example.com”.
Presenting “firstname.lastname@example.com” for registration phase 1 and then authenticating (as “firstname.lastname@example.com“) doesn’t allow you to register a key.
IMO it would be ideal to associate the key with the “real” username that is the one that the IdP internally recognizes as the user’s canonical username but still have the registration flow support others as well as long as they canonicalize to the same username. What I mean by that is that searching for keys from the webauthn management UI would still be based on username. However any keys in the user’s passkey provider would show as being registered to “firstname.lastname@example.com” or what ever they provided as their username during the registration’s 1st phase.
The registration workflow should support any username that the IdP canonicalization does.
A lot of our users don’t even know their username. They log in with “firstname.lastname@example.com” everywhere including the IdP. The IdP technically supports username/password login with the username, too, but few people use it. Internally the IdP canonicalizes the user to their username rather than the long-form “firstname.lastname@example.com”.
Presenting “firstname.lastname@example.com” for registration phase 1 and then authenticating (as “firstname.lastname@example.com“) doesn’t allow you to register a key.
IMO it would be ideal to associate the key with the “real” username that is the one that the IdP internally recognizes as the user’s canonical username but still have the registration flow support others as well as long as they canonicalize to the same username. What I mean by that is that searching for keys from the webauthn management UI would still be based on username. However any keys in the user’s passkey provider would show as being registered to “firstname.lastname@example.com” or what ever they provided as their username during the registration’s 1st phase.