End-users have non-password options for logging into the self-service UI - for one example, it could be via OpenID Connect authentication. Since passwords are not required for login, there is a good chance that these users don't have a password saved as part of their profile (as would be the case when they use social registration to create their account).
It may be desirable for these password-less users to still have the option to create a local password, so that they can login with their local credentials instead of being forced to rely on whatever other mechanism they had used to authenticate.
The default user model has a policy for passwords which requires that all end users must supply their "current" password before changing it (this is called "reauthentication"). This policy does not make sense for those users with no password defined. Therefore, the system must be able to take this condition into account when deciding whether or not to enforce reauthentication.
The current implementation enforces reauthentication via a policy evaluation. This design decision prevents the context-awareness needed to determine whether or not to allow a given request to change the password. The mistaken design around reauthentication is apparent when considering the nature of "context" - the reauthentication policy is presently the only policy which is context-aware. This context-awareness makes it a very awkward fit for policy enforcement - instead of evaluating the content of the data, the reauthentication policy only considers the context under which it is supplied. The problem for the bug described above is that the policy service does not evaluate policy functions on a per-record basis when listing the requirements for a resource - instead it merely returns a static list of policies which are known to apply to it. This would be fine behavior if those policies were all context-independent; however, for this one policy (reauthentication) context is everything.
To correctly solve this buggy behavior with reauthentication, the logic for enforcement needs to be moved out of policy (policy.js) and instead moved into the authorization logic (router-authz.js). To accomplish this, the declaration on the managed object schema will need to change slightly (so that it is no longer part of the policy configuration) and there will need to be a new way of expressing this authorization requirement to the end-user. The admin UI for configuring the managed object will need to be adjusted to account for this different authorization property, and the self-service UI will need to be adjusted slightly to account for the new way of determining which properties will require this reauthentication behavior. Finally, there will need to be additional customAuthz functions created in router-authz.js which perform the reauthentication check and only allow the request through if the check passes.