I’ve decided that there is no better way than to learn the ins and outs of a technology than to publicly assert your understanding — as long as your ego can take it, you learn very quickly where all the gaps and flaws in your logic lie :)
It turns out that all this time that I’ve been working with information cards, I’ve misunderstood the nature of .crd files and managed card portability. In my talk at RSA, I stated that managed cards had a different portability model than self-issued cards, because a user could download a .crd file from an Identity Provider at any time, import it into a new selector, and use it to get to all of their sites where they had previously associated a card from that account at the Identity Provider.
This isn’t the way that .crd files work, as it turns out. A .crd file is not an information card – it is an information card *template*. When you download a .crd file, the master key for the card is not part of the file, it is generated upon import — thus if you import a .crd file into two different selectors, each card will have two different master keys. Different master keys mean different privatepersonalidentifiers being sent to the Relying Party, who will most likely object. This means that even if somebody out there compromises my identity provider, they may be able to download a card that points to my identity, but it is highly likely that they won’t be able to use that card anywhere that matters (unless the Relying Party isn’t asking for ppid, that is). This revelation has opened the door for me to cook new hare-brained schemes around how cards might be used for what I like to call “user-centric forensics” –I see two possibilities for intrusion detection here:
1. If my card is an auditing card, I hope that in the future, Identity Providers will prominently feature any unsuccessful card use attempts, giving me a cue that something is wrong, and giving me data that I could use to find my attacker.
2. Depending on what the Relying Party keeps about a given card, it should theoretically be possible to detect a token submission where both the claims and the issuer are identical to a valid cardholder, but where the ppid differs (or perhaps where the submission comes from an IP address in a different country or a combination of this kind of thing). Whether such a thing is desirable or not is a different question — the RP would have to store a *lot* of data, and the resulting privacy tradeoffs might not be worth it. The PamelaWare plugins couldn’t do this kind of tracking, as we store a hash of the issuer and ppid rather than the values themselves (this is the closest thing to an RP best practice that I know).
If managed card portability is needed in the way that I originally understood it, I think it could still be done – a claim other than privatepersonalidentifier could be used to pass an identifier not tied to the master key of the card — but all in doing so, you lose one of the qualities that in my mind makes information cards unique, you would essentially revert to a two-party system, with the selector merely passing things around instead of being an essential participant. No matter what, I think this concept of card templates could be used to do some very imaginative things – now that I understand the difference, I can’t wait to go and play!
Many thanks to Vittorio for attending my RSA session and giving me such valuable feedback – I am very happy to be just a little less clueless in at least one tangible way :-D