Emmanuele Bassi <eba...@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 main other advantage that I can think of would be that it would make Online Accounts into a convenient place where someone can get an overview of apps using online accounts, although quite how compelling that is I'm not sure, particularly since it's not going to cover every app and account on the system. Allan _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
