For real we should ditch wallets and password managers and OAuth and instead use public keys + ActivityPub Actors + HTTP Signing. Though I guess it puts a lot of trust into the DNS layer?
@mauve problem with that is securely storing the private keys.
@thisismissem Yeah that too. In our case the answer to "what happens when I lose my keys or they are stolen" is "make a new keypair and add it to your actor object" which IMO is an improvement over "ha ha you lost your identity forever lol". Leaves a lot to be desired still though.
@mauve how can you add it to your actor object if you actor object is sogned with the previous key?
@thisismissem Err, do Actors need to be signed? I've only been using the signing for http auth. Didn't see anything about needing to sign the actor in any of the guides I looked at. 😅
@mauve well, in your system if te actor wasn't signed, I could mitm a server, add a new key to a copy of your actor object, and suddenly get that new key federated out.
@thisismissem Yeah! That's what I meant about being overly dependent on DNS. If you can't trust an HTTPS request the whole thing breaks.
@mauve I guess what I'm getting at is: key management and security is difficult, particularly distributed, and requires sneakernet verification often. So if you just blindly trust that a key mentioned in the Actor object is authentic, then that's the flaw in your security, because you service also doesn't want to be checking the origin's Actor object for every activity or federations-request, so would need to cache known keys, which would mean a single mitm would poison the key cache
