Restricted inter-application access

From Arnout Engelen

Sometimes you'd want to give a (web)application partial access to your data at another (web)application: for example I can imagine I'd want to allow some applications (but not everyone) to look at my free/busy time in google calendar.

OAuth looks like a good way to achieve the authentication side of this issue.

After authentication, there still needs to be some format in which the data is actually exchanged. I suppose this could be application-specific - for example for exchanging contacts there'd be portablecontacts (draft spec)

See also:

• people talking about this problem in case of podcasts
• article about this problem in RSS for libraries
• specifying restrictions on redistributions in RSS/ATOM
• opensocial must have this problem, i wonder if (and if so, how) it addresses that.

I imagine application X would redirect me to a special page at Google Calendar where I'd log in and configure the level of access, after which google calendar would generate some credentials for application X to use so with those credentials application X would get restricted access to my google calendar data

I suppose the problem can be sliced up as follows:

• Communicating to the Content Repository (e.g. Google Calendar) that application X would like access on behalf of user A.
• (user logs into Content Repository, configures access for application X and any restrictions)
• Communicating the credentials with which Application X can access the Content Repository on behalf of user A to the Content Repository.

And finally:

• Application X using these credentials to access user A's content in the Content Repository

[edit] application X would like access on behalf of user A

Perhaps this could be done with a XACML redirect?

[edit] Communicating the credentials back to the Content Repository

Can we use some XACML reply? Not sure.

[edit] using these credentials to access user A's content in the Content Repository

This should maybe be free, but HTTP BASIC AUTH seems to be a reasonable default (don't forget to use SSL though, otherwise username/pass get sent over in plaintext).

This allows application X be written largely in AJAX/Javascript, see here.

The username/password can, but don't neccecarily have to be checked by Apache: it can also just pass on the password for the application to process.