Ethereum community has solved a major problem of the Internet: Single Sign-On
twitter.com
twitter.com
The actual last thing in the world home users want is an authentication system where credential loss is literally irrevocable.
Meanwhile, the real market for Internet SSO is at companies, and one of the major reasons companies deploy SSO is to have policy control (particularly: onboard and offboarding) of who has access to what. A globally distributed authentication fabric is actually an anti-feature for those people.
The actual last thing in the world corporate users want is an authentication system their IT department doesn't control absolutely.
Part of what's happening with ideas like this, and the reason Internet identity has been such a tar pit for the last 20 years, is that there isn't one single service model for identity. Internet identity evangelists tend to overlook the fact that people have multiple identities on purpose.
Scones sounds tastier.
By the way, on a Mac you can just force press on any word, it gives a definition. Very useful.
This is generally a concern I have about blockchain technology. What if it succeeds in its goal to play a major role in some sector, and something immensely important becomes attached to it.
Mistakes happen. Both by humans and by computers. Software having bugs, hardware failing, bits randomly changing in RAM, are all obvious and commonplace. Mitigations exist (ECC, signatures...), but never along the whole chain. For example, BTC addresses might have checksums, but if the wrong row in a database deciding the address is selected in the first place, through human, software, or hardware error, that will not matter.
Do we want to attach extremely important things to a system that is by design irreversible?
Another example: Let's assume ownership of a house is defined by a blockchain. Through a mistake, ownership of your house has been transferred to someone else, or lost to an address with no existing private key. Alternatively, you were in the process of buying a house when the same happened.
Would you be happy with the outcome of this simple mistake being irreversible?
If not, and if you think litigation should retransfer ownership to you, what is the value of an immutable ledger, if the house went to a malicious party who does not intend to perform the transfer on said ledger, or to an address without private key, making transfer not possible in the first place?
I've thought about this a lot, and I think the solution is to use something similar to "social recovery wallets" [0], but with a dao (group of people) as the recovery mechanism. Basically, assume that the blockchain has the correct owner, and require very strong proof to overturn. This has the advantage of making 99.9% of transfers very cheap, rather than 100% of transfers expensive as is now.
RealT is a company that sells "tokenized" real estate, and they do something like this. They assume the ownership on the blockchain is correct, but you can contact them, and they can overturn ownership if you prove that it was stolen or transferred erroneously. I'd personally take this one step further and have a group of people in the community that oversee the process (basically a court, but a lot more efficient and transparent).
I find it hard to reconcile "99.9% of transfers very cheap" with the property that at least proof-of-work and proof-of-space actively rely on literally counteracting any effort at becoming more efficient.
"Classical" distributed ledgers in databases are not already more efficient by several orders of magnitude, they are made more efficient through advancements of technology, and those efficiency gains are actively sought out by participants, given that they usually directly translate into profit through reduction of overhead.
Currently when you buy a house, you have to go through a decent amount of effort both in time and money to essentially determine "who owns this house, and are there any liens on it". By using tokenized ownership, you can get rid of this part. Yes, it's not ideal that someone can override the ownership, but it's setup in a way that requires extensive effort and documentation to do.
Ideally the party that could overturn ownership wouldn't be a company, but instead would be an elected, large group of people that determined this. And maybe there could be a way to opt out or select an alternate override?
The point is that this system can be a ton more efficient, enable additional abilities (fractional ownership, instant, extremely low fee loans, etc), all things that the existing system does not allow. Yes, allowing ownership overriding isn't ideal, but I don't think allowing a group to override ownership in a transparent way completely negates all benefits of a system like this.
> I find it hard to reconcile "99.9% of transfers very cheap" with the property that at least proof-of-work and proof-of-space actively rely on literally counteracting any effort at becoming more efficient.
Ethereum will be moving to proof of stake in a year or 2 (> $10B are locked up until this occurs, so I am very confident it will happen).
If you do not trust the authorities of the locality, e.g. the courts, to properly assign ownership and, more importantly, to defend your claim of ownership through further legal action, then how do you trust the blockchain implementation with its share of elected people and override mechanisms to do the same?
> Yes, it's not ideal that someone can override the ownership [...] Yes, allowing ownership overriding isn't ideal, but I don't think allowing a group to override ownership in a transparent way completely negates all benefits [...]
The assertion already is that mutability and reversibility are necessary and desired properties under the assumption that mistakes and mis-assessments happen, whether through human error or technological failure. The question is, what benefit does a blockchain bring over a regular database under this requirement?
> Ethereum will be moving to proof of stake in a year or 2 (> $10B are locked up until this occurs, so I am very confident it will happen).
I know proof-of-work down to the very detail, I have not yet looked at proof-of-stake. If proof-of-stake exists, and does not share the same problem of massive inefficiency (directly or indirectly), then I still think that a classical database solves these problems more easily, but I cease to care what solutions stakeholders choose. Proof-of-work, on the other hand, makes me and everyone else an unwilling participant in this scheme through unnecessary, and growing, consumption of energy and resources.
With a database, you can only do what the county auditor (or equivalent) lets you do / what their ui lets you do. With a blockchain, you can build things on top of it, fractionalized ownership, simple transfers, etc. It's basically a permissionless database that anyone can build on top of vs a database shoved in a closet at the county auditors that you can only use via their api and ui.
Cars/planes/rockets seem to be fixable most of the time, or at least we would prefer them to be. (The last one is probably the least-easily fixable, and that is generally considered to be a negative attribute -- something to be mitigated, not celebrated -- and requires careful and even over-engineering because it's so hard/risky to fix a rocket in space.)
Or, perhaps I am completely misunderstanding your point?
Human life is both extremely important, and the loss of it is irreversible, at least for now :). People generally seem to be willing to take risks for the sake of convenience.
But in the end I believe we should be able to have our cake and eat it too - that is benefit from blockchain tech with safeguards preventing such scenarios
Problem here is the hard work needs to be done at the beginning. E.g. picture your grandparent needing help using the below.
As a power user, I like it.
Social recovery wallets: https://vitalik.ca/general/2021/01/11/recovery.html
Fortunately there’s little chance of blockchain as in cryptocurrency succeeding outside the scammers and their marks.
That's not much different than git frankly for any given open source project.
Chain splits are more like a consensus failure and could be likened to a religious scism.
It’s generally undesirable and so are forked coins. There are many many fork coins that nobody cares about.
Ok, well, how many times has the main bitcoin chain had a, uh, so there was the fixing some underflow really early on iirc, I think that counts, but I think that was a soft fork? Has the main bitcoin chain ever had a successful hard fork? I don’t know.
Anyway.
For example 8 keys where each has the weight of 1 and a signing threshold of 4 is required. That would mean form the 8 keys (persons) a maximum of 4 can lose their key. On top of that you may still have a master key that overrides all. Or you could lock 4 of the 8 keys in different places not meant to be used but just as backup for the 4 keys in use.
This stuff already exists. See [1] https://xrpl.org/multi-signing.html
There are almost endless possible solutions that could be implemented if needed. For example you could make a master key that overrides all others but requires an unlock Tx followed by an arbitrary escrow delay where funds are locked. This would be useful if a master key is stolen. As soon as someone uses it, it would be known that the key was stolen so the people with the multi-sign key could move the funds away before the funds are unlocked.
You could also make funds move to a previously defined rescue address after a while of inactivity. So in case the key got lost the fund would move to another address you just have to wait. And if the keys are not lost the time is reset every time a Tx is signed. Kinda like a dead man's switch. So people can inherit your funds if you are unable to sign a Tx.
The possibilities are kinda endless. If there is a need for it it can be coded.
> For example you could make a master key that overrides all others but requires an unlock Tx followed by an arbitrary escrow delay where funds are locked.
At what point is switching to a more classical database both worth the increase in efficiency by several orders of magnitude, and the decreased reliance on bug-free code?
But since its not a smart contract in the first place, the burden for code to be added is high. While everyone can code something, it has to go trough the amendment process and reach 80% support for 2 weeks before it actually would be applied. There is basically zero chance that something would get 80% support if the active developer team would question the code quality. Every code goes trough audits and runs on the test net first before people even consider to make the amendment. Still bugs happen and if you look at the change logs [1] you can see bug fixes are common for each new release. Most of these bug fixes dont affect the ledger logic but are just bugs in the node software. So funds can not be lost but in a worst case scenario it could temporary halt the network if such a bug crashes multiple nodes at the same time.
[1] https://github.com/ripple/rippled/releases
>At what point is switching to a more classical database both worth the increase in efficiency by several orders of magnitude,....
Thats a strange question. That point "is reached" whenever you dont need a blockchain/distributed ledger but instead have situation where the whole system is run by one entity or by a few who have legal agreements with each other. Its like asking at what point you simply write data to a file instead of to a database. There are tons of config files out there and no one suggests that we instead use a database. So why would someone ever switch back from the database to a simple file? Its p much a made up situation that never happens. There must have been a reason to use a database and that reason would need to go away.
Same for DLT. If you dont need it there is mostly no point in using it. There are a few exceptions for example you could use the XRPL to store tiny bits of data for communication between otherwise autonomous systems. The benefit here isn't blockchain/DLT tech but rather that fact that you dont need to maintain servers and the fact that the XRPL has probably the highest uptime of any public internet "storage" you could use. If that is critical then it may be a valid reason. You get the 5 9s (99.999%) uptime that you simply can not buy for cheap anywhere. But again if you dont need any of the specific properties of a DL there is no point using it and comparing it to other tech with other properties.
> This is an extremely solved problem.
Not with the properties of Sign-In with Ethereum (SIE), which is single, user generated authentication credentials, a self-custody portable username in a naming system that isn't reliant on a trusted-third party, and that people are already getting for other reasons (to use Ethereum, so extra incentive to get set up, not just SSO incentive).
> ordinary home users are effectively tethered to their email accounts, because that's how you reset a login
Yep, and I don't expect that to change very much anytime soon, but there is a small but growing community of people tethered to their Ethereum wallets and ENS names and using those instead. Given the advantages and crypto incentives, I expect it to continue to grow. Note also that service can always re
> The actual last thing in the world home users want is an authentication system where credential loss is literally irrevocable.
Doesn't have to be. Depends on how your wallet provider works. There are already some wallet providers with social recovery, etc.
Note two other key things:
1) Crypto incentives (unrelated to sign-in) mean that the private key management industry ("wallet" industry) is already highly incentivized to make it very difficult for people to lose access to their accounts (because then lost money). That's part of my point: private key management has never been good enough for average people, but crypto incentives have spurred on an massive industry to solve this problem. And while it's not solved (still needs improvement), it has improved rapidly in the last five years to be much better than ever before, and I expect it to continue to improve.
2) What I've described is just on the user side. If a web2 service adopted this, they can always do things like require you provide an email address or other information, and they can still have a process for reassigning your account with them to a different Ethereum account.
> The actual last thing in the world corporate users want is an authentication system their IT department doesn't control absolutely.
Again, depends on what you want, you can make it so that a third-party has access to all of your company's employees Ethereum accounts.
> Internet identity evangelists tend to overlook the fact that people have multiple identities on purpose.
Yep. I don't expect this to replace everything else immediately, but I do expect overtime for this to become a ubiquitous option, such that a user could use their one Ethereum account everywhere if they wanted to. Also, re the need for multiple identities: as i point out in the thread, a person can generated as many Ethereum accounts and have as many ENS names as they'd like.
> This is an extremely solved problem.
Not with the properties of Sign-In with Ethereum (SIE), which is single, user generated authentication credentials, a self-custody portable username in a naming system that isn't reliant on a trusted-third party, and that people are already getting for other reasons (to use Ethereum, so extra incentive to get set up, not just SSO incentive).
> ordinary home users are effectively tethered to their email accounts, because that's how you reset a login
Yep, and I don't expect that to change very much anytime soon, but there is a small but growing community of people tethered to their Ethereum wallets and ENS names and using those instead. Given the advantages and crypto incentives, I expect it to continue to grow. Note also that service can always require a user to also provide an email address, it just wouldn't be used for authentication.
> The actual last thing in the world home users want is an authentication system where credential loss is literally irrevocable.
Doesn't have to be. Three things on this point:
1) Depends on how your wallet provider works. There are already some wallet providers with social recovery (multisig under the hood), etc.
2) Crypto incentives (unrelated to sign-in) mean that the private key management industry ("wallets") is already highly incentivized to make it very difficult for people to totally lose access to their accounts (because then lost money). That's a key part of my point: private key management has never been good enough for average people, but crypto incentives have spurred on a massive industry to solve this problem. And while it's not totally solved (still needs lots of improvement), it has improved rapidly in the last five years to be much better than ever before, and I expect it to continue to improve.
3) What I've described is just on the user side. If a web2 service adopted this (not aware of any right now, it's pretty much just web3 services that use it), they can always do things like require you provide an email address or other information, and they can still have a process for reassigning your account with them to a different Ethereum account.
> The actual last thing in the world corporate users want is an authentication system their IT department doesn't control absolutely.
Again, depends on what you want, you can make it so that you have access to all of your company's employees Ethereum accounts.
> Internet identity evangelists tend to overlook the fact that people have multiple identities on purpose.
Yep. I don't expect this to replace everything else immediately, but I do expect overtime for this to become a ubiquitous option, such that a user could use their one Ethereum account everywhere if they wanted to.
Also, re the need for multiple identities: as I point out in the thread, a person can generated as many Ethereum accounts and have as many ENS names as they'd like, using their real name or pseudonym, or whatever they'd like.
Anyway, sorry for long comment, thanks for engaging!
I don't doubt that there are things you do to facilitate account recovery on immutable distributed ledgers, but it just seems pretty clear to me that you're working against the design of a blockchain when you do that; the blockchain isn't doing much that centralized systems aren't already doing, and they're doing a lot that gets in the way.
Certainly, I wouldn't want to be the person whose job it was to explain to a SOC2 auditor how my company's Ethereum SSO system works.
I wouldn't stake real money on the value of ETH or BTC; the market can stay irrational longer than I can stay solvent &c &c. But I'd probably make a real bet on blockchain-mediated single signon never achieving significant adoption, for some reasonable definition of "significant".
Additionally, they want decentralized logins. People use logins of work and their phone all the time. No work environment is going to give control out to help their employees for example.
No SAAS wants to be unable to help their users.
They mention that DNS isn't meant to be about auth and then they talk about signing your identity with your wallet private keys. I want that to be totally seperated!
And blockchain isn't meant for sso either.
So many people just won't understand any if this, this is just a dead born baby from the start. The statement "many people use this" is probably insignificant in relative terms. I'd be surprised if there are 50 on Belgium in a population of 10 million.
Urbit's approach seems pretty good for this? They use Ethereum to manage ID ownership/transfer, but they generate pseudonymous IDs by default (the user can decide if they want to connect them to their real name). They also have a small, but non-zero cost making them not really economically viable for mass spam - people hold on to them and develop reputation with them. There's a lot to like about that model (I think it solves a lot of these issues while also not having the IDs entirely owned by one company).
You'd think that, but I can't remember how many people have asked me how to implement mutual authentication using whatever random client certs their partners send to them and who don't realize that putting all those issuers in the SSL handshake bloats the heck out of it.
So they may well end up both accepting every random client cert issued by Entrust, Verisign, etc. and then advertising that fact to the world with every SSL handshake.
Most people still use the same password (or password management device, or physical MFA device) for both their work and personal logins. This is evidence that most people have the same identity, as would be intuitive. I’m not sure what the bigger picture is, but password secrets are the single service model for identity.
I also take issue with:
>Ethereum is giving average ppl computer generated public/private key pairs...
'Average' people aren't into crypto. And the average computer user doesn't know how to use asymmetric keypairs.
Anyone want to try to explain asymmetric keypairs to mother-in-law who's in her 70s and needs help applying Windows patches? I sure don't. And I spend my days in SAML and OAuth world.
If IT professionals--who are presumably above average in IT knowledge since it's what pays their bills--don't uniformly understand how to handle asymmetric keys, what hope do most non-professionals have?
Do I know the exact profile of what the average computer user is? No, but I'd bet a paycheck that it doesn't include using crypto or private/public keys.
Average people didn't know how to use email 30 years ago. Didn't know how to use GPS 20 years ago. Didn't know how to use social media 15 years ago. Didn't know how to hail an Uber 10 years ago (and still thought riding in cars with strangers was dangerous).
I think they can be educated.
Protecting the secrets words for a crypto wallet is pretty much the same thing as protecting the strong password for a password manager. If you lose that, then you're out of luck, and those are very popular.
You could also delegate trust in several places in the chain to trusted third parties if you feel the need, that could re-enable access, or shift assets into a new wallet.
Yep. Note that ENS is an open source self-running protocol, i'm really the dir of operations of True Names LTD, the non-profit that de facto manages. Funds raised from .ETH name registrations/renewals don't even go to TNL but to an Ethereum community multisig (never spent, but plan is to use it for long-term ENS dev funding). I'm thinking about these things precisely because I'm working on the project.
>'Average' people aren't into crypto. They increasingly are
>Anyone want to try to explain asymmetric keypairs to mother-in-law who's in her 70s and needs help applying Windows patches?
You don't have to, just like you don't have to explain to her how TCP/IP works. You just have an account and it works.
So another point for not worrying about a mother-in-law in her 70s as various solutions get tried and more stacks get added to the stack
This one is hilariously complicated; the thread ends with this call to action:
Want to get a portable web3 account?
Pick an Eth wallet: https://ethereum.org/en/wallets/find-wallet/
Get ETH (sometimes built into wallet, otherwise use a service like Coinbase)
Get an ENS name: http://app.ens.domains * (Choose which is your username by setting reverse record at My Account)*
It's that easy!
I think the author underestimates how little most people care about their weak passwords, or centralised authentication.
Yep, I agree SSO by itself isn't enough of an incentive to use something. A key part of the thread is that that's not what's happening. People are getting Ethereum accounts and even ENS for other reasons, and the fact that this is being used for SSO is a side-effect.
>This one is hilariously complicated; Yes, but this is getting simpler over time. Better than it was a few years ago, still clunky, getting better over time. That is what crypto incentives is doing to pub/priv key management and related things. Again, this is a key part of the thread: crypto is incentivizing adoption and improvements in tech that existed previously but people didn't have a strong enough incentive to adopt or improve.
sigh.
It's a bug, not a feature. It's people throwing away their privacy for convenience. It's proverbial dancing piggies.
Problem with global-scale SSO is not corporations, that control shared identity. It's shared identity itself.
Distributed SSO is as good idea, as eco-friendly vegan huffing solvent.
SSO outside of such closed realms, i.e. in the open Internet, rather only seems to be a "problem" because people don't want to adopt it. Instead, password managers are the solution that won. The Twitter thread mentions "No sweat: you can have as many Eth accounts as you want w/ different ENS names", but if you end up having one (or more, see throwaway accounts on Hacker News) accounts for each site anyway, why go through the trouble with public/private keys, when the random shared secret in your Password Manager works so well?
Unless you have multiple devices, in which case it feels like you’re logging in constantly
Am I missing something or is this just a fancy way of having a single password that gets you access to everything, and if compromised would be utterly devastating.
> No sweat: you can have as many Eth accounts as you want w/ different ENS names
https://twitter.com/BrantlyMillegan/status/14023881680418119...
As a result, reserving a name on ENS costs 120$ a year. Few people would be ready to pay that to get a username.
For .eth names, you can pay ahead as many years as you want, so you can pay once and forget it about it.
The you likely got to $120 is that there is also Ethereum network gas fees to pay to registration a name. That's a one time thing and fluctuates a lot. Since you can register for many years at a time, you can pay the gas fee once and get the name for many years. We're also working on putting parts of ENS on L2s to cut down on gas fees dramatically.
Not your keys, not your life sounds awful.
For what it's worth I think the whole effort is wrong-headed except in some pretty niche areas of credentialing, somewhat for reasons you allude to; but it's weird context to ignore.
I am not so sure this kind of authentication will really catch on - the UX of Metamask and other wallets is just atrocious for say my father.
BUT I do happen to like to connect to a site just with my ETH wallet, it is much nicer than using username/password or handing over ALL your data to Google for the OAuth convenience. It's a bit sad that the web is no longer a place for people with basic tech literacy, I'd love to use my Ledger Nano everywhere.
I also was really fond of Civic for KYC and stuff, but it's gotten awfully silent.
If the sign-up process was as difficult for the small services as it is with Google or Facebook, users would give up. But users already have Google/FB accounts or know it's worth it to have one, so they don't mind the process for Google/FB.
For now, there's no accepted standard identity mechanism attaching to ETH wallets. It's not a trivial problem either. If while reading this you just had some idea how to quickly solve it, chances are someone had it before and it's vulnerable to either centralized control or user abuse. ENS might work at deterring spam but it's way too restrictive for now.
On the other hand, cryptowallet based sign in systems generally don't give you a verified way to contact the user, but they do allow you to see if the user has put money behind this identity. That could be an interesting way to reduce sybil attacks. Having an email address does not mean much in terms of level of buy in to a particular identity (and that, much more than 'real names' is key for managing behaviour).
“The Ethereum community has accidentally solved a major problem of the Internet - https://news.ycombinator.com/item?id=27473889 - June 2021 (14 comments)
ENS isn't needed strictly speaking, but highly useful to make everything human-friendly. It's like saying DNS isn't useful because you can just input a website's IP address.