News Spirals : News Spirals

 Thursday, March 27, 2003
Blog Aggregators.

Un solo click, tanti blog.Blog Aggregator, made in Italy.. Something very interesting has been going on in the Italian blogosphere in the last couple of weeks, a lot of smart people has been working and discussing about aggregators, categorization and weblogs. Here's the story. [Paolo Valdemarin: Paolo's Weblog]

In addition to this project and Phil Pearson's Topic Exchange - there's also something called Stereotypography.  I'm sure there are others...... These Blog Aggregators are part of a new trend in on-line communities - as folks are figuring out how to use RSS, OPML, XML-RPC and the MetaWeblogAPI in new and creative ways.

This is certainly something that a new kind of distribution system - would eat up.

[Marc's Voice]
12:05:38 PM  #  
Publishing a project weblog.
Configuring Movable Type
A couple of years ago I predicted that Weblogs would emerge within the enterprise as a great way to manage project communication. I'm even more bullish on the concept today. If you're managing an IT project, you are by definition a communication hub. Running a project Weblog is a great way to collect, organize, and publish the documents and discussions that are the lifeblood of the project and to shape these raw materials into a coherent narrative. [Full story at InfoWorld.com] ... [Jon's Radio]
12:03:44 PM  #  

Identity is a Secret.
Identity is a Mystery.
Identity is a Killer.


That's the teaser for a new film, but it conjures up the Digital ID debate. It's a mystery how we're going to keep our identities secret from people we don't want to hear from, and Doc thinks that the right (NEA) form of DigID could be part of a killer app:

"When I spoke at Digital ID World last Fall, I said I didn't believe any of this would begin to happen in a meaningful way until we had an invention that mothered some necessity--a dirt-simple killer application or killer protocol that would spread like wildfire and carry its own default infrastructure to ubiquity. I'm not sure Liberty supports that, but I don't know.

I'm confused about how a commercial, non-NEA form of DigID would roll out. It still feels like the only killer feature of DigID will be to silence the conversation about DigID and the Liberty Alliance. Big outfits that talk about our "Liberty" sound like Ashcroft PATRIOTism.

To be fair, Liberty isn't proposing a new identity database, which was my previous, mistaken concern. They're creating a way that your sign-on to United Airlines' site would not require a separate sign-on when going to the Avis link from the United site, which becomes one of many "Identity Providers" you may depend on. You'll still have separate IDs everywhere, it's just that some of them will take United's word for who you are, sort of like what Yodlee already provides. Does that mean you'll still have to register a new credit card everywhere each time you pass an expiration date?

Dave quoted Sean McGrath quoting (he thinks) Adam Bosworth:

"Every layer of abstraction costs you 50% of your audience."

When you add business alliances and linking commissions to the mix, it gets really hairy. This bad boy feels too complicated for a timely rollout. I must be the only one who thinks the obvious launch sequence for any commercially federated ID will be:

  • Version 3.2 (or so) of the standard is finally agreed to.
    (Wanna download v. 1.1? Here's the 4.1 MB spec in 8 files.)
  • Participating companies (like these) negotiate and subdivide into their "affinity groups"
    (mini-federations linking among themselves)
  • Participants provide a transition period to the new protocols.
  • Participating sites patiently explain the new rules to shoppers.
  • Longer than expected, shoppers click, "Not Now. Do It the Way I'm Used To."
  • The transition echoes the conversion to HDTV and the metric system.

Won't it take years for this cycle to be played out? Those first 2 bullets really are killers. Both of the people who read my rants are pretty technical, but I bet we don't manage our browser cookies the way we should. I don't see how well we'll manage this byzantine trust matrix:

POLICY/SECURITY NOTE: Implementors and deployers should make allowance for the user to decide whether to immediately authenticate with the identity provider or be offered the chance to decline and authenticate either locally with the service provider or select from the service provider’s list of affiliated identity providers.

The way I read the Liberty Architecture Overview (736 KB PDF), when you deal with United Air Lines, you're set up to deal with United's affinity group of vendors. But when you go over to American, you'll need to sign in again. This feels like a balkanized federation, not the EU. Section 5.7 of the Overview, "Example User Experience Scenarios" lists 3 user scenarios and 4 sub-scenarios, each of which requires the user to remember her user name & password for the designated "Identity Provider" for each affinity group:

5.7.1 Scenario: Not Logged in Anywhere, No Common Domain Cookie
    5.7.1.1 Login via Redirect to Identity Provider Website
    5.7.1.2 Login via Identity Provider Dialog Box
    5.7.1.3 Login via Embedded Form
    5.7.1.4 The User is Logged in at CarRental.inc
5.7.2 Scenario: Not Logged in Anywhere, Has a Common Domain Cookie
5.7.3 Scenario: Logged in, Has a Common Domain Cookie

How do United and Hertz agree that United will be the Identity Provider when Hertz knows as well as we do that United may have bigger concerns than DigID, like, any day now? My guess is that the IT guys designing this beast haven't yet discussed it seriously with Marketing, Legal and the Executive Committee. When they do, They'll surely be sent back to the drawing board.

XML co-inventor Tim Bray's blog today is titled Enterprise Software Wreckage:

"If you go back to the Global 2000, the buyers of big-ticket software, and get the typical CIO hammered and indiscreet in a bar, and ask about failed installations of big-ticket software, you'll get bitter laughter (or bitter tears, depending how hammered). It happens all the time. I'm talking about projects with software licensing and deployment costs adding up into the tens of millions, going nowhere, producing no results, and eventually shutting down."

And that's when everybody works for the same guy...

The Complexity of a Deal...

The complexity of a deal expands to match the available brainpower;
No one can manage a business as complicated as they can design it.

                                                Blaser's corollary to Parkinson's Law

Even if some immaculate conception births this puppy, we still haven't solved the real dilemma: this model isn't what we want. We don't want separate IDs everywhere, whether singly or in arbitrary affinity groupings. We want a single sign-on, preferably encrypted in our browser, Java ring or biometrics, that works everywhere. But we don't want our data centralized, which would leave us hostage to an identity czar.

Nobody, Everybody, Anybody

Doc's Linux Journal article goes on to say,

What this requires is something we don't have right now: a new identity infrastructure--one provided by open APIs, protocols and other standards that serve no agenda other than to enable useful dealings between buyers and sellers of products and services. Like the Web and e-mail infrastructure that are already part of the Net, this new infrastructure would be a full-fledged service on the Net. And it won't become that unless it's something nobody owns, everybody can use and anybody can improve. Again, like the Web, e-mail and the Net itself. . .

. . . Right now there are other moves afoot, too premature to talk about, all intended to build out a mydentity-based infrastructure. "

Doc also quotes Andre Durand, founder of Jabber and PingID, who is working with Liberty, and who says everyone should be their own Identity Provider. "Hijack the Liberty protocol," he basically says, going on to suggest embedding ID data in a Jabber client, which then would be a full peer to the airlines, banks and other Identity Providers that want to attract you to their fiefdom. Andre's is a profoundly cool idea that I didn't comprehend until Doc told me that, at its core, Jabber is an XML router. Now we're talking: a P2P petri dish that's good for years of innovation.

Just one problem. Which jabber client would your ID live on? You'll need access to it anywhere, not just on your main machine. Surely some universal ID reader will someday be embedded in all devices (fingerprints, smart card, etc.). Meanwhile, wouldn't it be swell if each person owned their own web site to host their private Identity provider? Coincidentally, that's the Xpertweb model.

Doc and Mitch and Flemming and Henshall, Husband, & Patrick and I agree that the role for Xpertweb in all this is to provide the relationship layer on top of DigID. The controversial thing about the Xpertweb model is that it establishes a complete identity file for each user, on the user's own web server. It's an admittedly big conceptual leap, but the problems it solves are legion. Now you own a trusted database served by a trusted script, ready to expose ID info whenever you OK it, but never otherwise. Sure, you still have to deal with the explicit permissions, but that's the case under every DigID model. The important thing is that, like Andre's suggestion, each ID owner controls their ID, but unlike Andre's proposal, it's universally available to any corporate supplicant the owner chooses to bless. Certainly our DigID protocol will be no worse than Xpertweb's!

Smarter guys than I say it's impossible. If they're right, you're wasting your time reading this design study. Keep moving along folks, there's nothing to see here. But most technologists look at our alpha code and beta concept and say the concept's unusual, but the technology's trivial. We like novel, trivial technology.

[Escapable Logic]
12:01:56 PM  #