5 ms·

It's a step in the right direction, but it's still centralized. A lot of the work done by the Indie Web community around IndieAuth[1] is really attractive. Yo

by mawise 6y ago

It's a step in the right direction, but it's still centralized. A lot of the work done by the Indie Web community around IndieAuth[1] is really attractive. Your identity is your domain, and you can change how your domain says you're allowed to authenticate. Now you can even use sign-in with google without getting locked out should you loose your google account. Aligns really well with using your own domain for email instead of gmail. [1] https://indieauth.net/ https://indieauth.net/

F3nd0 6y ago
There’s also re:claimID¹, which should be fully distributed and work on top of GNS², but it’s still very much a work in progress. 1. https://reclaim.gnunet.org/ https://reclaim.gnunet.org/ 2. https://gnunet.org/en/gns.html https://gnunet.org/en/gns.html
- theamk 6y ago
  First promotion point: > Self-sovereign You manage your identities and attributes locally on your computer. No need to trust a third party service with your data. Why do people assume that is a good thing? I do cybersecurity at work (among other things) and it takes a lot of effort to keep things both available and secure. My home PC, not to mention PCs of my friends, are never going to be as secure. A system which has a chance will have to be federated, not local-only.
  - Osiris 6y ago
    I work in crypto and we sell a hardware device to keep your seed phrase secure and the physical device is required to sign transactions. But then you should listen to the advice we're given if we use one for personal use. 1. buy two devices 2. Generate a phrase on one then import to the other 3. Put the second one in a safety deposit box in another city or state, or a safe with a family member also out of the city or state. 4. Keep a copy of the phrase on steel seed phrase tool (Steely, etc) 5. Mount the steel seed phrase backup inside of a wall of your house and plaster and paint over it. 6. If your phrase ever gets seen by any electronic means, it's compromised and the process must be redone (note that importing uses a randomly shuffled alphabet on the device to make MITM or keylogging attacks unusable). So... Security is hard. We should build systems that make it easy. There should be ways to recover from backups of a service goes offline, but we can't expect everyone to make good decisions. Not to mention having passwords synced between devices and available on demand is really a requirement of you use random passwords for every site and need to log into something (heaven forbid) on someone else's device.
    - TedDoesntTalk 6y ago
      > [effective and meaningful] Security is hard. We should build systems that make it easy These are in direct conflict with each other.
      - bsder 6y ago
        Not necessarily. What's your threat? Most people are not trying to stop a determined attacker. Most people just want random people to not get be able to get into their stuff--same as a physical lock. They carry a physical key on their person. It's not too much to ask them to carry a "digital" key on their key ring. The problem is that most "digital" keys are a pain in the ass: 1) Mostly because everybody wants to "centralize" authentication so that they can charge you and administrate you. 2) Secondarily because there is no good solution for talking to the key on your person. NFC sucks. USB requires that I plug my key in. WiFi requires that the device be able to hit your network. BLE has no access from web pages. BLE is probably the best choice, but there is no real money in making it work.
        senectus1 6y ago
        Any tool used to create another tool, is the very tool that will be used to help dismantle that other tool. There is no way around this... Security isn't a state, it s a process. It relies on the human to propagate it. A bit like a garden. Make the process simple for the user (but not thoughtless) and that is about as good as is going to get.
quicklime 6y ago
I hadn't heard of either Promise or IndieAuth before reading this thread, so apologies if this is a dumb question. But one of the benefits of Promise is that it's pseudonymous: > You will get a unique identity pr. service you use. This ensures that relying parties have no way to profile you across services. For me, this is actually the biggest reason that I stopped using social sign-ins. It's not that Google might disable my account one day; it's more that I don't want Google or Facebook tracking me. How does a decentralized system handle this? If my identity is my domain, doesn't that mean that all these websites now have a unique id which they can use to join together all their separate pieces of data about me?
- anderslemke 6y ago
  Being pseudonymous is one of the main selling points of Promise. Only by being pseudonymous can it provide the level of privacy that should be expected from the global authentication infrastructure that Promise wants to be.
  - account42 6y ago
    Does Promise get to know which sites you sign in to?
    - anderslemke 6y ago
      Yes. Promise keeps a map of your sites and IDs.
      - s_gourichon 6y ago
        Isn't that a problem, like "let's get rid of Google and all the evildoers because they know too much about us" then "oh we realize we created another one which knows too much about us"?
        anderslemke 6y ago
        I get where you're coming from, and this is something I've been thinking a lot about. It would be possible to not save the map, and then use some kind of hashing to infer user ids for each site. I chose not to do this, to be able to guarantee no collisions. This might be silly, though. But the thought of people with colliding user ids makes me giddy. The data stored looks something like this: { "ids": { "example.com": { "07c5c163-875f-424c-a659-a4f99e74eb12": "default" }, "other-example.com": { "ab38b2a6-d560-43d3-b2a3-9148cd91d1b4": "default" } } } Worth noting is, that there is no personally identifiable information (PII) here. But we have to have the discussion if this is "too much" data to keep about a user. AFAIK this is the bare minimum of data needed, to be able to guarantee no collisions of user ids. If there is another way to do it, we should do that!
anderslemke 6y ago
I'm a bit divided on whether or not the "centralized" thing is actually a problem Promise should tackle. On one hand, I want to tell you that Promise is only centralized by default. Which is good for people that doesn't understand what a OpenID/IndieAuth Provider is. But as Promise is open source and the protocol caters for it, it is possible to have Promise redirect authentication requests to your own instance. Which then redirects you back to the relying party you want to sign in to. So it is possible to decentralize if that is what you want On the other hand, I'm not sure it's a good idea to do it. Centralizing gives a lot of benefits. User experienc being one, but also being able to roll out eg. security updates quickly. But sure, centralization also creates problems. But until now, I have a feeling that the problems with centralization, can be solved by other measures than going decentralized. Eg. being a non-profit organisation owned by the relying parties. This would guard against a lot of the problems with being centralized. And I'm still to encounter a decentralized solution with a reasonable user experience for most people. OpenID, IndieAuth, SQRL, re:claimID, I'm looking at you. Sorry.
- mawise 6y ago
  You're right that the user experience is a huge blocker, but I think that's something we as authors of tools can improve on. For example, there's a Wordpress plugin that lets your Wordpress site act as an IndieAuth identity[1]. That makes it pretty usable from and end-user perspective. The challenge with centralized is that it is a single point of failure. The original post was more focused on "If you get locked out of google, you get locked out of everything". In that vein if promise gets hacked/bought/abandoned/changes it's business model etc.. then you lose all your accounts. The anonymous nature of it is great, but this is something Apple already offers with their sign-in with apple which is already widely supported and with the proxy-email solution you can still be contacted by the sites you're signing up with. I got interested in IndieAuth because of a project of mine[2], trying to make it really easy for everyone to self-host their facebook/twitter equivalent with direct control over who has access. This runs into the problem with wide adoption where you have a separate credential for each of your friends' blogs. With IndieAuth built into the self-hosted platform, then your own self-hosted site becomes the one credential you can use on all your friends' sites. Self-hosted distributed identity for privacy AND ease-of-use. [1] https://wordpress.org/plugins/indieauth/ https://wordpress.org/plugins/indieauth/ [2] You can find the link in other comments I've made on HN

by mawise 6y ago

F3nd0 6y ago

There’s also re:claimID¹, which should be fully distributed and work on top of GNS², but it’s still very much a work in progress. 1. https://reclaim.gnunet.org/ https://reclaim.gnunet.org/ 2. https://gnunet.org/en/gns.html https://gnunet.org/en/gns.html

theamk 6y ago
First promotion point: > Self-sovereign You manage your identities and attributes locally on your computer. No need to trust a third party service with your data. Why do people assume that is a good thing? I do cybersecurity at work (among other things) and it takes a lot of effort to keep things both available and secure. My home PC, not to mention PCs of my friends, are never going to be as secure. A system which has a chance will have to be federated, not local-only.
- Osiris 6y ago
  I work in crypto and we sell a hardware device to keep your seed phrase secure and the physical device is required to sign transactions. But then you should listen to the advice we're given if we use one for personal use. 1. buy two devices 2. Generate a phrase on one then import to the other 3. Put the second one in a safety deposit box in another city or state, or a safe with a family member also out of the city or state. 4. Keep a copy of the phrase on steel seed phrase tool (Steely, etc) 5. Mount the steel seed phrase backup inside of a wall of your house and plaster and paint over it. 6. If your phrase ever gets seen by any electronic means, it's compromised and the process must be redone (note that importing uses a randomly shuffled alphabet on the device to make MITM or keylogging attacks unusable). So... Security is hard. We should build systems that make it easy. There should be ways to recover from backups of a service goes offline, but we can't expect everyone to make good decisions. Not to mention having passwords synced between devices and available on demand is really a requirement of you use random passwords for every site and need to log into something (heaven forbid) on someone else's device.
  - TedDoesntTalk 6y ago
    > [effective and meaningful] Security is hard. We should build systems that make it easy These are in direct conflict with each other.
    - bsder 6y ago
      Not necessarily. What's your threat? Most people are not trying to stop a determined attacker. Most people just want random people to not get be able to get into their stuff--same as a physical lock. They carry a physical key on their person. It's not too much to ask them to carry a "digital" key on their key ring. The problem is that most "digital" keys are a pain in the ass: 1) Mostly because everybody wants to "centralize" authentication so that they can charge you and administrate you. 2) Secondarily because there is no good solution for talking to the key on your person. NFC sucks. USB requires that I plug my key in. WiFi requires that the device be able to hit your network. BLE has no access from web pages. BLE is probably the best choice, but there is no real money in making it work.
      - senectus1 6y ago
        Any tool used to create another tool, is the very tool that will be used to help dismantle that other tool. There is no way around this... Security isn't a state, it s a process. It relies on the human to propagate it. A bit like a garden. Make the process simple for the user (but not thoughtless) and that is about as good as is going to get.

quicklime 6y ago

I hadn't heard of either Promise or IndieAuth before reading this thread, so apologies if this is a dumb question. But one of the benefits of Promise is that it's pseudonymous: > You will get a unique identity pr. service you use. This ensures that relying parties have no way to profile you across services. For me, this is actually the biggest reason that I stopped using social sign-ins. It's not that Google might disable my account one day; it's more that I don't want Google or Facebook tracking me. How does a decentralized system handle this? If my identity is my domain, doesn't that mean that all these websites now have a unique id which they can use to join together all their separate pieces of data about me?

anderslemke 6y ago
Being pseudonymous is one of the main selling points of Promise. Only by being pseudonymous can it provide the level of privacy that should be expected from the global authentication infrastructure that Promise wants to be.
- account42 6y ago
  Does Promise get to know which sites you sign in to?
  - anderslemke 6y ago
    Yes. Promise keeps a map of your sites and IDs.
    - s_gourichon 6y ago
      Isn't that a problem, like "let's get rid of Google and all the evildoers because they know too much about us" then "oh we realize we created another one which knows too much about us"?
      - anderslemke 6y ago
        I get where you're coming from, and this is something I've been thinking a lot about. It would be possible to not save the map, and then use some kind of hashing to infer user ids for each site. I chose not to do this, to be able to guarantee no collisions. This might be silly, though. But the thought of people with colliding user ids makes me giddy. The data stored looks something like this: { "ids": { "example.com": { "07c5c163-875f-424c-a659-a4f99e74eb12": "default" }, "other-example.com": { "ab38b2a6-d560-43d3-b2a3-9148cd91d1b4": "default" } } } Worth noting is, that there is no personally identifiable information (PII) here. But we have to have the discussion if this is "too much" data to keep about a user. AFAIK this is the bare minimum of data needed, to be able to guarantee no collisions of user ids. If there is another way to do it, we should do that!

anderslemke 6y ago

I'm a bit divided on whether or not the "centralized" thing is actually a problem Promise should tackle. On one hand, I want to tell you that Promise is only centralized by default. Which is good for people that doesn't understand what a OpenID/IndieAuth Provider is. But as Promise is open source and the protocol caters for it, it is possible to have Promise redirect authentication requests to your own instance. Which then redirects you back to the relying party you want to sign in to. So it is possible to decentralize if that is what you want On the other hand, I'm not sure it's a good idea to do it. Centralizing gives a lot of benefits. User experienc being one, but also being able to roll out eg. security updates quickly. But sure, centralization also creates problems. But until now, I have a feeling that the problems with centralization, can be solved by other measures than going decentralized. Eg. being a non-profit organisation owned by the relying parties. This would guard against a lot of the problems with being centralized. And I'm still to encounter a decentralized solution with a reasonable user experience for most people. OpenID, IndieAuth, SQRL, re:claimID, I'm looking at you. Sorry.

mawise 6y ago
You're right that the user experience is a huge blocker, but I think that's something we as authors of tools can improve on. For example, there's a Wordpress plugin that lets your Wordpress site act as an IndieAuth identity[1]. That makes it pretty usable from and end-user perspective. The challenge with centralized is that it is a single point of failure. The original post was more focused on "If you get locked out of google, you get locked out of everything". In that vein if promise gets hacked/bought/abandoned/changes it's business model etc.. then you lose all your accounts. The anonymous nature of it is great, but this is something Apple already offers with their sign-in with apple which is already widely supported and with the proxy-email solution you can still be contacted by the sites you're signing up with. I got interested in IndieAuth because of a project of mine[2], trying to make it really easy for everyone to self-host their facebook/twitter equivalent with direct control over who has access. This runs into the problem with wide adoption where you have a separate credential for each of your friends' blogs. With IndieAuth built into the self-hosted platform, then your own self-hosted site becomes the one credential you can use on all your friends' sites. Self-hosted distributed identity for privacy AND ease-of-use. [1] https://wordpress.org/plugins/indieauth/ https://wordpress.org/plugins/indieauth/ [2] You can find the link in other comments I've made on HN