Adventures of an Eternal Optimist

Yes

there will be an Information Card Interop Event at the Burton Group’s Catalyst 2007 conference in San Francisco on Wednesday June 27, 2007 from 6 – 9:30pm.

Yes

all of the cool kids from the world of information cards will be there, and ready to show each other, the Burton analysts, and most importantly – YOU, the folks who might just want to use this technology to solve a few important problems, just what this technology can do – not in theory, but in demonstrable practice.

Yes

we’ve already started — everyone got together at the IIW conference in Mountain View on May 15, 2007, and started testing combinations – 11 Relying Parties, 7 Identity Providers, and 5 Identity Selectors (also known as Identity Agents) all worked together to see what combinations of 4 different token types, 2 different managed card authentication mechanisms, and 10 different required claims, of varying types.

Yes

the Pamela Project is participating in the Interop — please make a point of dropping in to say hi, I’ll be hanging out in the Relying Party section, and I would love to talk to you.

So are you coming out to see us?

YES!

Mark Dixon is asking what some common success/failure factors might be for Identity Management projects.

To me, talking about success/failure of an IdM project is like talking about success/failure of a home plumbing renovation. Technically the project is a success once the water starts flowing — but the real story is in how long you went before you could take that first shower, how much $$ you had to lavish on the project, and whether you had to rip the drywall out again a week later.

I think the essential problem lies in the fact that IdM tools are built and sold on the strength of their ability to handle common, well-understood business scenarios, but the companies that try to implement such tools are messy conglomerations of systems and process with almost as many exceptions as there are rules.

My experience has been that the companies most likely to get into trouble are:

• Companies with long & varied histories of mergers & acquisitions.
• Companies with fractured lines of communication between different provisioning entities.
• Companies with executives who *think* the business processes are straightforward but don’t take the time to dig any deeper.
• Companies who are afraid or unable to take action when business process problems become evident during attempts to automate.

My strongest advice for companies starting IdM projects is: know your business processes and survey your repository content & structure to determine conformance to those processes before you try to assign a cost or a length to your project. Otherwise, what’s really happening is that you are giving your IdM project a bad rap – because they are having to perform both a business process audit and a technical implementation of the results all in one go, and when that happens, timelines slip.

Look at the small things – that is what will drag you down. Look at things like identifier life cycles across different systems, like identifier length limitations, especially on legacy systems, look at case sensitivity and encodings (ie Latin-1, UTF-8) of both names and identifiers across systems (especially mail systems, and even if you don’t believe that anyone in your company has a name that uses fancy characters), look at how geographically diverse your AD forest is and understand what the processes for choosing the fileshare that home directories & mailboxes get allocated onto, as well as whether those allocations or other business process decisions depend on departmental or locational data. If they do depend on departmental or locational data, is that data actually present in reliable format and in a consistent way from a data repository? This last question is CRITICAL – because if the only way a user gets placed on the right fileshare, or into the right groups is due to the fact that the person who enters the data into the system “just knows” where the right place is… well that’s tough to emulate in a system, and you had better anticipate a little consternation from the deployment team.

The bottom line is, garbage in, garbage out:

• the complexity of your IdM project is directly related to the complexity of your business processes, especially those that are non-standard, or that have multiple originations.
• the initial length & cost of your project will be related to how much/badly your company diverges from the common scenarios covered by IdM tools.
• the likelihood that you will stay on-time and on-budget within that project depends on how close your initial understanding of the gotchas and exceptions are to the reality of your specific situation, and how good you are at forecasting what time will be needed to deal with all the things out there that you haven’t found yet.

Not that I have strong opinions on this subject or anything :-D

Who’s to say
What’s impossible
Well they forgot
This world keeps spinning
And with each new day
I can feel a change in everything
And as the surface breaks reflections fade
But in some ways they remain the same
And as my mind begins to spread its wings
There’s no stopping curiosity

I want to turn the whole thing upside down
I’ll find the things they say just can’t be found
I’ll share this love I find with everyone
We’ll sing and dance to Mother Nature’s songs
I don’t want this feeling to go away

Who’s to say
I can’t do everything
Well I can try
And as I roll along I begin to find
Things aren’t always just what they seem

I want to turn the whole thing upside down
I’ll find the things they say just can’t be found
I’ll share this love I find with everyone
We’ll sing and dance to Mother Nature’s songs
This world keeps spinning and there’s no time to waste
Well it all keeps spinning spinning round and round and

Upside down
Who’s to say what’s impossible and can’t be found
I don’t want this feeling to go away

Please don’t go away
Please don’t go away
Please don’t go away
Is this how it’s supposed to be
Is this how it’s supposed to be

– Upside Down, Jack Johnson

Here is a simple and likely RP scenario that I’d like you to consider:

A given site wants to allow users to pay with either their Visa or their Mastercard information card. They do not, however, accept American Express. How should they create their security policy such that Visa and Mastercard managed cards are both highlighted in the Identity Selector if present, but also such that an American Express Card is grayed out and not clickable?

Would you all agree that this is a pretty important thing for a Relying Party to be able to implement? I think it’s important too, but I don’t see an easy way to actually accomplish it.

To my knowledge, there are two ways to choose what cards are highlighted and what cards are grayed out in the identity selector:

• if a card’s issuer matches the value of the issuer parameter
• if the entire set of required claim types are all present in a given card.

In the scenario above, the issuer parameter is a non-starter, because Windows CardSpace v1.0 only accepts a single issuer. And at this point in the identity metasystem, what WCS says, goes. I can specify Visa’s STS, or I can specify Mastercard’s STS, or I can choose not to specify an STS at all, but I cannot specify exactly two of them. Bottom line: as soon as I need to create a policy that lists more than one issuer, but less than all issuers, I cannot use the issuer statement.

So – that leaves us claims. Claims are great – when you can use what’s in them. In this case, however, the RP can’t work with claim values, only with claim types. In order to succeed in my scenario using claims, I would need to be able to specify a claim type that both Visa and Mastercard offer, but that AmEx doesn’t, in order to have the right cards show up and the wrong cards gray out. What exact claim type would that be? The only way I can see to architect such a thing is to have a commonly agreed upon but different claim type for every possible distinct combination of credit cards. Let’s say that there are 6 major credit card companies out there. How many permutations & combinations of claim types would be necessary to cover every single combination of 2,3,4, and 5 accepted cards, and how ugly would it be to add a new credit card?

It could theoretically be done. Identity Providers would have to start publishing two very separate types of claim types — contentless claim types that advertise capabilities, and content-rich claim types that would deliver actual data values. If you implement the capability claim types as constants and not as directory schema, it isn’t so bad — but the big problem is, it takes the ‘distributed’ out of this wonderful distributed system.

Unless things change (or unless I’m proven wrong, maybe I’m just missing some answers and need to be educated), here is what I fear will happen: users would go to a Relying Party Site, only to be presented with an HTML “menu” of supported managed card providers. They would then click on the card provider logo, and an HTML object would be invoked which has an issuer tailored to that single provider. Is this what we want to have happen?

If it does happen, I can see all sorts of fallout:

• Common claim types are no longer needed to ensure the user picks the right card. This is good.
• Every RP has to alter HTML to support a new Identity Provider. This is bad, or at least worse than adding a url to an allow or deny list.
• The ability for a Relying Party to require the same claims from every Identity Provider becomes damaged. This is bad. Of course, with issuer in the state it is in, I would say that no matter what, this is already the case.
• The system is more distributed, but MUCH less consistent for the user. This is bad.
• It opens the door for the more established Identity Providers to set arbitrary rules on what attributes “must” be asked for in order to interoperate, forcing Relying Parties to embed different code for each provider. This is bad.

Of course, all of this hinges on how important the initial card presentation ceremony becomes to the world. Remember that we are not talking about the RP’s ability to accept or reject a card once it has been selected. We are only talking about how to get the most user-friendly initial display of highlighted or grayed out cards when the selector opens. Maybe this small part of the information card ceremony won’t end up being that important — but I predict that it will. If I could have have any kind of solution to the problem, it would be the ability not just to list multiple issuers, but to apply Boolean logic to the list, so that I could represent ideas like “every issuer except these two”.

Kim, Mike, what can we do? Is this as big a problem as I’ve made it out to be, or am I just whining about something inconsequential? What is your vision of how my scenario could be implemented? Can this be solved with a few best practices, or do we need to change the way that information card RP security policies can be specified?

Update:  Kim answers here – thanks for being so responsive   :)

The story of Joe Anthony and the Barack Obama MySpace profile is a crazy tale of identity and social networking power.

My probably garbled & over-simplified summary:

• A fan worked for several years to create and maintain a network of friends in support of Barack Obama, using an online profile that is the MySpace equivalent to barackobama.com. The resulting network of friends was huge – 160,000 connections.
• The campaign decided that this web property was too critical to not directly control. They asked Joe to make a buyout offer and Joe gave them one – a little under $50, 000.
• The campaign balked at the number, never counter-offering, and decided that Joe was squatting. MySpace agreed with that assessment (remember, the profile was created in Barack Obama’s name).
• Control of the web property was given to Obama campaign — but after what appears to be some yelling and screaming, the friends list was assigned back to Joe, on a newly chosen web property.

The combined value of the web property and the FOAF list is obvious. How much value have they each lost by being separated? And what about the damage done by the publicity over the separation? I really, really like the justice in awarding the property to the identity-holder, while awarding the friends-list to the relationship-builder. It is a rare single-site example of the value of portability in social network data.

If Joe had registered barackobama.com and had it taken away by the campaign (an open/shut squatting case), the campaign would have gained control of both the website and the readership. An easy done deal, no ifs ands or buts, thanks for the work we’ll take it from here Joe.

But at MySpace, Joe still has his soapbox. And the Obama campaign still has to work to build up their social network again. The great thing about this, is that the readership gets to decide. They can show their support for this political campaign by registering for the now official profile. They can show support for the unofficial fan site by sticking with the original profile under a new name. They can do both. They can do neither, withdrawing subscription from both profiles in protest. I don’t think it gets much more egalitarian than that.

Power to the people, baby, power to the people…

I`ve barely recovered from this year`s Directory Experts Conference. As always, the NetPro folks found a great location, fed us well, and kept everything running like a finely oiled machine. Even a Wookless event couldn’t kill the fun — Wook took his challenge from Stuart Kwan remotely and exceeded all expectations as usual. This time the challenge was to adapt the kermit-the-frog song “rainbow connection” to describe strong authentication… it was priceless.

This year, it wasn’t the partying that tuckered me out at DEC – it was the coding marathon! We had a last-minute sprint to finish up our information card adventure for the attendees at DEC, cooked up by a few of us for the purpose of getting people at the conference to use and understand the Identity Metasystem as a real thing and not merely as a lofty concept.

Our adventure was a website called HOT CHICKEN!. Hot Chicken! is a site where you can go to vote on the best picture of a DEC attendee with the DEC Chicken — in this case a 6’5″ rendition of said chicken. The attendee who gets the most votes for their picture will win a Microsoft Zune – but you have to use an information card to see the pictures and to vote. If you are wondering what on earth any of this has to do with a chicken, the answer is that the chicken has a long and venerable history at DEC, which I am nowhere near qualified to explain. You’ll have to check out Gil`s blog for that kind of insider information :)

The Hot Chicken! site is built with Joomla (the open source Content Management System) and has PamelaWare for Joomla installed, not quite a version of PamelaWare that I can release (I hard-coded most of the admin settings) — but it is pretty darn close. Using PamelaWare for Joomla (PW-jos for short), users can authenticate to Joomla via information cards.

Even MORE interesting is that you can authenticate to Hot Chicken with one of two Identity Providers:

• Kim Cameron’s “Human Present” Identity Provider (this is the code that Kim demoed at IIW last december)
• The Pamela Project Identity Provider (an instantiation of the Higgins STS, running on Ubuntu)

So please go and give Hot Chicken! a try! You’ll see there are still loose ends & holes (there are a few blog entries that will come from my chicken experience, that’s for sure), and we’re missing some critical validation bits & testing, but I’m still pretty sure that by enabling Joomla and opening up 2 new identity providers, we have taken a big step.

The Pamela Provider is up and running as a direct effort on the part of the Bandit team, and particularly of Daniel Sanders and Dale Olds, who managed to plow through all sorts of barriers and issues with dogged determination to get the provider running in time for Gil’s announcement on DEC day 2, as I worked on RP code (which was originally contributed by Pat Felsted, another Bandit, and then “pluginified” by me). The Bandit team as a whole has earned my eternal respect & gratitude, many thanks everyone (even Tom) :). I’m really looking forward to growing and maintaining the Pamela Provider for a long time to come, and to contributing back to Higgins in as many ways as I can.

Of course, all of these shenanigans were really a prelude to my talk on CardSpace — a summary of which I will save for another day.

So go vote!!! And tell me what you think…