Comment by betwixthewires
4 years ago
So the thing about this is that there is no need to permanently tie identity across all sites and services you used (and provide), rather, the ability to do so when and where you need to do it.
There's nothing requiring a user to use the same identity across every service they interact with, but the option should be there. I wouldn't want my matrix username(s) and my fediverse account(s) tied to my HN username(s), but I might want a github/gitlab/codeberg account tied to a social/messaging account while having different "personas" for different applications. Overall it's a useful tool to have in your belt, so long as it doesn't limit you in other ways.
So if you are not going to go whole-hog and have one true identity for everything, why bother using anything apart from an email address?
The argument seems to be that consistency allows you to prove ownership and re-use all of your content etc across the web by tying everything back to one verified identity. If you are having different identities on different sites then that benefit disappears, and I fail to see how it is then any better than using email addresses? You end up with different wallet IDs each with their own island of content, just like you have with email addresses.
Sure you could chose to "move" content with one of your many identities by just logging in with the ID (presumably losing all of your existing content), but we have copy-paste for that already (and I am only half-joking saying that...)
Well I thought I explained it effectively, but there are numerous scenarios where you'd want to use the same identity across multiple services, cross sharing of data, provable rights, etc. But that doesn't mean you're limited to one, or that you want to use it for every service you use. The benefit doesn't disappear, the benefit only applies when you want it. It isn't all or nothing.
You just described OAuth/OIDC.
11 replies →
Email addresses aren't really good for this. It's really easy to sign up for a service with someone else's email address, for example. Sure, if that person ever finds out they can potentially claim ownership of the account through a password reset, but it doesn't erase the fact that you have been using their "identity" for some time.
Is this still a thing though? Pretty much everything I've used in the past 10-15 years has required email validation before allowing you to do anything meaningful.
Either way though, I don't see how an account claiming to be "wan23" would be any more trustworthy to me as created off of the back of an email account or off of a wallet ID - I still have no idea (nor do I care) who you are.
1 reply →
> Email addresses aren't really good for this. It's really easy to sign up for a service with someone else's email address, for example. Sure, if that person ever finds out they can potentially claim ownership of the account through a password reset, but it doesn't erase the fact that you have been using their "identity" for some time.
This is also true of a private key, in fact it's literally the same scenario...
1 reply →
That's what email confirmation is for. Let's you confirm possession of the email account you enrolled with.
For one thing, I don’t have to deal with every new website’s crappy signup and email confirmation flows, broken password reset flows, login forms that deliberately break password managers, etc. Obviously Web3 has nothing directly to do with these things, but a consistent auth system becoming ubiquitous could be inherently nice.
Your wallet is your identity, and so can directly be tied to web3. It could be implemented in alternate ways as well, but that's one situation that web3 can already handle. (Sort of. Password (private key) resets aren't a thing, yet.
It doesn't give you that ability though. The reason we use Google and Facebook OAuth is because Google and Facebook did their due diligence with the account. We would just accept any OAuth provider if we didn't care about that validation.
And again, with these web3 identities, centralized services would still be providing the authorization even if they did not provide the authentication. I don't see what web3 identities provide.