Internet Identity Workshop 2007, Day One

Posted on Published by Eugene Eric Kim

Quick thoughts from day one of the Internet Identity Workshop (IIW):    (M9G)

  • This is the fourth IIW. The first one was in October 2005. Amazing. It feels like we’ve been doing these for at least five years.    (M9H)
  • Over half of the participants were there for the first time.    (M9I)
  • I opened the conference with an introduction to Identity Commons. Got some good feedback, and great support from others who have been active in the rebirth of Identity Commons. My big goal is to get the community to think of Identity Commons as “we,” not “they.” We’ll see how successful we are at the end of this workshop.    (M9J)
  • We participated in a nice exercise where folks got into small groups and surfaced questions. It got people interacting, and as Phil Windley noted afterwards, people stayed in small groups chatting away well after the day had ended.    (M9K)
  • One thing that struck me about the group exercise: I heard no new questions. A common characteristic of Wicked Problems is not knowing what the questions are. A good number of us seemed to have successfully identified most of the key questions a long time ago. This is both a sign of progress and of concern. We as a community are starting to face growing pains, and community memory is becoming more and more of an issue. Doc Searls suggested that in addition to surfacing the questions, we should have asked, “Okay, who has the answers?” I think some variation of that would have made an excellent complementary exercise.    (M9M)
  • I like Pibb, JanRain‘s Web-based real-time group chat tool that uses OpenID. (Think IRC on the Web with OpenID for identities.) But I also agree with Chris Messina; Pibb needs permalinks — granular as well as thread-level.    (M9N)
  • We had a series of lightning presentations following the group exercise. They were all well done. Remarkably, they were all about basically the same thing, only told from different angles, something that Mary Hodder also observed. I think this is a good sign. It shows the ongoing convergence of our community. There was also a lot of Spotlight On Others — folks referring to each other’s work, even borrowing slides from each other — another sign of a healthy community.    (M9O)
  • There wasn’t anything new conceptually, but there were many more implementations, yet another sign of progress. Speed Geeking basically consisted of 15 different implementations of Single Sign-On, which doesn’t make good fodder for demos, but which is great for the community.    (M9P)
  • Two Speed Geeking projects stood out: Vidoop and Sxipper. Vidoop is user authentication via image recognition and categorization, which in and of itself is interesting. But what got people buzzing was its business model: sponsoring images that would be displayed to users for authentication. I don’t know if it’s viable, but it’s definitely creative. Sxipper is a Firefox plugin that handles account registration and login. What’s really interesting is what’s happening beneath the covers: It’s essentially an OpenID Identity Broker running from your browser. It looked very slick; I’m looking forward to playing with it.    (M9Q)
  • Doc Searls gave his traditional day one closing talk. I’ve heard bits and pieces of this talk many times, but I never tire of listening to him speak. He’s just a fantastic storyteller, and he’s always on point.    (M9R)
  • I carpooled with Fen Labalme, and as we were discussing our takeaways on the way back, he said, “I’m glad I didn’t sit with you at dinner.” He wasn’t joking, and I wasn’t offended! I felt the same way! One of the really special things about this community is that there are no snobs. We all like to hang out with each other, but we all also really value quality time with folks we don’t know. You could really see this at dinner. I didn’t see any cliques, and there was plenty of mixing.    (M9S)

Ph-Off and i-name Promotion

Posted on Published by Eugene Eric Kim

I’m at the Identity Open Space in Santa Clara right now. Lots of good stuff scheduled today, including a session I’m co-leading on Identity Commons, the next generation. Two things worth mentioning now. First, i-names have officially launched. A lot of folks purchased i-names through the Identity Commons fundraiser way back when, and those will finally become useful. If you didn’t have a chance to buy one at the special rate a few years ago, you can buy them at a special rate over the next three days: $5 for the first year of registration. Go to:    (L5U)

and register before 7pm PT, this Thursday, September 14.    (L5W)

Second, Andy Dale has whipped up a cool, anti-phishing Firefox plugin for OpenID users appropriately named, Ph-Off. OpenID and similar technologies rely on the notion of an Identity Broker — a third-party site that handles authentication. Because these Identity Brokers will become increasingly important, we need good ways to be sure that things that look like our i-brokers actually are our i-brokers. When you configure Ph-Off, the toolbar turns green and you get a green thumbs up indicator when you visit your actual i-broker. It’s simple and useful.    (L5X)

Identity Commons: Empowering the Individual

Posted on Published by Eugene Eric Kim

At last month’s Planetwork Conference, Blue Oxen Associates proudly demonstrated the first Identity Commons system for Single Sign-On. Conference attendees could access the PlaNetwork Wiki (which we hosted), Living Directory (for online profiles), Neo Society (a social networking site), and the conference site itself, all with one username and password. Although I’ve mentioned this work in passing on a few occasions, I’ve neglected to explain exactly what Identity Commons is about.    (1LG)

In short, we’re building a system where individuals have full control over their digital profiles. It’s an idea that was heavily inspired by the Augmented Social Network paper that was published last year.    (1LH)

Here’s how the system works. Individuals have one or more global identifiers — e-names — and Identity Brokers associated with their e-names.    (1LJ)

These Identity Brokers know three things about you:    (1LK)

  1. How to authenticate you (e.g. your password).    (1LL)
  2. Where your profile data is located.    (1LM)
  3. Link contracts that define who can access your data and what they’re allowed to do with it.    (1LN)

The latter two points are critical, because they differentiate this system from efforts such as Liberty Alliance and Microsoft Passport. Identity Brokers know where your data is, but they don’t necessarily store the data themselves. There is no central repository. Your data can be completely distributed across multiple sites. The only way sites can access your data is if you give them permission to do so via the link contracts.    (1LO)

There are two components to all of this: the technology and the social/legal agreements. The latter is the hard stuff. It’s not enough to build systems that can negotiate and agree on contracts; the organizations behind these systems have to respect these contracts. That’s why Identity Commons exists. Identity Commons is a member-owned Chaordic Organization founded by Owen Davis, whose primary purpose is to work out and enforce these social and legal agreements.    (1LP)

e-names and XRI    (1LQ)

I’ll have more to say about social agreements another time, most likely in response to other people’s queries and comments. In the meantime, here are a few more technical details.    (1LR)

E-names are based on an OASIS standard called XRI — eXtensible Resource Identifiers. Think of them as extended URIs. E-names are (mostly) persistent, globally unique, globally resolvable identifiers. E-names have multiple forms, but the ones most people will see are:    (1LS)

  =eekim   @blueoxen*eekim    (1LT)

The first form is part of a flat, global namespace (as specified by “=”). Sometime in August, individuals will be able to register global e-names as part of an Identity Commons fundraiser. The second form is an e-name associated with an organization (as specified by the “@”). That’s my actual, working e-name.    (1LU)

E-names are associated with e-numbers, which are persistent, numerical addresses. (Think IP addresses, except persistent.) You can associate multiple e-names with an e-number. In other words, requests for the email address of =eekim and @blueoxen*eekim would go to the same place, because they would both be associated with the same e-number.    (1LV)

You can use e-names for Single Sign-On, and you can also use them for data sharing and synchronization. For example, an e-commerce site could regularly request your latest contact information from your Identity Broker via your e-name, and it would get it — provided you give them permission. That information might be stored at another e-commerce site or at a social networking site or at a gaming community to which you belong. Neither the e-commerce site nor the Identity Broker care where that information lives.    (1LW)

Why do users need to remember yet another identifier format? Why not use email addresses? That would defeat the purpose of what this system is supposed to be about. Your email address should be your information, and you should control how it is used. If you just gave your email address out indiscriminately, that leaves you vulnerable to spam, which is the status quo. If you passed out an e-name, you couldn’t be spammed — folks would have to get your explicit permission to get your email address.    (1LX)

Why not use URIs? Two reasons: They’re not persistent, and they’re not user-friendly. One of the nice things about working with the OASIS XRI Technical Committee is that they are accomodating. None of the other TC members have had to worry about identifiers being user-friendly, because only software has seen those identifiers. However, they have already made some changes in their 1.1 spec to accomodate our desire for the identifiers to be more user-friendly.    (1LY)

Single Sign-On    (1LZ)

We’ve got the basic XRI resolution working and a Single Sign-On system working on top of that. The protocol is available on the Identity Commons Wiki. The protocol looks just like any other Single Sign-On protocol, and in fact, will most likely resemble the Liberty Alliance and SAML spec even more closely over time. Our intention is to use what’s good and available, not to reinvent the wheel.    (1M0)

I wrote the Perl implementation of the client library (XDI::SPIT), and there are currently PHP and Java versions as well. One way you can contribute immediately is to develop implementations in other languages (Python anyone?). The other way is to integrate these libraries into your tools. Note that all of this stuff is technically pre-alpha. It will change. That said, the APIs should remain fairly stable. It’s good enough for people to start using immediately.    (1M1)

Link Contracts and XDI    (1M2)

The most important pieces of all this are the data interchange protocol and the link contracts format. Fen Labalme, the chief architect of the Identity Commons project, is working hard on this right now, with help from Victor Grey, who implemented the first Identity Broker and also founded Living Directory.    (1M3)

Both of these pieces will be built on top of XDI (XRI Data Interchange), an XML application that is currently going through the standardization process. This is not something that’s being designed from scratch. XDI is based on previous work developed by One Name (now Cordance).    (1M4)

How does FOAF fit into all of this? The short answer is, “It will.” Think of what we’re doing as FOAF with authentication and link contracts. To be brutally honest, I can’t accurately assess this question until I see the XDI stuff, but I see no reason why XDI won’t be able to interoperate with FOAF, and vice versa. In fact, I’ll be gathering with Fen, Victor, and some other folks tonight to start exploring that possibility.    (1M5)

What’s Next?    (1M6)

This is without a doubt a grassroots effort, but there’s some serious technical and intellectual weight behind it. The technical specs are based on OASIS standards, with representatives from major corporations. The global registry for e-names will be operated by Neustar, which operates the .biz and .us registries among many others. Several of the people working on Identity Commons participated in Liberty Alliance.    (1M7)

Realistically, Amazon.com and Visa aren’t going to adopt this overnight. Once user demand passes a certain threshold, however, companies are going to have to start paying serious attention. Right now, users don’t have a choice. It’s give up your data or nothing. Once users realize they have a choice, I firmly believe that people will opt for privacy over the status quo.    (1M8)

Our strategy for getting to that threshold is to target civil society groups. So far, response has been outstanding, and I hope that this blog entry generates additional interest. Single Sign-On and data sharing solves an immediate technical need, and the fact that it does this while respecting individual privacy is a huge bonus.    (1M9)

What’s my role in all of this? Blue Oxen Associates is about improving collaboration for a better world. This system fits the bill perfectly. Not only does it promote tool interoperability, it does so in a way that will help improve people’s lives. I’m proud to be one of the project’s many contributors right now, and I’m proud that Blue Oxen Associates will be one of the first large-scale users of the system when our collaboratories go live next year.    (1MA)

If you want to help, more information is available at the Identity Commons Wiki.    (1MB)