Adventures of an Eternal Optimist

For your holiday hacking fun, I’ve got a new version of PamelaWare for WordPress ready!

Version 0.9 is a big improvement over previous stable releases, but still only allows a single card to be associated with a given account. While you’re messing with this version, I’m hoping to add the ability to associate multiple cards with a given account, as well as the ability to add and remove cards while in an authenticated state.

I have tested this version extensively — but I’m sure I’ve missed things — any of you who might wish to play could go to my test blog: http://pamelaproject.com/pamtest if you want to play with a vanilla install, and to the pwwp main blog: http://pamelaproject.com/pwwp if you want to test a blog upgraded from the original beta.

If you want to see what’s up with the Pamela Project, you should check out our development site: http://code.pamelaproject.com.

I’d like to see a few people (like, oh, say, Kim) give this version the thumbs up before I holler about it too loudly. But I’m really glad it is out. You can get tarballs or go directly to subversion from our development site.

Have fun, drop me a line if you see any problems. I’m away snowmobiling until January 2nd, so until then, enjoy yourself, and Happy New Year!

Imagine this little scenario:

• Your Macbook hard drive fails.
• You take it to the Apple Store to get fixed.
• They charge you a fortune for an out-of-warranty repair and then refuse to return your broken hard drive to you – they say it is Apple’s property, not yours.
• Your original hard drive gets refurbished – and somebody thinks to look at the platters before they zero it for the next person.
• Next thing you know, your data is for sale on Ebay.

The first 3 bullets happened to Dave Winer – and he has no control now over whether the last 2 bullets become a reality.

What I find especially interesting about this story is that this wasn’t even a case where Dave got a free drive through warranty — he actually paid for the new drive, he paid for the computer itself — yet the original drive was not considered his property. How does that work exactly? And how does Apple get away with an opaque policy with no option for redress?

I sincerely hope that none of Dave’s data shows up in the wrong hands. Apple should hope so too; that is assuming Dave’s story even penetrates Apple’s shiny white corporate iExterior.

Well, now that we’ve had some time in the clouds (so to speak), I feel like getting back to earthbound reality. I’ve been playing for a while with an interesting beta offering — an Identity Provider called SlashID.

SlashID calls itself an ‘untrusted’ provider – my interpretation of that is, you don’t have to trust that SlashID will accidentally or purposefully betray your data to anyone – because they store that data in encrypted format, with your user password as the key, and the unencrypted key is never in reach of SlashID servers. Similar to a service like HushMail, this should mean that SlashID is incapable of abuse or negligence (other than losing or corrupting your data en masse, I suppose).

Of course, there still is trust needed – you have to trust their code to not contain backdoors, legally coerced hacks, and so on (queue the evil music reminding us of HushMail’s recent issues). There is an excellent response to this and other issues (such as the relationship between SlashID and OAuth, or OpenID Security) on the SlashID blog, if you’re interested.

SlashID uses its own protocol specification, and they have a lot of information available on why they’ve gone in this direction, but what I like about this company, is that this is not a company who is trying to blindly make a business out of a technology — they understand the service they want to provide, and the value proposition for that service — and they are leveraging the technology that they feel is going to get them to their business objectives. I feel like this is a healthy, healthy approach.

I’ve got the SlashID Relying Party code running on one of my test blogs right now, so if you want to try out the service there, be my guest. One day, when I move my blog to my own domain, I’ll enable my blog as a permanent SlashID client. You need to register for a user account at SlashID before you can authenticate; once that is done, you can use your credentials at login screens where you see this logo: Just remember — these guys have NO way to get your account back if you forget your password, so make sure it is recoverable by you, yourself.

I think that one of the biggest problems facing SlashID right now is identical to that of any company trying to offer mainstream products or services based on crypto: how do you make both the general user and the RP app owner understand the underlying paradigm well enough to make secure decisions and understand the consequences of their decisions, while still providing a user experience that isn’t too terrifying?

I’ve had a great time working with the SlashID guys on this – they are responsive and very interested in feedback, so if you have any to pass on and aren’t sure how to communicate it, drop me a line and I’ll make sure to pass it on.

Since you all probably won’t want to run off and register your own website while checking this stuff out, let me know if you’d like to see/play with either my RP setup at SlashID or on my blog — otherwise I’ll end off with a few screenshots of what it takes to set up a relying party with this technology (click on the image to get a bigger version)…

Configuring Attributes passed from IdP to RP at the IdP:

Configuring Crypto at the RP, via a WordPress Plugin:

Yes, I do think that this technology will have a SKU Paul. It will have a million of them. I believe one day you will buy a cell-phone at Future Shop and the first thing that you will do when you turn that new phone on will be to import all your contacts — and all your information cards. Same idea when you buy your Tivo/PVR – the first thing you’ll do is specify what information cards are authorized to view content. Same idea with your wireless router. Same idea for your set-top box, and for your video game console. That is my personal vision for information cards. They will be commodotized, integrated, a taken-for-granted part of our daily lives. They will be futureshopped — or they will be forgotten.

But that wasn’t really your point, was it Paul?

Your actual point corresponds with one of my major takeaways from this month’s IIW conference: we have critical problems with our ontology (or lack thereof)- and for several reasons. There appear to be serious misunderstandings about which terms Microsoft has trademarked and which ones they haven’t. There are also some very literal minded folks who just can’t handle the use of a semantically loaded but generic term as a proper noun. And then there are the people like me; I’ve been using the term ‘Identity Metasystem’ as a synonym to the stack of protocols described by the Identity Selector Interoperability Profile (ISIP) v1.0 — while at the same time using it to describe all information card systems. I realize now that I need separate names to describe the visual metaphor, the technical paradigm, and the specific protocol stack for which I write software.

Seems to me that if our community can’t describe what information cards are or what they do, in simple terms that nobody argues about, we certainly aren’t going to get anywhere close to daily use by millions of people. This is a starting-gate hurdle. So where is the sweet spot of terminology that will let us move forward?

I’d say I don’t care what the names are as long as they are consistent, but of course I do care. Quite a lot really. Here are the things that I perceive to be useful during this debate:

1) There are two and only two terms that I am positive cannot be used generically: they are “CardSpace” and “digitalMe”. To my knowledge, these terms are trademarked, copyrighted, and backed by bloodthirsty lawyers. Calling the whole system ‘the CardSpace system’ is a no-go. Period. I can’t see why anybody would want that in any case – and yet I’ve heard it proposed.

2) Shortening the “Identity Selector Interoperability Profile 1.0″ to ISIP 1.0 is very very useful. It is probably the least contentious way to describe today’s prevalent information card system. Calling it MS ISIP 1.0 seems to me to just be adding more letters to an already clear acronym but hey – fill your boots. Calling it MS ISIP ™ is just silly, imo.

3) Using the terms p-cards and m-cards to describe the two types of ISIP cards currently out there makes no sense to me, since in my vocabulary, personal and managed mean very simple things: personal means you make the card yourself, and managed means somebody else makes the card for you. As such, I believe there will be personal and managed s-cards, personal and managed r-cards, and so-on.

4) I’m tired of the metasystem debate. I find it divisive and pointless. To me, it’s like not being able to accept the term “the Internet” because you are morally and ethically opposed to the fishing metaphor. I’m happy to let the term die, in the idealistic hope that we never ever have to play semantic table-tennis with the word meta again.

Instead, how about I tell you all a new story, containing some different words that might make everybody happy?

Once upon a time, there was a metaphor called information cards. In the same way that web pages are manipulated with a browser, information cards are manipulated with a selector. Information cards can be cards you create yourself – those cards are called personal cards. Information cards can also be cards that somebody else creates for you – such cards are called managed cards.

Every information card is part of a “cardsystem” – the set of protocols that enable cardsystem-specific components to communicate with each other. The first cardsystem implemented was created by Microsoft and uses the ISIP specification. Other cardsystems include r-cards, where the set of protocols include RSS, and s-cards, where the set of protocols uses SAML but not ISIP. Currently the cardsystems supported by the CardSpace and digitalMe identity selectors are limited to ISIP v1.0, but in the future we expect other cardsystems to mature and become supported among information card components.

Does this work?

This is my response to a current blogosphere conversation on user centricity in the Enterprise, started by Patrick and carried on by myself, Nishant, Johannes, and Matt…

I have a lot of passion about the tools I choose to work with. I believe in working on and with tools that further us as a democratic society. I believe in using tools constructed such that the easiest way to implement are ways that by default tend towards preservation of user privacy, minimization of data retention, and smallest attack surface.

I also, however, believe that the tool has to fit the task at hand. Part of choosing a tool in an Enterprise is deciding whether the tool is capable of adherence to internal policies – this may include privacy controls, platform support, cost, improvement in end-user productivity, regulatory compliance, and so on.

If you take all of the tools out there that have had the ‘user-centric’ tag associated with them, and try to shoehorn any one of them into an Enterprise based on the moniker alone, I will laugh at you, as one IT professional to another. Really, I will. The idea that ‘user-centric’ has to mean anything at all in an Enterprise context, just makes no sense. My advice to Enterprise decision-makers is simple: take the tools and find out if there is a story that those tools can tell that brings value to the organization. If the story is there, adopt the tool. If the story isn’t there, walk away. Whether or not the marketing term applies is, to me, utterly inconsequential.

I can tell you a story for OpenID in the Enterprise. I can tell you a story for the Identity Metasystem in the Enterprise. I can tell you a story about Liberty in the Enterprise. If any of the stories match your goals for your business, fantastic. If they don’t – no problem. There are a large number of stories, but there are infinitely more business scenarios to match them to.

If you try to tell me that using a tool such as the Identity Metasystem to accomplish something other than a user-centric philosophy is wrong, I will also laugh at you. If these tools were built properly, the philosophy should be inherent, not resultant – in other words, you should get user centricity as part and parcel, the kernel of the technology that makes it user-centric shouldn’t be subtractable — but user centricity doesn’t have to be the actual problem that is solved along the way.

I would like to see Enterprises adopt technologies such as the Identity Metasystem for no other reason than because it helps their business to succeed. The fact that as a welcome corollary we lay the plumbing for users to also have greater control in other aspects of their internet life, and for future developers and/or administrators to perhaps begin to be able to architect their applications around a claims-based security architecture, thereby perhaps one day furthering the beliefs I spoke about at the beginning of this entry — well that’s just gravy. I feel it is possible that we can get to a place where such a thing just might work, which gives me faith that maybe we can begin an organic upwards security spiral, with identity at the center and acting as a foundation and inspiration for other areas of this industry.