Disclaimer : The views represented in this blog are completely personally and do not necessarily represent the views of the company I work at..
Hey Sriram,
OpenID, LID, SAML, WS-Fed, iNames... and the list seem to growing. All these protocols are trying to broadly achieve federation of users, and consequently Single Sign On. To discover them all exists YADIS !! In addition there exist frameworks like Higgins, Bandit and Pamela, all trying to give concrete shape to Identity Metasystem. Despite all this efforts, federated identity systems have not really become widely used, and has not used its potential.
Enter CardSpace, and things look promising again. One of my friends even called it the "Face of Federated Identity", a term that very appropriately describes its link to the offline world. However, after reading and re-reading a lot of material, watching podcasts by Arun Nanda on its architecture, and Andy Harjanto , a few questions seems to trouble me.
As I see it, I am still missing the novelty in CardSpace.
Identity Discovery:
Apparently, it looks more like a Identity Provider (IDP) Discovery service, allowing people to select cards. In all cases, the user just selects an identity provider, like the IDP Discovery Service as in SAML.
Card Selector:
It claims to be user-centric, but thats what protocols like OpenID, or more generally YADIS and SAML were already doing.
In CardSpace, the user selects a Card from a UI.
In SAML, a list of IDPs are displayed using common domain cookies.
In YADIS, the user types in the URL of the IDP. This also allows the selection of protocol.
If only the UI look and feel is an enhancement, it may be easier to develop cross platform UI in HTML rather than putting a software written in native and managed code.
Location of the Cards;
CardSpace locally stores the cards, with the UI providing additional features like export/import of cards, and protecting them with PIN for shared computers. SAML saves this information in a Common Domain Cookie. However, in case of YADIS, the user has to remember the IDP url / name. The cards are stored using double encryption at the System and User level, using native windows libraries. Would it not be simpler to store them at a server, and use a cross platform getter protocol like https for the user to use ?
IDP authentication:
CardSpace authenticates the user by showing the login form as a part of the secure desktop. This may become a little limiting as the different ways the IDP may want to authenticate could be theoretically infinite. Typically, building systems like biometric authentication, Smart Card, SecurID, Virtual Keyboard or others may not be possible, and hence the Secure Desktop may have to provide extensions for this. SAML and OpenId seem to take the easier approach redirecting the user to the IDP page. The argument against phishing can be countered by Passmark, mutual authentication etc. Hence, I am not sure about the gains by getting IDP authentication to the secure desktop.
Secure Desktop:
The login screen is a separate desktop that prevents any other programs from watching the data sent. The reason for doing this was to prevent spyware from getting the user data. However, once the authentication is done, all transactions that happen in the browser are at the familiar windows desktop. Given the fact that spyware can listen to this data, and steal the user cookie may actually defeat the purpose of the secure desktop. If the requirement was really securing against malware, then why even have the ability for one program to watch another ?
Privacy:
One impressive point about CardSpace is that the IDP may or may not know about the Relying Party (RP). The concept of display claims, and encryption at the CardSpace do cater to these needs. This is a feature that SAML and OpenID may not provide as this would mean making the browser more intelligent using javascript.
Non-Web Scenerio:
SSO in non-web scenario could be done using Liberty ID-WSF or Web Services. In the ID-WSF specification, there is a frequent mention of the need of a desktop agent to perform various tasks like credential collection for IDP, user consent etc. The uniformity of CardSpace would help such a desktop agent easy and possible.
Protocol Payload:
CardSpace only allows different type of payloads; the protocol for data exchange is similar to WS-FED. This reduces the concept of Identity to possession of Token. This may be a serious concern, considering the fact that passing a single token may in one single exchange may not be sufficient for all authentication mechanisms. An example scenario that I can think about is Risk Based authentication, where the RP may want to exchange multiple messages to verify the user, and the IDP itself.
YADIS on the other hand passes to control to the protocol once the discovery is done. This seems simpler as the protocols now have more independence.
Pseudonyms:
The concept of pseudonyms or Name Identifiers have not really changed. This pseudonym is required to uniquely identify users. The user having a unique number per card-RP pair. In case of SAML and OpenID, where there is no concept of a card, the IDP and the SP share a nameID to uniquely identifier a user.
Well, so this is my comprehension on CardSpace, and let me see if time and talking to people fills gaps in my understanding of the technology that seems promising to bring Federation to the common janta !!!
