Hey,
Many people have been toying with the idea of using CardSpace as a vehicle for e-commerce payments. The main driver for this idea I believe is the fact that 3-D secure resembles the federation protocols like SAML or WS-FED. Ironically, 3-D secure and federation seem to have the same problems with user adoption. Thought the technology is simply remarkable, the engineers don't seemed to have covered the last mile of taking it to end users.
I first read about this idea in a blog by Sid Sidner. Many others including Ashish Jain (Ping Identity) and Kim Cameroon had linked to the post. I had also found XMLDAP having simple demos of the concept. The guys at xmldap have put up demo. The sample card issuer that corresponds to a bank, and a sample merchant site. The cards issued at the the bank can be used as currency at the merchant site.
In this post, I try to analyze the various issues with the idea, and potential solutions.
The first problem is that the demo does not work with the Windows Cardspace. Even after importing the card, it does not show up in the Identity selecter at the merchant.
The reason it fails is that the required claims for the cardspace is something like
param id="requiredClaims" name="requiredClaims" value=" http://schemas.xmlsoap.org/PaymentCard/account http://schemas.xmlsoap.org/PaymentCard/VV http://schemas.xmlsoap.org/PaymentCard/expiry http://schemas.xmlsoap.org/PaymentCard/trandata?price=2700EUR
The card that is imported has all the claims except the last line. The URL parameter that follows the question mark (in red) is dynamic and hence is not a part of the claims in the card.
The best way to accomodate this is to enhance the cardspace standards to make it recognise the URL the parameter as separate entities.
A quick fix however is to include this as an optional parameter. In this case, the user will have to explicitly select that parameter when he submits the card. The STS can throw an errorr (new version supports custom error messages) is no value is submitted.
A couple of other enhancements could be to identify this uniquely as a payment card by having an attribute that indicates the type of the card. This could be an attribute that all the merchants and the banks will have to agree upon and would help merchants to show up only the cards that they accept. Additionally, the currency (viz. dollar, rupee or euro) could be a separate url parameter, something like price=2700¤cy=rupee.
The last glaring problem that I see here is the fact that getting the user consent on the money transfer is not simple. The consent is buried with other attributes, but I feel only the money part should be hilighted.
The cardspace standards sure are evolving, and I hope to see a simple single standard protocol for federation. On second thoughts, why should not people use OpenID (and YADIS for discovery) for online payments ?
