Derived keys should have different authentication levels

[carlosgio]

First of all, thank you very much to @AeonSw4n and @maebeam for the great work they are doing.

Continuing the discussion on Discord, I think that current plans for one-size-fits-all derived keys should be improved.

• The problem:

A derived key that expires shortly (maybe a few weeks or a month) resolves the problem of limiting the attack surface inherent to derived keys.

But this isn't practical for third-party apps that only need to create "social" transactions (post, like, etc.).

A social third-party app (think Hootsuite or Buffer) would need to request a newly derived key to all its user every few weeks.

• The solution:

I propose that derived keys should have at least two authentication levels. Let's name them "coin" and "social".

Transactions signed with a "social" derived key wouldn't be posted to the blockchain unless they are social-network related only, and vice versa.

The expiration date for "coin" derived keys should be a few weeks/a month. The expiration date for "social" derived keys should be a few months/a year.

[maebeam]

I think keys with different permission levels is a great idea. At the moment, derived keys can have any expiration but Identity will only issue keys with a 1-4 week expiration time. I think I would prefer a more granular access level but I'm not positive.

[carlosgio]

What about something like this?

1 "Profile": update profile only.
2 "Like": like posts only.
4 "Social": post, reclout, quote, comment.
8 "Diamond": send diamonds only.
16 "BitCloutCoin": send BitClout coin, buy BitClout using Bitcoin.
32 "CreatorCoin": send, buy and sell creation coin.

[StarGeezerPhil]

Love the idea, but suggest Profile is more sensitive than likes.

Could this be granular at the TYPE level, with cumulative limits to avoid microtransactions being used to drain wallets by bad actors.

e.g.
BASIC_TRANSFER, Limit XXXX DESO
CREATOR_COIN, Limit XXXX DESO
E.g. diamond permissions would still allow me to programmatically empty any public keys that authenticate to my app.
Even if a per transaction limit was established. A cumulative limit, set by the user, would limit the potential exposure/risk.

I'd add this same cumulative limit for self-sells of a creators own creator coin too - thus avoiding total rug-pulls, limiting losses and allowing holders time to exit before the full holding is sold.

[carlosgio]

I think that granular at the TYPE level could be too granular. I'm thinking about the UI needed for authorizing all the TYPES. It would be too complicated/cumbersome.

But I agree 100% with cumulative limits.

Granular permissions + cumulative limits is a great idea.

Also, Profile is more sensitive than Likes, you are right.

[tijno]

Doesnt the change @lazynina committed partially do this ?

Ive not looked at the code in detail yet but I believe it offers different limits per transaction type.

Seems its freq limit per type though.

The main pieces are:

• GlobalDESOLimit: cumulative amount the derived key is authorized to spend

• TransactionCountLimitMap: map of txn type to number of times this derived key is authorized to perform the txn type

• CreatorCoinOperationLimitMap, DAOCoinOperationLimitMap, NFTOperationLimitMap: authorize a derived key to perform a specific operation (buy/sell/transfer for CCs, mint/burn/etc. fro DAO coins, update/bid/accept bid/etc. for NFTs) for specific Creator coins, DAO coins, or NFTs.

deso-protocol/core#216

[carlosgio]

Yes, it seems so!

It even offers the option to choose when the limits will take effect:

// DerivedKeySetSpendingLimitsBlockHeight defines the height at which derived key transactions will have their
// transaction spending limits in the extra data field parsed.
DerivedKeySetSpendingLimitsBlockHeight uint32

// DerivedKeyTrackSpendingLimitsBlockHeight defines the height at which derived key's transaction spending limits
// will come in effect - accounting of DESO spent and transaction counts will begin at this height. These heights
// are separated to allow developers time to generate new derived keys for their users. NOTE: this must always
// be greater than or equal to DerivedKeySetSpendingLimitsBlockHeight.
DerivedKeyTrackSpendingLimitsBlockHeight uint32

I'm curious @lazynina : How will identity service handle this? How will the user know the spending limits per transaction type that the app is requesting? I'm supposing that identity UI will show a list of transaction types and values, but this list could be quite big/difficult to understand to the user.