Given what I've read about the Google policy (and I don't know how much of that was added with the Jan. 15 revision), but it seems like the very concept of GOA as a centralized account repository goes against Google rules. Google wants to know by whom the OAuth key will be used, and how. Under an open system where any third-party can implement access to GOA, GNOME cannot be able to tell Google about the use of the key (which is part of what they're asking in their request, as the ansible issue presents <
#2>).
Therefore GOA *needs* to change somewhat. At the very least, it cannot let third-party applications use the GNOME OAuth key to access Google APIs. This would be fine, however I don't think having a conceptual exception for Google is particularly good.
I see two ways to approach a hypothetical re-design of GOA.
A first way would be to put GOA as the authentication backend of the system itself (considering core apps as part of the system), and close access to third-party. This effectively is a regression on usability since having a centralized authentication system does make life (ever so slightly) easier for both users and developpers.
A second way would be one pretty much inspired from Android. In Android, apps that want access to the users' Google account simply contact the backend with an authentication request. Since Android phones are almost always linked to a Google account, the user only sees an OAuth confirmation prompt (the prompt outlining which services will be granted access to the app) which links the application's key to the account.
In GOA, this could work in a similar way: If a Google account is already present, GOA presents an OAuth confirmation dialog that grants access to the application. At any point, GOA doesn't know about which apps have been granted, because in the case of OAuth applications the role of access control is left to the account.
For non-OAuth applications, the logging in and access control is left to GOA (a simple enable/disable access to this app should be sufficent, the same way it works for location and notificatio access), but the workflow is the same.
In the second case, on top of having a more flexible GOA, it would provide real value to users and developers by having GOA continue being an open service that both reduces boilerplate and provides a centralized place to manage accounts. The downside is that this implementation is going to need work and maintainship, which might be lacking*. This is what the first option answers directly: it strips down GOA so that maintaining it is less work.
Those are my 2cc on GOA as a whole, as I do see real value in keeping it there.
Nathan
* Yes, I realize I'm saying this while I'm all talk and no walk. However I am not confident in my ability to be part in such a complex project, even less writing code for it. I am however happy to help whenever and wherever I can.
