Wednesday, August 15, 2007 8:28 PM
by
renel
Rerun: Cardspace and Digital Signature
A lot of people (well at least two) have asked me to translate an earlier post I did in January. Thanks for engaging I really appreciate it.
Entschuldigung, aber mine deutsche sprache kunstshaften sind nicht gut und ich glaube das ich nur verwirrung macht, ob ich eine deutsch Übersetzung versucht … (I rest my case*) so let me instead try to write what the “Cardspace og Digital Signatur”-post was about in English.
Each year in January “Danish IT Society” hosts a security conference. This year a Danish government appointed CA – TDC – presented how improvements in user experience for identity management like Cardspace can add value to an existing X.509 infrastructure.
Some background: In Denmark there is a government appointed CA that issues digital certificates for citizens to use when interacting with government services. The certificate is called OCES – which is an acronym that I could translate into – Open public Certificate for Electronic Services. The digital certificate is also known as Digital Signatur – translates to Digital Signature – hence its primary usages signing email and legal documents.
There are primarily two things about Cardspace that interests TDC:
- Attribute services – the issued certificate basically only holds a unique number used to identify the certificate holder. This number is used in exchange for “real” data about the certificate holder by calling a attribute service that returns a name/value pair e.g. shoe-size/43. TDC saw the Security Token Service (STS) described as a main component of a WS-Trust architecture as a generalized attribute service with all security concerns enable out-of-the-box. Their thought being: “Why continue architecting our own attribute services when a generalized idea is backed by multiple vendors and communities”
- Authentication – the Achilles heel of the Identity meta-system is the authentication against the STS before a security token can be issued. Some might even argue that the removing of passwords from website authentication with Information cards is turning into a introduction of password authentication at the STS’s instead.
TDC employee Peter Lind Damkjaer came to Microsoft with proposal to start a small POC on how to use the OCES (X.509 certificate) as the authentication technology towards one or more STS attribute services
So back to the original post – Peter gave a talk called “User friendly digital identity – is it possible?” During his talk he did a demo that I had made for him. The demo shows a user trying to log into the website “Rent-a-fant” (Because an elephant was the most compelling graphics I had on my machine at the time – it was an Expression Design sample). When the user tries to log on to the “Rent-a-fant” website the Identity Providers STS will ask for a specific X.509 authentication. The Cardspace Identity selector will try to access the specific certificate – however this call is intercepted by the OSP software that will prompt the user for a specific passkey. Note – In Denmark it is mandatory for a government issued certificate to be protected by a strongly typed passkey. After the user types in the correct personal password the certificate is “released” and a security token is passed on to the relying party – “Rent-a-fant” – and the user is logged on to the website.
Peter told the audience that this was a “World premiere” of seeing Cardspace and OCES working together.
My part in this POC was to
- Setup and configure a simple STS to do the right things – including setting up the right certificates at server and client. I used the Simple STS from the Cardspace community site as well as the web application with the certificates for Contoso (and other well know fictious companies). I configured the STS to be able to get the right revocation list for the OCES test certificate – kind of a drag if you are not online at demo time – otherwise you have to download the revocation list before the demo and have the STS look for the local store list to check for revocation.
- Develop the relying party website (“Rent-a-fant”) – build on top of the simple reference implementation that comes with Simple STS using ASP.NET 2.0.
- Produce the unique graphics for the “Rent-a-fant” information card :-) - we wanted to do a co-branded card with both the logo for the relying party - “Rent-a-fant” – and for the “protector” of the local information card – “Digital signatur” (the two nuances of green that you might be able to spot on the card, just to left of the elephant). When we did this in 2006 we had a theory that putting a “Digital Signatur/OCES” logo on the graphics of the information card containing the relying party site logo, would give end users more perception of security or at least give them the meta-information the invoking this card will eventually lead to the prompting of the OCES password dialog.
The picture shows the situation where the user has pressed the information card icon on the relying party website and a call to the STS is made, the user is choosing the “Rent-a-fant” card and is prompted for the password to the certificate.

*I have a great college that encourage me to broaden my reach each time I meet him, however I am sure he was laughing behind my back when I tried to order a meal at a German gasthaus two months ago!