Re: GNOME Online Accounts 3.34 won't have documents support

[Emmanuele Bassi <ebassi gmail com>]

On Wed, 23 Jan 2019 at 16:41, Allan Day <aday gnome org> wrote:

Emmanuele Bassi <ebassi gmail com> wrote:
...
>> > This is because we never specified a way to get third party keys stored inside GOA as part of a process to get third party modules to it.
>>
>> If apps could provide their own keys that would certainly change the
>> picture (I didn't actually know it was a possibility.) It would also
>> change the nature of Online Accounts of course; it's always been
>> designed as part of the system, that's used by the system and the core
>> apps. Might take a little thought.
...
> We had a key store for web services API keys in Moblin/MeeGo, as part of libsocialweb, mostly because we couldn't have OEMs ship with Intel OTC keys, and OEMs didn't want to make their key public either. :-)
>
> Re-implementing that would not be hard, especially if we make it a prerequisite that new services must come with their own key. Additionally, it would let downstream vendors ship their own keys, if they are so inclined.

Thinking about this idea a little more, I wonder what the value would
be for users, over apps implementing online auth themselves.

The original goal of Online Accounts was single sign-in: it was to
avoid users having to repeatedly log into the same account, and to
avoid multiple apps from carrying the UI to do so. If apps provide
their own keys, then I assume that users will have to authenticate for
each key, so the main advantage to users wouldn't apply.

The way this was designed in Moblin was not for apps to ship secret keys for web services, but to have a semi-centralised way of shipping secrets for system integrated services; then you could get your single-sign-on platform. Think of it as a gsettings-desktop-schemas kind of scenario: a repository of the secrets, with the ability to override them on a per-OEM/per-installation basis.

Of course, if GNOME decided to remove a service, apps would still fall over; but for that case we could move the secret to a separate "external" repository that apps can depend on in a new release.

Alternatively, we could have priorities dictated by search paths, and apps could always install their secret at a lower priority than the system one; this way, if GNOME removes a service from GOA, it will fall back to the application's own secret without degrading the user experience further than "you now have to authenticate yourself when you use this app". This would also work for sandboxed apps, because then they could avoid the API break when the system's GOA changes capabilities.

Ciao,

 Emmanuele.

--

https://www.bassi.io
[@] ebassi [@gmail.com]