Since I’m a data addict I have various alerts shot straight to my phone by tireless perl scripts in my basement. This morning as I drove downtown one of these informed me of high wind warnings in the area.

Like FEMA receiving a report of a Hurricane headed for the homeland I carefully filed this away and did nothing. I forgot that it was recycling day.

Later upon returning home I turned up my street to find it strewn with hundreds of pieces of paper. Each recycling container along the street was methodically pealing one sheet after another off the top and donating it to the party.

So I parked the care and began to pick up. It was like flying monkeys had attacked my neighbors identities. Credit card offers, bank statements, gas bills, magazines, catalogs. Mother nature the identity thief.

The curse of being a data addict is that random bits of knowledge bubble up and clutter your head so you can’t stay focused on task. So as I picked up all my neighbor’s bits I found my self stuck on the last bit of the last verse.

Yes, ‘n’ how many times can a man turn his head,
Pretending he just doesn’t see?
The answer, my friend, is blowin’ in the wind,
The answer is blowin’ in the wind.

Most web login schemes work the same way. When the site becomes curious and wants to know more about the user it delegates that task to identity provider. The identity provider then authenticates the user and sends him back to the original site. Information about the user can then be sent via back channel of one kind or another. Lots of schemes exist for implementing these back channels: shared cookies, extra CGI parameters, full fledged TCP back channels.

Building a good identity service is delicate work. People screw it up because it’s hard. Criminals spend a lot of time working out schemes to trick the identity server into misbehaving.

Here’s a way to get it wrong: let untrusted parties bounce off your login server. In this example eBay’s the one that messed up. The problem? Phisher’s entice users to go to their eBay account an log in. Once log on the user is bounced over to the phisher’s web site. The user at that point thinks he’s talking to eBay; but he’s not. He’s talking to a bad guy.

The user thinks, when he logs into eBay, that he’s entering the world of eBay. This is similar to what in Liberty is call the circle of trust. As a rule of thumb identity servers shouldn’t provide services to unknown sites. The users presume that sites reached directly via the login server have some degree, no matter how slight, of trust among them.

It’s possible that an extremely lite weight identity system, like OpenID, could break this rule. The cost of conforming to the rule is two fold. It makes it harder to run an ID service, since you have to provision and maintain an account relationship with every site you service. More critical from a business model point of view – you raise the barrier to entry for additional sites adopting your service.

Personally I think ID services should always have an account relationship with the sites they serve. They can then hang a lot of useful junk off that account data; for example a list of URL patterns they are willing to bounce back to.

Every time you see data stuffed into a URL you obviously need to worry about what that might be revealing about the user which ought to be kept private. What’s less obvious is how every time you see an URL getting bucket brigaded along you need to puzzle out how the user’s trust model is changing as he travels. That URL can tap that trust. The first worry is about stealing bits of the user’s privacy. The second is about stealing bits of trust off the intermediaries.

Here’s an interesting example of what a huge wake we leave behind as we move thru modern life. The CIA team that kidnapped a guy in Italy and sent him off to Egypt to be “interrogated” left behind a nearly complete record of their movements (down to a few feet) and contacts. They left their cell phones on and since modern cell systems track and record everybody’s movements the Italians only had to get a court order and a database query. There is an unbelievable amount of casual revealing about you that your totally unconscious of.

A few years back the Irish cellphone company discovered that they had neglected to discard ten years of this data. Traces of every cell phone user in Ireland for a decade! Kinda puts to shame the data set MIT collected recently. They got a 100 volunteers and recorded 40 years of data (i.e. a couple months each). But you can download large swaths of their data and they have been doing some really fun things; like discovering who your real friends are and where your likely to be next tuesday at 6:45pm.

No worries.

People thinking about the identity problem will want to skim/read Bruce Schneier’s description of how the muscle behind the medical privacy laws is being gutted. I don’t see how we can expect to get reasonable levels of privacy without the regulatory schemes modeled by the various Privacy Protection Acts. But in the current climate the industries effected by the PPAs seem to have an easy time capturing the resulting regulatory agencies and gutting them. These are not problems that technology can solve.

OpenID’s #1 feature is the decision to have a web page for every persona. For example my OpenID might be “enthusiasm.cozy.org” (well actually it’s https://enthusiasm.cozy.org/ but OpenID sanctions some shorthands). This becomes in effect a universal identifier, like an email address or a social security number.

Deciding to adopt a web page as the user’s handle is an interesting design choice. It’s not hard to see how they fell into this choice. The primary driver of OpenID is a blogging company. Their users all have blogs. Their users are pretty much defined by their blogs. It’s a natural choice. OpenID is unique among the identity systems I’ve looked it, it has only one use case. Leaving a comment on a blog in a way that ties that comment back to the author’s blog.

This isn’t an identity system, like Liberty, designed to support account linking and sophisticated data sharing between mutually suspicious firms on the behalf of thier supicious customers. Since the design’s core feature is a universal identifier for users no privacy advocate is likely to love it. The lack of encryption on the message exchanges is a red flag for large numbers of people.

That said there is a lot to like about OpenID.

The question one needs to ask: Will we have an identity system where user persona is represented by public web pages? Once you accept that that is extremely likely then OpenID becomes a lot more acceptible as a point in the design space of identity systems.

Clearly web pages are better than email addresses or a phone number because those have a obvious operation available on them which is open to abuse. The set of operations on a web page are more limited and more easily configurable.

Users already have a mental model for web pages that is reasonable accurate. This reduces the chance they will just assume more privacy than they are in fact getting.

One very nice aspect about web pages is that we already have a deep suite of tools for empowering users to configure them.

User know, or they ought to know, that web pages are public and durable. So what ever the user publically reveals on the page he uses for his OpenID becomes public information, probably forever.

Nothing about this choice precludes users from having many persona. Nothing about this choice precludes those persona from being reasonably anonymous. It’s a shame that persona management isn’t more carefully designed into OpenID; but at least the mechinisms for it are reasonably transparent for users.

As a choice the decision to adopt the URL of a web page as the corner stone of a public open idenity system seems enivitable.

It’s important to take OpenID on it’s own terms. In it’s heart of hearts it is really just attempting to tie contributed content back to authors; at least a little. That is a more central problem that it might at first appear. OpenID is not trying to solve all the world’s identity problems.

I was confused about OpenID. This posting is second run at explaining how it works. Hopefully I’ll get it closer to right this time. (Nope, it’s not quite right yet.)

Like most identity systems we have three parties in the story. The user, a site that can ID the user, and a site that would like to know the user. It helps to personify these.

• Alice – the visiting user.
• Steve – the site Alice is visiting that wishes to know Alice.
• Victor – a site that knows Alice and can introduce her to Steve.

I think of Steve as suspicious and Victor as able to vouch for Alice.

In OpenID Alice is denoted by a URL, typically her blog’s URL, and then Victor helps Steve to be sure that when Alice actually owns the URL she claims.

The protocol is simple.

• Alice, via her browser, visits Steve.
• Steve asks Alice to reveal her URL, so he can get to know her better.
• Alice tells Steve her URL.
• Steve fetches that page.
• Steve finds a pointer to Victor’s service on that page.
• Steve works with Victor (via Alice’s browser) to check the URL.
• Victor provides Steve with a signed statement: “This URL is owned by the person currently signed on with Victor via this browser.”

This design has a number of options that aren’t obvious at first glance.

For example Alice might enter a URL that triggers a series of redirects before it finally generates a page. So she might enter alice.isp.com and the redirects could lead to http://alice.isp.com/homepage.html. The URL of page that is finally retrieved is used to denote Alice. This helps to normalize the URL used to denote Alice, but it also provides the chance to do some clever things.

Denoting Alice with a URL can be bad. Important ID safety I do not hand out global identifiers! It encourages revealing a lot more about Alice to Steve than Alice may desire, and it can make it easy for information about Alice to be aggregated from Steve and others like him. There is a work around for this, but it’s a bit unnatural.

Normalizing the URL could be used to work around this. If Alice enters is logged in at isp.com and enters id.isp.com then it the redirect could return http://id.isp.com/anonymous/for-steve/234145. All this reveals about Alice is what appears on that page, and that she has an account with isp.com.

I must admit the work around is beginning to grow on me. That thing (i.e. http://id.isp.com/anonymous/for-steve/234145) is what’s known in the trade as an opaque id for Alice; getting it out in the open has some advantages.

Another point to make is about Victor. Victor’s job is to introduce Alice to Steve, that’s it. He doesn’t need to run Alice’s blog, or host her pages. Alice doesn’t even need a blog. In one scenario Victor might work at Technorati; Technorati already has a page for every blog including Alice’s. If Alice gets an account at Technorati and claims her blog then she then Technorati knows enough to be her vouch for her. In another scenario Alice doesn’t even need a blog, she just needs an account with some site that’s willing to play the role of Victor.

The service that Victor offers to Steve is very limited in the current version of OpenID. Victor signs a statement: “The user denoted by this is currently signed on at my site via the browser in question.” Steve can check that signature by using Victor’s public key. Steve can grab the key from Victor’s web site.

Currently the design is only as safe as the Steve’s ability to get Victor’s public key, trust it, and trust Victor. The design doesn’t dig into these issues very deeply.

The design does not include a way to check Alice’s reputation, or tarnish it if she misbehaves. So if Alice isn’t a spammer she doesn’t get to accumulate karma for her good behavior; nor does it provides a way to revoke that karma if she suddenly turns into a raving loon. Of course one man’s loon is another’s endangered species; or in other words reputation is very contextual. If Alice’s ID URL is valuable to her that helps some.

Interesting arrival at the identity party OpenID. It’s simple, so it might spread fast.

This is a design that works with the existing web infrastructure. No need to update the installed base of client software. Good, that’s a nearly immovable object.

The usage scenario is straight forward. A random anonymous visitor wanders into supicious site. Supicious site would like to know more about this visitor. It asks the user for the name of some site that can vouch for him. The user enters a domain name. The suspicious site fetches the home page of that domain. Secreted away in the header of the home page is information about where the suspicious site can go to have a conversation with the vouching site. Using that info the two sites can then work with the user to make everybody happy.

It’s a nice design because the user explicitly reveals the name of the vouching site he’d like to use.

The spec could use some careful security review. The design is currently silent on why the supicious site would trust the vouching site. The design lacks any tools for fine grain control over what’s revealed about the user, and the distribution of that info.

The usual scheme to bootstrap finding the vouching site is to use a shared cookie; this is a nice alternative. The server in your basement might be able to play the vouching role. That’s something geeks like in a design.

Tim Bray’s posting on the Sun Microsoft interop demo is fascinating on many levels. It certainly adds to his reputation as an independent voice that while sympathetic to Sun’s goals is not entirely in the thrall of its message discipline.

He gives some validation to my hypothesis that the customer demand is one of the key drivers here when he writes “there’s no doubt that when the customers tell you to interoperate, then you bloody well interoperate.”

He makes the point I’d expect of a principle of institutionalized standardization to make “WS-Federation is yet another WS-backroom spec that might change (or go away) any time the people in the backroom want it to; not something I’d advise betting on.”

That the WS specs lack legitimacy from the perspective of a professional standards craftsman is absolutely true, and I suspect that customers were demanding that much more than they were asking to interoperate. An interop bridge is a poor substitute.

Getting a stamp of approval from a real standards body isn’t relevant if your solution wins in the marketplace. Microsoft’s installed base on both desktop and browser make that outcome entirely plausible.

Predicting how the market for enterprise identity management will standardize and how many vendors will get a portion of the market share remains a tough call. Both WS and Liberty are such complex specs that they aren’t well positioned to get rapid adoption. That is good for Microsoft and a problem for Liberty. Liberty is available in the market today, with implementations, real legitimacy from a credible standards body, a choice of vendors, and broad industry support. So that’s good for Liberty and a problem for Microsoft.

I don’t know what’s going to happen. Does the recent interop between Sun and Microsoft signal an end to the battle in this area, or does it just buy Microsoft some more time. It certainly does tend to let CIO/CTO decision makers defer deciding.