Idea of not distributing registrations is dumb. Sounds like they didn’t even tried to find something better. This defeats purpose of federation. Everyone will land on one instance because hashtags don’t federate and people will start moving to big instances.
We don’t need corpo sso. We need federated auth providers and org which can fund instances which want to be on “trusted list”
It’s possible with OpenID. All you need is extract domain from login id and get provider configuration at https://<DOMAIN>/.well-known/openid-configuration. Problem is that if it’s down you can’t login into same account using another provider.
Technically same way as google or apple SSO works just fixed list of domains. Another problem with using whatever domain user supplied is that some domains are more trusted than others, or rather owners. I don’t mean from privacy perspective I mean stability and security. It’s much easier to hijack domain of small server which struggles to pay for domain name consistently than google.
If Fediverse want to use OpenID for login someone have to vet trusted auth providers.
Otherwise we need someway to federate user logins. Maybe literally have replicated users credentials across instances. Then all federed instances can authenticate users from any federed instance.
Because you can’t count on every instance playing by the rules. If anyone can set up an instance and authenticate any federated account, then they could also choose to impersonate me.
I won’t pretend I looked into authentication algorithm of every fedi apps but I doubt it’s “trust me bro” algorithm. Otherwise what would prevent malicious instance to post from your name today. Even if it’s some wacky algorithm it’s not a rocket science to enhance it. Message signing and public key sharing is one of common ways to solve this kind of problems. The only reason I see not to do it is lack of will or resources, or both
To explain why the comment below is correct, you are right that the other instance couldn’t get your password. They don’t need that to create a post/comment that is supposedly sent from an account though. Those aren’t cryptographically signed or anything like that. It just says “this user sent this message”.
I don’t even think there is a way you could do this with some kind of cryptographic signature, unless it basically just sends an encrypted message to the home server and it verifies it, which then we have the same issue we started with of relying on a single server. I guess every message could be sent with a key, which can be disputed later. If the home server is unavailable, the message is sent, but it can later say that it’s a forgery when it comes back online. It’s not a perfect fix, but it’s the only way this could even possibly work I think.
The only reason signatures work is because only your home instance can post as you. If you’re saying you want any instance to be able to authenticate any user, even if all the rest of the fediverse is down, then you’re eliminating that trust anchor (i.e., your home instance).
Currently, a malicious instance could pretend to post as any of ITS users, but NOT external users. The problem is if that instance is able to authenticate someone from a different instance, an you’re suggesting. Then, they could post as that user and propagate that action through federation.
The only way this could work is if YOU as the user had a public/private key your on YOUR device(s). Then, any action made on your behalf could first be required to be signed LOCALLY on YOUR device.
Problems with that approach are:
Key management: Using the fediverse on multiple devices
Trust: Where do I “register” my public keys? Again, you need some trusted third party/parties, which defeats your idea of absolute decentralization. Who decides which key store instances are to be trusted? How does the registration work? For example, what if you have two such public key stores (decentralization much) that either don’t federated together or they take some time to do so. What if the users register their own distinct public keys for the same username but in the two different public key stores? Trying to solve that requires either a fully centralized node or going into the dangerous territory of crypto bros (blockchains, i.e., some form of “majority” vote on which of the users is “allowed” to live on on).
Idea of not distributing registrations is dumb. Sounds like they didn’t even tried to find something better. This defeats purpose of federation. Everyone will land on one instance because hashtags don’t federate and people will start moving to big instances.
We don’t need corpo sso. We need federated auth providers and org which can fund instances which want to be on “trusted list”
Wasn’t that the idea behind OpenID?
It’s possible with OpenID. All you need is extract domain from login id and get provider configuration at https://<DOMAIN>/.well-known/openid-configuration. Problem is that if it’s down you can’t login into same account using another provider.
Technically same way as google or apple SSO works just fixed list of domains. Another problem with using whatever domain user supplied is that some domains are more trusted than others, or rather owners. I don’t mean from privacy perspective I mean stability and security. It’s much easier to hijack domain of small server which struggles to pay for domain name consistently than google.
If Fediverse want to use OpenID for login someone have to vet trusted auth providers.
Otherwise we need someway to federate user logins. Maybe literally have replicated users credentials across instances. Then all federed instances can authenticate users from any federed instance.
Letting a random instance authenticate a random person as me is a terrible idea.
Can you explain why exactly? Particular scenario would be helpful to understand your POV
Because you can’t count on every instance playing by the rules. If anyone can set up an instance and authenticate any federated account, then they could also choose to impersonate me.
I won’t pretend I looked into authentication algorithm of every fedi apps but I doubt it’s “trust me bro” algorithm. Otherwise what would prevent malicious instance to post from your name today. Even if it’s some wacky algorithm it’s not a rocket science to enhance it. Message signing and public key sharing is one of common ways to solve this kind of problems. The only reason I see not to do it is lack of will or resources, or both
To explain why the comment below is correct, you are right that the other instance couldn’t get your password. They don’t need that to create a post/comment that is supposedly sent from an account though. Those aren’t cryptographically signed or anything like that. It just says “this user sent this message”.
I don’t even think there is a way you could do this with some kind of cryptographic signature, unless it basically just sends an encrypted message to the home server and it verifies it, which then we have the same issue we started with of relying on a single server. I guess every message could be sent with a key, which can be disputed later. If the home server is unavailable, the message is sent, but it can later say that it’s a forgery when it comes back online. It’s not a perfect fix, but it’s the only way this could even possibly work I think.
The only reason signatures work is because only your home instance can post as you. If you’re saying you want any instance to be able to authenticate any user, even if all the rest of the fediverse is down, then you’re eliminating that trust anchor (i.e., your home instance).
Currently, a malicious instance could pretend to post as any of ITS users, but NOT external users. The problem is if that instance is able to authenticate someone from a different instance, an you’re suggesting. Then, they could post as that user and propagate that action through federation.
The only way this could work is if YOU as the user had a public/private key your on YOUR device(s). Then, any action made on your behalf could first be required to be signed LOCALLY on YOUR device.
Problems with that approach are: