Dbus service for maintaining users' online accounts

[Marina Zhurakhinskaya <marinaz redhat com>]

Hi!

We are planning on moving the Bigboard accounts system to a stand-alone 
Dbus service that other applications can use to collect and retrieve web 
accounts information. Here are some details of our plan. 

The org.gnome.OnlineAccounts service will centrally manage all web 
accounts supplied by the user and store them in a GConf directory, for 
instance under "/desktop/gnome/online-accounts". It will also store 
account passwords in the GNOME Keyring. The applications should not need 
to know the exact details of how and where the accounts and passwords 
are stored in GConf and GNOME Keyring, since the basic functionality of 
the OnlineAccounts system would be to put accounts information into 
GConf and GNOME Keyring for the applications and retrieve it from GConf 
and GNOME Keyring to supply it to the applications. Within the 
org.gnome.OnlineAccounts service, there will be an object for central 
management of all accounts at /org/gnome/OnlineAccounts and objects 
representing individual accounts at paths such as 
/org/gnome/OnlineAccounts/OnlineAccount/1.

While OnlineAccounts system will provide methods for adding and removing 
accounts that the applications can use as the backend for their own UI, 
we will encourage using the dialog provided by the OnlineAccounts system 
for collecting information about user accounts. This dialog will have 
two modes -- one containing all the account types and another one 
containing only the account types specified by the application. So a 
photo application would be able to request only the types of photo 
accounts that it handles to be listed for the user to edit and add new 
ones. In addition, the version of the accounts dialog that contains all 
the account types will be available to the user at all times through the 
Desktop Preferences.

Take a look at the attached screen shots of the current accounts dialog 
in Bigboard to see how the accounts dialog might look.

When the account is added, removed or disabled, this information will be 
propagated to all applications. Therefore applications should use the 
remove and disable account functionality very cautiously and inform the 
user that this will remove or disable the account from the centralized 
list of user accounts. If it makes sense for an application to maintain 
a private status of a certain account as being disabled, it should be 
done so by the application, along with maintaining other properties for 
an account it might find useful. The key service of the OnlineAccounts 
system is to centralize the maintenance of the user credentials for an 
account, i.e. the username and the password, as well as the desktop-wide 
status for an account as enabled or disabled. The reason for restricting 
OnlineAccounts system to just that level of service is that this will 
allow to maintain a consistent state for the user, while applications 
can let the user disable accounts through their own UI and make it clear 
to the user that the disabled status is for the given application only.

The accounts will be backed up online at online.gnome.org whenever the 
online.gnome.org identity is available for the desktop user. When 
accounts are being set on the server, we might run certain checks to 
verify the validity of the submitted usernames, such as verifying the 
url for the account exists. The accounts dialog might display an error 
to the user if the username was not saved or a warning if the username 
was saved, but the account is in the private mode and that might limit 
applications' access to it. If applications are adding accounts 
directly, without using the OnlineAccounts system dialog, they should be 
prepared to handle such feedback.

The set of account types will be maintained at online.gnome.org and will 
be extensible with application developers being able to enter new 
account types and information about them. A web interface for adding and 
editing account types will be available on online.gnome.org. Dbus 
service and clients will use a short name for an account type submitted 
through online.gnome.org to identify the account type. A combination of 
the account type string and the username for the account will uniquely 
identify an account.

While password entry will initially be shown for all account types, in 
the future we might provide a dialog mode that allows entering accounts 
of certain types, but does not ask for passwords. Such dialog would be 
useful if an application does not require user passwords for the online 
accounts it works with.

Dbus methods and signals exported by the OnlineAccounts object:

methods:
GetAccounts() -- returns object paths of all accounts available for the user
GetAccountsWithTypes(types_list) -- returns objects paths of all 
accounts available for the user with given types
GetEnabledAccounts() -- returns object paths of all enabled accounts 
available for the user
GetEnabledAccountsWithTypes(types_list) -- returns objects paths of all 
enabled accounts available for the user with given types
GetOrCreateAccount(type, username) -- returns a tuple with an object 
path for the account as the first element, and a boolean indicating if a 
new account was created as the second element
RemoveAccount(account_object_path) -- removes account at the given 
object path, removes it from online.gnome.org account for the user if 
one exists
OpenDialog() -- opens the dialog with all accounts provided by the user, 
where the user can enter passwords for the accounts, disable, or remove 
them; the dialog also has a way for the user to add accounts of all 
known types
OpenDialogForTypes(types_list) -- opens the dialog with accounts of the 
given types provided by the user, where the user can enter passwords for 
the accounts, disable, or remove them; the dialog also has a way for the 
user to add accounts of the given types

signals:
AccountAdded(account_object_path) -- emitted when a new account is added
AccountRemoved(account_object_path) -- emitted when an account is removed
AccountEnabled(account_object_path) -- emitted when an account is 
enabled, including when a new account is added
AccountDisabled(account_object_path) -- emitted when an account is 
disabled, including when an enabled account is removed

Note about signals: if an application is using GetEnabledAccounts() 
function to get the accounts, it should connect to AccountEnabled and 
AccountDisabled signals, but not AccountAdded or AccountRemoved signals.

Dbus methods and signals exported by the OnlineAccount object:

methods:
GetType() -- returns the account type
GetUsername() -- returns the account username
GetPassword() -- returns the account password
GetEnabled() -- returns enabled boolean status
SetPassword(password) -- sets the account password
SetEnabled(enabled_flag) -- sets a desktop-wide enabled status, but the 
setting does not affect online.gnome.org user account or other desktops 
used by the user

signals:
Changed() -- emitted when account's password or enabled status changes

New server object GnomeExternalAccountType will be added as a field to 
ExternalAccount and will have the following fields. We will prime the 
system with all the external account types that are currently specified 
in Mugshot.

externalAccountType (one of the types defined for Mugshot and either 
ExternalAccountType OTHER or None)
shortName -- a short name that must be unique
fullName -- a full name for the account type, such as "Remember The 
Milk", while the short name might be "rtm"
siteLink -- a link to the site that can provide you with this account
siteUserInfoType -- what is used to identify the user for that service 
(username, e-mail, etc.)
maintainer_id -- online.gnome.org id of the user who added this account 
type, and can remove it if there are no accounts of that type in the 
system or edit certain fields, such as externalAccountType, prettyName, 
siteLink, and siteUserInfoType

Any feedback is welcome!

Marina