Username is inconsistent with Cognito when using UsernameAttributes

[jagregory]

When you have a User Pool with email as a UsernameAttribute, you can create a user by specifying an email address as their Username in the admin-create-user call. In Cognito (proper) the email address is stored in the email attribute and the Username is set to a generated sub UUID; however, in Cognito Local the email address is actually set as the Username.

What happens when you create a user in a pool with email in UsernameAttributes in Cognito?

1. Registering without providing an email attribute, with an email as username: username is validated as an email, sub generated, username set to sub, input username set as email attribute
2. With email attribute that doesn’t match username = “User email should be empty or same as username, since username attribute is email”
3. With email attribute that matches the username, sub generated, username set to sub, email attribute set to username/email attribute (whatever, they’re the same)
4. With a username attribute which isn’t an email = “Username should be an email”

Open questions:

1. What about a pool without email as a username attribute?
2. What about a pool with phone number or preferred_username?
3. Seems to be a bug where a user gets created even if their attributes are rejected?
4. Email validation on creating users (user exists with email) doesn't match

[kadyrleev]

Yep, and the sub attribute is immutable so attempts to change it should throw an exception.