The wp user update documentation says the command accepts a number of parameters including the generic

--<field>=<value>

which is described as

One or more fields to update. For accepted fields, see wp_update_user().

The wp_update_user() documentation says

See also: wp_insert_user(): For what fields can be set in $userdata.

As far as I can tell this is an exhaustive list of the field values that can be used.

• user_pass
• user_nicename
• user_url
• user_email
• display_name
• nickname
• first_name
• last_name
• description
• rich_editing
• user_registered
• role
• syntax_highlighting
• comment_shortcuts
• admin_color
• use_ssl
• show_admin_bar_front
• locale

This same behavior occurs with other update commands,

e.g.

The correct version

wp post update 1 --post_title="New title"

and a version with a typo (underscore _ is replaced with a dash -)

wp post update 1 --post-title="New title"

or a version with any invalid argument.

It would be nice to flag bad fields, perhaps with a warning.

wp post update 1 --notafield="New title"

All display

Success: Updated post 1.

Yes, I agree, WP-CLI should verify the flag against a whitelist. This would need to be kept in sync with the WordPress Core version, though, and we need to deal with the changes between Core versions as well.

I'm thinking about an external list of entities and their properties, with starting and/or ending version numbers for each. Having that outside of the individual commands would make it easier to maintain it and check it against new releases.