Let me write down some thoughts about how SyncEvolution handles
credentials and authentication, in particular with regards to web
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
(, ): 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
* 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
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
* 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  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
I can think of five different such backends:
* gSSO = glib-Single-Sign-On - https://01.org/gsso
* uoa = Ubuntu Online Accounts -
* goa = GNOME Online Accounts -
* user = traditional username/password setting, only needed in
cases where the username happens to start with one of the
* 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
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
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.