don't understand this but agree this isn't a priority.  thinking through the options:

1) user = loginUser (or user blank) and user.password != loginUser.password -- i.e. caller wishes to set a (new) password for the login user different to what they logged in as.  not a priority:  use a new user.  also, use private keys.

SHOULD probalbly log warning however if user.password != loginUser.password.  (that changing the password is not supported in brooklyn currently, and subsequent logins may fail attempting to log in with user.password.)

2) dontCreateUser is specified

i expect that caller's intention in this case is to user the given user with the given password, both of which are set up already.  someone might think they can change the password using this field, which actually could be useful, but not high priority.

COULD add comment on dontCreateUser that it won't create the user or the password, but it will authorize a public key.

on a related note:

0) if the user already exists (and dontCreateUser is not specified), do we crash and burn, or proceed to set password / private key ?  the latter would be nice, and would argue that in the case of dontCreateUser we should neither change password nor authorize a public key.