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 “http://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 “http://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 + 3^rd-party WebAuth sign-in + 3^rd-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.

If you have any additional feedback on our lessons learned then you can send them to our OpenID Tech Preview Feedback address.

References

1. OpenID Foundation Home Page http://OpenID.net
2. Windows Live ID Home Page http://dev.live.com/liveid
3. Original announcement of the Windows Live ID OpenID Provider CTP http://winliveid.spaces.live.com/blog/cns!AEE1BB0D86E23AAC!1745.entry
4. Windows Live ID Web Authentication SDK http://msdn.microsoft.com/en-us/library/bb676633.aspx

There will be lots of the great sessions at the the Microsoft Professional Developer Conference (PDC) in October and the Windows Live Platform crew will be there in force to share all the latest goodness we have been working on during the last few months.

You can expect some very interesting announcements at PDC that will be of great interest to anyone developing cloud applications....

Jorgen Thelin will be there this year presenting a session about the wealth of Windows Live ID Identity Services functionality that developers can use to enable Windows Live / Live ID services to be integrated into their web sites and applications.

Session BB22 - Live Platform: Identity Services

The Live Platform enables developers on any platform to choose the identity integration model that best enables their scenarios, including: web or client authentication, delegated authentication, or federated authentication. Learn how to build seamless, co-branded, and customized sign-up and sign-in experiences.

The other session from the Live ID Team is being presented by Tore Sundelin, and is one you won't want to miss either.

Session BB29 - Connecting Active Directory to Microsoft Cloud Services

Learn how to augment your existing IT infrastructure with Microsoft Services. Manage and secure end user access to cloud services using your existing investment in Active Directory. Enable end users to access cloud services through existing Active Directory accounts, the same way they access your intranet-hosted software today. Hear how to enable existing software to use new service capabilities without re-writes, and do it all through the use of open and standard protocols.

The PDC is designed for leading-edge developers and software architects. If you are interested in the future of the Microsoft platform, you are responsible for the technical strategy in your organization, or you are a highly skilled developer who likes to delve deep into the heart of the platform, then the PDC is for you!

Check the full agenda here, then make your registration online. Hope you can join us in Los Angeles!

Today the Windows Live™ ID team released the Delegated Authentication SDK v1.0, which provides a platform-neutral way for Web applications to access customers’ information from Windows Live services while customers remain in firm control of their own data. This release is part of a broader announcement of a whole set of releases from the Windows Live Platform team that are described by our boss David Treadwell in his blog posting today.

Windows Live Delegated Authentication is a feature that gives Windows Live ID customers the ability to consent to the scoped release of their personal information to particular Web sites in a reliable yet flexible manner. Customers grant (or withhold) consent by means of a straightforward user interface, as shown here:

Delegated Authentication is a way to grant access to personal information, but with more precise control over permissions and usage than the current binary decision (that is, fully on or fully off) that comes with the generally bad practice of handing over your account credentials to another Web site.

Simultaneously with the debut of Delegated Authentication, the Windows Live Contacts and Windows Live Photos teams have released updates to their services to use this new feature, enabling customers to permit other Web applications to access their photo albums or their Hotmail® / Messenger contact lists.

This is a big step in delivering real, user-centric data portability—giving Windows Live customers explicit control over releasing their information from Windows Live services and sharing that data with other applications that they want to use. The value of allowing software to access our personal data across multiple Web sites can be huge in terms of:

• Time saved—who wants to keep contact lists up to date manually across a number of different e-mail accounts?
• Possibilities created by combining data from different sources in new and innovative ways—for example, overlaying your friends’ latest home and work addresses with the details of your travel itinerary for an upcoming business trip could allow unexpected opportunities for reunions with people you haven’t seen for many years.

Windows Live Delegated Authentication is the strategic delegation platform for Microsoft Web properties, and is built on the proven, highly scalable technology used by the Windows Live ID authentication service.

Delegated Authentication is an evolution of the earlier prototype Cumulus PGUX Alpha release (a.k.a. Windows Live Data) seen at MIX07. The PGUX system will be phased out during the next six months, and during that time we’ll be working with any developers currently using the PGUX service to help them make the transition to the Windows Live ID Delegated Authentication system.

A white paper is available to provide a high-level overview of how Delegated Authentication works and how it can be implemented and used by Web application providers. More details are provided in the Delegated Authentication SDK documentation on MSDN®.

The SDK release includes sample applications for each of six different programming languages: ASP.NET, Java, Perl, PHP, Python, and Ruby. The use of this SDK is governed by the Windows Live Platform Terms of Service.

Delegated Authentication is the strategic programming model for consent-based data portability for all Windows Live services going forward. More Windows Live services will be releasing support for this feature in the coming months; the Resource Provider Directory shows the current list of Windows Live services that support Delegated Authentication and the status of each release.

Windows Live Delegated Authentication is both a powerful enabler of a new class of user-centered Web services, and also an opportunity for users to take back control of their own personal data and make informed decisions before releasing that data to other parties.

-- Jorgen Thelin, Senior Program Manager, Windows Live Identity Services

Some Typical Scenarios for Windows Live Delegated Authentication

Here are some scenarios that illustrate how Windows Live Delegated Authentication might be used.

Social Networking Address Book – A social network site can synchronize a customer’s Windows Live Contacts list with his or her “friends” lists from other social networking sites, to ensure that the customer can keep e-mail and contact information updated as friends change jobs or move around the country.

Family Photo Album – A family Web-site service could automatically retrieve the latest digital photographs from each individual family member’s personal photo-hosting account, to create an up-to-date snapshot of family activities.

Resources

· Understanding Windows Live Delegated Authentication white paper

· Windows Live ID Delegated Authentication SDK

· Windows Live ID Delegated Authentication SDK documentation

· Windows Live Platform Terms of Service

· Windows Live Delegated Authentication - Resource Provider Directory

· Windows Live ID - Development Support Forum

· Windows Live ID Developer Home Page

· Windows Live Contacts Developer Home Page

· Windows Live Photo APIs Developer Home Page

· David Treadwell’s Windows Live Platform Announcement blog posting

Windows CardSpace is a new way to sign in securely and conveniently into websites. And now you can use CardSpace with your Windows Live ID account! Using CardSpace with Windows Live ID means you don’t use a password to sign-in. Instead, just send your Information Card to Live ID to identify you and get signed into Hotmail, Windows Live Spaces or any other site that accepts Windows Live ID. And it is incredibly easy to use CardSpace with your Live ID. Just follow this link (here) to get going in minutes! 

If you are using Windows Vista, you are all ready to use CardSpace! If you are on Windows XP or Windows 2003, you will need to get IE 7.0, our newest and coolest browser and .Net 3.0 with CardSpace support (if you don’t already have them). You will also need to add an Information Card to your Live ID account.  To install these components and add an Information Card to your Live ID account, visit the Windows Live ID Information Card management page.  Also go to that page to make changes to the Information Card added to your Live ID account.

Once you’ve added an Information Card to your Live ID account, sign in using the Information Card. You will be amazed at how easy it is! BTW, that Windows Live ID CardSpace support is still a “Beta”. We are still working on it and know a bunch of things that could be better. But do let us know your wish list; it is always good to get feedback.

Nayna Mutha, Program Manager - LiveID

Rob Franco, Lead Program Manager - Windows CardSpace