Adventures of an Eternal Optimist

I’m very excited to see Patrick Harding from Ping is blogging – he’s always got great conversation starters.

I’d like to continue a conversation which Patrick started with his entry entitled “User-Centric Identity Within the Enterprise” – Patrick made the following points about user centric identity, and stated that he is trying to go past technology issues, to underlying definitions, and relate those definitions back to an Enterprise employee world. You need to read the whole article – don’t depend on the bullets, but this is the gist:

• User centric implies user control
• User centric implies self asserted information
• User centric implies user choice of identity provider
• User centric implies simplicity and SSO
• User centric implies identity for Web 2,0
• User centric implies user privacy

I suppose the question is what it exactly it means for ‘user centric’ to imply something. Obviously use of a user centric technology is not limited in any of the ways that Patrick has described – at least with information cards, it is perfectly possible to build a tightly controlled set of RPs that are locked down to a single Identity provider serving managed data only, and heaven knows that its possible in general to use user centric technology to create things that aren’t simple, don’t do SSO, have nothing to do with Web 2.0, and in no way respect the privacy of users. But to run with Patrick’s idea of looking at the value of popular user centric tenets with respect to the Enterprise, I have a few thoughts.

• User Control
  • Perhaps it is true that most companies will be doing the choosing with respect to what data is sent where — however, the same features that aid user control also could serve an Enterprise belief in transparency.
• Self-Asserted Information
  • Self-asserted information is already commonly used in Enterprises – it is just called “profile self-service”. Most Enterprises I visit are very busy trying to set up interfaces for employees to self-assert address changes, name changes, and so on in order to reduce help desk overhead, so I’d have to say that there is a place in the Enterprise for this concept.

Hopefully this is a useful and construction addition to the conversation – I look forward to many more along this vein now that Patrick is around.

Apparently the HTML people received different instructions than the folks writing the client-side error handling :)

.NET Framework version 3.5 is now out of beta and in production – this means that the new version of Windows CardSpace is available too.

Based on the v3.5 download page, it looks like .NET v3.5 will co-exist with, not replace .NET v3.0 — so I’m not currently expecting any Windows Update surprises to be coming down the pipe, although I am guessing that .NET 3.5 would be part of Vista SP1 whenever that comes out. If I get more details, I will let you know. My big question is — if the .NET 3.0 version was v1.0 of CardSpace, what do we call this next version? v2.0? v1.1? v3.5? CardSpace TnG? I need something short so I can be simultaneously precise and lazy.

If you hadn’t heard about the new version and wanted to hear about some of the changes that have been made to CardSpace, you should check out the official CardSpace blog.

Oh Hushmail, you have failed us.

Here is what I naively would have expected to happen, when the feds showed up at Hushmail with a Canadian court order:

Feds: we need you to decrypt and turn over all email from the account of Mr. X — he is a very bad person.

Hushmail: gosh, we’d sure like to, but the whole point of our business model is that even if we wanted to, we couldn’t. Sorry ’bout that. If you want a whole bunch of encrypted mumbo jumbo to go play with, we’re more than happy to oblige, got a flash drive?

Here is my reconstruction of what seems to have happened:

Feds: we need you to turn over all email from the account of Mr. X — he is a very bad person.

Hushmail: well lemme look here… ooh! Whaddaya know! It just so happens that Mr. Bad Person X was stupid enough to not choose our uber-paranoid service, he instead chose the service where he trusts our servers for one single split second… What an eediot!

Feds: (rubbing hands together) excellent…. we’ll go get the flash drive…

Yeah, I get that Hushmail (the company) was in a bad spot, and I’m sure that this was not a joyous experience for them. I also understand that Hushmail (the service) is still a better choice than nothing at all, at least as long as you can keep yourself from being legally classified as a “bad person”.

I know that Hushmail has always gone out of its way to point out the extra risk attached to their more convenient service. I also understand that Mr. X probably really was a bad person.

None of that makes me feel better. My problem is not with the fact that Hushmail rolled over, it’s that they could roll over. Hushmail theoretically avoids liability and evokes trust as a secure service because the technology ensures that betrayal is not even a possible choice. Perhaps that trust should still be accorded to Hushmail for the more secure of their email services. Perhaps it’s true that there is no loophole for that second service. But if there is, we know that Hushmail could be compelled to use it. These days, anyone can be compelled.

I think the government should actually go one step further. I think they should take their inspiration from the North Dakota law enforcement team that invited 40 individuals with outstanding police warrants to an Alice Cooper pre-concert party so that the cops could arrest the criminals in a convenient and leisurely manner. The Powers that Be could create their own stooge “secure” service, then very comfortably sit back and let the privacy zealots come to them. It would be much more convenient and reliable than all this horrible mess with court orders, constitutional rights, citizenship, and so on. But wait, maybe they are way ahead of me? Perhaps this is what Dual_EC_DRBG is for… ?

James Governor notes the fact that the “fireside chat” as a medium for communication of data is more effective than PowerPoint ever has been:

Could it be that briefing without PowerPoint makes us more honest, as well as more engaging? Or perhaps its just that the execs I have recently met under the format are confident enough to be really frank.

The difference seems obvious to me – in a fireside chat, the words are your own. They haven’t had the sincerity sucked out of them by iterative waves of examination from handlers, marketers, or other protectors of the corporate faith, and the communication isn’t merely broadcast – it is a genuine feedback loop. You may still be the product of hours of PR training and briefing by everyone under the sun — but in order to reiterate without props, you are also forced to understand – and the depth of your understanding is suddenly directly proportional to the depth of the message you are able to convey to others.

That being said, I don’t think it is fair to blame the slide software. To bastardize a catchphrase, PowerPoint doesn’t bore people — People bore people.

I personally aspire to more of a Pecha Kucha style of presentation. I sure hope my legions of handlers and marketing personnel can take the transition…

If you aren’t already aware, the Internet Identity Workshop is coming up in December.

IIW isn’t a ‘sit and watch the experts’ kind of experience. It is a ‘roll up your sleeves and get your hands dirty’ kind of experience. It is about showing off what you’ve done so far and collaborating in the moment to do more. You don’t have to have a big name or a fancy title to be ‘good enough’ to be heard here. You just have to be doing interesting things and be willing to share.

IIW is not an expensive conference to attend, and the unconference format means that the attendees can control the agenda. It will be both a formative and an informative event, I hope to see you all there.

I hate to be a stickler here — but I still hate all of these generalizations. Sorry Gerry, Paul — I’m not trying to be mean, but my Implementer spidey-sense won’t stop tingling here. I hope I can explain some of my concerns here – and then I think I’ll have to put my money where my mouth is and write something in response that has a bit more meat to it.

If my bank were to one day allow me to associate an information card with my account, I see absolutely no reason why I would hesitate to associate a self-issued information card. If I’m reading Gerry’s taxonomy correctly, in doing so I would be doing my daily banking via a pseudonym-based, no assurance, low-value transaction. If I read Paul’s taxonomy correctly, there would be technical confidence but no legal confidence, even though I as an end user do indeed have a contract with my bank.

Let’s go past an authentication-only scheme and say that my bank will trust everything I assert from my self-issued card. That boils down to contact information — the same stuff that many websites let me change already. I can use a web form, the telephone, probably even a fax machine to do this already, and if I were to change my name on my bank account to “Mindy the Marvelous Mouse”, using any of those methods (including any kind of card), the consequences (legal or not) of doing so would be identical regardless of the actual mechanism I used to make my claims. So – in my mind, legal confidence with respect to fraud on the part of the claim originator should have nothing to do with the delivery mechanism. On the other hand, legal confidence with respect to impersonation of the claim originator may have a very different look and feel. Depending where the blame lies for the impersonation, the RP may not even be able to sue the claim originator, because they may not be at fault or even involved (or their terms of use may disclaim all liability, not sure if that really sticks legally or not). All of this points to the fact that you definitely do want to consider the delivery mechanism when deciding what mechanisms you allow in the first place — but if the system compromise happens at a low enough level, it no longer matters who you trust to say what (theoretically the big difference between self-issued and managed cards), because you can’t even guarantee the who, let alone the what. I don’t see an obvious reason why it would be easier to compromise an Identity Selector than an IdP — either way, there is certainly no reason to malign either card mechanism until proof exists that either one is more vulnerable than the other.

But wait, you say, how about data with real legal teeth? What if my bank allowed me to use my self-issued card to make claims about my own credit score?

Self-issued cards can’t make claims about credit score or SSN number or bank account number. They are incapable – by design. For what they can do, I believe they can do it well. For the rest, they are simply not applicable – which to me is very different from being low in assurance.

In summary, the only situation I can see where use of a self-issued card means a possible legal or technical setback of any kind for an RP (within the normal uses of such a card), is in a case where normal contact data is changed by the user to be fraudulent. I don’t think this case is much of a big deal — because people can do that now, via other channels, and it is a known risk that websites already seem to accept. If there are other cases which I’m missing, please let me know.

I apologize for continually throwing rocks at other people’s glass houses – I realize it’s a lot easier to criticize than to create. As soon as I have a free moment, I’ll try to write out all of what I consider to be valid factors, so that everyone can have a chance to throw rocks at my glass house too :)