![image.png](https://files.peakd.com/file/peakd-hive/howo/irniJMju-image.png)

This title may confuse some of you so let me explain, this idea comes from this issue on gitlab : https://gitlab.syncad.com/hive/hive/-/issues/49

to quote @blocktrades: 

```
IIRC, Bitshares was looking into adding "custom keys": keys which allowed for a given subset of operations to be signed. If it's not too intensive, this could be a useful feature for Hive as well. For example, a user could create a key that could only be used for voting, but not for posting, preventing potential identity theft when providing a voting key to another user or service.
Maybe someone from BitShares can chime in on if this was implemented, and if so, how easily/usefully it might be implemented for Hive.
```

So my problem with this idea is that being able to create any number of keys for x/y operation  quickly becomes annoying to manage them all, and it could be compromised more easily. plus it means that dapps will have to manage keys as well (and there is always a risk of a hack where we all find out that those keys were stored in plain text and not encrypted).

But I do think there is a use case, I shouldn't need to give my complete posting key to a service that will just vote, to me it looks a lot like the add authority operation, if you are not aware it's an operation on hive that allows you to "authorize" a certain account on hive to do some actions on your behalf (posting/voting/whatever) without you having to give out your actual private key. It is used on multiple dapps like https://downvotecontrol.com or https://hive.vote/ This is great for dapps who don't want to manage multiple user keys, but it has the drawback of needing the active key to authorize the app in the first place.

And it's always a bit awkward to take the risk of using your active key on a website just to give them posting authority, nowadays we got great tools like keychain or hivesigner, which mitigate that risk, but those could always get compromised and it would be much better to not have to use an active key at all.

So my suggestion is simple, what if we change the key requirements from active to whatever is the op that has the highest requirements in those you want to authorize.

let's say bob wants to give voting, posting authority to alice, all of those op require a posting key, so to authorize he will just need a posting key. 

Now let's say bob wants to give voting and transferring authority to eve, voting requires posting, transferring requires active so granting the authorization will require the active key. 

You get the idea.

I think this would be a nice improvement to the UX and security to the blockchain where we will see less raw keys going around to servers that may be unsecured and more authorities that can easily be revoked.

What do yall think ?