Windows Live ID OpenID Status Update

  • Article

Here's an update from the Windows Live Group on integrating Windows Live ID with OpenID from the Windows Live blog:

Many people have asked recently about the status of the Windows Live® ID community technology preview (CTP) OpenID endpoints, so here is a quick update.

We gathered a lot of great feedback during the OpenID CTP period, and we have fed that into our team's OpenID product plans. Thanks to everyone who provided input—you have directly impacted the product!

The Production release of Windows Live ID's OpenID Provider support will look significantly different from the CTP version, so we are in the process of closing the OpenID CTP endpoints to avoid any confusion.

Currently, we do not have a schedule that I can publicly share for when we will release full Production support of OpenID for Windows Live ID users, but rest assured that we are working actively to provide OpenID functionality to all of our 500+ million Windows Live ID users!

Background: Our Approach in the CTP

A major characteristic of our OpenID Provider (OP) CTP was the attempt to use an account alias as both a “vanity URL” as well as a defense mechanism to help protect against phishing attacks.

In the CTP, Windows Live ID users were required to create an OpenID alias (such as “https://openid.live.com/john”) attached to their account, and then to use that alias not just at the OpenID relying party site, but also as the way to identify themselves to the Windows Live ID OP. When arriving at the OP sign-in screen, users were required to enter their OpenID alias (instead of their normal Windows Live ID user name) plus the password (or one of their other associated credentials, such as an Information Card) from their main Windows Live ID account.

Why this approach?

One of the main things we were (and still are) trying to do with the Windows Live ID OP is to provide as much protection as possible to our Windows Live ID users against phishing attackers who use OpenID. OpenID does not support a network sign-out function as part of its protocol, which can mean that users are left in a state that differs from what they might assume. For example, Windows Live ID users who sign out of an OpenID site might expect to be completely signed out of their account, because that is what happens on all other Windows Live ID-enabled sites.

How did it go?

We had envisaged that using an alias for OpenID sign-in could provide some separation of the two identity networks.
However, the usability model for this approach has turned out to be unfeasible and/or just plain confusing to users!

Lessons Learned

So the main challenge uncovered during the CTP was around aliasing, and then there was a grab bag of other things that we learned too.

Aliasing: a separate OpenID namespace for users

  • Users were confused about the need to associate a separate OpenID alias with their main Windows Live ID account.
  • Users didn’t know where to go to create their OpenID alias; more setup pages to click through led to more drop-off.
  • Users from different Windows Live ID namespaces would be upset if they could not get the same alias as they already had. For example, john@hotmail.com and john@live.com and john@hotmail.co.uk could not all have the alias “https://openid.live.com/john”.
  • Acquiring all the “best” aliases quickly becomes overly competitive.
  • Users got confused about whether they needed to enter their OpenID alias or the user name of their main Windows Live ID account to sign in.
  • Many users forgot what their OpenID alias was, so we would have required a separate “alias recovery” process.
  • At the OpenID alias sign-in page, we would have had to present to users (and of course specifically test) all combinations of the different sign-in credential options that we already provide for Windows Live ID accounts—going beyond user name and password to include smart cards, Information Cards, and other types of credentials. This complexity was pretty much a direct multiplier factor on the size of the required test matrix.

Multiple entry-point paths

  • Having multiple entry-point paths [for example, standard sign-in page + OpenID sign-in page + 3rd-party WebAuth sign-in + 3rd-party consent sign-in page] complicates all the sign-in interrupt flows that we must support.
  • Preserving the user experience and familiarity across multiple entry-point paths is challenging if any or all could potentially be updated independently.
  • The cost of always keeping multiple entry-point paths exactly in sync would have been too high.
  • Any form of combined sign-in/authentication + consent/authorization flow would be also complicated if we have multiple entry-point paths to deal with.

Explaining things

  • Last, but not least, we had a really hard time creating the right text to explain the choice between global unique alias and anonymous ID values being returned to relying party sites, even to super-geeks who work on identity software every day!

Conclusion

Basically, then, users will be able to use their existing Windows Live ID account credentials to sign in to OpenID sites directly -- just like they currently can do for any sites already using Windows Live ID Web Authentication . Users won’t be required to pre-create a separate OpenID alias attached to their account in order to use it at OpenID sites.

We plan to optimize our production implementation around OpenID provider discovery / identity select functionality (enter live.com in the OpenID sign-in box on a third-party site) as the best way forward for the vast majority of the users of our OpenID Provider.

We will also aim to reuse and/or consolidate the various sign-in entry-point paths wherever possible -- to simplify the engineering and user experience for everyone.

Finally, we are planning to hide the choice of ID value / type to return to relying parties -- to simplify the overall user experience for our mainstream users.