InfoCard/CardSpace getting the big picture …

Recent posts on this blog suggest our interest in “open” in browser single sign on systems. As a result we have been discussing briefly perceived strengths and weaknesses of yahoo BBAuth and emerging OpenId standards. Regarding OpenId , it has appeared to us that the enthousiasm of the community is unfortunatly not backed by sufficient technology to make the system applicable in the context of the wild open Internet. The recent announcement that CardSpace and OpenId are engaging into a mariage allow microsoft to capitalize on the buzz created by OpenId. We now see OpenId as a void shell (a remarkable online marketing success though …) , the stringent question that remains to be addressed is what is the value of this CardSpace stuff ?

Like others single sign on system , CardSpace involves three different parties :

• A relying party (RP) which is a website having interest in authenticating a end user
• A end user (subject …) which is expected to use a browser that can interact with a cardspace identity selector …
• An identity provider that can authenticate the end user and delivers what is called a security token that contain certified claims of end user identity

InfoCard

Prior to enter into CardSpace protected websites , the end user shall contact a relevant (this will be detailled later…) Identity Provider and defines what kind of token it later want it to produces on his behalf. The end user delivers to the Identity Provider personal informations that will be later disclosed to relying parties and defines after which kind of authentication such information maybe put in a token. This “token production contract” is what InfoCard are all about. After this initial Identity Provider registration the end user will be delivered an InfoCard that is stored into the CardSpace identity selector on machines the end user may later access.

So to summarize , an InfoCard does not directly contain the end user identity , but clearly define which Identity Provider is supposed to emit proof of identity for the end user , what identity information such proof may contain (email , phone , home address …), and in what circonstances (successful authentication using password , smartcard etc…) such identity proof (later called token …) maybe released.

Initial RP site access

Websites that want to make use of CardSpace authentication shall operate over https. When the end user enters in such site a special page is returned that contain a description of the kind of token that the site is expecting from the end user to later authorize the access. This token request details the expected end user information that the token shall contain , and what Identity Provider is suitable to emit/certify the token. Identity Provider may be selected on the basis of who they are and/or the authentication methods they support. This allow the system to be used in a wide variety of context , from “off the shelf” community website where a self certified token is more than what is required to security demanding websites that needs to be sure that end user have been strongly authenticated.

InfoCard selection

After the end user has received the page that contains the token request , he may press a button that triggers the identity selector client side application. The identity selector first presents to the end user details on the website that requires the token. This site control part proceeds by parsing the website certificate as browser normally do and presenting certificate related information in a more helpfull manner than browser currently do (padlock icon and pop up if something is wrong…). The future will tell if this is sufficient in preventing rogue sites to operate , we believe it is not as certificate ultimate control is still the responsability of the end user. From here the end user is presented a list of the InfoCards currently in his possession that would allow him to deliver a suitable token. The end user choose a suitable InfoCard if any , the identity selector then clearly informs the end user of the personal informations he will disclose to the relying party if a suitable token is emitted , and if he agrees the identity provider packs the required information into a certified token that is finally forwarded to the relying party.

Does this offers more security than what we currently have in browser ?

Our answer here is yes , and microsoft should be praised to be the first to put in browser what is required for this to go on reliably. One part which we need to understand better is the way the end user is supposed to authenticate to the Identity Provider. It looks though that the InfoCard contains the necessary information for this to happen reliably.

Our understanding of the system allows to anticipate 3 problems :

1. The fact that the end user is still supposed to address how safe a web site is , based upon the content of a certificate. Though the proposed end user experience appears a more complete one than the one currently implemented in browser , we don’t see this as sufficient to reliably change the situation
2. The other problem relates to the fact that token may not contain a clear mention of the site where it shall be used. If emitted like this , phishing can continue to go on as today. A relying party may prevent this to happen by requiring the token to contain an applyTo assertion.
3. The fact that it is taken for granted that the client machine will be always controlled by a legitimate end user

That said , in the context of this system , providing that the ApplyTo assertion is contained into the token and that certificate authorities are fully trustable , the maximum damage that the end user will experience as a result of phishing is unwanted release of personal information. It then depends upon what exactly has been released when trying to access a relying site if it is an email nothing serious , if it is a credit card number all bet are open…

A better CardSpace

The main drawback that we see is that as soon as self certification is not considered sufficient the end user is supposed to deliver all of its personal informations to the Identity Provider. We believe that CardSpace should allow for a third type of tokens where personal assertion are delivered by the end user but strong authentication occurs with an authentication provider that knows nothing about who you really are in the real world.

Though openness is largely advertised :

1. The only platform that delivers implementation for an identity selector is windows
2. Recognized strong authentication methods are windows compliant only
3. It forces the view that your personal information shall be disclosed to Identity Provider others have chosen to trust on your behalf

We shall see if this make a better world. This looks a good system though.

Ressources

For everything about CardSpace , visit the Kim Cameron identity blog.