CardSpace: cascading managed cards, or chains or trust

The product is not out yet, and I already think of the stuff I’d like in vNext.. 🙂

Today’s wishful thinking is about chains of trust.

Imagine that your department of driving licences (DDL) issues you a managed card which represents the digital counterpart of your phisical license card. Your bank will presumably trust it: after all, if you go in a bank branch for cashing a check showing your driver license is enough for visual identification. A managed card would be even better, thanks to the cryptographic guarantees. That’s fantastic! The bank may leverage this trust relationship, and allow me to access my home banking by using my driving license information card (DLIC): if the DDL already authenticated me, and the bank trusts the DDL, why should the bank repeat the operation. However there’s a small problem. The claims in the DLIC may be useful for discovering that my name is Vittorio Luigi Bertocci, that I’m a guy, that I was born in <haha, do you think I’ll really blog it?> and that I can drive cars (but not trucks): however, they don’t help much if many of the bank backend services want to know my credit history. The credit history is a claim that is part of my identity as a subject that deals with money, as opposed to a subject that drives around: no surprise that a token obtained from the DDL does not contain it. Of course we won’t be stopped by such trivial problems: the bank can install an happy resource STS (R-STS), which will transform the incoming DLIC-derived token with a token containing the claims needed to do business with the bank. Now the backend is satisfied again, I can wire up my claim based logic without scattering backend accesses around.

All solved? Hmm, well, if you see things from the bank viewpoint maybe: but from the user point of view, I’m missing an opportunity. The opportunity here is being able to manipulate my financial identity. The token translation performed by the R-STS is transparent for the user.
There could be a number of entities which trusts my bank, and that would offer me finance- based services: for example, it would be very handy to be able to go on a car dealer web site and know how much I’d save thanks to my credit score[1]. I have everything: during the former scenario the bank resource STS even issued me a token that satisfies both the trust and cliam conditions! And yet… if I go to the car dealer website, the identity selector will stay sad and gray. What I lack is a representation in form of information card of my financial identity, so the card dealer policy does not find a match in my card collection.  

Again, that seems easily solvable. Let’s say that the bank sees all the advantages of issuing me a managed card (fidelization, branding, prepaid stuff, etc) and issue me one. No need for a resource STS, I can now exchange my bank information card (BIC) with a token issued by a full fledged Identity Provider STS (IP-STS). But… how will the IP-STS recognize me? Or, in other words, what the second authentication factor of BIC will be? The answer seems pretty natural for me: nothing changed, the IP-STS is part of the bank and the bank trusts the DDL.

And here we get to the sore point. I may be wrong, but It would appear that v1 will not allow backing a managed card with another managed card. This is not strictly necessary, there are workarounds for dealiong with this scenario, but I think it would be really a neat feature in vNext!