More on identity

Dave Winer wrote a blog post titled Using DNS as a thin ID system . I encourage you to go read it, but in essence his main gripe is that the current means of identifying a person online are too complicated.
And I agree, but with a caveat: there is clearly a need for a simple identification system, while the need for (and current existence of) more complex ID systems is also there.

Winer postulates that the DNS could be used for the simple ID system. Let's call it SID for short. Here again I have to agree he's on to something, since when we designed the .tel top level domain, that was a primary goal.
However, with .tel we started by the complicated stuff, implementing all the current stuff like OpenID et. al., and also implementing a unique, original encryption system for sharing private information inside the DNS zone itself.
So now in the spirit of bootstrapping and getting something up quickly, here's my implementation of Winer's SID:

http://passw0rd.henri.tel

Here's how it works:

• Assume you don't know the above URL
• I go to your site and want to authenticate myself
• you ask me for my domain name (henri.tel) and password (passw0rd)
• you look up password.domain
• if you look up using DNS and it returns NXDOMAIN, then authentication failed
• if you look up using HTTP and it returns 404, then authentication failed

That's about it.

Oh, one more thing: inside passw0rd.henri.tel there are a number of interesting records of type NAPTR that point to my different web properties. There are also TXT records that define my name and current work. If you're looking it up via HTTP, you'll get that info in the hCard of the resulting page.

All of this, today, is available to any .tel owner, without any need for knowledge of DNS or anything beyond knowing to uncheck the "create a link" box in the below screen:

That's all there is to it.

Now the purists will say that this identification system lacks much more than it provides. I agree. If you want OpenID, my henri.tel domain is an OpenID provider as well.

But here, we're looking for a dead simple way of knowing that the person is the same person who came last week. We don't want more than that, and I think Winer's SID is something worth trying out, especially since it's pretty much universally applicable across all top level domains. (I would only use domains, because they give you good legal control in case someone tries to impersonate you, etc...)

.tel's record types

In this post I'll talk about how .tel works but I won't get into the exact details and specifications. The full specs, policies, documents, howto's, etc... will be available on the telnic.org website in time for the ICANN meeting in Paris, France on June 23rd. Of course I'll post here the links as soon as the info is up on the official site. In the meantime, I'll write articles in this blog from the point of view of .tel owners, users and developers.

On to how .tel works:

From a technical perspective, the DNS specifications allow storing a staggering amount of different types of data in DNS zones. Traditional TLDs such as .com or even .name use in general the following types:

• A : the standard name -> IP translation (give a name, return an IP)
• CNAME: a name that points to another name (so you can have name -> name -> IP)
• MX: "mail exchange", i.e. an email server for the zone
• PTR: the opposite of A  (IP -> name)

Those are the main "meat and potatoes" types of records that traditional TLDs use. Taken together, their main goal is to translate back and forth computer names to IP addresses.

.tel on the other hand focuses exclusively on three types of records:

• NAPTR: your basic key/value pair, where the key is an Enumservice specification
• TXT: text records, where you store keywords and other freeform text
• LOC: location records comprised of latitude, longitude and altitude.

That's it. A .tel owner can only work with the above three types of records, but in this case less is more.

If you are proficient in UNIX command-line usage, you can look at my henri.tel domain's info for all three types of records using the following commands:

dig henri.tel NAPTR +bufsize=4000

dig henri.tel TXT

dig henri.tel LOC

Alternatively, use the following links to see the information: NAPTR, TXT, LOC

That's pretty much all there is to a .tel. Remember though that NAPTR records can accept any type of Enumservice, such as voice:tel, web:http or even extensions such as im:x-skype. In addition, NAPTRs can point to any other .tel domain or subdomain, which means that I can point from henri.tel to social.henri.tel.

.tel and the meanings of TLDs

So we're working hard to release Yet Another top-level domain (TLD) to the world, named ".tel". I hear the moans already... Doesn't the world already have .com, .net, .us, .mobi, .name, .tv, etc... etc...? What's the point of having another one?

Well, .tel just isn't like the others. At all.

Up until .tel, all TLDs have been used to facilitate computer-to-computer communications. They are the user-friendly face of the DNS. Want to go hit google.com? Your browser will call your computer OS's networking library and ask "hey, can you tell me what is google.com"? Your OS will in turn communicate with a DNS server that's probably hosted at your internet provider's facility and ask it that same question. The DNS server will then look up the google.com zone and respond "hmmm... looks like google.com is actually the server 64.233.167.99" (you can try it yourself here). Once your browser gets that information back, it will then communicate directly with 64.233.167.99 and request the main web page.

Yes I know all the above is the true idiot's idiot guide to how DNS works, but I don't know yet how knowledgeable my readership will be (if any). Anyway, long story short: every single TLD today is focused on facilitating computer-to-computer communications. All information in the DNS is about and for computers: which machines are mail servers, which ones handle the DNS itself, which machine names are actually aliases to other machine names, etc...

.tel on the other hand is about people-to-people communications inasmuch as communicating does still generally necessitate communications devices.

I showed you what happens when you ask for info about google.com (you can try again here). Well, let's see what happens when we ask for a certain type of info (NAPTR records, but I'll explain those later) about henri.tel (go ahead, click).

Interesting, isn't it? Instead of learning about the IP address of the machine that hosts the henri.tel website, you learn all sorts of interesting things about me, namely in this case my phone numbers, email addresses, IM handles, etc... Oh, there are also links to websites and to some of my subdomains, such as social.henri.tel.