Problem: Currently privileged users must maintain multiple user accounts when wanting to log on with lesser access.
Who would benefit: Any privileged user, especially highly privileged users such as admins, interface editors, stewards
Proposed solution: Allow users to create sub-identities similar to Special:BotPasswords with different access grants, that allow interactive logon.
More comments: This will allow users that want to log on with less access (for example from mobile devices, from less trusted devices, or just to test things) to do so without having to maintain multiple accounts, with possibility of not requiring 2FA if otherwise enabled for sub-identities.
I think having two accounts with different privileges is a much easier concept to explain and understand than one account that has different privileges depending on which password you put in. Multiple accounts seems like a much simpler solution to the problem and it's also a solution that already exists. I don't think this wish is a bad idea per se, but personally I'd rather see Community Tech focus their limited resources on problems that do not have fairly workable solutions already. --Deskana (talk) 16:28, 9 November 2018 (UTC)[reply]
Single accounts already do get different privileges depending on the credentials used with BotPassword and OAuth, however they are limited to the API instead of the WebUI. Keep in mind, this would not prevent the existing method of creating all the accounts someone wants. — xaosfluxTalk20:24, 9 November 2018 (UTC)[reply]
Some things to keep in mind: if/once this is implemented, would there be a window for users with multiple accounts to merge their contributions? And if/once those mergers are complete, should we amend the relevant policy as to disallow users having separate accounts (as opposed to using this feature)? Rehman02:18, 20 November 2018 (UTC)[reply]
Actually like this idea a lot. The best way to implement it is to have the user always login without privileges. When he/she need admin permission, he would click on a button, may be get prompted for password and then his/her privileges are elevated. 15 minutes later, they fall back to normal privileges. See how Atlassian have implemented it for example in Jira — The preceding unsigned comment was added by Wk muriithi (talk) 13:48, 24 November 2018 (UTC)[reply]
Security measures that you allow will always have a tiny fraction of the impact of security measures that you require. It will be used by the most security-conscious users, who have strong unique passwords and good account security and thus aren't an easy target anyway. Unless you are ready to make this required, and to acutally enforce it by software (and I don't see how that would work), it's just not a good use of time. Something along the lines of what Wk muriithi said (make all logins de-privileged, and require a temporary elevation) makes more sense, and actually we are sort of doing it already for some very limited things (like password change), but figuring out how to do it without crippling the productivity of privileged users is not easy. --Tgr (talk) 04:00, 25 November 2018 (UTC)[reply]
Support I have often had problems in other platforms that were difficult to resolve because the person trying to help me was too privileged to see the problem, or I was the one who was too privileged to see the problem. This is a sound concept for all computing environments. Jc3s5h (talk) 11:00, 19 November 2018 (UTC)[reply]
Support. It would take away the headache of having to maintain multiple accounts for different uses (editing from home, editing from office, editing from unsafe network), and would also reduce the opacity of certain users (i.e. admins) reviewing editors owning multiple accounts. Rehman02:18, 20 November 2018 (UTC)[reply]
Support as proposer. — xaosflux Talk 20:19, 16 November 2018 (UTC)