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.
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:
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:
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.
Before any exchanges can take place, some things need to be set up. This section talks about that.
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
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!