The idea of federation usually conjures images of enterprise partnerships, people in blue suites (and short hair!) shaking hands, corporate portals of unmistakable extranet taste, and so on… the famous federnet I was mentioning some posts ago.
Some months ago I was discussing with my good friend Garrett about an example of federation that would really click with the end user experience, and we didn’t spend too long before landing on airline alliances. IMHO that’s the perfect example for understanding the value of federation for the community at large: it’s even culture agnostic, as opposed to certain forms of coupons &rebates that I’ve seen only here in the US. Let’s explore the scenario a bit: later we’ll see how CardSpace can bring value to it.
Pretty much every airline nowadays offers you a frequent flyer program: if you subscribe to it, every time you flight with that company you will accumulate miles. Once your miles reach certain tresholds, you gain privileges related to the travel experience: access to the VIP lounge, priority in standby lists, priority tag on your luggage, extra allowance, free upgrades to business class… now, all this sounds great, and it is! However that alone would not be a great idea if it would work in isolation. No airline can give comprehensive coverage of all possible destinations, so if everyone would have a separate program you’d end up with your miles scattered on a big number of cards. Luckily airlines realized that and joined to form alliances, teams, leagues… all fancy names which basically means federations.
What happens now is that if I have N miles with airline A I’m a Gold member, and I have access to some privileges; if I fly with the federated airline B, however, my privileges are equivalent to its Elite members. In other words 1) B recognizes the credentials I get from A (namely the card I show & the number on it) and 2) B maps a claim value that is valid for A (Membership=Gold) to a value that makes senze for its authorization protocols (Membership=Elite). Now this is great! I can grow my miles pile even if I travel on different airlines, and I can enjoy my privileges in an airline-agnostic way as well. Of course, the trick works only in the context of the federation: if I go to the counter of the non federated airline C and I show my A card, the maximum I can obtain is a smile.
Finally, note that the airlines often give access to their assets via their websites: once you log in, using your credentials ([PIN|frequent flyer number|username]-password), you can do things such as book flights, check your status and so on.
That brings us back on the CardSpace topic. One obvious advantage of it would be to obtain single sign on: the website of B may honor its trust relationship with A by letting me log in in its website by using my information card issued by A. I would probably not have the full experience of B customers, however it would be handy to lower the barrier for access (and maybe gain a customer!). But in fact, CardSpace may do much more than that. Right now the mapping between privileges is somehow hidden in the conversion tables of the federation relationship, and its logic has to be applied pretty much end to end. There would be a clear advantage in making that mapping explicit, codifying it in the list of claims that defines the intersection(and/or union, sometimes?) between the various offerings.
Let me define it better. Would not be handy if a flight booking service would accept directly a token containing claims about if you like the aisle better than the window seat, if you are eligible for free business class upgrade and your email address you use for confirmations? Such a system would not be susceptible to changes in the details of a relationship between airlines: the logic would always work on claims value, and the criteria with which those claims has been populated would be the business of the STSes involved in the process. So the booking function will always look for the boolean value EligibleForBusinessUpgrade, and it will be gloriously decoupled from the fact that yesterday A Golds were entitled to it when flying with B and today they are no more: the STSes will take care of that.
Think how lean the process could become, how easy would be to use the same client across different backends! In order to determine the shared core of claims there would be need for a certain degree of agreement among all the airlines involved in card issuing; and the claim set would never be truly complete or perfectly overlapping… however there’s an unmistakable set of common concept in the industry, it’s a phenomenon common to many other verticals, and it would be great to be able to leverage it in that fashion. My bet is that this is going to happen, in a form or another, and not even too far in the future: I have still some doubts about how the dual granularity claim/token is going to drive the evolution of common forms & cliam vessels, but that’s the topic of an upcoming post 🙂