Hacker News new | comments | ask | show | jobs | submit login

This is the problem i-names are intended to solve.

An i-name is a short name that looks something like =name. So instead of your OpenId URL, you can type in =name in any OpenId form and it will log you in as usual.

So instead of name.myopenid.com, I'm =name.

There are registrars who sell an i-names for relatively cheap. (There are also free ones.) The i-name points to the broker's lookup service. In their database, your i-name is associated with a unique number that you keep even if you let your name expire.

That entry points to an XRDS document, and that document tells the login form a number of things. Most importantly, it tells it your OpenId URL. It also provides a series of forwarding addresses that look like this:

Et cetera.

My favorite is =djacobs/(+contact). It points to a page on my broker's site with a contact form. This contact form knows my e-mail address, and people can use it to e-mail me without finding that address out--like any other contact form. More importantly, the form comes with useful spam-fighting settings, options like "don't let anyone e-mail me without an i-name of their own".

I happen to think i-names are pretty cool and will tend to make everyone settle on one ID. Maybe a good vocabulary will come out of the forwarding syntax, and we can approach a loose Semantic Web using i-names instead of URLs and triples.

Caveat: As of now this is painfully tedious to set up for the average user. Eventually, though, people will see the merit in this approach, and more competition in this market will drive a user-friendly setup.

For now, it's just for hackers.

How is this in any demonstrable way better than a username and password? I can't even imagine trying to explain how to use this to my parents.

Your mother doesn't need to understand it. I gave the technical details because this is Hacker News. Brokers need to make setup simpler, yes. But even today, logging in is as simple as typing =djacobs.

Or I could type nkohari and a password...

Exactly. This eliminates 50% of the hassle. Maybe 75% of that if you consider having a single name to type in on any site on the Internet.

I don't understand how that's the case. You still need to authenticate with your OpenID provider using -- you guessed it -- a username and password.

Or, you could allow your provider to put a persistent cookie on your machine, and (as we've seen from the Firesheep news lately) making it that much more likely your identity will be compromised. (Not to mention if someone steals the cookie for your OpenID provider, the impact is potentially much larger.)

The i-name stuff is just DNS for OpenID providers. It adds another layer of bullshit on top of layers of bullshit that don't need to be there in the first place.

I carry the key to my car. When I want to get in, I press the button on the fob or I open the door with the key. OpenID is like having to make a phone call to someone, tell them I need to get into my car, so they can then press a button that will open my car door. And hopefully they aren't on their lunchbreak.

If I had 60 cars scattered around the city, well, I'd want that phone service.

Security issues are not unique to i-names, and I think the abstraction layer (removing a domain name from your login) is important and useful.

Disagree if you must.

And to think I was going to joke that what we need is an OpenIDID standard to manage our OpenIDs for us.

I mean the whole thing is ridiculous, yes. OpenIds should have been names and not URLs from the start.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact