@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.
@thisismissem 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
@mauve Mastodon & fedi software only deals with any of those fpr their webapps and extensibility use cases, not for federation
@thisismissem 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.
@thisismissem 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.
@thisismissem 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.
@mauve 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