The key to an open social web is permissions. There is data we don’t want to share and data we do want to share, permissions let us create the appropriate barriers. Closed networks like Facebook have reasonably rich permission infrastructures but what about open networks? How should Google and Microsoft enable document sharing across Google Docs and Sharepoint Online? Sure WebDAV can handle the actual mechanics of listing out documents, editing, etc. But how do the permissions get put into place in an open manner directly between users of the two services? This is a hole in the standards infrastructure and it’s time to fill it.

Contents

Disclaimer

This article represents my personal opinions and only my personal opinions. Nothing in this article should be construed as representing my current employers opinions, actions, plans, or what have you.

1 Bring in the scenarios!

1.1 Notification that permission has been granted

Jane works at Big Corp international where she uses Exchange to maintain her work calendar. Jane wants to give her spouse, Lucy, permission to see her free/busy time so that Lucy can schedule events with Jane that won’t interfere with Jane’s work schedule. Jane sets up a permission for Lucy in her calendar granting Lucy permission to see Jane’s free/busy time. Lucy, who uses Yahoo Calendaring for her personal calendar, is notified by Yahoo that Jane has granted the permission and asked if she accepts the permission. Lucy accepts the permission and Jane’s free/busy time is displayed in Lucy’s Yahoo Calendar.

1.2 Asking for permission

Morgan is a vendor hired by Istvan’s company to help with a project. Morgan uses Google Docs to edit and manage documents while Istvan uses Sharepoint Online. To get the project done Morgan needs access to certain documents in Istvan’s Sharepoint. Morgan uses a permission request dialog in Google Docs to send a request to Sharepoint Online asking Istvan for access to Istvan’s Sharepoint. Sharepoint Online receives the request and shows it to Istvan who approves granting Morgan read/write access to a particular sub-directory in Istvan’s Sharepoint. Sharepoint Online then notifies Google Docs that Istvan has granted Morgan read/write permissions to a directory in Istvan’s Sharepoint. Google Docs notifies Morgan and displays the folder from Istvan’s Sharepoint as part of Morgan’s Google Docs workspace.

2 Breaking down the scenarios

Below I break the scenarios into what I think are the ’key’ actions. My suspicion is that if we can define reasonable ways to achieve each of these actions then the rest of the questions around how to implement the scenarios will more or less answer themselves.

2.1 Notification that permission has been granted

Identify the principal

In order to grant a permission Jane had to let Exchange Online know ’who’ Lucy is so that Exchange could transmit the permission to Lucy. What is the pointer used to identify Lucy to Exchange Online?

Describe the permission

What format did Exchange Online use to tell Lucy about the permission granted by Jane? What information is needed in the format?

Discover where to deliver the permission notification

How did Exchange Online figure out where to deliver the permission notification to?

Deliver the permission notification

What are the details of how Exchange Online delivered the permission notification, isn’t this just a spammers dream?

Utilize the permission

Assuming that Lucy accepts the permission how does she go about taking advantage of it?

2.2 Asking for permission

Identify the principal

How did Aahan tell Facebook that he wanted to ask for permission from Aanjay at Flicker? What is the pointer that Aahan used to identify Aanjay to Facebook?

Describe the permission

How does Facebook tell Aanjay about her father’s permission request? What is the format? What information is in the format?

Discover where to deliver the permission request

How does Facebook know where to deliver the permission request?

Deliver the permission request

What are the details of how Facebook delivered the permission request, isn’t this just a spammers dream?

My assumption is that if the permission request is granted then notification of this fact will be delivered in the manner specified in the previous section.

3 Addressing the scenario components

3.1 Identify the principal

The obvious answer would seem to be e-mail addresses. Jane types in lucy@yahoo.com (or more likely selects Lucy’s entry in Jane’s personal address book which then resolves to lucy@yahoo.com). Unfortunately e-mail addresses are lousy identifiers for a couple of reasons.

Late bound identifiers

Are identifiers that are resolved to a principal at time of use and are not guaranteed to always bind to the same principal. In other words, Jane’s spouse Lucy may have control over lucy@yahoo.com today, but who knows who might own lucy@yahoo.com tomorrow?

Non transferable

If Lucy decides that she no longer wants to use Yahoo and would like to move to another identity provider or even be her own identity provider there is no well defined way to achieve this goal with an e-mail address. Once the address is abandoned, that’s it. There’s no forwarding mechanism.

Not uniquely bound to an identity provider

It’s tempting to argue that when trying to interact with the identifier lucy@yahoo.com it makes the most sense to contact yahoo.com. But what to then make of folks like Live or Google who will let users create account with other identity provider’s e-mail names? For example, Lucy can create a Google account using her Yahoo address. So when typing in lucy@yahoo.com to give a calendaring permission does Jane mean Lucy’s calendar with Yahoo or Lucy’s calendar with Google?

These are all very serious problems but solving them will require introducing a new identity infrastructure. There are ways to make this new infrastructure work over the old one but the issues are complex and I think we should solve the easy problems before the hard ones.

So I’m going to assume that principals are identified by e-mail. Once we have that more or less working we can move on to the more difficult identity issues.

3.2 Discovery where to deliver the permission notification/request

So who gets notified that a permission has been granted? I suspect a key requirement is that we don’t mandate a single notification point for all services. In other words if I want to notify someone about a calendaring permission I should be able to do that at a different location than say an IM permission. That way services can be well factored and spread out. But this also means that there needs to be some mechanism to go from the principal identifier (an e-mail address) to the right address to notify for a particular service.

There is already a proposed solution for exactly this problem that we could, in theory, build on top of - Link-based Resource Descriptor Discovery (LRDD). But besides supporting no less than three different discovery mechanisms and throwing in XRD I think LRDD has is backwards. It assumes that one publishes all the data to be known about oneself. Besides wasting space this makes versioning and extensibility a nightmare. What if one supports four different types of calendaring protocol with various versions for each one? LRDD requires publishing the whole lot.

It’s tempting to argue that LRDD is easier to implement than a service since with LRDD one can, in theory, just publish a static file. But given the type and amount of data likely to be in a LRDD retrieved discovery file, the ’static file’ argument is, in my mind, a fiction. The data in a LRDD file will be dynamic and it will be maintained so it’s a service. Might as well treat it as one.

LRDD, besides describing what’s in the discovery file (e.g. the file containing the pointers to various services) also describes how to find the discovery file for a particular user when starting with an e-mail address. Specifically LRDD uses Web Host Metadata. But this is just another static file (using the XRD format that is also used in LRDD) that hangs off a well known address. Instead of using a request/response service (”here is the e-mail I’m looking for”, ”here is the address to go to”) It uses a static file that includes a templating language which one downloads and then locally feeds the e-mail address into the template which then spits out a URL.

So the LRDD process of going from an e-mail address to a service URL involves two steps. First one retrieves the Web Host Metadata that contains the pseudo-regular expression that one then downloads and ’runs’ locally to translate the e-mail address to a LRDD discovery file location. Then one retrieves the LRDD discovery file and from there finds out the service address.

Personally I think having a service at a well known location that one can send a request of the form ”I want to talk to the calendaring permission server for user X” and get back a response would be oodles easier to implement and reason about and involve one less hop.

But in any case, at least there is some existing work to start from.

3.3 Deliver the permission notification/request

In theory delivering the request or permission notification is easy enough, just POST some bit of XML or JSON and call it a day. But this is going to be a spammer/security nightmare. We need some authentication. But in this case we need to authenticate the sender, which is the service sending the notification and not the user who granted the permission. This simplifies things a bit and more accurately represents who the responsible parties are. (Note: For you WS-* heads, this is explicitly not an ’act as’ scenario)

For services with long standing relationship HMAC’s can be used to validate the POSTs by pre-arranging a shared secret. For ad-hoc scenarios I suspect we’ll want to use digital signatures and leverage the previous discovery mechanism to find the public key for a service. That way when a service receives a message it can validate the signature by checking the source service’s public key.

Another check against spamming/security attacks is to make sure to only process requests or permission notifications who are identified as coming from people the user ’trusts’, typically people in their address book. Yes, this leaves open the question of how to handle requests that aren’t from folks in the address book but most social networking systems already deal with this by asking users if they wish to receive requests or permissions from people they don’t have listed.

3.4 Utilize the permission

In the case of a permission notice the service receiving the notice will need the right information to use the permission on the user’s behalf. This is a classic OAuth use case so my guess is that we should just use OAuth access tokens in the permission notice and use the OAuth access pattern to exchange the access token for a request token (or whatever they are called this week) which is then passed into the actual service.

3.5 Describe the permission

This leaves the question (which I moved out of order because I actually think it’s the least interesting question) of what the actual permission notification/request looks like. My guess is that we should, again, rely on OAuth. It has a very simple format that can be easily adapted for the purposes of describing anything and it provides mechanisms for sending requests either over SSL or without. Again, no need to get fancy. The whole thing then becomes just another OAuth profile.

4 Conclusion

I think we have all the pieces to create a really powerful ad-hoc sharing infrastructure that can allow a user of any random kind of service to ask for or grant permissions to any user of any other service. This is what a real, open, social web is all about. So let’s get cracking!