Category: user-centric

Identity at RSA

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

Concordia
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

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

Mix-it-up
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.

Words out of vocabulary

Note to self; Stop using the following words while discussing identity.

  • Federation
  • Trust
  • User Centric Identity
  • Identity Metasystem
  • Claims

Update: Got a comment from Hans and I realized I haven’t provided the context here. My ‘note to self’ is after reading this and this and this and this and this and this and this and this:-) At times, we get a bit hung up on the terminology.

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) whatever.myfavoriteopenidprovider.com 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.

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.

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.

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.

mutitool21.jpg

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.

Image | WordPress Themes