On Thu, 2013-07-11 at 17:07 +0200, Patrick Ohly wrote:
- Walk through specific flow for Google CalDAV and CardDAV,
the configure options needed to provide the keys and what the SSO
backend would get from SyncEvolution.
Let's consider a naive attempt to use Google CalDAV:
$ SYNCEVOLUTION_DEBUG=1 syncevolution --print-items --daemon=no
The commands fail with "403 Forbidden" and a rather unspecific
application/vnd.google.gdata.error+xml error which points towards the
need to register the app (see google-caldav.log, attached).
From that the client may conclude that it is dealing with a Google
service. But that could be misleading. For example, what if some other
service uses the same error format?
a bit more Google specific, but looking at the content of a help text
just doesn't feel right.
IMHO this boils down to the need to determine the authorization method
beforehand. According to
the following pieces of information are needed for OAuth2:
end point: https://accounts.google.com/o/oauth2/auth
redirect_uri: as registered for that client_id
Is the end point something that must be passed to (g)SSO or is it
something that it already knows? What "redirect_uri" should be used when
The information above could be provided to SyncEvolution at runtime in
a /usr/share/syncevolution/authentication/google-calendar.ini file. The
content of that file is determined by the packager. In addition, files
could also be searched for in
or /etc/syncevolution/authentication. That way, a user and/or system
admin could personalize or add services without having to recompile
To use OAuth2, the user would need to use:
username = gSSO+google-calendar:firstname.lastname@example.org
Note the extra "+google-calendar": that tells SyncEvolution to use the
"google-calendar" authentication method. How much it needs to know about
the method is open for debate - it could be treated as key/value store
whose pairs SyncEvolution simply passes through to the SSO backend
without caring about the content, or it could simply pass the string
itself to the backend and let the backend resolve it.
The password was empty above. It could also be set by the user, with the
expectation that the SSO backend then uses that instead of triggering
When used during "--configure", it could be used like this:
syncevolution --configure \
No peer config needs to be specified on the command line in this case (a
deviation from the current command line syntax!), instead the "foobar"
password and "john.doe(a)gmail.com" string will be handed over to the SSO
backend with the expectation that it'll store the password as securely
as it can for use later on.
At runtime, when given "username = gSSO+<service>:email@example.com",
SyncEvolution will ask the backend for the kind of authorization that it
needs to use. Possible options, depending on the actual <service> value
and the .ini file it references:
- traditional username/password, with both provided to SyncEvolution by
- OAuth2 access token
For service=google-calendar, then answer would always be OAuth2. For
service=credentials, it is username/password. Again it is open for
debate whether there really needs to be a credentials.ini file for that,
or whether just the string alone could have that special meaning.
When using an access token, SyncEvolution must be aware that it will
have to ask for another token when it gets authentication errors. Or how
else would it detect that the token expired?
Does this all sound reasonable so far? Can someone explain how that'll
map to APIs and functionality in gSSO and UOA?
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.