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.