Category: Infocard

Identity at RSA

I’ll be at RSA Conference next week participating in the following events.

What: The current goal is to demonstrate that SAML, WS-Fed and Information cards can co-exist and some of use cases where it makes sense. For instance, if you already have a federation setup (using SAML or WS-Fed), you can leverage Information Cards as an authentication mechanism and tighten the security. Similarly if you are planning on authenticating using an Information Card, you can extend the reach (and hence get more value for your investment) by federating using SAML/WS-Fed.
Who: Fugen, Internet2, Microsoft, Oracle, Ping Identity, Sun, Symlabs.
When: April 7th, 9AM-12:30 PM
Where: Red Room 302, Moscone Center North/South, Esplanade level

What: This is an interop event where you will get to see most (if not all) of Information Card as well as OpenID providers and consumers. What started off as an informal interop session at IIW, now has 57 participants. A lot of credit for this goes to Mike, Dale and Pam for continuing to encourage (read harass) other participants.
Who: 33 Companies. 24 Projects. 57 Participants.
When: April 8th, 9th. Working session 11AM-4PM. Demos: 4-6PM.
Where: Mezzanine Level Room 220, Moscone Center.

What: This has now established itself as a standard event at the main identity conferences. This is where we leave the vendor, customer, big enterprise, small company hats behind and just have a good time. Most end up getting wasted and missing out on their next day appointments.
Who: All available.
When: April 8th. 6-8 PM (it’s not really going to end at 8).
Where: 111 Minna Gallery (Tel: 415.974.1719).

See you there.

What is your mother’s maiden name?

A while back I spent some time researching into several strong authentication methods that are available in the online world. In order to get real user experience, I ended up creating online accounts with several banks and financial institutions . I got to try out various methods including OTP, biometrics, device fingerprinting etc. However, I found that every bank had something in common. They had all implemented some form of KBA (knowledge based authentication), also referred by some as challenge-response or Q&A. It was either implemented as a secondary authentication method i.e. give me your password and then tell me the color of your eye. Or as a means for back-end authentication (either to recover the password or to register my computer).

So….when we first launched with Infocard authentication (and account recovery via email) , we received some feedback that the site is only as secure as the weakest link. Hence in the follow up release, we upgraded the account recovery to use KBA.

We spent some time coming up with the right questions for the users. Should we ask

  • What’s the name of your first spouse? OR
  • What’s the name of your first love?

The difference is that the answer to the first question is a “fact”. And the answer to the second question is an “opinion”.

To illustrate this further, here are some “fact” based questions:

  • What is your mother’s maiden name?
  • What is the color of your eye?
  • What was the make of your first car?
  • In what city were you born?

And here are some “opinion” based questions:

  • Who is your favorite sports team?
  • Who was your childhood hero?
  • What is the name of your best friend?
  • Who is your favorite movie star?

It’s a lot easier for others to find facts about you. And hence the ‘fact’ based questions are a lot less secure than the “opinion” based questions. However, based on my experience and others that I have talked to- it seems when presented with a choice, most of the users choose the ‘fact’ based questions…simply because they are easier to answer and don’t make you think.


To me, it seems like another area where security and convenience are at odds. I’ll be interested to hear if others have an “opinion” on this.

Three days more / Interop Zen

Suiwo, the disciple of Hakuin, was a good teacher. During one summer seclusion period, a pupil came to him from a southern island of Japan.

Suiwo gave him the problem: “Hear the sound of one hand.”The pupil remained three years but could not pass the test. One night he came in tears to Suiwo. “I must return south in shame and embarrassment,” he said, “for I cannot solve my problem.”

“Wait one week more and meditate constantly,” advised Suiwo.Still no enlightenment came to the pupil. “Try for another week,” said Suiwo. The pupil obeyed, but in vain.

“Still another week.” Yet this was of no avail.In despair the student begged to be released, but Suiwo requested another meditation of five days. They were without result. Then he said: “Meditate for three days longer, then if you fail to attain enlightenment, you had better kill yourself.”

On the second day the pupil was enlightened.

It’s good to have deadlines and interops every now and then.


Paul lists some Reconciliation  ideas in a recent blog entry. His post raises two issues:

  • Why does require the profile information in the card (even though the site has the information already)?
  • As an RP/SP, how do you deal with the user’s profile information?  Do you keep a copy? Do you ask it every time from the IdP? How do you handle claims freshness, expiry, etc?

The second one is a bigger question since it is dependent on several other things like RP business model, IDP/RP relationship etc. We need to have a F2F session to drill down on that one.

Let me attempt to answer the first one. We did spend a significant amount of time on this particular subject before coming up with what we have. It’s not perfect but it’s the best among the choices that we had.
If you (or anyone else) have a better idea to address this, please share and beers are on us next time we meet.

At, we had the following requirements:

  • we wanted our users to have the option of registering multiple cards (one for work, one for home etc).
  • Once the user has registered a card with, he/she should be able to go to the My Account page, look at the registered cards and quickly determine if a card has already been registered.

We prototyped 3 ways to address the requirements:

  • Display PPID – This option will require the card to only have a PPID (every personal card has one). And then under My Account, the user will see a list of PPIDs. In case you haven’t seen, this is how a PPID looks alike – 7n+eg3TBKNP1ylqPrksKmS0xB8uyhTVX36XcdiEDdk0=.  Needless to say, it isn’t exactly user friendly. Additionally, the PPID is created on a per site basis. In order to see the PPID, the user has to submit the card to the site. Therefore if the user likes to verify if a card has already been registered, he/she has to invoke the card selector, select a card and submit it. 3 clicks only to find out if the card has already been registered.
  • Card name / label – At the time of registration, allow the user to enter a card name or a label to identify the card. The CardSpace client has a card name associated with the card. However, when a user submits the card to the site, the name does not get transmitted to the site. Therefore the name/label at the site has to be a completely manual process and will have no link with the card name in the identity selector. (We could have used nickname as the card name, but it meant overloading the claim and we didn’t want to go that route).
  • Additional claims – Ask for more claims from the user (e.g. firstname, lastname, email address) and hopefully that will give the user enough indication if a card has already been registered. It still has the problem since the user might have multiple cards with the identical claim values.

We had an independent team perform a usability test on the 3 prototypes and they preferred option 3.  Personally, I would have preferred a way for the cardspace client to send the card name to the site and then pick option 2.

Net/Net as it stands today, we aren’t using the claims in the card to map it to the user’s profile data but merely as a visual clue for the users to look at their registered cards. If you have a better idea, I’m all ears.

Online Payments using Information Cards

Here are the slides from Sid’s DIDW presentation.

To try out the demo, go to DIDWDemo, get yourself a card and ‘Go shopping at Starbuzz Coffee’. You need to have IE7 and MS CardSpace to checkout the demo (the bank site doesn’t support Firefox).

From the outside, it looks like any other ‘Managed Information cards’ demo. But behind the scene, the merchant site and the issuer are integrated with ACI’s Access Control Server and Payment engine. In the coming weeks, we’ll allow the user to monitor the transaction details between the merchant and the issuer.

For more information on the concept, checkout Sid’s post here .


Hesitation from Relying parties

James mentioned another reason for relying parties’ lack of support for Information Cards. Wanted to add more thoughts on that:

  • I haven’t seen many consumer based web applications that leverage the web access management products. I may be wrong but the WAM products are more in use for the internal/enterprise centric applications.
  • The access management products that you have listed provide authentication modules (and the SDK) which allows other authentication schemes to be hooked. Therefore, it’s not a big deal to create a custom authentication module/scheme for Information cards and then create the appropriate token/session.
  • We demonstrated a similar use case at Catalyst last year where you can use an information card to login to a Siteminder or CoreID domain. Behind the scene, you retrieve claims from the information card, contact the access management server and then create the appropriate token.
  • CA (Siteminder), Oracle(CoreID) and IBM (TAM) were all part of the OSIS interop demo at Catalyst in June. And Sun has demonstrated a CardSpace extension to their OpenSSO offering too. I don’t know when these products will be commercially available but I’m sure you know that a real customer/requirement can change priorities pretty quickly in the vendor world.
    Let us know when you are ready :-)

Open letter to the CardSpace team

Noticed from Kim’s blog that the CardSpace team is blogging. I’m just back from DIDW where I had some good discussions while presenting our Payment Card Demo. So I figured it might be a good idea to compile a list of the things that I heard and share it with the CardSpace team. If I have missed anything, please let me know and I’ll update the list.

  • Too many clicks
    In our demo, we showed how can you use a card to make an online purchase with a merchant e.g. Amazon. Once I have my profile setup at Amazon, it takes “1” click to make the payment. With Information cards, it takes “5” clicks. Everytime.
  • UI too techie
    The whole CardSpace UI is too techie especially the error messages. Messages like “Personal Card is encyrpted…” and when to ‘retreive’, ‘preview’ or ‘send’ a card are all technically correct… but explain that to my grandmother in Omaha. (My grandmother doesn’t live in Omaha nor do I think that people from Omaha are dumb…but you get my point).
  • Too slow
    This is my personal pain point. Since launching in July, I haven’t used the username/password option while logging on to However, the CardSpace client is too slow (especially during the first invocation). At times, I wonder if I clicked it or if the site crashed. The auto-form-filled username/password option is so much more convenient.
  • CardSpace Distribution
    Relying parites see no reason to support CardSpace at this time, since there is hardly any user adoption. “<grin>I’ll implement it when more than 5% of my user base can use it</grin>” is the standard response from the application providers. From the user perspective, “<chuckle>I’ll install it when there are more than 2 websites where I can use it.</chuckle>”. It’s a Catch 22 but someone has to bootstrap the process. Vista adoption has been slow. One can download it for XP, but the download is over 50MB and there is no reason for an average user to go through this. My suggestion ( talk is cheap :-) ) is to break the CardSpace component out of the .NET 3.0 framework and then push it down to the user’s desktop via Windows update. I know this is probably wrong and breaks a few of the identity laws (user consent etc) but it’s not like you haven’t done something similar to this in the past. Plus it’s for the user’s own good. They just don’t know it yet.
  • Submit it to a standards body
    You have done a great job in opening up the specifications. Other identity selectors like xmldap and DigitalMe are proof that you can have an end-to-end deployment without any Microsoft technologies. However, the CardSpace profile (I don’t know if this is the right term. It was used by one of the attendees) on how the selector gets invoked and how the message gets encrypted, the 14 self-issued claims are still under your control and it will be nice to submit it to a standards body and let others collaborate/contribute.
  • Open up your road map / bug list
    I understand that you have a lot on your plate and you are working as hard as you can to get the next version out. However, it will be nice to get some transparency into your roadmap / bug list on what and when you are planning to release. I’m not asking for an exact date for the CardSpace 2.0 release, but it will be nice to get what month/quarter do you plan to release and what are the top 5 features that we can expect. If you can open up you backlog/bug list to the public, that would be awesome.
  • Get some awareness
    Something on the likes of The OpenID foundation did a great thing by starting the bounty program. Native plugins for Joomla, Drupal, WordPress and the likes will really make it easy for the site owners/deployers. I understand some of this is in progress. The Catalyst event in June and the one coming up in Barcelona are a step in that direction. But it will be nice to get the ‘13 year old army’ (learned this term while attending a Boulder Barcamp) behind you. BTW…last time I checked is still available.
  • Open/Free RP toolkits
    This relates to the previous point. It takes a weekend to get an OpenID library, deploy it and test it. It takes over a week to understand the specs around Information Cards. Some drag and drop library where the installer/deployer doesn’t really need to know the inner workings will really help.
  • Cards Portability
    This issue has to be addressed (if not resolved) before calling CardSpace a real, production-ready, mature, ready for mass deployment technology. I know that cards can be exported and imported but it’s not practical. A way to carry my selector on a USB key or a smart card based selector or a mobile based solution or a service in the cloud with one click sync.
  • Get the terminology right
    I understand the difference between CardSpace, Information Cards, Infocard, Idenitity Selector, Identity Agent, Digital Me etc, but it causes confusion. When building FAQ, we looked around for an official definition for ‘Information Card” and found none. Our tech writers eventually came up with this. Have an official one page to explain the terminology and then heavily reference that page everywhere.
  • Features
    This is at the bottom of the list. You can always add features and still have some more to add. I don’t think it’s the features that’s hindering the adoption. All of the below items will be good to have but some real world deployments even with limited use cases should be higher priority. Here is a partial list of the features that came up:

    • Allow for mutiple issuers for the RP.
    • Allow for RPs to transfer information to the IdP at runtime. I know this can hacked a bit by setting ‘RequireAppliesTo’, but I would like to be able to pass proper data structures both ways.
    • Ability to either modify or extend the CardSpace GUI.
    • Ability to allow for other type of authentication methods e.g. OTP.
    • Allow the user to shut-off the cardspace invocation on a per RP basis. I agree with the user consent et all but it does get annoying on frequent use.

I strongly believe that CardSpace/Information Card is a great technology. Kim, Mike and the rest of the Microsoft folks have been very open and supportive in sharing information and resources. Most of the people I talked to, shared the same sentiment. We even had a round table on CardSpace/OpenID during our User group session after DIDW and everyone can see the potential. I hope we all will be around to see that happen :-) .

Identity MetaSystem….or not

Bob provides an excellent summary of the Catalyst user-centric interop. Provides a great overview of the state of user centric/information card technology.

Paul , Robin and Gerald argue over the definition of identity metasystem.

  • In theory…the information card flow/protocol is token agnostic and hence worthy of being referred to as an “identity metasystem”. The event demonstrated different components (IdP, RP, Selector) from different vendors interoperating with each other. The event then should be qualified as an identity metasystem interop.
  • In theory…Project Concordia addresses information card as well as OpenID, SAML and WS-Fed. And hence an “identity metaystem”.
  • In theory….another identity metasytem is required that not only addresses the above protocols but Siteminder, Oblix, Sun Access Manager, App server specific tokens etc.

By the time, we are done defining the super uber identity metasystem, there will be another identity protocol that will warrant us to start over.


My 0.2 cents

  • It was a great event that brought together a lot of vendors and provided a reality check to all of us. Bob and Gerry deserve full credit for that.
  • Everyone agrees that OpenID, SAML, WS-Fed should be part of the interop scenarios in future events. Even though I would argue that use cases I have seen so far demand for a mash-up and not an inteorp.

OSIS Interop at Catalyst- Part 2

I’m back at work after Catalyst. Here is the real leaflet from the OSIS interop event. Looks a lot similar to the one I used in my previous post…without the baby…and different set of companies :-)



I participated in the OSIS interop event (using a dev version of and finally got to meet a bunch of people I only knew through email.

Here are some tidbits:

Last year at Catalyst: We had one Information card-enabled Relying party . And no IdP.
This year at Catalyst: We had 24 Relying Parties, 6 Identity Selectors and 11 Identity Providers.

Last year at Catalyst: Attendees were confused between the words Infocard and Information Cards.
This year at Catalyst: Attendees were confused between the words CardSpace and Information Cards.

Last year at Catalyst: Not many had heard of OpenID.
This year at Catalyst: Over 3000 relying parties…..and counting.

Last year at Catalyst: There was no agreement on the term “User Centric Identity”.
This year at Catalyst: There was no agreement on the term “User Centric Identity”.

OSIS Interop at Catalyst

Things have been pretty busy lately….for a reason. We announced today …more on this later. Will also be participating in the Catalyst’s OSIS Interop event on Wednesday (6 – 9:30PM ) with a bunch of other providers. Time to find out how much of this is real :-) . If you are attending Catalyst, drop by to see it all in action.

The following image is only a placeholder :-) … till I get the real OSIS leaflet from Dale and Pam . Looks similar though.


Image | WordPress Themes