WebFinger, OAuth and Freebusy lookups

One of the more frustrating aspects of calendaring systems is that the freebusy lookups are all proprietary.  Meeting invitations can be sent from one system to another (assuming you know a time to meet).  However, it is not possible to lookup when someone from Lotuslive, someone from gmail and someone from Yahoo are all available to meet.  In the corporate space this type of scheduling is invaluable.

The format for looking up someone’s freebusy time is included in a standard that was completed in 1998, but they punted on all the hard stuff.  The hard bit, as I have mentioned before, is working out where someone’s freebusy is stored on the web and then authenticating with that store in a manner that can be verified. WebFinger and OAuth are now putting the complete round trip within spitting distance.

Below I’ll propose an approach to scheduling a meeting with my mom (who uses gmail) from LotusLive (which I use). I will be rob@robubu.com (but using LotusLive for my calendaring service) and my mom is mom@gmail.com.  We’ll also assume that my mom has told google that it can share her calendar free time data with any one in her contact list and that I am in her contact list.

  1. I head into my calendar service (on lotuslive), click on Add Event and type mom@gmail.com into the invitees list.
  2. LotusLive now uses WebFinger to lookup the different api services that google provides for access to my mom’s data along with the corresponding URL for the service.  The details on how this works are outlined here on Eran’s blog. At the end of this, LotusLive gets back a XRD document that looks something like the following.

    <?xml version='1.0' encoding='UTF-8'?>
    <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
        <Subject>acct:mom@gmail.com</Subject>
        <Alias>http://www.google.com/profiles/mom</Alias>
        <Link rel='http://portablecontacts.net/spec/1.0'
              href='http://google.com/api/people/' />
        <Link rel='http://ietf.org/icalendar/freebusy'
              href='https://google.com/api/calendar/mom/freebusy/' />
    </XRD>

    From this LotusLive can now determine that my mom’s freebusy endpoint is at https://google.com/api/calendar/mom/freebusy/.  It concludes this by looking for the link with a rel attribute of http://ietf.org/icalendar/freebusy

  3. If my mom had made her freetime calendar data public then LotusLive can simply retrieve the data from the URL, but to add to the complexity let’s assume that it requires authentication i.e. LotusLive needs to prove to Google that it has rob@robubu.com at the browser and then Google checks that rob@robubu.com is in my mom’s contact list. We’ll do something here very similar to what signed fetches do in opensocial i.e. lotuslive will use OAuth to assert that it has rob@robubu.com at the browser. What we’ll end up with is a url that looks something like

    https://google.com/api/calendar/mom/freebusy/
    ?opensocial_viewer_id=rob@robyates.com
    &xoauth_public_key=https://lotuslive.com/keys/publickey.crt
    &ampoauth_signature_method=RSA-SHA1
    &oauth_signature=djr9rjt0jd78jf88%26jjd99%2524tj88uiths3

    LotusLive has here claimed that it has rob@robubu.com at the browser and using OAuth has signed the request with a private key.  It has also indicated where the public key is to validate the signature.

  4. Google receives the request, retrieves the public key and verifies the signature.  If it trusts signatures and keys from LotusLive (verifiable by retrieving certs from an https url with a lotuslive.com domain) then it is done at this point. However that is a fairly large amount of trust to place on LotusLive as LotusLive could assert on behalf of any identity. Google really needs to check that LotusLive can assert rob@robubu.com’s identity.  Here we’ll use webfinger again.
  5. Google now does a WebFinger lookup on rob@robubu.com and gets an XRD document such as the one below

    <?xml version='1.0' encoding='UTF-8'?>
    <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
        <Subject>acct:rob@robubu.com</Subject>
        <Link rel='IDP' href='    https://lotuslive.com' />
    </XRD>

    Google now sees that lotuslive.com is a valid Identity Provider for rob@robubu.com and so accepts the assertion.

  6. Google checks that rob@robubu.com is in my mom’s list of contacts and as I am returns her freebusy.
  7. Finally, LotusLive gets a response from Google outlining my mom’s free time and displays it in a nice calendar.  I can choose a time that she is free and send her an invite.

I know this is not perfect and I know there are probably a fair amount of changes that are needed, but I wanted to jot down something that, I think, is fairly close to a workable solution.  Am very interested in other’s thoughts.

p.s. WebFinger on email addresses does provide a means of discovering valid email addresses, but no where near as much as this does.  The fight against spam can’t center on not making email addresses discoverable.

10 thoughts on “WebFinger, OAuth and Freebusy lookups”

  1. It is a nice goal to have some generic approach like this that could work for any mail provider to any other mail provider. Some comments:

    Gmail is allowing any user in contacts list to see your freebusy time. Fine, I am sure there is some variation of this that could work for all email providers providing it was clear to the end user.

    Rob needs to call gmail and assert his identity. Is Oauth doing anything other than verifying the call came from LotusLive? I guess it is also used to grant the access token which can then be used to make the freebusy call
    Is there a better mechanism for asserting identity that can be used such as OpenId or SAML. Can the OpenId/OAuth hybrid protocol be used except here it is 2 legged Oauth with openId assertion used to determine what the scope of the Oauth token is

  2. @Mark, yes there are many variations that could govern the business rule as to who is let in e.g. in an app like lotuslive it could be set at the org level.

    OAuth provides a means for LotusLive to assert to google its claim that it has rob@robubu.com at the browser. If there is trust between Google and LotusLive then no further checks are needed. If Google wants to check that LotusLive has the right to claim it has rob@robubu.com at the browser then it needs to check using WebFinger that LotusLive is authorized to make that claim.

    The problem that Openid and SAML have is that they have no bindings for HTTP calls. I think that this is going to be addressed as it looks like there is interest in building the next version of openid atop OAuth 2.0.

  3. I think this is freaking brilliant. There has been a huge hole in the calendaring protocols, and you’ve figured out how to fill it in, almost entirely, by putting two emerging protocols together. Seriously Brilliant.

    That said…… and you knew this was coming… I do have some concerns. Biggest among these is the immaturity of webfinger. You’re essentially talking about standardizing on the use of something that barely exists yet. We would have to put serious weight behind the webfinger effort to help it succeed, in part by participating in its evolution, but even more importantly by bringing the calendaring community in as supporters, and by helping shepherd webfinger through the IETF. (Even though most of the work will probably be done at calconnect, the documents will have to go through the IETF wringer.) Leadership in those venues would be a good thing for IBM to contribute.

    There are also some missing details about the format of the data that you receive about free/busy — are you basically thinking of this as a caldav proxy, with iCal coming back? Or something more XML-ish and probably not yet well-specified?

    Overall though… great idea!

  4. SAML does support HTTP binding.

    I think Webfinger is an excellent idea for step 2, discovering the feebusy endpoint. I am not so sure about it’s use in asserting identity and perhaps that is just because I don’t know the types of attacks that could be launched at steps 4/5.

    Wouldn’t a strong identity assertion protocol at step 4 negate the need for step 5 (binding issues aside)?

  5. @Nathaniel I am not sure the process by which WebFinger is becoming a standard. I can’t even find a mailing list about it. I will ask Eran on his blog. Maybe it will come out of the IETF OAuth group.

    On the format for the data, that is all in that spec from 1998. We could maybe change it if we wanted, but what exists with VFREEBUSY probably works for most.

    @Mark SAML does not have a binding for arbitrary REST api calls. It has a binding to http GET redirect or POST, but those are essentially browser basesd http bindings and not for general api usage.

  6. I conceptually like the proposal here. This is fantastic approach. In fact one could use this generic API calling mechanism to do things like get updates from linked-in/facebook, get location information and so on.

    It does make sense to use ‘OAuth-style’ calling for making these one-off calls to do free busy lookups without real token management etc. I am not familiar with webfinger. At this stage, I believe it would be good if we can optimize step 5 (webfinger lookup). If the user’s email is something like user@yahoo.com and the call is made by yahoo (call uses yahoo certificate), it won’t be necessary. Won’t it cover the most of the cases?

    Anyway.. I believe this is a great idea !

  9. Hi Do you have any sample project to access Google Oauth 1.0 API .
    if you have please send me .

    Thank you
    bharat singh

Leave a Reply

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