The PDC excitement is over.
The Azure Service Platform has been disclosed.
The Live Services are included in that and one of the Live Services is Web Authentication with Windows Live ID, meaning that you can use existing Live IDs to authenticate users to your service.
The Great News
From the current licensing terms of Web Authentication amongst the licensing terms for Live Services:
These services or applications have no user limits or fees.
The Concerning News
Amongst the Terms of Service for Live Services:
9. How We May Change the Contract.
If we change this contract, then we will provide notice as provided in section 20 below at least thirty (30) days before the change takes place. If you do not agree to these changes, then you must stop using the Services before the change takes place. If you do not stop using the Services, then your use of the Services will continue under the changed contract.
We may choose in the future to charge for use of the Services. If we choose to establish fees and payment terms for such use, Microsoft will provide advance notice of such terms as provided in section 20 below, and you may elect to stop using the Services rather than incurring fees.
This agreement will become effective on your first use of the Services or APIs. This agreement may be terminated immediately for any reason and without notice by Microsoft. If this agreement terminates, all rights granted to you by this agreement will automatically terminate and you will cease to have any rights to use the Services or APIs.
You could invest a lot of time making your site use Live ID for authentication only to find that you have no service with no notice or additional costs with 30 days’ notice – and 30 days’ notice means nothing if the service can be terminated without notice.
So how can plan to mitigate against this? Well if you already have a service, chances are that you have your own authentication and that you would be adding Live ID, in which case you should make it a supplemental identity, not a replacement. This does mean that once you’ve added it you should make it clear to users how they can recover their original service credentials in the event that Live ID needs to be removed (possibly without notice or because it would be too expensive). In adding a secondary identity, you may as well go the whole hog and support multiple identity providers if appropriate. Deep down in your database you may have a Users table. This essentially becomes an Accounts table with a new Identities table allowing for the mapping of 1+ identities to each account. Each Identity is a user claim from a provider you trust (e.g. Live ID) or provider claims you trust (e.g. the provider’s claim to be a government ID provider is trusted).
If you are creating a new service than you need to give this some serious thought. If you can stomach understanding the identity frameworks, then I’d suggest multi-identity support from the start.
Note that with Microsoft Federation Gateway, the owner of a domain (e.g. domain.com) can now have all Live ID web-based logins to that domain (e.g. firstname.lastname@example.org), diverted to a web page they provide for login. The web-based identity space is become truly federated. For the wider Microsoft claims-based federation model, you can also check out things like Geneva, ADFS & Microsoft Services Connector CTP (which works with the Federation Gateway).
The change and termination clauses I mention above apply to all of the Live Services. Many of the services are free up until a usage limit after which you need to enter into an agreement. I haven’t looked into whether that commercial agreement includes Service Level Agreement clauses or better change-management clauses. If it does then I’m wondering if one can pay for the Web Authentication in order to benefit from such potential clauses.
Back when Live ID was Passport, this kind of Web Authentication was also possible, however there was a stiff annual fee deterring service providers from using it.
I suspect that many care-free hobbyists, micro-ISVs or larger are diving headfirst into support of Web Authentication using Live ID. Caution is required…