On the idea of Portable STS (P-STS)

Already Sunday evening. It was a weird weekend, partially spent under the influx of powerful pain killers (dentist played alpinist with my jawbone: and no, do not expect any aesthetical improvements). That's probably the reason for which I recalled this very specific idiosyncrasy I have for the hype around the idea of P-STS, often presented as THE solution of the roaming problem for CardSpace. I've been known to react to those expressing those opinions with disproportionate outbursts, I think the last public one was at TechEd EMEA (Keith & Dominick were in the same room :-)), but that's not really fair until I give a decent explanation of why the P-STS is not the silver bullet for roaming. Don't get me wrong: P-STSes have the potential of playing an extremely important role in roaming scenarios, it's simply that alone they are not enough (perhaps for easy cases they may not even required). In order to make our point, we'll make a little thought experiment: we'll assume that a P-STS device do exist, and we'll try to use it with CardSpace V1 ie what's available today.

First: what is a portable STS (or P-STS for brevity)? The market is not exactly ripe in that space, so there's not really an official definition for it: we'll have to settle with my intuitive idea of that. Here it goes:

A portable STS is a WS-Trust endpoint that is capable of issuing security tokens (ie: implements the Issue action), whose code resides & executes on some sort of pluggable device.

With "some sort of pluggable device" I mean some super smartcard, a USB dongle, you name it. The form factor is important in term of usability & uptake of such a device, but from the trust chain viewpoint it it doesn't really matter. The little STS that lives on the device is able to issue a well known set of claims, and that it contains the values of those claims as well. Also, the factor required for securing RSTs is known: for example, it seems reasonable to use an X509 that lives on the device itself.

Let's say that when you plug such a device in your system the corresponding endpoint becomes addressable by your system: something like http://mydevice/sts. It may not happen exactly like that, you may have special protocol schemas or a unique URI, perhaps the device may impose its own secure APIs instead of directly exposing the ws-trust endpoint, whatever: again, for the discussion here it does not matter. If I have an STS address and a list of claims, and assuming that there is a valid ws-mex endpoint as well, I can create a managed card that points to it. Cool! Are we roaming yet?

Ehm... nope. What we obtained is some sort of personal card on steroids! Check out the sketch below.


On the top-left corner there's a pic of our imaginary device. Like every STS worth its name, it has its private key (triangle head, red). Then there's a little store for claim values, which I'd expect to be reachable only via STS. Below that, there's the STS itself: here it represents code that runs directly in the device chip, so that the hosting computer cannot fiddle with it in any way (think smartcard signatures). Finally, I've added an extra set of keys (round head) for representing an x509 and its private key, so that the device contains both the STS and the auth factor needed for authenticating RSTs (hopefully there will be a pin to be entered at some point to protect it from unauthorized use).

The device is depicted as inserted in a PC (blue rectangle). On the same PC there's the managed card we described above: it points to the P-STS endpoint, and uses the x509 mentioned above as UserCredential.

Let's assume that we have an RP which needs claims from the ones that our P-STS can produce, and that such an RP does not specify an issuer (we'll elaborate on this later). I've spared you the usual RST-RSTR dance: what you see in the middle of the picture is the message that is sent to the RP once a suitable token has been obtained. You'll notice that the token has been signed with the red triangle key. With a regular STS, that would mean that the miracle of federation is about to happen: the token would arrive from a well known authority, and the RP would know the corresponding public key; if the signature would match the call would succeed, even if this particular user would be calling this RP for the very first time.

But a P-STS is not a regular STS. I cannot say it for sure, as I'm not a smartcard expert, but it seems reasonable to imagine that every device would have a unique (triangle) key: as an authority I would not feel comfortable in delegating my signing power like that. If every device has its own special key, there's no federation to speak of: every [corresponding public] key, or derivatives like the UniqueID, must be recorded explicitly in the RP authentication store. Exactly like in the selfissued case. Right, here I can have an arbitrary set of claims or issue exotic token types, whereas personal cards are constrained on both dimensions; and I can use a P-STS in offline scenarios and private networks, where connectivity to an authority would be a necessary condition in the traditional scenario. Furthermore, there are obvious advantages in having all those operations performed on truly trusted code. That said, even if every device would have the same signing key that would not really affect the following roaming considerations.

Let's say that you extract the device, you pocket it and walk away. You get to the PC of a friend of yours, and you want to access the same RP from there: can you?

No, you can't. Unless you export the corresponding managed card and you re-import it on the PC of your friend, your portable STS will keep sleeping in the cozy chip of your device. Wait a minute, isn't this exactly what you have to do today for moving any card type?

Ahh, we're finally where I wanted to get. Roaming requires to do something with the cards store. The P-STS can really help a lot, in fact it seems the only way of reproducing personal card behavior when using a device, but in the end what needs to roam are the cards themselves rather than the token issuers. In fact, if you'd want to roam only managed card you may not need a P-STS at all: card metadata and authentication factor would be all you need, if the issuing logic runs on the remote STS as usual. 

Now, working on the store is the real challenge. I won't go into further details on that, I am not deep enough on the issue and I'd almost certainly say some silly thing: besides, people smarter than me are working on the problem and I'm sure they'll come out with something just great! 🙂

Comments (7)

  1. blowdart says:

    Well now it depends surely? You could have a P-STS that simply acts as a proxy to a full blown STS somewhere, for some, or for all claims; pointless? Certainly, but it’s possible. But then, if you’re doing that why not just use smartcards? (Aside from the fact I’ve never managed to get those to work *grin*)

    The lack of a portability story is a major sticking point for some customers right now, and the lack of discussion around it isn’t helping.

  2. Barry,

    never said that it’s pointless: in fact, in the post I list a number of things for which it comes in handy and I even identify it as an important component of the solution. My point is that the P-STS is not the entire story. That said: I used smartcards with the simple STS in many occasions, and wrote posts about it here and there. If you have issues, drop us a line 🙂

    About lack of discussion. This post should have made clear that there’s not much we can do for roaming with the architecture of CardSpace v1; so unfortunately there’s not much to discuss 🙁 BUT we mentioned in various occasions that roaming is a top priority for the next version. Hence we are in the best shape we can be 🙂 I’ll just add that, as people says here, I am super-excited by what’s coming!!!

  3. Ashish Jain says:

    How about touching on the idea of taking the card store with you in the P-STS (or whatever device). And then having something like a selector-selector to indicate to the RP on which selector to invoke – the one on the PC OR the one on the device.

    Alternatively, how about a card store in the cloud with a one-click sync to the local card store.

  4. Hello Ashish,

    absolutely. Let me tell you the reason for which I don’t go down that route here.

    I have my own opinions and considerations about how to approach the roaming issue, and some of those are pretty similar to the ones you are hinting to: it’s at least a year I think about it, I could fill another 2 chapters of the book with it:-). However here I expressely avoided to speculate on how roaming could be implemented, simply because the cardspace team is working on it. I know I have a big disclaimer that says that what I write here is my own thinking and does not reflect the official Microsoft position, but still I want to avoid that the casual reader would take my musings as indications of what will actually end up being in CardSpace.

    That said: if you want to exchange opinions on the subject I am happy to do it (i should definitely try to come to some of those identity-only conferences, I’d love to hang around with people like you!), I am simply not going to broadcast on that until I will have a feeling that by doing so I benefit the community.


  5. Ashish Jain says:

    Understood. I guess I should wait for the next release of CardSpace.

    BTW…you should try to come to the RSA 2008 in April. You will get to meet lots of identity folks with lots of opinions 🙂

    – Ashish

  6. The other day and friend of mine asked me about portable STS implementations, if I knew about any available

Skip to main content