"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 https://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.

Comments (2)

  1. Marc Mercuri says:

    I like to think of the scenario as the equivalent of staying at a hotel. For a set period of time, you’ll be at a given property and when you arrive, you leave a copy of your credit card at the front desk. This entitles you to utilize any number of the services that particular hotel provides (spa, minibar, restaurants) without asking for your credit card each time.

    From a usability standpoint, you’d prefer not to be prompted for your card each time, and that instead they reference the ‘cache’ at the front desk. This leaves you free to easily consume any of the service within the known universe of the property.

  2. vibro says:

    Your expectation is legitimate, but I would not say that the scenario requires "caching": it requires standard session building capabilities. When you check in in the hotel the person at the desk will collect information about you and it will keep those in the equivalent of a session. During your stay you will enjoy different services requiring (eventually) the use of a credit card, but the credit card info will not be used "as is" like it would happen to a cached resource. Often the credit card claims won’t even emerge during the transaction (read – uncorking something at the minibar) but much later in the process. If the sheer existence of a credit card number is enough for me to be enabled to perform the operation, what this operation is asking for is a different kind of claim ("HasRegisteredCreditCardAtCheckin"). I am not accessing the resource at all hence I am not using caching in the sense "a temporary place from where getting faster access when the item is needed again". It’s just a matter of how you chose the semantic of the term; if you have a set of services offered by the same RP, and for obtaining SSO across them you save the token (or selected info from it) on the RP side, rather than caching I talk of "session".

    If you want to stay in the hospitality business, here’s one example that IMHO embodies the idea of token caching.

    When you go to those vacation all-inclusive in touristic villages, you can literally eat and drink anything you want, any time you want (not good for the waistline but hey, it’s vacation :-)). However you share the place with other customers who, more wisely, decided to save some money and pounds by refusing the all-inclusive formula. Instead of forcing all-inclusive customers to continually assert their status to bartenders and massoterapists, the tour operators devised brilliant a token based way of solving the problem.

    Upon arrival, all-inclusive customers receive a colorful wristband which represent their status. At that point the customer will be eable to quickly affirm his status by flashing the wristband to anyone who trust the tour operator authority. In this case the token is undobtfully cached, since it is issued to the customer and it is the customer that keeps reusing it ACROSS MULTPLE SERVICES without further requesting a new one; and if there’s a notion of session that’s the one intrinsic in the duration of the token itself, rather than the big scope shared session data.

    There is another bug difference in this case. When the token cache is managed by the subject, he owns the necessary material for *using* its content; in other words the subject holds the keys associated to those tokens and that allows him to extract a token from the cache and use it for securing a new call. When the token cache is not managed by the subject, for example by the RP, it is not trivial that the token may be reused  (the session key in the token may be asymmentric) apart from  just-re reading its content, in which case it’s not caching (no need to maintain the info formateed in token form).  Furthermore, even in the case in which the RP would be able to reuse tokens as is it is questionable if it should have the right to impersonate the original subject for whihc the token has been issued.

    it’s an interesting topic :-)