Adventures of an Eternal Optimist

I’m now a proud member of LinkedIn – entirely due to conversations I was part of during the Identity Open Space in Vancouver last week. This particular site seemed to be the poster child for cases involving portability & accessibility of relationship data. The question on everybody’s mind seemed to be: Assuming that protocols exist to make relationships portable, what possible reason could there be for a site such as LinkedIn to adopt such protocols? Isn’t their identity silo a corporate asset? Technically, you can export your LinkedIn contacts – but the trick is, without some kind of common identifier to re-link your list into other social networks, your list is nothing but a bunch of text strings. Really it isn’t the data itself that is valuable – it is the method by which the data is indexed.

Enter Liberty “PeopleService”. The idea is for users to create & manage relationship lists which are made available & indexed in such a way that they can be leveraged in many places. Every person in the relationship cloud would have an IdP account that is (a) used to authenticate to the PeopleService, and (b) is used as part of the “handle” that would be used to uniquely identify this person within a relationship list that might span multiple PeopleServices. This is a woefully simplistic summary of the service, based on a talk given at IOSVan by Paul Madsen, hopefully I’ve got the essence.

The advantages to this plan are straightforward. Users would see the same relationship data at multiple sites, and would only have to maintain those relationships in one place. Sites leveraging this information could gain access to a fully fleshed out network of people without having to persuade their users to input everything from scratch. Best of all, everyone’s computer-unsavvy aunt doesn’t have to be walked through a whole new account creation step every time you want to share something with her on a different site – just get her an IdP account and refer to it forever more.

The problem is, entities who have worked to build their own “zoo” (to use the slashdot term) will need a good solid profitable reason to switch from a successful silo mentality to a federated method, which in their case would seem to be more about giving than taking. The idea that everyone will just suddenly see the light and ‘heed the lessons of Microsoft’ makes me laugh. Not even I’m that optimistic :-)

The way I see it, the only way the plumbing is going to change is if the decision is a business decision and not a technical decision. And the only way I can see that decision-makers who don’t happen to be visionaries in this space will come to understand the benefits, is to be outplayed. In a rosy perfect world, the right startup company will adopt Liberty’s PeopleService (& therefore the rest of the stack) from inception, and build their zoo from scratch. They will sign everyone up to what I predict would be their own ‘locally owned & operated’ IdP & PeopleService, and the resulting zoo + service will be adopted gladly by other sites. At some point the advantage of a wholly owned relationship cloud would consequently dwindle. The advantage will fall to those with valuable meta-data, as Bob Blakley so eloquently pointed out at Catalyst this year.

Can I pause to ask a dumb question? Is it really a given that moving ownership of the zoo from application silos to IdPs gives more power and/or convenience to the user? Pete Rowley asked at IOS Van whether the Liberty folks were just architecting yet another identity silo. His comment started me down the path of pondering what happens when you distribute ownership of the zoo, but merge usage from an RP perspective. Seems to me that vertical silos will be replaced by horizontal silos. Sure, in theory no one IdP would control all the users – but they will control all the sites that their own local userbase can access, through negotiation of trust relationships and/or contractual red tape, however that works. This seems to me to potentially be much more powerful than the clout wielded today by a Yahoo! or a LinkedIn. Are we leaping from the frying pan into the fire, trading application lock-in for IdP lock-in, or is the portability built into the protocol enough to make sure that a user can dodge that kind of pitfall with their relationship lists intact?

Either way — wanna connect?

– Pam

There seems to be a big kafuffle over this calendar, which features Aussie women in IT as famous Screen Goddesses. The goals are listed on the site, but generally include focusing media attention, raising awareness, and smashing stereotypes.

Some people are upset about using sex to sell a brainy career. Personally, I have never understood this idea that showing off the diverse talents of girl geeks somehow demeans them. We’re not robots, we are flesh & blood people who have jobs that we work hard at. Many of us are pretty damn good at what we do. Some of us are beautiful, some of us are introverted, some of us have crazy hobbies, some of us are just plain crazy. It’s true, the women in this calendar may not accurately ‘represent’ all women in IT. Oh SHUCKS. Name me the person who ‘represents’ all men in IT. I doubt there would be consensus there and why should there be?

My thoughts are that being intelligent does not mean we can’t also be sexy, or express ourselves in any number of other ways. Appearing in a calendar IN NO WAY reduces the intelligence of those women, and implying that somehow their beauty or their decision to be in an IT-associated calendar diminishes their ability to act as role models to young women considering careers in IT seems crazy to me. This calendar may not speak to all women, but it doesn’t have to. I’m sure there are many other recruitment initiatives in place (initiatives that this calendar is intended to help to fund BTW) that would meet the approval of even the most conservative critic. Diversity is good, both in people and in recruitment approaches, and if everybody disapproves, that should show in poor calendar sales.

Of course, I intend to buy a copy of the calendar, and I consider the whole exercise to be all about Grrl power. I *will* be objectifying these women. I will admire them from afar as being smart, successful and sexy. Just try and stop me.

Well then, back to your regularly scheduled identity-ish blog…

1. The July CTP is out, with an updated CardSpace Client! Will review right away.
2. MS has launched a nice new WCS Community Site, with easy links to the forum, samples, announcements, and a “sandbox” site that tells you how to get the client set-up and going. Thanks Dave, for pointing it out to me.
3. I’ve put a new permanent page up: CardSpace: Quick Start. The goal is to make this a place where all the tidbits I discuss in the blog are collected. A sort of “one-stop-shop” page. Please take a look and let me know what you think. I’m sure there is a lot missing so far, I’ll make sure to add whatever you all suggest, and keep it up-to-date in general.
4. Since a few people have asked, I would like to state for the record that I wouldn’t know a Prada purse if it hit me in the head :-)

It’s CTP time again!!!

The WinFX (now .NET 3.0 Framework) June CTP is available for download. If you aren’t in a big hurry, and you only have time to play with one CTP in the next 2 months, you are much better off to wait for the July CTP (no really, not just my opinion) — as well, I believe that the long-awaited almost-mythical-by-now IAM Resource Kit will be updated by that time too.

One small fly in the ointment: the June CTP doesn’t actually seem to work with any internet-based Relying Parties. Every single one of them results in the CardSpace introductory page coming up on my client, but then the client exits and I’m left with an error page on the RP. (update – Big Dave Diode points to a published but not proven workaround here)…

But hey. Can’t have everything, right? I’ll try and figure out what’s wrong there, and I’ll also fire up my Sept Resource Kit code and see if it works or breaks. Until then, I can’t really talk about functionality yet, just the eye-candy:

New Colors!!!

(OMG I feel like a teenager squealing over a new prada purse :-))

• All of a sudden, CardSpace looks like a built-in Windows component. I have no idea what the Vista look/feel is, but I have to imagine that it is closer to this new GUI than it was to the old one (although I was very partial to the old one).
• There are tons of new options too, like accessibility and so on. I can’t actually authenticate to anything yet, but when I do, I expect to see other exciting things.

Logo

• Both the CardSpace logo and the “digital identities” control panel applet have nice new logos.

Small Bitty Itty Cards

• All that trouble to add your own picture to your card, and you can barely see it! On a managed card, you may want to examine it in a more detailed fashion than is currently available.
• I remember asking if it was possible to resize your cards to your own liking — apparently there are just a few items higher on the priority list for version 1.0 :-)

New/Altered Claim Types

• Web Page URL:
  • The CardSpace UI has been changed to add a field called “Web Page”. Woohoo, first item to be fully checked off of my Laundry List!
• Date of Birth Validation:
  • The CardSpace client no longer allows you to type in a random text string for the Date of Birth – it is now a calendar pop up. I have no idea what the backend storage type is (perhaps ISO 8601?) but as soon as I can, I’ll find out and let you know. I have to imagine that an updated version of the technical reference will be coming out soon, with these claim types updated.

General Flakiness

• Every so often I lose all of the desktop icons and the task bar (not a huge deal cause you can still use CTRL-ALT-DEL to log off & on again)
• I’m not sure if the “can’t authenticate” thing is a bug or just an incompatibility (or a PEBKAC thing). If it is a bug it is short-lived, as the July CTP is going to obsolete this preview right away. My guess is that this is temporary.
• Update – there also seems to be a few issues with shutting down. As in, it hasn’t managed to accomplish that task yet, although it has been trying valiantly for quite some time.

IE7 Notes

• Good news: IE7 beta 3 now supports a whole bunch more platforms, including Windows Server 2003. This is much less restrictive. Bad news: you now have to “Validate” your Windows installation. This really cheeses me off, in fact the whole “must be on the internet to install” thing enrages me, for both dotnetfx and for IE7. I am using virtual machines that I don’t particularly feel like patching and therefore DO NOT WANT ON THE INTERNET!!! Forcing me to do so makes my life riskier, and I resent not having a choice in the matter.

After reading & responding to Ashish’s thoughts on the recently changed Microsoft name for InfoCard (now CardSpace), I’ve gone back and read some of my own pre-name-change blog entries, and it turns out that after blathering away about how articles (the, a) made all the difference, I wasn’t even consistent with my own usage.
I naively thought, ‘Hey, why don’t I just quickly write out what I mean when I use these terms, so that I am at least consistent in my own writings’.

Ha. Yeah right.

Turns out that attempting to exactly define things raises more questions than it answers. For example, in order to differentiate between the Identity Metasystem and an Identity Metasystem, I first have to explicity state what an Identity Metasystem is! I have my own understanding of what that is, but is that understanding definitive? Probably not – and do I really want to publish a poorly thought-out definition on the big ol’ internet? Nope. Well, so much for ‘quickly writing things out’.

Next comes the term “Identity Selector”. Does the presence of such a term automatically define the process of using that Identity Selector as ‘identity selection’? I’ve never used that term, but it occurs to me that it would be nice to have a term to refer to that process. Can I just make it up? Who knows.

After that, I define Identity Provider (IdP) and Relying Party (RP) – but I’d like to restrict the meanings of those terms to the exact functionality of ‘the Identity Metasystem’. In reality, those terms are used in many other technical contexts. Do I need to qualify the names in order to let people know that I’m specifically talking about entities that do very specific things like kick off WS-* enabled Identity Selector clients and communicate security policies via WS-*? If so, how do I qualify them? ID-WSF has Identity Providers, Relying Parties, and Identity Selectors too, I think. How do I differentiate without writing long verbage every single time? Do I abbreviate like this: IM-IdP, IM-RP, IM-IS, ID-WSF-IdP, ID-WSF-RP, ID-WSF-IS? What about the IdP and RP in an ADFS context? Where do you limit the scope, I ask? Oh, the humanity…

I hate getting all uptight about naming. I know I could continue with my current semi-ambiguous names; anyone who would find this blog remotely interesting is probably already familiar with the concepts. Still, it makes me feel that if I can’t definitively state what it is I’m talking about, then perhaps I shouldn’t be talking about it in the first place.

I have to admit – I’d much rather go play with the protocols… just writing this much about it has me contemplating an alternate future career in macrame :-)

Maybe someday I’ll be brave enough to take the naming bull by the horns.

–Pam