Re:Reconciliation

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

  • Why does SignOn.com 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 SignOn.com, 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 SignOn.com, 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.

One Response to “Re:Reconciliation”

  1. Vittorio says:

    Hello Ashish ,
    I have a recent post that discusses similar issues in broader terms. It’s at http://blogs.msdn.com/vbertocci/archive/2007/10/29/the-tao-of-claims.aspx.

Leave a Reply

Image | WordPress Themes