* Arriving at a hotel that doesn’t have records of your reservation
Back in 1996 I wrote a column for Network World talking about some travel woes I’d had. A recent discussion about OpenID reminded me of that column, and I think that it’s still relevant today.
Back then, Comdex was the biggest thing going in technology trade shows; participants pretty much bought out all of the hotel space in Las Vegas for the duration of the show – you needed to reserve a year in advance to get any hope of landing a good room. I made a last minute decision to go that year, and was faced with finding a room with only two weeks to go. It seemed like an ideal time to try out the then new Expedia travel service. I booked a room through Expedia, but on arrival in Vegas the hotel denied any knowledge of me. Even the confirmation number I had was different from the style used by the hotel. The kicker, though, was that the rate I’d been quoted was actually higher than the hotel charged. After some three-way conversations with the hotel and Expedia, the hotel did put me up. I later discovered that the reservation service Expedia used had booked me into a hotel in Moscow, not Las Vegas! You can read the whole story here.
Expedia, like most travel agents, didn’t book directly with the hotel but with a reservation service. The reservation service keeps a database of all its hotels, identified by a property number so that there’s no confusion about which hotel is being booked. Did you know, for example, that Florence, Italy has at least three hotels called “The Grand Hotel”? When Expedia made a reservation, it was done by property number, not by hotel name or location. The Las Vegas hotel had dropped out of the reservation service some months before this booking, but Expedia’s database hadn’t been updated. The reservation service, though, re-issued the property number to a Russian hotel. Thus the mix-up.
The reservation service’s property number is meant to be a unique identifier for the property. And, under one definition of unique, it was. The number did only exist once in its database. But because the data from that database was distributed to many other places (such as Expedia), and because there weren’t good synchronization procedures in place (if any at all), it really wasn’t unique – the same identifier was attached to two different entities!
The OpenID community is going through a discussion of this very thing right now – should an OpenID provider be able to re-issue an identifier to a new user? The simple answer is, of course, no – else the problem that I encountered could be replicated, and disastrously. Suppose, for example, someone else was issued your OpenID identifier and accessed some or all of the Web sites that you’d been using that identifier for. Talk about identity theft!
An identifier needs to be unique in the namespace within which it serves to identify something. But it must also be unique over time unless the managers of that namespace can guarantee that all replications of their data are synchronized to the authoritative repository for their namespace identifiers. In a decentralized system like OpenID that’s simply not possible. Identifiers cannot be reused because any reuse will mean that the entire system will lose the trust of those who must rely on it. Enforcing a policy of “no reuse,” though, seems technologically impossible today. That’s the conundrum that OpenID faces, and how that community solves that problem may well determine if it becomes mainstream technology or simply a footnote to the history of the Internet.
