The plan for rolling out remoteStorage to Dutch universities

[Michiel de Jong]

On Sunday evening, Francois and I had a three-hour delay waiting for the train from FOSDEM to the Netherlands, which we used to brainstorm about how we should implement the remoteStorage service for Dutch universities.

We'll probably use CouchDB for the storage. This seems to be more mature, stable and robust than most available WebDAV servers.

We encourage universities to implement a BrowserID primary IdP on their domain, because it's a promising technology in its own right.

A lot of the universities (but not all) are already federated together in surfnet using a SAML network. It is possible to open a SAML dialog to replace the username/password login in the OAuth dialog.

BrowserID is useful both for discovery of the user address people want to use, without them having to type it explicitly, and for confirming that it's really them without them having to adopt a new password. The first thing happens on the application; the second thing happens in the OAuth dialog of the storage provider.

Puttling this all together, we think we should do the following:
- keep the 'Sign In' button on Libre Docs as BrowserID.
- if the user address is at a university that acts as a BrowserID primary IdP and correctly implements webfinger, then the user will be prompted by BrowserID to log in there, and by the time we get to OAuth, the user will thus already be logged in at their university, and will only have to click 'allow'.
- if there is no BrowserID but there is webfinger at the university, then the OAuth dialog will redirect straight to SAML, and when coming back from there, the user can click 'allow'
- if there is also no webfinger then we'll prime our centralized unhosted-users database (i called this 'fakefinger' in the code, see also https://github.com/unhosted/website/wiki/webfinger-fallback ) with the fact that users at that university have remoteStorage at surfnet, and the rest will be through OAuth and SAML as in the previous point.
- if the university supports no BrowserID, no webfinger, and also no SAML, then the user will get a second BrowserID login button on the OAuth dialog. it's not ideal to present a user with two BrowserID buttons in the same sequence, but this can be integrated into one button to 'sign in and allow' in one click, so that makes it a bit better.

so it's sort of a complement of BrowserID, webfinger plus maybe fakefinger, OAuth, and SAML plus maybe again BrowserID. i guess it's a bit hard to visualize, but it will look very natural once we put it all together, especially in the cases where we can use SAML to avoid the second BrowserID popup.

we're also talking to Terena on Thursday, about doing something for all European universities, and Melvin said he may be able to convince people at MIT to follow suit later this year if we do an attractive demo in the Netherlands (they are already providing the servers for http://opentabs.data.fm/ i think). Also, I met one of the people behind Greece's network of universities at FOSDEM - they already offer a per-student storage space, and were quite intrigued by the possibility of slapping a remoteStorage interface onto that.

[Sebastian Kippe]

Puttling this all together, we think we should do the following:
- keep the 'Sign In' button on Libre Docs as BrowserID.
- if the user address is at a university that acts as a BrowserID primary IdP and correctly implements webfinger, then the user will be prompted by BrowserID to log in there, and by the time we get to OAuth, the user will thus already be logged in at their university, and will only have to click 'allow'.
- if there is no BrowserID but there is webfinger at the university, then the OAuth dialog will redirect straight to SAML, and when coming back from there, the user can click 'allow'
- if there is also no webfinger then we'll prime our centralized unhosted-users database (i called this 'fakefinger' in the code, see also https://github.com/unhosted/website/wiki/webfinger-fallback ) with the fact that users at that university have remoteStorage at surfnet, and the rest will be through OAuth and SAML as in the previous point.
- if the university supports no BrowserID, no webfinger, and also no SAML, then the user will get a second BrowserID login button on the OAuth dialog. it's not ideal to present a user with two BrowserID buttons in the same sequence, but this can be integrated into one button to 'sign in and allow' in one click, so that makes it a bit better.

This doesn't sound like any 3rd-party developer will be able or willing to develop apps compatible with the SURFnet action. No?

[Sebastian Kippe]

we're also talking to Terena on Thursday, about doing something for all European universities, and Melvin said he may be able to convince people at MIT to follow suit later this year if we do an attractive demo in the Netherlands (they are already providing the servers for http://opentabs.data.fm/ i think). Also, I met one of the people behind Greece's network of universities at FOSDEM - they already offer a per-student storage space, and were quite intrigued by the possibility of slapping a remoteStorage interface onto that.

I think it's critical that we have an easy-to-develop-for relatively final concept right from the start. If not, there won't be much more than LibreDocs and although that may be a good demo, it's not enough to make users love the whole thing. We need more apps, and that means we can't use 5 different login procedures. If some universities don't support the primary one from the start, why not e.g. roll out slower and just wait until they do?

[Michiel de Jong]

Hi Basti,

On Tue, Feb 7, 2012 at 11:23 AM, Sebastian Kippe <sebasti...@gmail.com> wrote:

I think it's critical that we have an easy-to-develop-for relatively final concept right from the start. If not, there won't be much more than LibreDocs and although that may be a good demo, it's not enough to make users love the whole thing. We need more apps, and that means we can't use 5 different login procedures. If some universities don't support the primary one from the start, why not e.g. roll out slower and just wait until they do?

From the app's point of view, all this will be hidden behind the OAuth dialog.

In fact, today we talked about another small change:instead of a BrowserID signin button like on Libre Docs, we would have a text input where the user already types their email address. This is then passed to the BrowserID call. This is the flow used on for instance http://myfavoriteshow.org/
The reason for this is that we will not always be needing BrowserID on the application side. If OAuth is needed, then BrowserID sign in will happen only on the storage provider, and not on the application.

We're prototyping this and want to present a first prototype of the login flow at Terena TF-Storage on Tuesday:

http://www.terena.org/activities/tf-storage/ws12/agenda.html

Then we have 3 months for https://tnc2012.terena.org/ in Reykjavik, where we will have a a Birds-of-a-Feather session about Unhosted, and will hopefully present a working demo of logging in to Libre Docs with a Dutch student account, so that other countries can understand that this is an example they want to follow. After that, world domination will be imminent. ;)


Cheers,
Michiel