Category: OpenID

IIW2007B – My Takeaways

I’m back from IIW2007B. As always, there was a lot of energy, lot of discussions and lot of networking.
OpenID 2.0 was announced. OAuth 1.0 was announced. There were quite a few sessions on VRM. Some good discussions on reputation around OPs, RPs and users. I also got to spend one afternoon in the OSIS session where the discussions have moved beyond the “happy path” and the vendors (me included) are ready to tackle the edge use cases around Information Cards.

One of my favorite session was “What’s next for OpenID” led by Dick (Sxip) and Josh(JanRain). Now the OpenID 2.0 is wrapped and shipped, what needs to be improved for the next version(s).

Here are my notes from the session: (if you were there and I have missed or misinterpreted anything, feel free to correct).

  • Single Sign Out: OpenID allows the user to have a single identifier and get a single sign on experience across multiple applications. RP applications have different session time outs and this results in an inconsistent user experience as well as security issues. The protocol should have a way to “single log out” from all the applications.
  • Phishing resistant: OpenID has a couple of security issues, phishing being the primary one. It’s very easy for a rogue RP to redirect the user to a fake IdP and steal his/her credentials. There are a few solutions e.g. firefox plugins but it will be nice to have support for it in the protocol (or at least a best practice or recommendation for providers).
  • User experience less geeky: It may seem easy to some but typing (and remembering) is confusing and cumbersome for non-geeky, non-identity people.
  • Performance: Too many redirects. Direct authentication to the site using username/password results in a faster experience.
  • Cardspace – OpenID integration: CardSpace and OpenID are both addressing one fundamental problem – “Reducing Password overload”. Both have their strengths and weaknesses. It will be nice to have some convergence.
  • Identifier control: This is the identifier recycling issue plus some additional concerns. e.g I have my own domain name that I have redirected to my favorite OpenID provider. RPs may attach my identifier (i.e. my domain name) to my account at the RP. If I forget to renew my domain name (or I get hit by the bus), someone else may acquire my domain name and thus get access to my account at the RP.
  • Non-browser authentication – Ability to authenticate to non-browser applications.
  • Consolidation / Synonyms – If a user has multiple OpenIDs, then the RPs should allow attaching multiple OpenIDs to the same account.
  • Identifier management – The users may already have an OpenID identifier from AOL,Yahoo etc. but don’t know how to use it at the RP. This is a usability issue for the RP sites.

In the past, if you raise issues like “phishing”, the standard response was “this is a problem with SAML too” OR “this is out of scope for OpenID”. It was refreshing to be able to openly discuss the weaknesses and figure out ways to improve the protocol. I consider this a sign of maturity.

Get a bucket

Paul is right. They have met before. But this is different since both have reached a certain point of maturity and have proven themselves.


Interestingly, on both occasions, it’s the SAML kid that’s making an attempt. He is definitely feeling insecure;which is ironical given it’s the more secure, mature protocol and all that. But then, may be you get wiser and more accomodating as you grow.

Regarding the Zen comment, we all need to empty our cup; Or get a bigger one; Or make a hole at the bottom; or start drinking faster;or just switch to beer and then I know that your cup will never runneth over.


Zen – A Cup of Tea / Dynamic Federation

Nan-in, a Japanese master during the Meiji era (1868-1912), received a university professor who came to inquire about Zen.

Nan-in served tea. He poured his visitor’s cup full, and then kept on pouring.

The professor watched the overflow until he no longer could restrain himself. “It is overfull. No more will go in!”

“Like this cup,” Nan-in said, “you are full of your own opinions and speculations. How can I show you Zen unless you first empty your cup?”

 SAML. Meet OpenID; OpenID. Meet SAML. Introducing dynamic federation.



I spent the last couple of days at Defrag. I was going to list some of the happenings but it seems like Phil  got that taken care of. Nonetheless, some of my observations:

Before the conference I wasn’t really sure what the conference was all about. After the conference, I’m still not sure what the conference was all about. It felt like a lot of electrons with lots of energy and moving in every possible direction. I need more defragging.


Identity Mashup

A while ago Paul and I had a conversation about how the neighborhood kid teases his daughter Ophelia Pauline Edna Nicki Irene Daphne for the lack of certification. And how I was concerned that my son, San Ashish Mator Lester  gets picked since his friends think he is fat and difficult to understand.
It’s refreshing to read that compared to Higgins, San…Lester is considered sexy. It’s about time our kids hook up. In case you are interested,  Inspired by Intellectual Women in December is planning to have a speed dating event. There are couple of other dating services, Open Source Invitation for Singles  as well as Contrasting but Cordial where San…Lester normally shows up.

However, the word on the street is that Ophelia…Daphne doesn’t believe in pair wise relationship or trust. Ours is a conventional family. It’s not like we are asking for exclusivity but at least some kind of white list will be nice.


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. Upgrade

We have added a couple of new features to Your comments/suggestions are always welcome.

  • Support for SeatBelt
    SeatBelt is a Firefox plug-in by Verisign. It assists you while logging in to OpenID RP sites. You can find more information as well as download it from here:
    In a nutshell, it allows for the following:
    - One click to get to your IdP.
    - Status indicator if you are currently logged in to your IdP.
    - Convenient way to switch OpenID providers.
    - OpenID form-fill at the OpenID RP. If you are not logged in to your IdP, it challenges for authentication. If you are already have a browser session with your IdP (e.g., it does form-fill at the RP.
  • Support for OpenID Provider Authentication Policy Extension (PAPE)
    PAPE is an OpenID extension that allows the RP to specify an authentication policy. It allows the IdP to inform the RP what authentication policy was used. It’s similar to the concept of AuthnContext in SAML. Since support multiple means of authentication (username/password and information cards), we update the OpenID response accordingly. Currently, there aren’t many RPs today that leverage this feature. That should be changing soon. You can find more information on PAPE here.
  • About Me
    This is one of the most requested feature by our users. The ‘About’ page allows you to share your information with the world. Consider it the digital equivalent of your business card. Once logged in to, you can fill in your information in the ‘My Profile’ section and click on the publish_true.gif  image to publish it and share it with the world. As an example, checkout .

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 :-) .

OpenID Whitelist

AOL announced yesterday that they are going to start accepting 3rd party OpenID logins. This is a great milestone since I believe this is the first big RP to do so. However, they also adopted the concept of ‘OpenID Whitelist’ which brings up a couple of interesting questions:

  • Is this the right thing to do? OpenID strength lies in it’s ‘distributed nature’ and the ability for the user to control his own identity. Only allowing ‘selected providers’ negates that. I personally believe that “if OpenID has to move up the value chain then ‘whitelisting’ is inevitable”. However, I mentioned this in a barcamp a few months ago and most of the participants disagreed. They thought it’s against the spirit. The ability to run their own OP is why they like it more than the other identity systems. At the end of the day, it has to be the RP’s decision. AOL approach, however, might set a precedent for other RPs .
  • The second issue is a follow up on the first one – ‘As an RP, how do you decide which OP to add to your whitelist?’

As it turns out, is not in their initial list. I talked to the AOL folks and they promised to add it during their update next week. Fair enough. However, this model isn’t scalable. Given the distributed nature of the protocol, it doesn’t seem right for IdP/OPs and RPs to individually contact each other to maintain this list. Isn’t there a need for an OP Reputation, a.k.a. qualification, a.k.a certification suite that the RPs can leverage? There can be some objective analysis for the OPs:

  • How long have you been in existence?
  • What form of authentication do you support?
  • Do you support https?
  • What’s your account recovery process?
  • What’s your privacy policy?
  • How do you handle spamming?
  • Do you support Attribute exchange?
  • Do you support PAPE?
  • What’s your registration process?
  • Are you OpenID compliant (wait…that’s another big topic)?
  • Do you charge your users?
  • Do you have a cool logo?

So far the adoption for OpenID has been driven by the IdPs/OPs (it’s pretty apparent by the imbalance in the number of OPs and RPs). However, I believe the OP Reputation suite has to be driven by the RPs. They are closer to the problem and have a real need to filter out the unreliable OPs. I hate to volunteer others (well..not really ?), but it will be great if the AOL folks can take this initiative.

Image | WordPress Themes