"Caching" cards

Caching is one of the topics that sooner or later arise when you reason about cardspace. If I use the same card across different applications at the same time, or in a short period of time, can’t I cache the card? If with a certain application I reuse the same card all the time, can’t I automate that choice so that I don’t get prompted?

Valid questions, that deserve detailed answers. I won’t make any considerations rooted on the Laws: for example, I may say that caching is overstretching the consent of the subject, since in a single point in time the user deprives his future self of the chance of perceiving the moment in which his/her data will be disclosed. But I wasn’t the one taking the decision of not implementing caching in the identity selector, the above may not be the reasons for which it’s not there. For this post I will stick with what I handle best, token juggling: there are solid reasons for which certain forms of caching would not work, and those are the ones I’m gonna share here. I had this post in the pipeline since pretty long, and here it is.

In CardSpace a managed card represents the ability of obtaining a token from a certain IP. If the policy of one RP accepts a token from a certain IP, the subject can 1) select the managed card that represents the corresponding token 2) take whatever steps is needed to be recognized by the IP 3) if 2 was successful the subject obtains the token from IP and, after reviewing its content, he/she can decide to send it to the RP.

The first observation here is that if we want to cache something, this has to be the token (the notion of caching a card is, in ws-trust terms, ill-posed). There are many good reasons for which somebody may want to cache a token: for example an application may want to talk with a web service that lives on the same RP (hence protected by the same X509), but that has a different endpoint than the first web service that was contacted (for example I may have obtained my token for www.foo.org/ws1, while now I want to talk with www.foo.org/ws2). In order to address that situation I wrote the example described here.  CardSpace does not have any native way of caching tokens even in rich client applications, but the extensibility of WCF (on which cardspace implementation is based) was expressive enough to allow me to create a simple caching system.

Now: my caching system is expressly designed for avoiding to prompt the subject more than once when he is contacting different endpoint of the same RP. That sort of make sense, because from the transaction point of view is it the same RP that the subject is dealing with, the same business entity to which he/she decided to disclose: the fact that the function the RP delivers uses more than one endpoint is more of an implementation detail. However my caching system would NOT work with multiple RP, for a very simple reason: the cached token was not released for RPs that are different from the intended one.

When we use a managed card for obtaining a token, we encrypt such a token for the specific RP for which we are making the request; the IP may or may not know the identity of the RP, according to its auditing policy, but in the end the token that the subject gets back is encrypted in a way that only the intended recipient will be able to use it. Basically, a token obtained for RP1 & cached cannot be re-used successfully with RP2. That’s one reason for which tokens cannot be reuses “as is” across different RPs.

We may want to transfer the burden to the identity selector, and say that a “cached managed card” is a card that, if used successfully for obtaining a token for RP1, once it will be used for RP2 it will simply repeat silently the steps for obtaining a suitable token without subject’s intervention. Again I won’t go into the implications of such a behavior in term of abiding to the 7 Laws, but I’ll again come out with a practical consideration: obtaining a token from IP for RP1 requested the subject to use some authentication factor for securing the RST, and such a factor may simply not be cacheable (see OTPs) or require the subject to perform some explicit step (insert a smartcard, swipe the finger, etc).

The image attached tries to give visual sense of what I said (the notation is straightforward: same as http://channel9.msdn.com/ShowPost.aspx?PostID=241455. Note that for simplicity here I don’t distinguish between public and private key, just assume that the E operator always uses the public key and the S operator always uses the private one).

In the picture the diamond key (highlighted in yellow) is the session key generated by the IP: it is encrypted for the key of the first RP (the square one, highlighted turquoise) hence it cannot be consumed as is by the second RP (that has the reverse triangle key). Also, for sending the IP a RST the subject needs the round key (highlighted green). That may be something like a smartcard that needs a pin, an OTP or anything else that cannot be cached by the identity selector (since the verification code lives elsewhere).

PS: I know that the above didn’t address the usability point about the fact that having the need for an IP always online breaks the physical cards metaphor. I think that is the directed identity principle that itself poses a limit to the physical card metaphor suitability: in the online world we have cryptographic guarantees that are much more powerful than the simple assumption that the holographic pattern on an ID is difficult to fake, but as long as we use the cards as means to obtain unidirectional tokens the reduced scope is something difficult to avoid.