What's Your i-Name?
I'm looking to invalidate Searls' 4th Law, which says, "No matter what car you want to rent, what you'll get is a Chevy Cavalier." The law proved itself again during the weekend I'm finishing this column. When I went to the National Car Rental counter at the airport and asked if they had a choice of compact cars, they said "all we have are eleven Chevy Cavaliers". Next door at the Budget counter, where I had arrived earlier with a print-out of my Web reservation for a Ford Focus "or equivalent", all they had were (surprise!) Chevy Cavaliers.
I used to prefer renting from Budget because I stood a chance of getting a Ford Focus, which is a great little car. But Budget fell off the list of car rental agencies at the United.com site, so they don't currently offer bonus miles for my United MileagePlus account. National does, so here I am, driving The Most Generic Car in the World.
Which is appropriate. This month's theme is Desktop Linux. And, as I said in my speech at the Desktop Linux Summit one year ago, Linux desktops and laptops should aspire to be the computing equivalents of Chevy Cavaliers and Pontiac Grand Ams, the "intermediate" equivalent. In a SuitWatch newsletter last April, I explained why:
Chevy Cavaliers, Grand Ams and other generic rental cars have two characteristics that make them ideal models for Ultimate Linux Laptops. First, they're not bad--really. Second, all but the stripped-down models come with a full complement of minor conveniences you want in a car today: cruise control, air conditioning, electric doors and windows, AM/FM radio, CD player, cup holders, automatic transmission--and a wireless thingie on the key chain for unlocking doors and opening the trunk. Those are the equivalents of Wi-Fi, USB and CD burning in a laptop.
I think that's still a good model, even if Linux desktops and laptops eventually beat every competing platform--which they will. Crawl before you walk, drive before you fly.
Meanwhile, the car rental business makes an ideal controlled study for customers transforming whole business categories, whether vendors like it or not.
To explain what I mean here, it helps to go back to an e-mail Chris Locke sent to David Weinberger, Rick Levine and myself, while the four of us were plotting the posting of what was to become The Cluetrain Manifesto. Attached to the e-mail was this graphic:
This was the moment when, as Jakob Nielsen later put it, we "defected from marketing and sided with markets".
Yet, six years later, there's still a problem with that statement. Even though the Net has enlarged and leveled the playing field we call the marketplace, customer reach still fails to exceed vendor grasp. Networked customers may get smarter faster than most vendors, as Cluetrain also said, but market power still is unbalanced in favor of vendors, and that's not good for either side.
For evidence, look in your wallet. Every card you carry that features an identity--driver's license, credit cards, ATM cards, membership cards--has been issued by somebody other than yourself. Each tells you who you are and where you fit in the walled world of each organization.
Contrast that with your enormous portfolio of actual vendor relationships--with your coffee shop, your cleaners, your grocer, your public TV station. Then, consider your even larger portfolio of tastes and preferences. Precious little of that is represented by the cards you carry in your wallet, each of which embodies a limited data set, maintained for its own convenience by those who issue the cards.
"Markets are conversations", Cluetrain famously said. But how much conversation--of either the literal or the metaphorical sort--is allowed within the siloed confines of the name space you represent to your bank, your airline or even your local library or YMCA?
After Cluetrain came out as a book in January 2000, a higher principle than "markets are conversations" was suggested separately by open-source advocate Eric S. Raymond and Nigerian theologian Sayo Ajiboye. That principle is "Markets are relationships". To help clarify matters, Ajiboye also related an expression common in his native language of Yoruba: "Life is a marketplace".
In Raymond's bazaar and Ajiboye's marketplace, power is balanced between supply and demand. Markets can grow and thrive at any of three levels: transaction, conversation and relationship. These levels also are outlined separately by both men. In the industrialized world, however, power has long been unbalanced in favor of large industrial vendors. For practical among other reasons, these vendors have limited severely the scope of both conversation and relationship with customers, concentrating instead on making it as easy as possible to conduct identity-enabled transactions. Whole economies are seen entirely in terms of transaction, with minimal respect paid to the higher levels where conversation and relationship take place. There's a lot of business to be had up there, if the vendors begin to see the possibilities in conversations that aren't just about billing and credit card transactions.
Even on the customer side, the credit-card system alone is so familiar and so deeply ingrained in our culture, that it's hard to imagine life as a fully empowered customer. It's even harder to imagine a marketplace in which vendors compete to fulfill needs that customers themselves express.
Imagine walking up to the counter at a random coffee shop and presenting a card that lets the barista know you like double short decaf capuccinos. Or imagine a world where car rental agencies really do compete to provide you with the car you want and the options you want rather than Yet Another Chevy Cavalier, plus the usual up-sell for insurance and an extra tank of gas.
Imagine that same identity card--one you own, that contains secure pointers to whatever identity, preference, interaction history and relationship information you choose to accumulate and disclose, for your own or mutual purposes--letting the coffee shops on a road trip know you're coming.
We're not going to get that from vendors, for the same reason we didn't get Linux from vendors: Big suppliers in any category have trouble pioneering anything that's good for everybody and not only for them. Sure, they'll gladly get behind a grass roots movement once it grows like wheat over a big enough marketplace. (Exhibits A through D: Support for Linux by IBM, HP, Novell and Sun.) All due respect for the support these companies eventually do provide; they're simply not going to sow the first seeds.
To their credit in the identity space, big vendors have been thinking about identity problems for a long time and have made some moves that eventually will support grass-roots identity efforts. For example, the notion of "federating" digital identity is getting bigger than ever. In an interview last year, Eric Norlin of Ping Identity Corp. (disclaimer: I'm on the company's advisory board) described federation with a question: "How is it we allow the end user--be they an employee or a customer, or an investor, or a partner or a supplier--to actually have some sort of virtualized control over these distributed bits of digital identity?"
Those "bits" include all the credit, debit, ATM, library, club and other membership cards that live in your wallet. "Federation", Norlin explains, "leaves the distributed environment as it is but seeks to let the end user link together those pieces and still have control over their privacy and what information gets shared and how.... Federation seeks to leave the distributed environment as it is and still attain the advantages and benefits of what normally would be a centralized environment."
Although that description pays respect to the customer, all of the action with federation so far has been on the supply side, opening data silos for customer information to pass between siloed databases. In practice, this involves a selective form of blindness. As Eric Norlin puts it, "neither side...knows the identity of the data that's passed between them. The specification purposefully makes it hard to violate the customer's privacy."
That would be the Liberty Alliance ID-FF 1.2 specification. The Liberty Alliance includes a number of large companies (including Sun, Novell and--as of last October, IBM). Another group of Big Boys is gathered around the WS-Federation, Web Services Federation Language. That group includes IBM (a founding member), Microsoft, BEA, RSA Security and Verisign.
At the Digital Identity World conference last October, I jokingly referred to federation as "giant companies having sex with your data". That was unfair, even though it got a lot of laughs. Federation between companies and between parts of companies behind firewalls is a necessary thing, and both these projects should be commended for their efforts to protect privacy while achieving other purposes that everybody agrees are desirable.
But we still need that grass-roots movement.
In my closing keynotes at the first two Digital Identity World conferences, I cried like a wolf in the wilderness for somebody--anybody--to come sow some grass-roots identity seeds. By the middle of last year I pretty much had given up hope. Then, during last summer's LinuxWorld Expo in San Francisco, I found myself in the top row of the nosebleed section behind first base at a Giants baseball game. Next to me was a woman with a laptop doing stuff on the Web, thanks to the free Wi-Fi provided by the ballpark.
She said her name was Kaliya Hamlin, and she worked for IdentityCommons.org. In name alone, IdentityCommons sounded like it might be the Johnny Identityseed I'd been looking for. Naturally, we got to talking. Several months later, my by now traditional closing keynote at Digital ID World was about Identity Commons and the grass-roots effort it's leading around a set of customer-native identity standards, including one called i-names. XDI.org calls an i-name "the first universal private address--a single address you can use for all types of electronic communications while always maintaining control of your privacy".
The most immediately useful purpose for i-names is spam protection. XDI.org explains:
Conventional addresses such as postal addresses, phone numbers, and email addresses are tied to a specific location, device, or service. By contrast, i-names are abstract--they are not tied to any specific location or device. Instead they are a way to ask permission to contact an individual or organization--and for the i-name owner to control to whom this permission is granted.
An i-name is simply "unspammable"--you can't send it email, call it, or send it a fax directly unless the owner has given you permission. If you don't have permission, you can use an i-name to make a contact request of the owner. These requests can be automatically filtered by your i-name service provider (i-broker) using a personal contact page to eliminate all but legitimate requests for contact.
Because an i-name is not tied to a specific physical or network address, it is also the first address that an individual can keep for life--across schools, jobs, homes, and travels. Furthermore, using the XDI trusted data interchange specifications under development at OASIS, individuals will be able to use their i-name to instantly share and link the precise set of personal data they want with other people, businesses, or organizations while always maintaining strong security and privacy protection.
...when shared contact or other data changes, your i-name service provider can automatically synchronize changes with all linked contacts that have permission to receive them.
An i-name is represented by a =name convention. At Digital ID World, Kaliya's badge said =kaliya. Over the course of the conference, a growing number of attendees had appended an = prefix to their badge names. Mine said =searls. I obtained that unique identity from 2idi, the first commercial i-broker. Later I added =dsearls (I found that =doc already had been taken).
Behind i-names are two other standards: XRI and XDI. Here's how XDI.org explains them:
Together, XRI and XDI solve the twin problems of persistent identity and trusted data sharing relationships by providing the technical foundation for linking people and organizations in a "Web of trust" just the way the Web lets us link pages in a "Web of text".
XRIs (Extensible Resource Identifiers) address a longstanding problem on the Internet: how to have a persistent, portable, privacy-protected identifier for any resource, from a person to a company to an application to a concept.
XDI (XRI Data Interchange) uses XRIs to securely and privately share, link, and synchronize data between any two devices, domains, or applications--and maintain this link for as long as the two parties want to keep a data sharing relationship.
So, in this context, XDI.org calls i-name "a human-friendly XRI intended for everyday use in browsers, email clients, Web pages"--any place a Web address (URI) would appear today.
Drummond Reed, the founder and CTO of Cordance.net, has led the development of these specs and their ancestors for a decade or more. He says they are "about identity ownership and trust that starts with individuals, out in the marketplace, rather than inside any large company, or association of large companies".
Identity Commons and XDI.org were not alone among the open-source identity advocates at the conference. There was a good bit of energy around the XML-based Simple eXtensible Identity Protocol (SXIP). Like a number of other commercial/noncommercial efforts, there's a Sxip.com and a Sxip.org involved.
Sxip's grass-roots solution to identity problems involves two breeds of sites:
*Homesites* are web sites that authenticate and identify users, provide a repository for user information, and release this information (with user-consent) to other web sites that want it. The Homesite typically serves one or more Membersites, and allows their constituents to seamlessly authenticate and share data between them.
*Membersites* can store user data at and retrieve it from the Homesite, ask for authentication, and release the user data to other Membersites that request it.
Sxip networks support single-sign-on and provide other goodies. Using i-names is allowed as well, so that's not a problem.
Two of the leading authorities on identity--Kim Cameron of Microsoft and Craig Burton--attended Digital ID World and were intrigued by these grass-roots efforts. But they also lamented that each involved creating "yet another name space" in a world where name space proliferation is itself a problem. Yet this was one rare occasion when I had to disagree with both men, who also are close friends of mine.
These grass-roots efforts may be flawed in any number of ways, but they're coming from the right direction and for the right reasons. They won't reach critical mass without early adopters. That's where the rest of you come in. Check out both IdentityCommons.org and Sxip.org. See what you think and help any way you can.
Let's see how soon we won't be forced to rent Chevy Cavaliers.
Doc Searls is Senior Editor of Linux Journal. He writes the Linux for Suits column for Linux Journal. He also presides over Doc Searls' IT Garage, which is published by SSC, the publisher of Linux Journal.
Doc Searls is Senior Editor of Linux Journal
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- Interview with Patrick Volkerding
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Returning Values from Bash Functions
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide