In order to support a clean interactive authentication flow without any confusion about when a password prompt should be popped up to the user, we need to distinguish between POD User Keys that come from passwords and those that are centrally managed and distributed as random nonce values.
This means that CLIAuthProvider should only respond to a new PasswordBasedRootKey key type and not generic UserKey requests. Device interactions that support a distinction between password based and raw user keys such as authentication over bluetooth can first request for a UserKey and if that fails request for a PasswordBasedRootKey in order to give interactive login methods a try as a last resort.