Users should not sign documents

The notification pattern is a matter of the application; this is not my main concern (plus, there are better ways for applications to get trusted notifications than require them signed). From the platform point of view, everything is dynamic, so it makes sense to react quickly.

For instance, the HTTP signatures as used with ActivityPub are valid for around 30 seconds (from what I learnt from Mastodon), after which no verification is made (so the key can be dropped). The PoP tokens used by Solid are also issued for a limited time window, in order to limit the amount of server-side caching of already issued tokens.

The pseudonym identity is not interesting, because at one point all the members of your social graph need to agree on who you are. Having different separate identities with only one other identity in each social graph is not great, to say the least ^^

Ah. Now I finally understand where this tactic of discarding the private key comes from. ActivitPub’s technique probably comes from Signal’s Open Whisper double ratchet technique that’s used by What’s App. This is effectively similar to TLS Perfect Forward Secrecy and the credit card industry’s DUKPT (Derived Unique Key Per Transaction):

In these schemes, the private key is NOT discarded (except by the Double Ratchet). Instead, a new key pair is derived from the original key pair so that a new, temporary key pair is used for each message. Yes, this is a technique used to counter attacks that can be applied when lots of messages are encrypted using the same key pair. But, each new key pair is always derived from the same original key pair that’s verifiably associated with the entity that’s represented (person, server, credit card).

Yes, that’s a good technique to use. But, to use that you only need one public key published via your Solid Pod. You don’t need to update the public key with each message. Instead, each message includes the technique used by the sender to derive the current encryption key. Then, the receiver can apply the same derivation formula to get the current decryption key.

That’s all generalities. As this specifically applies to Solid, the profile in the Pod would publish one Authentication public key, one Signing public key and maybe one Key Management public key. Those can then be used for the DUKPT technique without ever discarding the original key pairs. Yes, this is a good technique. I’m glad I understand where you’re coming from. We want to use Solid Pods in our systems. But, if Solid incorrectly applies encryption techniques we would need to find another secure data store solution.

As long as there is no way to verify that all the keys are linked together, that’s fine with me.