xmldap / openinfocard paymentCards

Axel Nennker from ignisvulpis has been enhancing the openinfocard identity selector – I'm hoping to catch up with him soon and learn more about where the project is headed.  Meanwhile this post is very interesting:

At DIDW 2007 I heard Sid Sidner talk about variable claims and how they could be used for online payment. Kim Cameron, who sat next to me during Sid's talk, suggested that I should include this into the openinfocard id selector. Today I uploaded two new applications to xmldap.org. You can use the STS to create a paymentCard and import it into the openinfocard id selector:

Next go to the paymentCard relying party. You can change the price to see that the claim can be changed by the merchant. Type a new price into the input field and press enter. Next click on the paymentCard icon to start the openinfocard id selector:

 

 Select a paymentCard using the openinfocard id selector:

 

 The result looks something like this:

 

Please note the “trandata?” claim. This is the one that is modifiable by the relying party. It can contain anything. Sid suggested to base64 encode the data needed for 3D-secure. I just use the variable claim to transport price information from the merchant to the STS. The basic principle: If a claim contains a ‘?’ then the matching of the claim against the claims in a information card stops; that is the claim “matches” and the whole claim is send to the STS in the RST. Of course this does not work with the current version of CardSpace. Some newer version of the openinfocard id selector should do it. This functionality is inside it since end of October (I think). I did not find time to blog about this feature earlier. Have fun.

I tried importing the card into CardSpace, but wasn't able to do so since the openinfocard STS currently issues the card using an expired certificate.  CardSpace checks for this, and other identity selectors should too.  Is this one of the tests in the emerging information card interoperability test suite? 

I'll pick this up again once the certificate problem is fixed.  Until then, it works very nicely with the openinfocard selector.

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.