Right now, in order to have server-wide oper privileges, you need to create an entry in the opers section of the server config, including a username and password to use with OPER. Since users may already be authenticated with an account, it would be more convenient in some circumstances if the following could be supported:
In the config file, in addition to password and certificate, you could configure account as a method to verify oper privileges (that is, if a user is logged into an account with a given username, they would automatically be given the permissions of the relevant oper class)
A new command could be used which would allow server ops to grant an account op privileges of a given oper class (without having to edit the config file)
A similar method to (or extension of) auth-script could update oper privileges of an account. For example, you could imagine imagine adding an additional property to the object returned by auth-script that would be an array called operClasses to update the classes the account is part of every time they log in, or a script that could be called at some interval to retrieve opers and their classes. Alternatively, you could argue that it would be better to implement this by creating an oped bot that could be used to update op status in an event-driven fashion, though it would need to be affirmed that this mechanism could handle situations where an external account is given privileges, but does not yet have an ircd account. SAML (#502) and OAuth (#2004) both provide mechanisms for specifying roles/permissions, so that should also be considered in how this would be implemented.
Right now, in order to have server-wide oper privileges, you need to create an entry in the
operssection of the server config, including a username and password to use withOPER. Since users may already be authenticated with an account, it would be more convenient in some circumstances if the following could be supported:operClassesto update the classes the account is part of every time they log in, or a script that could be called at some interval to retrieve opers and their classes. Alternatively, you could argue that it would be better to implement this by creating an oped bot that could be used to update op status in an event-driven fashion, though it would need to be affirmed that this mechanism could handle situations where an external account is given privileges, but does not yet have an ircd account. SAML (#502) and OAuth (#2004) both provide mechanisms for specifying roles/permissions, so that should also be considered in how this would be implemented.