0043 XLS-43d: RestrictiveRegularKey

[zgrguric]

  Title:        RestrictiveRegularKey
  Status:       Draft
  Description:  Restrictive/Conditional Regular Key pair only for certain types of Transactions

Abstract

Currently the XRP Ledger offers account to authorize secondary key pair, called Regular Key Pair, to sign future transactions. This adds level of security to account, if regular key is compromised, one can choose to securely remove it by using master key.

Automated systems/server/software can auto-sign transactions to do certain tasks in the name of account by using Regular Key. But there can be even stricter rule to sign only "whitelisted" types of transactions.

Sample scenario 1

Automated software can only Mint new tokens, and 'whitelisted' transaction type would be NFTokenMint. Software may be hosted on potentially unsecure hosting provider, or hosting provider was trustworthy but at some point exploited by 3rd party. This can automatically expose signing regular key.

If Restrictive Regular Key was used, malicious party would not be able to drain account of funds, since only one said type of Transaction can be signed.

Sample scenario 2

Another 'NFT' sample is following: Lets say theoretically you would imprint this key to physical card, eg Tangem or other with NFC tag.

Account would hold single NFT, that this card is sold for or is proof of purchase. Account can be even black-holed.

This would allow only for creating one NFTokenCreateOffer (because after transaction is created RestrictiveRegularKey would be removed from account afterwards). This would potentially allow to transfer single NFT off that physical card to new owner.

Outcome

Mitigates damage caused by leaked/compromised regular key.

Implementation

Add new type of RegularKey to account data (new functionality)

New type SetRestrictiveRegularKey
Optional condition "Unset after first successful use" - unsets this RegularKey after one (or x) usages.

Stored in new location. Requires new handling within rippled. Flag-like field would required field, "0" flag is not possible.

Backward compatibility

This is new setting in Account, no backward compatibility issues are expected.

Amendment

This transaction will require amendment. The proposed name is RestrictiveRegularKey.

[shortthefomo]

This can already be archived via multisig, simply setting up a signer list then only giving the remote machine one of the keys. The current multisig solution can also scale further.

Once the gate to only restricting some types is opened there will be further requests for other keys that limit other types of functionality. This needs to be a programable thing if its undertaken, and should be done with a "smart contract" type layer rather.

[zgrguric]

This is valid, thank you for input.