Ultimate simplicity: 30 lines of code

With the latest CardSpace bits anyone who is handy with HTML and PHP, Ruby, C#, Python or almost any other language can set up CardSpace on their site in minutes – without the pain and expense of installing a certificate.  They can do this without using any of the special libraries necessary to support high security Information Card exchanges.

This approach is only advisable for personal sites like blogs – but of course, there are millions of blogs being born every second, or… something like that.  Students and others who want to see the basic ideas of the Metasystem can therefore get into the game more easily, and upgrade to certificates once they've mastered the basics.

I've put together a demo of everything it takes to be successful (assuming you have the right software installed, as described later in this piece).

From the high security end of the spectrum to the long tail

Given the time pressures of shipping Vista, those of us working on CardSpace had to prioritize (i.e. cut) our features in order to get everything tested and out the door on schedule.  One assumption we decided to make for V1.0 was that every site would have an X.509 certificate.  We wanted our design to start from the high end of the security spectrum so the fundamental security architecture would be right.  Our thinking was that if we could get these cases working, enabling the “long tail” of sites that don't have certificates would be possible too.

Let's face it.  Getting a certificate, setting up a dedicated external IP address, and configuring your web server to use https is non-trivial for the average person.  Nor does it make much sense to require certificates for personal web sites with no actual monetary or hacker value.  I would even say that without proper security analysis, vetting of software and rigorous operating procedures, SSL isn't even likey to offer much protection against common attacks.  We need to evolve our whole digital framework towards better security practices, not just mandate certificates and think we're done.

So again, when all is said and done, it is best to promote an inclusive Identity Metasystem embracing the full range of identity scenarios – including support for the “long tail” of personal and non-commercial sites.  One way to do this is through OpenID support.  But in addition, we have extended CardSpace to work with sites that don't have a certificate.

The user experience makes the difference clear – we are careful to clearly point out that the exchange of identity is not encrypted. 

Warnings are presented in words and graphics

In spite of this, CardSpace continues to provide significant protection against attack when compared with current browsers.  You are shown the DNS name of the site you are visiting as part of the CardSpace ceremony, not on some random screen under the control (or manipulation) of a potentially evil party.  And if you have been redirected to a “look-alike” site containing an unknown DNS name, you will get the “Introductory” ceremony rather than the more streamlined “Known site” ceremony.  This unexpected behavior has been shown to make people much more careful about what is appearing on their screen.  Ruchi from the CardSpace blog has a great discussion of all the potential issues here.

What software is required? 

As my little demo shows, if you have a website to which you want to add CardSpace support, all you need to do is add an “object tag” to your login page and parse a bit of xml when you get the Information Card posted back to your site.

On the “client” side, if you are using IE, first you will need to install an updated browser specific extension that will work at a non-SSL site.  If you have IE7 you probably already have it as part of the October security update.  If not, download it from here.

Second you will need to install an updated version of Cardspace that does the right thing when a website (we call it the “relying party”) does not have a certificate.  The latest version of Cardspace can be downloaded as part of .Net Framework 3.5 from here.

For people using Mac and Linux clients, I look forward to the upcoming Internet Identity Workshop as an opportunity to catch up with my friends from Bandit, OpenInfoCard, Higgins and others about open source support for the same functionality.  I'll pass on any information I can at that time.

Once you watch the demo, more information is available here and here and here.  The code snippets shown are here.

Download cheap oem discount software.

Getting claims when using no-ssl CardSpace

When a user tells CardSpace to “send” identity data from a self-issued card to a web site,  it posts a SAML token using the action attribute in the HTML form containing an x-informationCard Object tag.

In the simple, no-ssl case, this information will not be encrypted, so you can just treat it as an XML blob.  You can test this out by making the form's action a script like this one:

This script just takes everything that is posted to the web server by CardSpace after processing the invocation form, and reflects it back as an “XML encoding”.  The result is shown in my demo, and in the no-ssl zip file as result.xml.

As pedagogical as the XML dump may be, it isn't a good sample of how you would consume claims.  For that, let's look at the following script:

GetClaims() shown above is just a way of pulling values out of an XML document – use your own instead.  You will see that the givenname and privatepersonalidentifier claims used here are retrieved with this simple code.

I hope all of this will become very clear by watching the demo and looking at the aforementioned zip file, which you can cut and paste for your own experiments.

[Note:  the raw XML display code above did not include the stripslashes function when I first posted it, which caused the function to fail in certain php configurations.  Thanks to Alex Fung from Hong Kong for the report.]

Claims in the self-issued Information Cards profile

This list of claims is taken from the Identity Selector Interoperability Profile, and specifies a set of claim (attribute) types and the corresponding URIs defined for some commonly used personal information…

The base XML namespace URI that is used by the claim types defined here is as follows: http://schemas.xmlsoap.org/ws/2005/05/identity/claims

For convenience, an XML Schema for the claim types defined here can be found here

8.5.1. First Name

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

Type: xs:string

Definition: (givenName in RFC 2256) Preferred name or first name of a subject. According to RFC 2256: “This attribute is used to hold the part of a person's name which is not their surname nor middle name.”

8.5.2. Last Name

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Type: xs:string

Definition: (sn in RFC 2256) Surname or family name of a subject. According to RFC 2256: “This is the X.500 surname attribute which contains the family name of a person.”

8.5.3. Email Address

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Type: xs:string

Definition: (mail in inetOrgPerson) Preferred address for the “To:” field of email to be sent to the subject, usually of the form @. According to inetOrgPerson using RFC 1274: “This attribute type specifies an electronic mailbox attribute following the syntax specified in RFC 822.”

8.5.4. Street Address

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress

Type: xs:string

Definition: (street in RFC 2256) Street address component of a subject?s address information. According to RFC 2256: “This attribute contains the physical address of the object to which the entry corresponds, such as an address for package delivery.” Its content is arbitrary, but typically given as a PO Box number or apartment/house number followed by a street name, e.g. 303 Mulberry St.

8.5.5. Locality Name or City

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality

Type: xs:string

Definition: (l in RFC 2256) Locality component of a subject?s address information. According to RFC 2256: “This attribute contains the name of a locality, such as a city, county or other geographic region.” e.g. Redmond.

8.5.6. State or Province

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince

Type: xs:string

Definition: (st in RFC 2256) Abbreviation for state or province name of a subject?s address information. According to RFC 2256: “This attribute contains the full name of a state or province. The values should be coordinated on a national level and if well-known shortcuts exist – like the two-letter state abbreviations in the US – these abbreviations are preferred over longer full names.” e.g. WA.

8.5.7. Postal Code

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode

Type: xs:string

Definition: (postalCode in X.500) Postal code or zip code component of a subject?s address information. According to X.500(2001): “The postal code attribute type specifies the postal code of the named object. If this attribute value is present, it will be part of the object's postal address – zip code in USA, postal code for other countries.”

8.5.8. Country

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country

Type: xs:string

Definition: (c in RFC 2256) Country of a subject. According to RFC 2256: “This attribute contains a two-letter ISO 3166 country code.”

8.5.9. Primary or Home Telephone Number

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone

Type: xs:string

Definition: (homePhone in inetOrgPerson) Primary or home telephone number of a subject. According to inetOrgPerson using RFC 1274: “This attribute type specifies a home telephone number associated with a person.” Attribute values should follow the agreed format for international telephone numbers, e.g. +44 71 123 4567.

8.5.10. Secondary or Work Telephone Number

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone

Type: xs:string

Definition: (telephoneNumber in X.500 Person) Secondary or work telephone number of a subject. According to X.500(2001): “This attribute type specifies an office/campus telephone number associated with a person.” Attribute values should follow the agreed format for international telephone numbers, e.g. +44 71 123 4567.

8.5.11. Mobile Telephone Number

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/mobilephone

Type: xs:string

Definition: (mobile in inetOrgPerson) Mobile telephone number of a subject. According to inetOrgPerson using RFC 1274: “This attribute type specifies a mobile telephone number associated with a person.” Attribute values should follow the agreed format for international telephone numbers, e.g. +44 71 123 4567.

8.5.12. Date of Birth

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth

Type: xs:date

Definition: The date of birth of a subject in a form allowed by the xs:date data type.

8.5.13. Gender

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender Type: xs:token

Definition: Gender of a subject that can have any of these exact string values –

  • 0 (meaning unspecified),
  • 1 (meaning Male) or
  • 2 (meaning Female). Using these values allows them to be language neutral.

8.5.14. Private Personal Identifier

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier

Type: xs:base64binary

Definition: A private personal identifier (PPID) that identifies the subject to a relying party. The word “private” is used in the sense that the subject identifier is specific to a given relying party and hence private to that relying party. A subject?s PPID at one relying party cannot be correlated with the subject?s PPID at another relying party…

 8.5.15. Web Page

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/webpage

Type: xs:string

Definition: The Web page of a subject expressed as a URL.

HTML to invoke CardSpace on your site

In an upcoming post called Ultimate Simplicity: 30 lines of code, I show how to tweak a web page so it presents the option of logging in with an information card – without requiring you to dirty your hands with certificates.

If you haven't seen the demo yet, I start from a simple web page like this one:

I add an HTML form like this:

The form has an ID of “ctl00′, and a post action called “dump_input.php”.  In other words, when the form is submitted (by clicking on the icon specified in the “img” section) the contents will be posted and the script “dump_input.php” will be run on the web server.

The form contains an x-informationCard object tag, which takes a parameter of “RequiredClaims”.  This is followed by the claims the web page designer is asking for – in this case givenname and private personal identifier.

The zip of the sample code is here.

If you copy demo.html to your site, then when using the most recent release of CardSpace, you can navigate to that page, click on the icon, and you will be prompted for an infocard. 

The claims supported in CardSpace for simple self-issued cards are defined here - you could cut and past them into the “RequiredClaims” parameter of demo.php to alter the form's behavior.

Zend PHP Information Cards

Dr. Dobb's Journal is dear to my heart.  My wife Adele Freedman, an architecture critic, always used to point to the copies I left lying around and tell our friends, “Check it out.  It's amazing to watch him read it.  No two words fit together.”

But to me it was like candy.  So it was exciting to read the following article today on Dobb's Portal:

Microsoft and Zend Technologies have announced a collaboration to enable support for information cards by PHP developers through a component built for Zend Framework. Using this as a stand-alone component or as part of the Framework, PHP developers will be able to specify a Web site's security policy and accept information cards from trusted third parties.

“Microsoft and Zend are making a commitment to deliver information card support to PHP developers, which will reduce development costs and help make the Web safer and more secure for people,” said Vijay Rajagopalan, principal architect for Platform & Interoperability Strategy at Microsoft.

The cooperative work on information cards extends Microsoft's previous interoperability efforts in this area. Microsoft, in collaboration with Fraunhofer Institute FOKUS and ThoughtWorks, has developed open source interoperability projects on information cards for systems based on Java and Ruby.

“Web sites developed on ASP.NET can already accept information cards,” Rajagopalan explained. “With this work, a Java-based Web site, for example, built on the Sun Java System Web Server, Apache Tomcat or IBM WebSphere Application Server can now accept a digital information card for security-enhanced identity. A Web site built on Ruby on Rails can accept an information card. There is also an open source information card library project implemented in C, developed by Ping Identity Corp.”

Information about Microsoft open source interoperability identity card projects can be found at:

When support for information cards within the Zend Framework (an open source PHP application framework for developing Web applications and Web services) is enabled, users who access PHP-enabled Web sites will receive consistent user control of their digital identities and improved confidence in the authentication process for remote applications, all with greater security than password-based Web logins offer. Zend Technologies’ implementation of information cards lets users provide their digital identities in a familiar, security-enhanced way. They are analogous to business cards, credit cards or membership cards that people use every day.

I guess everyone familiar with this blog knows I've developed a deep affection for PHP myself, so I'm very happy to see this.

Burton Group reports on user-centric interop

The Burton Group has posted its evaluation of the user-centric interopathon held at this year's Catalyst. The analyst is Bob Blakley, now with Burton and previously chief scientist for Security and Privacy at IBM Tivoli Software. 

Bob writes, “Prior to the event, there were some specifications, one commercial product, and a number of open-source projects.  After the event, it can accurately be said that there is a running identity metasystem.” Continue reading Burton Group reports on user-centric interop

PHP managed card provider

Here's a new managed card provider from Patrick Patterson at  Carillon Information Security Inc.  With commendable understatement, Patrick writes:

I just thought that you'd like to know about a demonstration STS for issuing managed infocards that we've just finished.It's written in PHP, backends into either a database or LDAP, and is easily customizable to accommodate custom claims.

And, since it is written in PHP, it is easily deployable for those that want to experiment with a CardSpace STS, but who may not have either a JSP server to deploy one of the other Java based implementations, or an IIS .NET server to experiment with the one Microsoft has provided.

It is available here.

I'm a sucker for PHP and Ruby on Rails, so I love seeing this support.  Beyond that, I'm interested in Carillon's support for certificates. 

What is it?

The Carillon STS is a PHP-based Federated Identity Provider (IdP) which is capable of acting as a Secure Token Service (STS) compatible with Windows CardSpace and other “infocard” implementations. It has been successfully tested with CardSpace, as well as with Chuck Mortimore's Firefox identity selector plugin.

Once installed and configured, the Carillon STS allows a user to authenticate himself, either by password or by X.509 certificate, whereupon he is issued a digitally signed infocard containing some standard identity claims and optionally some customizable identity claims. When he presents this infocard to a Relying Party's (RP's) site, his browser's identity selector requests a SAML token from the Carillon STS. If the authentication information is still valid, a digitally signed token will be issued with the various claims asserted. The browser takes this token, checks the digital signature, encrypts it for the RP, and passes it along. It is the RP's responsibility to decrypt the SAML token, check the digital signature, check the asserted claims, and make an access decision based on this information.

Current Status:

This project has been tested with available releases of Windows CardSpace and the Firefox identity selector plugin. There are several Relying Party (RP) sites on the web to test against; in particular, the xmldap.org RP is able to consume Carillon STS infocards and display their contents.

Version 0.01 is the initial release of the Carillon STS. It is presently under active development.


The Carillon Demo STS is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Carillon Demo STS is Copyright © 2007 Carillon Information Security Inc.


Note: Please hold down the SHIFT key while clicking on package you want to download to avoid file corruption.

Source: carillon-sts-0.01.tar.gz

I hope to meet Carillon at the next Interopathon.  It's really awe-inspiring to see this level of Information Card expertise developing spontaneously in the security and identity communities.  Congratulations, folks!

CardSpace control for ASP.NET

Dominick Baier at LeastPrivilege has made leaps and bounds in his CardSpace control for the Microsoft ASP.NET environment (though it should work equally well for people using a Higgins identity selector or managed card).  It is very cleanly designed.  Amazingly, he's already added support for the new icon (does he ever sleep?).  His blog has an ongoing discussion around the control and related issues:

After I made some incremental changes and releases of my CardSpace control (found some bugs, got some feedback), I wanted to consolidate all the information along with a new version and some new features here. It now contains all the features I need and will be the last release for some time i guess.

If you have any feedback or suggestions feel free to write me or leave me a comment. If you want to add support for XHTML, contact me too ;)

Download here. Have fun!

PS. This was only possible with a little help of my friends…thanks Brock and JasonD!


Easy to use syntax
One of my main goals was to have an easy to use markup syntax and intellisense support. I don't want to type in all those namespace URIs…

<lp:CardSpaceSelector runat="server" ID="_selector_sic" AutoPostback="true" 

    <lp:ClaimType Name="givenname" /> 
    <lp:ClaimType Name="surname" /> 
    <lp:ClaimType Name="email" /> 


Clean markup and independence of the server form
The emitted markup works with Firefox and IE. I also made sure that the <object> tag is placed outside of the postback form. This allows you to have multiple postback controls on the form without triggering the identity selector.

Support for standard InfoCard image
You can choose between all standard sizes of the official InfoCard image. You can also supply your own image and dimensions

Designer integration
I never use the designer – but I acknowledge the fact that some people do ;) The control renders correctly in the designer and has an editor to setup the required/optional claims (including intellisense support).

Event driven
The control fires an event when a token is submitted.

protected void _selector_sic_TokenSubmitted(object sender, TokenSubmittedEventArgs e) {     string xmlToken = e.Token; }

Conditional rendering
You can choose to render the control only if the client browser supports InfoCards. You can specify an alternative <div /> that would render in that case (e.g. to tell the user how to get CardSpace).

I intentionally didn't couple the control with any user management semantics (like membership) or decryption clases (like the TokenProcessor). It is totally up to you how to proceed after you received the encrypted token. This is considered a feature ;)


InfoCard setup

This enum has two values ‘SelfIssued’ and ‘Managed’. If you select ‘SelfIssued’ then the issuer URI for self-issued cards will be emitted. If you select ‘Managed’ you have to set the issuer URI yourself. Defaults to ‘SelfIssued’

Issuer and IssuerPolicy
Specifies the URIs for the issuer and the issuer policy.

Specifies the token type. Defaults to SAML 1.0.

PrivacyUrl and PrivacyVersion
Specifies to the URL and version of the associated privacy policy (if any).


Specifies a custom image to display. Defaults to the official InfoCard icon. 

Selects one of the standard images sizes for the official InfoCard icon. Defaults to 114×80.

Width & Height
Specifies the size of the image in pixels. Only relevant when a custom image is used.


When set to true, the control will only render if the client browser supports CardSpace. You have to embed the control into a <div /> and specify the name in the DivToRender attribute. Defaults to false.

Specifies which <div /> to render/make invisible based on client support.

Optionally specifies a <div /> to render when CardSpace is not supported on the client.

Choose between static and dynamic rendering. Static preserves the space for the control on the client. Defaults to Static.


Name of the hidden field used to transmit the token back to the page. Defaults to __XMLTOKEN.

Specifies if the control posts back after a card has been selected. Defaults to false.

Specifies if the identity selector should be invoked directly after the page has finished loading. Defaults to false.

Holds the encrypted token after the user has selected a card.

Dominick also did a set of four videos on CardSpace for UK MSDN that I would recommend:

Implementation Strategies

Also find the sample code he used here

Information Card Contest

I was still reeling from the latest chicken pictures posted by James McGovern when I stumbled onto news of a contest put together by my colleague Richard Turner

James was complaining that the contest would slow down adoption in his case since it would break corporate policy to accept a prize.  I added a comment to his blog saying I would try to figure out a way that someone who could not accept the prize could make a charitable donation instead. 

But I didn't know what the prizes were until I read the original posting by Richard:

Identifying yourself online is becoming increasingly difficult and dangerous. Most people who use the web have to maintain several usernames and passwords and have to remember which usernames and passwords to use at the various sites they use.

While usernames and passwords are a growing frustration to most users, this problem is dwarfed by the growing threat of phishing and other forms of malware and identity-related attack.

Follow the wrong link and try to sign-in to a malicious site masquerading as, for example, your bank, and you run the very real risk of suffering considerable loss. These potential losses may be financial but may also impact your reputation (e.g. credit score) that may take years to repair.

Microsoft, along with many partners in the IT Industry, is building a suite of technologies to help combat the phishing issue, whilst making it easier for users to authenticate safely online. Technologies such as Windows CardSpace enable users to identify themselves by presenting cryptographically strong identity tokens (represented visually as information cards) to supporting websites.

To help fuel the growth of sites supporting Information Cards, Microsoft is announcing a competition that is open to every website owner, regardless of your web platform of choice. We hope you'll join us in helping to protect your user's identities from abuse and make it easier for your users to sign-in to your sites! 

How to enter

  • Add sign-up and sign-in support for Windows CardSpace to your website
  • Email the following to identity@microsoft.com
    • Details of your site
    • Your details
    • Complete this statement: “We added support for information cards to our site because …”
  • All entries will be judged by the CardSpace product team and winners announced on August 17, 2007. The winner will be notified by email.

The prizes

  • Grand Prize:
    • 1 Round-trip ticket (from and to a single location within the United States)
    • Overnight accommodation in a hotel near Microsoft Campus
    • Meet the team – spend a day with various members of Microsoft's Federated Identity team
    • Dinner with Kim Cameron
  • Second prize:
    • XBox 360 Elite Games Console
  • Third prize:
    • Zune music player

[Please note that due to international gaming laws we are only able to offer these prizes to US Residents and that any taxes incurred from receiving a prize is the sole responsibility of the prize winner(s).]

Adding support for Windows CardSpace to your site

  • The following resources will be indispensible in guiding you how to add support to your website:
  • If you have technical issues, please post questions to the Windows CardSpace discussion forum on MSDN – we'll be monitoring this forum closely and responding as quickly as we can. Note – if you contact us directly with support requests and your request is generic in nature, we'll ask you to post your question to the forum. This is the help others who may be experiencing the same issue as you and so that we can better manage potential support issues.

Anyway, that sounds like a lot of fun, and I'll make sure the winner gets a really incredible evening at one of the top restaurants in the region. 

And as for James, now I know what the prize is, if he wins we can just make it a working dinner at the local pub, taking on the role of Information Cards in the enterprise environment and all the other things I'd like to discuss with him from a purely business point of view.

CardSpace and OpenSSO

The Sun Developer Network has published an article by Martin Gee entitled Securing Site Access with CardSpace and OpenSSO:

With today's ever-increasing demands for robust security software and systems, alternative authentication and trust mechanisms are gaining popularity. In particular, the user name-password authentication model is typically the root cause of many security frauds. Why? First, many of us record passwords somewhere, rendering them vulnerable for snooping. Second, our tendency to create passwords that are easy to remember makes them easy to be guessed or detected. Consequently, enterprises that have established processes along that model are looking for ways to better safeguard and optimize their systems without major overhauls.

Enter Windows CardSpace (henceforth, CardSpace), a Microsoft-led specification that has been gaining recognition over the past months. CardSpace defines a simplified paradigm that employs a security token called InfoCard for managing digital credentials and is available in Windows XP and Vista.

OpenSSO is Sun's open Web access management project based on Sun Java System Access Manager source code. As part of the open-source Project CardSpace on java.net, ICSynergy has extended OpenSSO to include CardSpace as a simple authentication module. In addition, ICSynergy offers a commercial CardSpace implementation for OpenSSO and Sun Java System Access Manager along with training programs.

This article describes the benefits, basic architecture, and process flow of the CardSpace-OpenSSO authentication module.

It is good to see things coming together across the “crevasses” that used to separate different industry forces.  If you do Java you should look at the Project CardSpace site.