Hello! Let me write down some thoughts about how SyncEvolution handles credentials and authentication, in particular with regards to web services. The most pressing need to do something about this comes from Google's move away from username/password-based authentication towards OAuth2 in CalDAV/CardDAV. By September there needs to be a SyncEvolution which supports that, because by that time Google will turn off the old method. Another motivation was mentioned in a previous discussion of that topic ([1], [2]): username/password sometimes must be set multiple times in the current config. Whatever we do about this, let's consider a few things: * Some services, in particular SyncML, only work with username/password, so SyncEvolution needs a way to retrieve both. * Other services, in particular Google CalDAV/CardDAV, depend on an OAuth2 based mechanism. SyncEvolution needs to recognize this, possibly after trying to use them, and then retrieve the necessary token from an OAuth2 implementation. * OAuth2 grants access to clients, which identify themselves with a key. Abuse of that key may lead to blacklisting that key and thus preventing access to the service. Possibly the creator of that key will also be banned such that he or she cannot create new keys. For SyncEvolution that means that sharing the same key with everyone is a bad idea. Whoever compiles SyncEvolution should at least have to make a conscious choice about which key he uses. For binaries that I publish on syncevolution.org, a key for Google needs to be included. There's no effective measure for keeping that key secret, so I might as well publish it on syncevolution.org and allow individuals to use it when compiling SyncEvolution for themselves. * Part of the initial usage of an OAuth2 based service is a dialog via a web browser where the web service confirms that access should be granted. In that case, the password for the service is only handed to the web server, not to SyncEvolution itself or the entity handling OAuth2. Of course, because the password typically gets entered on the local computer, this is still not perfectly secure. * Some users therefore won't care that much where they enter their password. Quite the opposite, entering the password in advance is useful in cases where such an interactive login is not possible or difficult, for example on a server where X is not running or which has no web browser installed. * In some cases, a pop-up asking for OAuth2 confirmation is desirable, sometimes it isn't. Need to define when to use it and when (and how) to fail with a authentication error. In [1] I proposed to introduce a new property that describes where username/password are stored. In retrospect I find that too limited and unnecessarily complex. Here's a different approach, based on interpreting the "username" value differently. So far, "username = <value>" had a username as it had to be given to a service as <value>. Let's extend that with one indirection: "username = [<sso-module>:]<identity>|<username>" <sso-module> is the identifier of some system which can provide more information about <identity>. There must be a SyncEvolution plugin which makes that system and its identifier known to SyncEvolution, similar to how src/backends/[kde|gnome] currently provide access to KWallet and GNOME keyring. I can think of five different such backends: * gSSO = glib-Single-Sign-On - https://01.org/gsso * uoa = Ubuntu Online Accounts - http://developer.ubuntu.com/resources/technologies/online-accounts/ * goa = GNOME Online Accounts - https://developer.gnome.org/goa/stable/ * user = traditional username/password setting, only needed in cases where the username happens to start with one of the prefixes above * id = a central identity managed by SyncEvolution "user" works without any additional configuration. The "password" property provides the password. OAuth2 is not supported. "id" enables sharing of credentials between different parts of a SyncEvolution config tree without depending on an external system. The <identity> string is the name of a normal peer config. Username/password can be stored for that peer as usual. It can even be used for syncing, if that is desired, but it is not necessary to do so. To mark a peer which is just used as a placeholder for credentials, "peerType=credentials" would be used. The GTK UI ignores all peers whose type it doesn't recognize (to be checked - at least that was the plan at some point). The "id" mechanism could be extended at some point to also support OAuth2 natively, perhaps using liboauth. "gSSO" and "uoa" use the same libaccounts-glib client library and different implementations on the server side. I've been told that some of these server-side differences leak through the common client API, so backends might be very similar, but not quite identical. Backends for "gSSO", "uoa" and will be expected to map the <identity>, a service identifier and a realm (or is it scope?) to a username/password combination (for a traditional login mechanism, similar to local password storage in GNOME keyring or KWallet) or the OAuth2 access token. For SyncML, the service identifier would be the sync URL. For WebDAV/CardDAV, it probably will come from the challenge sent by the server when it asks for authentication. The realm would be the string that Google uses to identify calendar or contact access. SyncEvolution must be aware enough of that mechanism to provide the backend with the client key that it got compiled with for the service and realm. TBD: passing valid username/password to the backend for later use, instead of prompting the user. Let me stop here for today. To do next: - Add usage examples for "id". - Walk through specific flow for Google CalDAV and CardDAV, including the configure options needed to provide the keys and what the SSO backend would get from SyncEvolution. My plan is to work on the infrastructure, a backend using gSSO/id and the OAuth2 usage in the CalDAV/CardDAV backend. Anything else would depend on outside contributors. Something else not in scope is automatic configuration, like automatically setting up syncing against all calendars or address books becoming available once a Google account is available in the central account system. Such functionality clearly would be useful, but it is also very system specific. Such functionality can be implemented by a plugin for syncevo-dbus-server, similar to how the PIM Manager (src/dbus/server/pim) runs inside the main event loop of the syncevo-dbus-server and sets up configs for PBAP syncing for IVI use cases [3]. [1] https://lists.syncevolution.org/pipermail/syncevolution/2011-May/002257.html [2] https://bugs.freedesktop.org/show_bug.cgi?id=52917 [3] http://comments.gmane.org/gmane.comp.mobile.syncevolution/4009 -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.