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. Update:ThisThe variable claim matching functionality is inside it since end of October (I think). The relyinparty and the STS are in the version control system since the same time. I did not find time to blog about this feature earlier.
Have fun.
Monday, December 03, 2007
xmldap / openinfocard paymentCards
Subscribe to:
Post Comments (Atom)
3 comments:
Cool to see this is working!
I was in that same session at DIDW and thought it was an interesting approach. While I was at Visa we had pointed out the problem of the merchant not having an ability to send transaction data back to the ID selector then back to the STS (the credit card issuer, most likely) for 3-D Secure. The assumption at that time was that we'd have to wait for Infocard 2 (as it was called back then) to get Infocard/Cardspace working with 3-D Secure.
Of course, the big challenge is actually making this 3-D Secure hack work in the ecosystem and convincing adopters its worthwhile. ..
Nice work, but I have to question why the transaction data is being smuggled in a claim? You're not actually requesting claim information here, but passing data in to support claim information.
If you're going to do something that's incompatible with CardSpace, why not do it properly instead of hacking existing data? XML is extensible, so why not add new "identity" or WS-Trust elements to pass data through to the STS?
Just curious, more than anything.
Keep up the good work - it's nice to see InfoCards in Firefox!
Cheers
Matt
@matthew: I think that Kim designed the system in a way that there is minimum information flow from RP to STS. I believe this is the reason that this is currently not inside CardSpace. This might change in the future.
I think the reason that Sid decided to smuggle the information thru the variable claims is that if you want to integrate this into an id selector then the change in the id selector is really small and simple.
Post a Comment