Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
What happened to XNS?

By Adam Theo in Technology
Fri Apr 26, 2002 at 04:58:01 PM EST
Tags: Focus On... (all tags)
Focus On...

XNS is/was a Digital Identity system to combine all addresses and identities of individuals, organizations, and devices into a single point of control (or failure, however you look at it). It was formally created in 2000 under the XNS Public Trust Organization, or "XNSORG". It showed great promise, but has ever since been beset by legal issues which no-one seems intent on solving any time soon.


The premise behind XNS was fairly simple: take all names and addresses that identitify a person, organization, or device, and combine them into one to be more easily managed and accessed. More precisely, create a new naming system (the eXtensible Naming System) and lay it on top of everything else, including DNS (for domain names and email addresses), telephone registries (for telephone numbers), postal codes (for mailing addresses), and anything else that can be covered. This new naming system would be controlled by XNSORG, and it would have the responsibility for handing out all new XNS names, or at least authorizing other organizations to manage the naming.

A user's XNS name would be "held" in their XNS Web Agent, a technology protected by four patents owned by OneName Corporation. This Web Agent would be a massive, complex software program hosted by an XNS provider. It would be the equivelent of a Web host, where you park your name. These Web Agents were expected to be too resource-heavy for end users to run themselves on their own computers. When a user wanted to change their personal information or how it could be accessed, they interacted with their Web Agent, and likewise requestors or other third parties also interacted with the user's Web Agent in order to get information on them (such as billing address or hobbies).

An XNS Web Agent allows the owner to set rules on the who and how of accessing their personal data. XNS was to employ a powerful contract negotiating protocol which would allow legally-binding contracts to be formed on-the-fly by end users to protect their privacy in ways privacy policies and the W3C's P3P cannot. Details of how XNS was to work can be found in their White Paper (PDF).

Unfortunately, XNS has come to a standstill. It did so almost immediately after beginning. Its managers and developer community have allowed themselves to become embroiled in legal negotiations stretching on for the past 2 years, and likely to continue for at least another 2. I have been subscribed to their mailing list for a year now, and have sadly watched the well-meaning developer community and the founders of the project be led around in circles. XNSORG treats their community very poorly. Let me show you.

The documentation is horrid. When I first began watching XNS a year ago, they had only a handful of non-specific, birds-eye-view overview documents. No specs, no code examples, nothing that could be used to start building any aspect of the XNS system. Nothing has changed since then. Still the same old docs, still no specs, still no code. The developers are working with the same information and tools that were given to them when XNS began in 2000.

When the members of the community finally have enough, or some new item comes out about Digital Identity that has no mention of XNS, they begin complaining. And the well-intentioned founders (such as Adam Engst) have no choice but to say "hold on, it will be soon". They have to reject any requests for more details on the XNS spec or even details on the progress of the legal negotiations because of "trade secrets" and other legal issues that have not been worked out in the 2 years. Then a thread of some 30-odd minor flamewar messages starts. This happens every 2-3 months. And when the dust settles, everything is the same as before, and "soon" never comes. This has gone on since I've been watching, and I understand it was going on long before I arrived.

As mentioned above, XNS is built on patented technology owned by and licensed from OneName Corp. The license allows XNSORG and XNS developers royalty-free use, but the exact legal terms of this license have been long in coming. For two years now XNSORG and OneName have been negotiating the specifics, and are currently being re-negotiated from a previous agreement in order to make the specifications to the Web Agent technology public (why this wasn't done in the first place, I have no idea).

So while XNS may have been the promising young leader 2 years ago, it has taken a nap, and now the tortoises are winning the race. Microsoft's Hailstorm came and went (although I believe it will be reborn as a federation of Good Old Boys led by Microsoft), Liberty Alliance rose to oppose a now invisible enemy, and my personal favorite, PingID, is putting the owner in complete control. These are the future titans of Digital Identity. XNS' days are passed before they ever began.

Note: XNS is also a name of a now-dead Xerox creation, the Xerox Network System. XNSORG cleared the name with Xerox beforehand, thankfully. Although XNSORG is incredibly slow on the legal aspects, they do seem to be thorough.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Will XNS make a comeback?
o No, it is dead. 74%
o Yes, it is too good not to. 0%
o Maybe, if it can free itself and move fast. 11%
o Yes, but it will be a minor player behind others. 8%

Votes: 35
Results | Other Polls

Related Links
o XNS
o XNS Public Trust Organization
o OneName Corporation
o W3C's P3P
o White Paper (PDF)
o overview documents
o No specs
o every 2-3 months
o Microsoft' s Hailstorm
o Liberty Alliance
o PingID
o Also by Adam Theo


Display: Sort:
What happened to XNS? | 15 comments (7 topical, 8 editorial, 0 hidden)
Open identity systems (4.33 / 3) (#8)
by deadplant on Fri Apr 26, 2002 at 11:13:59 AM EST

It seems to me (based only on my reading of this article) that the XNS identity system suffers from the same sort of problem as does the microsoft hailstorm system. Centralised control run by closed corporate software systems for profit.
I would prefer a more decentralized system. My big beef with the central repository idea is that it leaves the entire database of identities vulnerable to exposure, protected only by laws or contracts. You have to trust the holding company and in fact you have to trust their government aswell (anything US based would be wide open to gvt SS agents because we are perpetually in a state of war).

That PingID thing looks good, I'll have to read up on it when I'm not at work...

I haven't followed it much, but the dotgnu folks are working on a virtual identities system that could be deployed with any/all levels of control. In other words, you can run your own identity server, or let your ISP do it, or pay some Internet company to manage it for you. (just like we do with DNS..)

Hans Reiser over at namessys.com has a few words on the subject of unifying namespaces aswell:
http://www.reiserfs.org/whitepaper.html


I'm disapointed, I was thinking Xerox (5.00 / 1) (#9)
by georgeha on Fri Apr 26, 2002 at 12:18:21 PM EST

as in an early network protocol, XNS. It's nearly dead, there are hardly any resources for it anywhere, and I occasionally still have to support it.

I haven't gone through the links (4.00 / 1) (#11)
by tzanger on Fri Apr 26, 2002 at 07:47:35 PM EST

This sounds like a job for decentralized LDAP and a lot of PKI.

LDAP was designed to handle exactly this kind of information. Actually I think X.500 is the heavier cousin of LDAP but it's pretty much dead. LDAP is capable of handling all the data described and more. What it lacks in access control (actually LDAP has some pretty wicked control methods) PKI can come to the rescue with.

You hold the master key (electronically, and with some kind of backdoor that you specify, like bank accounts are done) and encrypt the various bits how you see it (ok for telemarketers, ok for family, ok for my spouse, ok for business, ok for doctors, etc., etc., etc. Similar to satellite TV, all the bits are encrypted with all of the public keys for the people/orgs/etc. that are allowed at it. This is where the computationally-expensive bit comes in but really isn't an enormous issue. A master could be kept at the town office or with a lawyer or in a safety deposit box and all changes to non-trivial data would be done at some kind of licensed company or government office, who would have to enable edits with the official's key.

Now like I said I haven't gone through the links but the very idea that something like this is patentable seems illogical. I like the idea of keeping all my data electronically in one place, and I like the idea of being able to selectively allow people/corps to view it based on my (and/or my governments) discretion. It sure beats the hell out of a birth certificate, driver's license, SSN, health card, VISA, union card, diplomas, etc., etc., etc. With encryption it wouldn't be any worse to keep it all on big iron or in your wallet.



You've obviously never worked with LDAP (none / 0) (#14)
by Sethamin on Tue Apr 30, 2002 at 06:12:17 PM EST

First off, what exactly do you mean "Decentralized LDAP"? Although LDAP is technically just the protocol, I've never seen a real decentralized implementation. Do you know of one? Where would it be decentralized to? User's computers or just various servers? If it's the latter, then how is it different from, say, AD?

Secondly, you've obviously never worked with LDAP if you think it's the answer to anything. It's actually a huge pain in the ass. The spec is completely obfusucated and imprecise. Anyone who has ever tried to normalize LDAP DNs knows what I'm talking about (for starters). And from a compatibility point of view the spec is way too vague; both AD and iPlanet are technically "compliant" (no matter what either company says), but still have enough annoying deviations to make it a pain to get them to work together. LDAP causes more problems than it creates.

I don't think your idea would work anyway. You've essentially rehashed the "public/private key for everyone" idea coupled with storing everything in an open LDAP directory. This former has been a pipe dream for many, many years. The latter would have to be run by the government, which most people aren't too keen on.

Lastly, it would be really redundant to store copies of the same data encrypted the same way for every single person/group you want to grant access to. However, what I could see in its place is that each discrete piece of data is encrypted with a random key (i.e. not public/private encryption). That key is then encrypted with the public key for each person/group you want to grant access to. In order to get access to the random they have to use their private key. When the data changes or you want to take away access rights, you generate a new key, reencrypt the data, and then encrypt the new key with the public keys you want to give access to. It's a complex process, I know, but it beats having redundant copies of the same data.

A society should not be judged by its output of junk, but by what it thinks is significant. -Neil Postman
[ Parent ]

Obvious, eh? (none / 0) (#15)
by tzanger on Thu May 02, 2002 at 10:49:15 AM EST

Secondly, you've obviously never worked with LDAP if you think it's the answer to anything.

You're "obviously" inept if you can't get LDAP to do work for you. I'm currently using it in several places and it is literally the best thing since sliced bread. Not only are all of our user accounts stored in LDAP along with their contact information but so are all of our customers and their relevant data. Now throw on a second major branch from the directory and that keeps track of every product we've ever shipped since setting up the directory. (things like configuration, distributor, end user, links to quotation/acknowledgement/service reports, etc.) It ties in beautifully with our RDBMS (PostgreSQL) by storing the DN as the key on the SQL side and/or storing an oid on the LDAP side.

"Obviously" it can't possibly work because you say so. I'd love to get the PostgreSQL backend working for OpenLDAP so that the data is stored in one (easily backed-up) place and there are just different accessor methods. With LDAP there is no need for separate difficult-to-keep-synced address books because they can all use LDAP. Palm software can hit the directory and generate customized lists for each person based on territory or any number of search keys. LDAP is very cool and very very useful, despite what you say.

Why not store everything in the RDBMS? Quite simply, it is obvious that this kind of data does not lend itself well to being stored in that manner. Some contacts have personal contact info, multiple business or territory information and so on. I could have created a bazillion joiner tables but that's crazy. Use the tool for the job.

The spec is completely obfusucated and imprecise. Anyone who has ever tried to normalize LDAP DNs knows what I'm talking about (for starters). And from a compatibility point of view the spec is way too vague; both AD and iPlanet are technically "compliant" (no matter what either company says), but still have enough annoying deviations to make it a pain to get them to work together. LDAP causes more problems than it creates.

The spec does not tell you how to lay things out, that is your job when you create the schema. Yes it is difficult to normalize a directory, especially when there is a lot of varied information. That's the whole point of choosing your DN scheme carefully. Honestly, it's no different than normalizing an SQL database -- the rules are the same but the problem is more difficult because the very nature of the data makes it hard to do.

AD and iPlanet are compatible on the protocol level; that's all the spec ever guarantees. To try and force schemes would be suicide. If you don't know the schema you're screwed, true, but have you ever looked at something like an AccPAC database table? If you don't have the documentation handy you'd be just as lost.

First off, what exactly do you mean "Decentralized LDAP"? Although LDAP is technically just the protocol, I've never seen a real decentralized implementation.

What I meant by that is something along the very same lines as DNS: you have your root servers handing out pointers of where to get information (these would obviously be run by the government or some "trusted" third party) but that's about it. You choose to upload (replicate) your information to the system using your master copy. Now you're known to the system and the various bits are encrypted to the people/systems/companies you have allowed for the information. My rough estimate would be that your infomation is then stored at the municipal level (giving a geographic scheme here), perhaps with a badass backup at the federal census database level.

I don't think your idea would work anyway. You've essentially rehashed the "public/private key for everyone" idea coupled with storing everything in an open LDAP directory. This former has been a pipe dream for many, many years. The latter would have to be run by the government, which most people aren't too keen on.

Yes, that is what I am proposing. You already have shitloads of data stored on you by the government, how is this any different? You at least get some degree of protection by your encryption of private/semi-private information. I'd take it a step further and allow arbitrary encryption on any non-essential attribute. Anything from ROT13 to triple AES mocha swirl inverse parabolic DES with elliptical XOR™. And you could also use the same trick as OpenDNS does and use different root servers with gateways to government networks. Pipe dream perhaps; I didn't say I was proposing something radically new, and I certainly don't understand why it can't happen today. You get a "smart" SSN card with your private key on it which has a TTL of 5 years or so (like a driver's license). Your private key you don't know. It's encrypted with two keys: a thumbprint/phrase combo and some government key which requires a court-order to use (akin to a search warrant, for when you lose your thumb or die or something -- potential MIB problem here).

Lastly, it would be really redundant to store copies of the same data encrypted the same way for every single person/group you want to grant access to. However, what I could see in its place is that each discrete piece of data is encrypted with a random key (i.e. not public/private encryption).

You're right, something like that would have to be implemented. I was suggesting a public key for "public searches", "government agencies", "law-enforcement", "family", "medical", etc. and then any specific persons or organizations.



[ Parent ]
well-written, interesting article. thanks [nt] (1.00 / 1) (#12)
by Sacrifice on Fri Apr 26, 2002 at 07:55:35 PM EST



SDSI/SPKI (none / 0) (#13)
by Robert Uhl on Tue Apr 30, 2002 at 01:12:32 AM EST

I'm rather partial to the SDSI/SPKI method of doing things. Rather than a central authority which certifies who's who and what's what--and hence a central point of failure to be compromised--they envision a `web of relationships' model. E.g., instead of me being Earth:US:Colorado:Denver:"Observatory Park":"Robert A. Uhl" (which changes) or "Internation Business Machines":"Global Services":..., my digital identity exists solely as a function of those who know and refer to me. Hence, I might be Kuro5hin's Robert A. Uhl, Slashdot's Bob Uhl, or even Jess's Phil's Bob (Jessica is my best friend Phil's girlfriend; a friend of hers might retrieve my identity with the path Jess:Phil:Bob.

I've been thinking of hacking together some elisp to tack this onto BBDB. Dunno if I'll ever get around to it, though.

What happened to XNS? | 15 comments (7 topical, 8 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!