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

PlankySteve Plank (Planky) is an Architect Evangelist on the Microsoft DPE team (Developer Platform Evangelists). Planky, in his own words, is ‘unusually intrigued by things like encryption and that kind of caper. Very interested in protocols and all the malarkey that surrounds them’. If you want to know more, take a look at his blog.

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

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.
    • 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.

  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.

I’ll continue the story in future instalments. Stay Tuned!

Published by Sara Allison

Sara is the editor of Ubelly - when not heads down scouring Ubelly articles for typos (and not always catching them), she's scouting for new writing talent. Give her a shout @SaraAllison if you've got something to say about development/design and want to be heard.

3 Comments So Far, what do you think?

  1. Pingback:It’s not about what we have, it’s about what we share… Part Two. : Underbelly

  2. novedades en perfumes originales

    I have been surfing on-line greater than 3 hours lately, but I never discovered any interesting article like yours. It is beautiful worth enough for me. Personally, if all webmasters and bloggers made just right content as you did, the net might be a lot more helpful than ever before.

  3. Tutto per l' animazione 3d

    Magnificent website. A lot of useful information here. I am sending it to some pals ans additionally sharing in delicious. And certainly, thanks in your effort!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>