I can’t think of a better way to spend a Friday ‘at work’ than going to dConstruct 2010. The day’s been filled with fascinating talks on creativity and how to consistently create the best digital experiences. Favs were Brendan Dawes and Tom Coates but all were inspiring. Kudos to uber nerd Merlin Mann and his definition of geek versus nerd, which went something like:

A geek will fix your computer – whereas a nerd can fix your computer too, but will talk to you for ages about the pros and cons of your software before even thinking of fixing it

So which are you? Answer on a postcard to…

The video from today plus a montage of pics of some of the dConstructees will be live next week, so make sure you come back to check them out!

We’re coming to Brighton! Yes, this Thursday the Underbelly possy and Microsoft bods be heading off to dConstruct 2010 – first stop the pre party at Lola Lo, and then up early for the big day itself.

So what will we be doing at this key event I hear you cry? Well, here’s a taster…

Use Foursquare? Look us up when you’re there and grab a free coffee and pastry to get your brain ready for the sessions.

We’ll be test driving IE9 and our experts will be ready to answer all your questions (yep, we’re expecting quite a few!).

We’ll also be sneaking in a Windows Phone 7 (or two) to show you and our roving reporter will be chatting to all willing (and able!) speakers and attendees about creating beautiful websites and applications.

Who the heck are we? Here’s a quick introduction:

• Alexandria Ball: Marketing guru known for her loud laugh and artistic abilities
• Andrew Spooner: Creative genius on the lookout for likeminded individuals
• Mark Quirk: IE9 technical expert and demo master extraordinaire
• Martin Beeby: Windows Phone 7 and IE9 technical wizard
• Sara Allison: Underbelly roving reporter, on the hunt for willing interviewees

Catch us #dConstruct on Twitter @ubelly.

See you there – or online!

Capitalising on this idea of sharing what you love, Loved.by is a site that rewards members for promoting products – essentially you get a cut of the sale if a friend buys a product. Sounds great, as long as it doesn’t mean I get friends ramming the latest products down my neck trying to persuade me to buy them (I could lose some friends pretty quickly!). But hey – if I happen to send some emails gushing about the latest ‘super expensive’ products I’ve found on the net, who can blame me…?

Don’t lose that app! If you haven’t updated your Twitter app to use OAuth, it won’t work any more. In order to increase security, Twitter has killed support for all basic user authentication in favour of OAuth from today, that many are wittily calling the ‘OAuthcalypse’. Twitter has posted a help page for anyone needing support in updating their app, and many devs have been working over the bank holiday (nothing new there) to ensure their precious work isn’t lost.

Twitter has also posted an article on the demise of basic authentication to explain the change to all Twitter users.

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

In part one I gave an overview of what was possible and started down the journey of the various bits of setup that had to be done, either by you, or setup that has already been done by the Windows Live team. In this article I show how the OAuthWRAP protocol works with Messenger Connect.

Windows Live ID wants to share some secrets

Windows Live ID is the Authorization Server. It implicitly trusts the Live IDs in its database because it created and issued them. But when it gets down to your site, it needs to have some assurances that the site that comes to it purporting to be your site is in fact your site. To this end it will create and share a couple of secrets with you.  In OAuth WRAP terms, your site is known as the client application, hence the secrets are termed the client ID and the client secret. It’s important that you keep these secrets, well, secret.

To obtain these secrets you must go through a registration process with Windows Live ID (the Authorization Server). You’ll be asked for the site’s domain name and the URL of a callback handler (covered later). The secrets will be stored against the domain and URL. Whenever your site communicates with Windows Live ID, all the parameters must match up; the URL, the domain, the client ID and the client secret. Security and authorization error messages invariably end up with one or more of these parameters not matching up correctly.

While the product is in Beta, you can’t register a domain unless you have also applied to join the Beta and been accepted on to the program. You are informed by email of your successful registration. This process can take a few days, so make sure you allow for it in your schedule. You’ll be asked questions about the number of users that hit your site and the scenarios you want to try. As a general rule, if you fill in all the fields accurately, the scenario you want to deploy is supported and the site is a genuine site, you will be accepted on to the Beta program. You’ll need a Live ID to register.

To register, go to http://dev.live.com and click the “Join the Beta” button.

Once you are registered, you can add additional URLs and manage their secrets. You can also upload logos that will be used in authentication challenges and so on. This is done at http://manage.dev.live.com.

Figure 2: Client application management at http://manage.dev.live.com

Protocol Exchanges

Once all this basic setup (certificates, client ID, secret, callback URL, domain name) has been completed, you can create/modify the pages in your site with the aid of the Windows Live SDK.

In this section, you’ll see how the browser, Windows Live ID, the Windows Live API Service, your site and so on all communicate with each other. In later sections we’ll talk about how most of this is wrapped up in the OAuthWRAPCallback assembly plus some javascript libraries. It’s useful to understand how the elements communicate with each other before understanding what the libraries and Windows Live tags do. Even though this means you’ll have to live with a degree of ambiguity until you understand more – but stick with it, it is better this way.

First, a protocol diagram:

Figure 3: OAuthWRAP protocol exchanges in Messenger Connect

Each element is numbered 1 – 17. At the end of this, the browser will have cookies that represent security tokens. Your web site will take these cookies, convert them to tokens and use them to access, for example, Windows Live profile information, or contact information.

1. The web browser connects to your site.
2. The web browser loads a page that contains a “Connect” button. Embedded in to this button is the client ID you obtained when you registered your application, the callbackURL you registered, a thing called the client scope (basically a permission type that will be covered later) and optionally, client state information.
3. Clicking the button causes the browser to see if it has already gone through a consent process by checking for a consent cookie. In this case we assume no consent cookie is present.
4. This causes the browser to go to a special page on Windows Live called the “Windows Live Consent page”.
5. The consent page prompts the user for credentials, but also, importantly asks the user “are you happy to be providing this site, with the following information”. The consent page looks like this:
   

   Figure 4: Windows Live Consent Page

   …clicking the “what will I share” link, shows something similar to the following:

   

   Figure 5: What you will share

6. At the same time, the consent page gathers up the client ID, scope, callbackURL and state, and makes a call to the Windows Live ID Authentication URL.
7. Windows Live ID is what is asking for the Live ID and password.
8. Because the user typed the credentials in to the consent page and they were accurate…
9. …Windows Live ID validates the password against the Windows Live ID and sees a genuine user. It now generates a short lived verification code and records this fact against the specified Windows Live ID in the back-end database.
10. Windows Live ID generates an HTTP 302 redirect to the callbackURL (which it obtained in step 6)
11. The verification ID, client ID and client state are passed to the callbackURL.
12. It’s the callbackURL that has access to the client secret (the one that was generated by http://manage.dev.live.com when you registered your site. Remember the screenshot in figure 2?). The code for the callbackURL is provided in an assembly as part of the Live SDK. The assembly checks in web.config to retrieve the secret which must match exactly the secret stored at manage.dev.live.com. Although it might appear to be a security risk to store sensitive information like this in a file on a web server, by default IIS request filtering protects this file. Of course though, if someone manages to find an exploit – there is your client secret for all to see. I’ll talk about a solution to this problem later.
13. The client secret is checked to make sure it matches the one stored against the specified client ID. The short-lived verification code is checked to see if it has expired yet. This is a simple protection against replay attacks. 2 tokens are now generated: the refresh token, which is long lived – 8 hours – and the access token, which has a short life. The names of the tokens are something of a give-away. You use the refresh token to get new access tokens when they expire. There is no need to re-trace every step, including authentication, to renew an access token. Simply supplying a refresh token returns a fresh access token. Say if the access token has a life of 10 minutes, it means if a Windows Live user makes a more restrictive edit to their profile, it will only be a maximum of 10 minutes before requests are no longer honoured. Of course, if the client application already has a copy of the data, then there is nothing Messenger Connect, the OAuthWRAP protocol or indeed the original owner of the data can do about that. Once past initial disclosure, it is not possible to destroy data that is now in somebody else’s hands. These tokens are stored in Simple Web Token format. Recall the description in the Part One post which shows how the tokens are additionally protected by encryption and signing, and remember this requires the creator and consumer of the tokens to go through a certificate exchange which involves the exchange of public keys.
14. The access and refresh tokens are returned to the callbackURL along with expiry information.
15. The callbackURL forwards the tokens to your web site.
16. Your website uses a process to copy the token contents in to a collection of cookies.
17. The cookies are returned to the browser. Although you might expect the site to keep copies of the tokens and maintain state between the browser and the tokens, in this case, the tokens are effectively stored in cookies on the client. They are session cookies, not long-lived cookies, so when the browser is closed, the cookies are destroyed. This means to get them back again, the process has to be re-traced in its entirety. The reason for doing this is because the code that runs on your site is a very clever javascript library. Storing cookies in the browser like this makes it possible to perform apparently complex state operations entirely in client-side code.

In Part 3, we’ll have a look at how the tokens are passed to the Windows Live API Service and the data retrieved. Then in subsequent parts we’ll look at some code and show how the various pages and services link together. I’ll cross reference the code that runs with the protocol diagram so you should be able to work out what’s going on.

Stay tuned, Planky

_______________________________________________________________

Thanks Planky! You can check out Planky’s blog here.

Go over to Kodak.com and read the full story about the invention of the digital camera.

In the meantime, if you fancy getting around London on the new Barclays sponsored bikes for hire but have no idea where to find them, 18 year old Daniel May has developed an application to help you find the nearest cycle hub based on your location. Sounds good to me!

CycleHubs WP7 preview from Daniel May on Vimeo.

Dunno about you but can’t wait to get my hands on one of those phones…

3D might be the next big thing in film, but is gaming a step too far? Gaming giants bet on 3D for next big boost – my bet is on 3D gaming reaching its peak in 5 years when we may have got around the need for glasses… ‘not’ (yet)

New Standard Hopes to Unify Your Address Book – in a post by Steve Plank we describe being able to manage all your social media accounts in one place – Messenger. The WC3 has recently published a draft of the contacts API to provide a unified address book of contacts, offering a way of standardising the way contacts are managed so individuals have more control over what applications use your data. Hmmm…. I’m too old not to care about privacy, so it’s definitely ‘hot’ IMHO!

Got a brilliant start-up idea but don’t know what to call it? .Dot.Com.Roulette does. Is this the start of a new naming convention? Might rely on roulette to name my pets! ‘Hot’.

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 3^rd 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!