I like CardSpace. I finally got it installed on my XP machine at home and have used it to log into Kims Blog. Installing it wasn’t as easy as I would have liked, it was a big download, a long install and then I had to get ‘special’ tech support in order to get it to work (by special I mean I had to call someone I know over at MS, in that department to help me). Now it turned out that it was an ‘obvious’ problem but on-line help was not easy to find and the error messages were not helpful. All I had to do was install IE7… another big download and install… BUT… that’s the price we pay for security :-)
I have seen CardSpace demos for years now, and have pondered the paradigm shift in the user login experience and have always liked it… Now that I’ve tried it I like it even more!! As a user experience this makes a lot of sense to me… and with some xri and xdi integration this thing could really rock :-0
There are 3 places that I would like to see xri and xdi integration into the CardSpace world. These opinions are based on a deep knowledge of xri and xdi and a pitiful understanding of anything beyond the basic mechanisms of WS-* that make up the CardSpace. I will try to explain the use cases and the properties of the interactions that I am looking for as I talk about these integration points and if there is alternate (better?) ways of solving the same problems I would love to hear about it.
Integration 1: Portability
One problem I still have with CardSpace is that my cards seem to be bound to a specific machine. If I create self issued cards at home and at the office and log in to Kim’s blog from both places; how do I get recognized as the same person?
In the Higgins project HBX card selector the Card Store is not on the client machine, it is ‘in the cloud’. I think that using i-names to bootstrap authenticating me and finding my card store would make CardSpace better. I want to walk up to any machine that is CardSpace enabled, enter my i-name, authenticate (using the multi-factor mechanism of MY choice) and have trusted resolution (not spoofable like DNS resolution) find my Card Store and let me use my cards. Now, I only have to log in once using my i-name, after that I just pick cards. Because I only have to log in once I’m fine jumping through a few multi-factor hoops to make sure that the authentication is solid. That would be cool!!
Integration 2: I-Name Authentication
OpenID is great a way to authenticate an i-name… but not the only way; I really like the ease of picking a card to login. BUT just because a card says “my i-name is =andy” does NOT mean it should be trusted. This is just the same as on Kim’s blog, my card asserted my email address but I still had to go through an email validation…you can’t trust self asserted claims!
So who should be able to make claims about i-name ownership… whoever the i-name owner wants…who the relying party is willing to trust… and here’s how that can work:
EZIBroker (an ooTao business) is about to start offering managed cards with i-name assertions. We hope that through our XDI.org accreditation and our general reputation we will become a trusted provider of assertions. But that isn’t enough… The owner of the i-name needs to ‘show’ that they have selected EZIBroker as their token service. They can do that by adding a Service Block of type “managed card’ to their i-name record (XRDS). So, a relying party, on receipt of an assertion that the ‘bearer’ of this card is the rightful user of the i-name ‘=andy’ should do 2 validation checks… 1) They should check that the asserting party is who they say they are and that they are trusted by the RP to make the claim and 2) They should perform xri resolution to check that the XRDS for that i-name does, in deed, designate that Token Service as the claims provider for that i-name (the theory being that only the i-name ‘holder’ can change the XRDS). XRI resolution should be performed by the RP anyway to persist the i-number as well as, or in stead of, the i-name.
Integration 3: Pointers as Data
This is close to the heart of my real passion… distributed data management. When an RP asks for an email address I want to be able to return either an email address OR a pointer to an email address. Today if an RP asked for an email address and got back an xri (or uri) I would expect it to be upset… and that’s why we need integration. There are use cases where you want to push the data to the RP, but there also use cases where having the RP be able to pull data on demand can be very useful (like current temp in your location so we know how much beer to deliver). In XDI land the response to any request can be one of 2 things… data or a pointer to data. In card space land the response can only be data (as I understand it). If the response is a pointer to data then the RP has to know how to dereference the pointer.. of course you want the protocols that support the pointer to protect privacy, have fine grained security, have link contracts, have pull and push cache syncornization… be xdi :-)
No comments:
Post a Comment