Working on an interesting side project this weekend, so pulled another interesting entry from the archives. This was originally posted in December, 2006.

I've had an interesting day today. Checked into the airport this afternoon, and had a debate with the woman at the counter about my reservation. I received my ticket and was surprised to see I wasn't sitting in business class.

The funny thing is, I had an itinerary and record locator that indicated that I was in business class, but our check in clerk claimed I didn't.

A quick call to her supervisor came back with a confirmation that I did not have a business class seat. The options - take a business class seat for another $200 Euros or take a seat in coach. There was some additional discussion on my part, but I was amazed at how uninterested and unhelpful this particular individual was.

Before leaving the desk, I requested that she use my air miles card from a partner airline. Her response, which struck me as a bit odd, was that there was no need, as I was a gold member.

I begrudgingly took the coach seat and made my way to security. While in line I was thinking about her comment about my being a gold member. While I'm gold on other airlines, this (and the partner) weren't one of them.

I rechecked my ticket, and found it had someone else's name on it.  Not sure who Vincent Mercier is, but he sounds a bit more French than this guy who grew up in Tewskbury, MA and knows just enough French to be either polite or offensive. I returned to the desk, pointed out the mistake and  had my business class ticket in hand.

When sitting in the airport lounge a bit later, I thought about what had just transpired.  Air France had asked initially for my passport, to check claims of identity. Those claims were recieved but were not utilized by the requestor, and a secondary claim - my reservation locator - was provided. Again, this wasn't used. Without success, the workflow required an escalation to another service - the supervisor - and again there was a failure. Here it was based on the information provided by the initial requestor.

It stresses the potential for a breakdown in an identity valdation scenario which involves a human component. The difference between Vincent Mercier and Marc Mercuri is fairly  obvious, but the check-in clerk may have done some faulty pattern recognition based on seeing MERC in both.

Had this been a machine driven interaction, this would likely have gone flawlessly. A selection of destination city would have been used to limit the number of potential name matches and from that subset, the name would have been valdated either 1:1 or possibly with something along the lines of a Soundex.

What makes this breakdown of 'the system' incredibly alarming is that there was no validation of claims from that point forward - once ticket was in hand, I had free access to the system, boarded the plane, disembarked in Paris and am now in my hotel. 

Sure, I provided the token assigned by the airline (a boarding pass) at security - but there was no requirement/check of my passport.  If I had continued through with my initial, erroneously issued token (the ticket in someone elses name), I would surely still be in Paris eating the French interpretation of Cajun Chicken wings.

In this specific context, an identity breakdown has horrific potential. Suppose the mistaken identity had occured with a guy less interested in connecting systems as in disrupting them -  a terrorist.

There were no further checks for identity (intra-EU flights do not have passport control), so someone who slipped through the system could now be freely traversing France.  Given the political climate here in Paris this week (for those unaware, there have been riots and individuals setting fire to cars in France), it's even more alarming.

With the recent move to self-service kiosks for check in, the mechanisms I mentioned earlier are helping avoid this issue. Introducing some of the technology used there in the human interaction piece (i.e. scanning of passports and system retrieval of information) would help solve the issue, surely.

But that answer begs different questions. We do quality assurance of the software systems, but how do we and how much time do we do testing of the human components in connected systems? And once you've established your test plan, and you go to 'rtm' of the process/workflow, how do your federated users report bugs? In this particular instance we're not talkng about a situation that results in some bizarre behavior in an IDE,  we're talking about international security in the heart of Europe. The clerk surely isn't going to tell her manager, as it points out big mis-step on her part.  There's no contact information on the boarding pass or airline timetable. Going to the Air France web site, I went to the link to their corporate office, which is entirely in French.  I'm on a hotel internet connection at 90 cents per minute, chances are I'm not going to spend an hour navigating their site to let them know about the issue, resulting in an open loophole in a frequently used workflow with potential for failure far, far worse than any blue screen.

In this particular scenario, the issuance of a false token was an 'honest mistake', but suppose that it wasn't.  Imagine if a terrorist cell had someone working behind the ticket counter, what checks are in place to prohibit intentional bad issuance or trust violations?

This isn't just with transportation companies, it spans verticals. For example, if John Smith is caught owing $200,000 in taxes, and the workflow for resolving this dispute is handled by Bill Jones who makes $20,000 per year, what can happen is John pays $50,000 to Bill Jones to make this whole matter disappear. This is not fiction, this really happens. Depending on the country, it happens alot.

These example involved a relatively simple workflow, this obviously gets more complex when dealing with interactons that run multiple partners/parties deep.

If you have a business with a high volume of transactions or high value transactions with consumers or areas with complex workflows , how do you / would you handle these situations? What types of SLAs and legal terms do you have in place to handle scenarios where a human taints the system with a manual violation of trust in a federated scenario?Feel free to speak in the third person and without corporate identities, I'm curious how/if this is being addressed.

One of the interesting things about writing a book on an emerging technology, is that you rev the chapters several times before they're released.  With the WCF book, this was because we were dealing with CTPS where the object model was changing, with the Information Cards/CardSpace book it's a much better reason. The industry is coming together and collaborating in a most excellent way.

One chapter I'm happy to update this week is the one that looks at information cards outside of Microsoft.

If you haven't heard, some signficant announcements came out of the RSA conference.

#1 JanRain, Microsoft, Sxip and Verisign will collaborate on interop between OpenID and CardSpace

As reported on Kim Cameron's Identity Blog:

JanRain, Microsoft, Sxip, and VeriSign will collaborate on interoperability between OpenID and Windows CardSpace™ to make the Internet safer and easier to use. Specifically:

• As part of OpenID’s security architecture, OpenID will be extended to allow relying parties to explicitly request and be informed of the use of phishing-resistant credentials.

• Microsoft recognizes the growth of the OpenID community and believes OpenID plays a significant role in the Internet identity infrastructure.  Kim Cameron, Chief Architect of Identity at Microsoft, will work with the OpenID community on authentication and anti-phishing.

• JanRain, Sxip, and VeriSign recognize that Information Cards provide significant anti-phishing, privacy, and convenience benefits to users.  Information Cards, based on the open WS-Trust standard, are available though Windows CardSpace™.

• JanRain and Sxip, leading providers of open source code libraries for blogging and web sites, are announcing they will add support for the Information Cards to their OpenID code bases.

• JanRain, Sxip and VeriSign plan to add Information Card support to future identity solutions.

• Microsoft plans to support OpenID in future Identity server products

• The four companies have agreed to work together on a “Using Information Cards with OpenID” profile that will make it possible for other developers and service providers to take advantage of these technology advancements.

Dick Hardt, Sxip Identity
Kim Cameron, Microsoft
Michael Graves, VeriSign
Scott Kveton, JanRain
 

http://www.identityblog.com/?p=668

#2 Ping Identity has released an open source module for Apache:

Ping Identity Corporation today announced the immediate availability of an open source module that allows Apache-hosted applications to use Windows CardSpace Information Cards for authentication. The Apache Authentication Module for CardSpace can be downloaded from http://www.SourceID.org, the open source federated identity management site sponsored by Ping Identity.

The Apache Authentication Module for CardSpace allows applications using an Apache Web server to use Information Cards as an additional authentication mechanism. It allows LAMP-based Web applications written in Perl or PHP to act as CardSpace relying parties (RP) by means of simple configuration. The module is responsible for decrypting the token submitted by the CardSpace identity selector, retrieving the claims and making the claims available for the application’s use.

http://www.pingidentity.com/about/show/165

This is important as it will increase the potential universe of sites secured with phishing-resistant mechanisms and provide a consistent user experience for consumers in CardSpace.