[foaf-protocols] The issue of authorising access to private resources
benjamin.heitmann at deri.org
Wed Sep 8 18:48:02 CEST 2010
in this email I would like to start a discussion about how WebID can be used for authorising access to private resources,
and how this can be standardised.
I already had some very long and fruitful discussions with Henry about this, and he encouraged me to bring this topic up for discussion.
In the currently visible work about WebIDs (and FOAF+SSL), it sometimes seems like the assumption is that WebIDs are meant to be used with public FOAF profiles. This has one important benefit: It allows everybody to focus on the authentication aspect of the WebID protocol, because the authorisation part is less important in such scenarios with public data (everybody can access it anyway).
However, Henry (and probably many of you on this mailing list) have also thought about use cases where there is a distinction between private and public data:
1.) If you remember Henry's example of the "restful printing service" , then you have a scenario which would require granting access to specific resources to a third party service.
2.) If you think back to Henry's very first post  (AFAIK) about the FOAF+SSL idea, which contained a very strong distinction between the public and the private part of a FOAF profile.
Bring private profile parts or private resources in general into the picture, puts the need for a standardised authorisation flow for the WebID protocol into string focus.
Standardising an architecture for using WebID for authorisation would allow WebID to compete with OAuth.
As you might remember, OAuth (in 2 different versions) power the ecosystems of both Twitter and OAuth,
so this is a very relevant topic.
What are the common roles in the Twitter and Facebook eco-systems?
a.) hub site: there is only one central hub site, and it serves as a data silo (no portability)
b.) user agents: browsers or eco-system specific clients can be used by the user to interact with the main hub site
c.) 3rd party services: Foto printing services (e.g. Flickr for Facebook), or value added services like Twibbon (for Twitter) have to ask the user for permission before they can access his data from the main hub site.
Why should the authorisation aspects of WebID be standardised ?
1.) This would allow WebID to enable a universal eco-system built around portable and private user profiles instead of closed data silos.
WebID could be used to replace OAuth.
2.) If the roles and the communication flow for using WebID for authorisation get specified then we can say that any implementation of the WebID protocol can operate with any user agent, profile hub site or personal profile storage site, and any third party service.
As you may recall, if you implement a client for the Twitter OAuth implementation then it is not compatible with Facebook OAuth or Google OAuth,
and vice versa.
3.) The printing service and Julia/Romeo examples show enough aspects of private resource authorisation which can be implemented in different ways.
So right now there is a real danger that using WebID for authorisation without clear standardisation will lead to incompatible implementations.
Some aspects which could be implemented in multiple ways:
* how to model private resources? Use different URIs for private and public profiles? Or use the same URI and then return different contents based on the credentials. Or something completely different?
* how to tell a 3rd party service which resources he can access? Drag and drop between browser windows or some sort of pingback.to ? Or something completely different?
So that is the reason, why I would like to get some feedback on the authorisation aspect of WebIDs.
If you (the community) agree that this is an issue, then I will probably go ahead and create a wiki page for the following:
* test cases and use cases
* experience from existing and emerging implementations of the authorisation aspect
* a collection of the different issues which need to be standardised in a wikipage.
More information about the foaf-protocols