It’s not about what we have, it’s about what we share… Part One.

  • Article

Facebook, MySpace, Twitter, Messenger, Spaces, Linkedin, Bebo and so the list goes on: places we share different aspects of our lives. We see something on the net that we like and we put it on our wall, we tweet it, we promote it, we chat about it, we allow others to share in the pleasure we get from it.

Each of these services is an Island. We go to the first one and register, create a profile, log out, log in, add to our profile, add friends, add photos, share photos, share the things we like. Then we go to the next service and guess what we do? We register, create a profile, log out, log in, add to our profile, add friends, add photos, share photos, share the things we like. As they say in the Rock and Roll world - repeat till fade.

Windows Messenger Connect is a way for us to connect these experiences and services together. For some of the features - such as creating a single login or sharing profiles, contacts and friends across different sites it does require the co-operation of the site concerned. Your site.

But many things can be shared in a natural way, because of the APIs and services exposed by these sites in any case.

We've all seen this sort of thing on various web-sites:

 

...a way of sharing that page through email, with our facebook friends, or through twitter. We can now add a new sharing icon - the Messenger Connect Sharing Badge:

 

When you see this icon on a site, it means you can share it with your Messenger friends just by clicking it. This is the simplest Messenger Connect feature to implement on your site because it just requires a few lines of HTML - Messenger at the back-end takes care of everything else for you.

Why would you do this on your site? The more people who share your pages with their Messenger friends, the more visitors you will have to your site.

Messenger Connect Capabilities

There's more than just sharing a page. This list gives you an idea of the sorts of things you can build right in to your site:

  • Lower the friction of getting users to register at your site. We've all done it - hit yet another page that asks for personal information like Last Name, Home Address, Home Telephone Number. We often find the process too onerous for the benefit we feel we might receive from the site and so we bail out. Depending on which study you read, between 80% and 99% of users who go to the registration page of a site, abandon the process.
  • o ASP.Net has built-in mechanisms for authenticating users. Or you can build a home-grown authentication system or use libraries from a 3rd party. The advantage of using Windows LiveID on your site is that it's a ready-made market of about half a billion people in the world who have already registered.
  • § There's a Windows Live Signin Control where you can integrate the authentication and consent process into your site using little or no JavaScript code.
  • § There are JavaScript and .Net libraries that allow you to sign users in, monitor their authentication state and, with user permission, get access to their Windows Live profile information so they don't have to go through the process of re-keying all that information yet again.
  • Real-time chat within your site:
  • A small bar at the bottom of the page; the Messenger Web Bar is a single UI Control that contains a full Windows Live Messenger experience. It allows users to manage contacts and interact with them, shows all active conversations, allows users to update and display presence and most interestingly - enables the user to stay signed in to Windows Live Messenger while they navigate from page to page within your website. Conversations that start on one page can continue on another.
  • The Chat Control can be embedded right in to your web pages: users can view a Messenger chat session and users who have a Live ID can use Messenger chat to send their own messages.

 

  • Contacts: Users spend more time on a site when they know their friends are there. Make it easy for them to discover their Windows Live contacts on your site.
  • Share your activities: Let your friends and contacts know what you are doing - it's a way to remain connected on a personal as well as a network to those close to you.
  • Share your Calendar and Photos: Isn't this really about sharing some of the minutiae of your life with the people you care about. Whether you can make it to a dinner party on a certain date, or a picture of you and your partner on a beautiful beach somewhere is not interesting to anybody unless they know you. The level of interest and engagements goes up exponentially when you know the people you share these things with. Messenger Connect just makes that process easy to do in an ad-hoc way when using the Internet.

The mechanics

Almost all of this is possible because of a web based protocol which is used for authorizing API access across sites: OAuthWRAP or Open Authorization Web Resource Authorization Profile. WRAP is a profile within OAuth. In the cases we are interested in, it uses browser redirects, HTTP headers and HTTP Post messages to transfer control and tokens between web sites, Live ID and the  web browser. The tokens contain authorization information that determines what site can get access to what information. The protocol has built-in features such as timeouts, security, encryption, secrecy and so on. There are 4 parties in an exchange:

  • 1. The Client Application (your website)
  • 2. The Authorization Server (Windows Live)
  • 3. The Protected Resource (Windows Live): for example your profile or your contacts
  • 4. The web browser (and attached to the screen, keyboard and mouse of the browser - the user)

In the case of Windows Live - it performs roles as both an Authorization Server and a Protected Resource. It authorizes or denies authorization to resources such as a user's profile, contacts, calendar or photos.

Setup

Before any exchanges can take place, some things need to be set up. This section talks about that.

Windows Live APIs trust Windows Live ID

Firstly, there needs to be a trust relationship between the Protected Resource (Live profiles, Live API service etc) and the Authorization Server (Live ID). The trust involves a certificate exchange which essentially results in the 2 services swopping public keys with each other. This ensures that tokens can be encrypted and signed - just a precaution to ensure tokens aren't cracked open and inspected, faked or modified. The diagram below shows the way this is achieved.

 

Figure 1: Certificate Exchange

  • 1. The Windows Live Authorization Server has a certificate (as does the Windows Live API Service). It contains a...
  • 2. Public Key.
  • 3. The related private key is held separately to protect it.
  • 4. A certificate exchange takes place, which essentially means the Windows Live Authorization Server and the Windows Live API Service swop public keys.
  • 5. When a Refresh Token or Access Token is generated by the Authorization Server, to assure its authenticity, it is signed by the Authorization Server's private key.
  • 6. Because the Windows Live Authorization Server has a copy of the Windows Live API Service's public key, it uses this to encrypt the Refresh/Access Token.
  • 7. The encrypted, signed token is passed to the Windows Live API Service.
  • 8. Because the Windows Live API Service has a copy of the Windows Live Authorization Server's public key, it can use this to validate the signature and therefore be assured that the token was indeed generated by the Windows Live Authorization Server, and not modified by an imposter while in transit.
  • 9. The Access/Refresh Token was generated by the Authorization Server, which used the Windows Live API Service's public key to encrypt the token. It therefore uses its own private key to decrypt the token. In this way the security and authenticity of the tokens transported between the 2 servers is maintained.

The reality is that this all happens entirely under the covers. It's merely included in this description for the sake of completeness. But it does mean as a developer you can be assured any time authorization information is passed via a user's browser, it is all safe.

This was my first MSDN Blog Post. I'll continue the story in future instalments. Stay Tuned!

Planky