Oddbean new post about login | logout @59c6c59c problem with that is securely storing the private keys.
@f50dbb78 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.
@f50dbb78 I think the dynamics become similar to a password in the end but it makes it just a little harder to spoof requests and it makes it just a little easier to not have to deal with JWTs/UCANs/Bearer tokens
@59c6c59c Mastodon & fedi software only deals with any of those fpr their webapps and extensibility use cases, not for federation
@f50dbb78 Yup! Exactly and so you have way more ways of making clients. IMO it'd be great if clients used signed requests to their inbox/outbox and if instances provided SPARQL or similar for querying data back out. Or better yet it'd be nice if clients loaded other peers' data directly.
@59c6c59c I think you may be searching for solid with solid-tls for auth
@f50dbb78 Mind linking to a TLDR for how that works? Solid is defs something I'm interested in. Is solid-tls the tls client certificate auth? I was ranting about how it sucks that isn't used more a few months ago :P Sadly I couldn't get it working on Linux with chromium or firefox so I gave up on pursuing it further.
@59c6c59c it's all available via the solid project website, it's one of the official specs but got superseded by solid-oidc, but I know TimBL still believes in it because OIDC annoys him
@f50dbb78 Neat yeah. I like the use of linking to profiles with the SubjectAlternativeName field in the certificate. Still wishing we had the future where we used client certs for auth. 😩 OIDC makes sense given the larger "identity" industry. Agree it can be annoying though. So many little pieces to keep track of.
@59c6c59c how can you add it to your actor object if you actor object is sogned with the previous key?
@f50dbb78 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. 😅
@59c6c59c 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.
@f50dbb78 Yeah! That's what I meant about being overly dependent on DNS. If you can't trust an HTTPS request the whole thing breaks.
@59c6c59c 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