Hmm, I wonder if I’d had too much coffee before getting on the phone with Jim yesterday. I have a habit, acquired from my dad, of pacing all over the place while talking on the phone, and I do have an awful lot of stuff going on all at once, so I’ll buy “rushed and frazzled”! (I always think of Worf saying, through gritted teeth, “I am calm.”) It was good to catch up with him. His skillful questioning about privacy did lead me to a new realization about two thoughts I’ve often had separately, which he captured well in his post.
Jim reported my saying that “OpenID 1.0 has a vulnerability in that it leaves users’ identities open to possible correlation by unauthorized third-parties.” To head people off at the pass who might incorrectly take “vulnerability” to mean something about “security” rather than something like “design consequence”, here’s more detail on what I meant.
OpenIDs are designed to be publicly known identifiers, which turns out to be a very handy property. However… While you can still have many of them, the “profile” capabilities of things like MyOpenID help you manage different subsets of information about you within a single one, and obviously having fewer logins is easier to deal with than having more. And while some new features in OpenID around “directed identity” may help you keep your real OpenID secret from the relying party, the architectural bias of OpenID’s design is public accessibility of the identifier. (This is something I commented on a bunch over the last few months, and the progression of “interesting identity problems” in my Moose Camp notes hint at it.) Also, despite the “pseudonymous” nature of an OpenID identifier, if you do own your own domain, there’s ways of looking you up. And so on.
And regarding the (only loosely and metaphorically) “opposite” problem in CardSpace, Jim points out a real question I have. Today, I’m used to logging in to (say) this blog by means of my laptop, my husband’s iMac, my Treo, random SunRays… Web authentication may not be hella secure a lot of the time, but it’s convenient. If I were to install a card in a CardSpace on my laptop for logging in here, how much trouble will it be to make it portable and/or install similar cards elsewhere? What are the consequences of developing client-bound context for each of these interactions? Is this issue being worked somewhere?
Having consumed my customary two cups (freshly ground beans in a Mr. Coffee) in the writing of this, I feel well fueled to tackle my day. Jim, if you come out this way, we can meet at the place I call the Lake Street office and the coffee will be my treat.
Is there a relationship between authorization and impersonation? How do I get to say who can impersonate me in what context?