The CardSpace dimensions

Axel Nennker from T-Systems in Germany now has a blog called ignisvulpis (OK, no translation found in search engines – I had to crack open my latin dictionary to be reminded that ignis means ‘fire’ and vulpes means ‘fox’…   Yikes, Axel!)  Axel is a contributor to the openinfocard project started by Chuck Mortimore and Ian Brown.

In a bizarre case of Information Card Fever sweeping through Germany, he writes:

Yesterday I learned that the team of the new java CardSpace project jinformationcard works in the same building as I do. As I am a contributor to the openinfocard project we now have two independent java CardSpace projects “in the house”. 

That's amazing.

Anyway, I heard Axel speak at a meeting a while ago and was fascinated by the way he conceptualized his “information card dimensions”.   Now I can share it with you because he posted it to his blog:

While thinking about how Windows CardSpace could be used and extended I came up with this graphic.

Thus the dimensions of Windows CardSpace are:

1. Cardstore: Where is the cardstore?
   Service Providers store the information cards and facilitate the use through different devices.
2. CredentialStore: Where are the credentials?
   Storage of credentials and engine for cryptographic operations.
3. UI Generation: Where is the UI generated?
   The UI could be generated on a server but be displayed on one of the user’s devices.
4. Identity Selector (UI): Where is the UI displayed and where is the Information Card selected?
5. STS: Where is the STS?
6. STS Authentication: Authentication Technology
7. Browser: On which device is the authentication needed?

Now imagine all the combinations of the coordinates which span “use case space”.  My colleague Jochen Klaffer designed and implemented a tool which helped us a lot to find relevant use cases in our “CardSpace for Telcos” project which we are doing for Deutsche Telekom Laboratories’ Jörg Heuer.

This is of course only a selection of possible dimensions.  Others were excluded for simplicity and because there are strong indications that they will never be relevant.  Kim Cameron said e.g. about using different protocols instead of WS-*: “This will not happen”.

So the “Trust Protocol” dimension is not shown in this graphic.

Other dimensions missing are new transport protocols like SIP instead of HTTP to transport the RST/RSTR. So the “Transport Protocol” dimension is not shown in this graphic.

You will probably notice that there are points on the axis that are not part of CardSpace version 1.0…

Let us look at CardSpace 1.0.

1. Cardstore: local (secure desktop).
2. CredentialStore: local (secure desktop).
3. UI Generation: local (secure desktop).
4. Identity Selector (UI): local (secure desktop)
5. STS: local or network
6. STS Authentication: fixed set of four technologies
7. Browser: PC

So this the current state, but the universe is expanding, right?

Interpretation of the axes and the new points the axes is left to the reader 😉

I think this is really brilliant and have been amazed at the methodologies being used.  I hope Axel will also report on the work by Jochen Klaffer to which he refers.

One small correction – we already support a simple RESTful http post of a token to a relying party – in other words, no need for WS.  So there is a protocol dimension.  In terms of the highly trusted connection between identity selector and identity provider, I would much rather avoid introducing alternate protocols that would drastically increase our attack surface and test matrix.