I came across OneName a few days ago. OneName is a namespace in the Namecoin blockchain and associated JSON schema for decentralized identity. It seems like it would be an interesting alternative to Discourse Hub for Discourse installations.
The project has built a web “explorer” for the namespace hosted at http://onename.io - but the actual identity info is in the u/ namespace of the Namecoin blockchain.
@codinghorror OneName is a decentralized identity system. One of the possible applications of this is a decentralized auth service.
The benefits of this are well known - users have true control over their data, users are not tied down to any one application/service/company for auth, apps can share data and build off of each other, etc.
We’re currently working implementing OAuth 2 and when that’s ready, we’ll have an open auth service, which in my view fits well with the goals of Discourse.
Apologies for not replying earlier. Was stuck behind the Great Firewall.
@ryanshea is one of the people involved in OneName, so suggested he jump in the thread, since he knows more about this than me. I’m just an interested user.
The benefits for the user as I see it are:
Same username across not only many Discourse forums, but also any other app/site/etc that uses the name space.
Ability of user to update identity info (avatar, blog, short bio, handles on various social networks, etc) in one place (their OneName namespace in the Namecoin blockchain) instead of hundreds of sites/apps that they have accounts on.
Ownership of this info: my identity is my own without regard to the jurisdiction that the forum may be operated in, Civilized Discourse Construction Kit is operated in. Someone can’t come along to a user in China and say “Hey I have a trademark on your username in the USA, we’re going to make Discourse Hub give it to us” (To be fair, I think 99.9% of users just won’t care about this)
For forum owners:
Same benefits of Discourse hub
No need to depend on a 3rd party service (Discourse Hub) with whom they may not have (or want to have) a business relationship with for global namespace checking. They could run their own namecoind instances, make api calls to onename.io or any other site that wanted to provide an api to access information in the namespace.
No need to leak information about their forum sign ups to a 3rd party.
I know global usernames aren’t mandatory and forum owners could get benefits 2 & 3 by just turning off the feature, but OneName (or something like it) let’s them have then benefits without giving up the feature.
For the Discourse project: support an up and coming open source project that could turn into the DNS of identity - but without the ICANN.
I agree with @codinghorror as well that the benefits are OAuth2 login aren’t well known. While I won’t go so far as to say that 3rd party login is dead, OpenID certain didn’t become what it started out to be and many (most?) sites that accept Facebook, Google, et al. login also force users to create local credentials.
As a user I hate being redirected back and forth between sites.
As a site operator, I dislike having the login experience of my users controlled by some 3rd party (who is likely using my users as their product). I also don’t like having to spend time supporting those who can’t log on when whatever third party login they chose decides to stop working. As a devops guy, I don’t like adding external points of failure.
But this particular topic, I think the distributed identity aspect is more interesting because it seems to have similar goals as the Discourse Hub with potentially wider application not just limited to Discourse instances.
If OneName develops an OAuth2 open auth system, that’s something Discourse can already support via a plugin/pull request.
@codinghorror, apologies for the brevity and lack of clarity. @larry did a great job expounding on the benefits of a decentralized identity/auth system like OneName.
It can be very convenient for both users and app developers to use a global username system. Users don’t have to pick a new username and app developers don’t have to think about this component of their service
Think “gravatar” for all user information.
I’d add that a service like Facebook or Twitter cannot revoke usernames either. Nobody can.
Yes, I understand the concern. It’s not my favorite experience either but all the auth services use it (Facebook, Twitter, Google, etc.).
There is also potential for rethinking the experience. There are ways to do auth with OneName without requiring a redirect.
With OneName, there is no “third party,” necessarily. And nobody can decide to turn off OneName, as it isn’t run by anyone. Your concern about not adding external points of failure is a valid one, but the simplicity of the system means that I don’t think it is as big of a deal as you might think at first glance.
Discourse could be a OneName registrant. The steps would be:
Discourse registers a name on grandma’s behalf and pays the $0.07. We can provide an API for this. Also, the cost of 7 cents will decreas
Discourse has grandma pick a password and emails her a copy of her private keys encrypted with her password.
The downside of this model is that if Grandma loses her password, her private key cannot be recovered. A secure backup system would be needed to provide additional protection.
Currently, you can require grandma to present a signed message using her private key (a service can facilitate this), but in the future, an OAuth 2 model could be used instead.
Identity verification is important here. Users can link their twitter, github, facebook accounts, etc. to their OneName profiles. If their private key gets lost or sold, they can unlink their other online accounts.
@ryanshea How does a user authenticate ownership of the name? Does the namecoin protocol allow you to sign a message demonstrating ownership of a particular key/name? (I guess this would be like using a BitCoin wallet’s private key to sign a message demonstrating ownership of it, but I don’t know if that’s how it works.)
Is the passphrase used by onename.io using some kind of standard way of deriving a key, such that the same passphrase could also be used to modify the record by other namecoin/onename clients? (i.e. does onename.io create any sort of lock-in?)
I find the idea attractive, I just want to make sure I understand the way it is decentralized.
I see just 1 very practical benefit to the user here:
Pick your name. Whatever it is. It doesn’t matter if anyone else picked it already. We can, just like in the real world, have 100 of Mikes. In discourse, if you’re the only @mike in the room, you’ll be the only one notified. Else, well, it’s like calling for “Mike” when there are many there. You’re free to pick a different nick at anytime. There’s no @mike in the room? There could come up a list based on mikes you frequently talk to, so you can pick one and shout out for him.
The other alleged benefit is not so practical in reality today. It’s actually an annoyance:
Forgot your password? Wait, there is no need for passwords! And you don’t have to share your data with Google or Facebook. And no redirecting back and forth. It’s a simple authentication process, much more secure than anything else, and if you’re a power user, you don’t even need a password manager anymore. How? You only need to keep your key safe.
That’s the problem, right there. How can you make grampa keep his key safe? Or remember a password only him can remember? What’s worse: you lose that single one passkey means you lose access to everything?!
A combination of U2F with biometrics might be getting close to the answer. But maybe we’ll never be able to come up with something that can scale up properly, without an Ai better than whatever we have today anyway.