That’s good to know! Honestly I’m glad you are setting the scope and expectations very explicitly upfront that it’s not intended for financial purposes
In that case the solution to this would be EIP-5573 (aka ReCaps) which allows you to describe some “capabilities” in the resources of a EIP-4361 (aka SIWE) message that allows you to “bind” a key to act on the behalf of an Ethereum account.
We actually use this in production for our Web3Inbox service where we generate a ed25519 key in local storage that can create, read, update and delete notification subscriptions for our Notify API server without requesting the wallet to sign for every action. (see image below)
How you actually construct the ReCap for your use-case is up to you… but the ReCap spec is perfect for your use-case and it allow greater user readability and allow you to build your app very flexibly.
All of this is achieved without any Smart Accounts and you can use any algorithm you want for your public keys (secp256k1, p-256, ed25519, etc) using the did:key spec.