re: "Caching" cards

Marc Mercuri — Wed, 30 May 2007 17:31:08 GMT

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.

re: "Caching" cards

vibro — Fri, 01 Jun 2007 06:22:43 GMT

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 :-)