Andrew Olsen and Lily Xia of Google Engineering posted recently on developments of the increasingly more powerful Google Apps APIs:

Organizations using Google Apps can take advantage of our APIs to make Google Apps fit their unique businesses processes and technology environments.

Customers have pulled off some useful customizations, like synchronizing Google Calendar with Microsoft Exchange and updating email preferences for all of their users. Today we're making our Google Apps APIs even more powerful.

First, we're improving the API for Google Docs, which is now capable of updating the actual content of documents, sharing documents, and moving documents into and out of folders programmatically. You can learn more about this API here.

We're also making our APIs even more versatile. Domain administrators can now use OAuth authentication to access GData feeds for users on their domains. This lets admins do things like integrate

with document management systems, enable third-party workflow applications, centralize backup of documents and contacts, and monitor document sharing inside and outside of the company. Using OAuth, administrators can enable this type of functionality for end-users without any end-user involvement. Premier and Education Edition admins can enable OAuth in the 'Authentication' section of the 'Advanced tools' tab of the Google Apps administrative control panel.

 

>Original article

The Google Docs API is now capable of updating the actual content of documents, sharing documents, and moving documents into and out of folders programmatically.Editions impacted:Standard, Premier, Education, Team and Partner EditionsLanguages impacted:US EnglishHow to access what's new:Visit the Google Documents List Data API overview site to get started. (See link below.)For more information:

Eric Sachs reports:

Yesterday we announced one step we took to help increase adoption of single-sign on across websites on the Internet. For more details, you can watch today's episode of thesocialweb.tv which covers the launch. While we announced that we would initially provide limited access to our OpenID IDP to make sure it was working properly, we were delighted to see that the number of sites that registered to receive access was significantly more than we had expected. So instead of having our engineers spend time manually maintaining that list of registered sites, we are now taking another step further and removing that restriction so any site can use the API.

That registration requirement also led to some confusion because users wanted to be able to use existing websites that accept OpenID 2.0 compliant logins by simply entering "gmail.com" (or in some cases their full E-mail address) into the login boxes on those websites. Normally what would happen after a user typed gmail.com is that the relying party website would look for a special type of file (XRDS) on the gmail.com servers that would check if Gmail run an OpenID identity provider. For yesterday's launch, we specifically chose not to publish that special XRDS file on gmail.com because if we had published the file, users would have received an error at Google if the website they were trying to log into had not registered with us. Now that we have removed the registration requirement, we will work on pushing that XRDS file as quickly as possible. Once the XRDS file is live, end-users should be able to use the service by typing gmail.com in the OpenID field of any login box that supports OpenID 2.0, similar to how Yahoo users can type yahoo.com or their Yahoo E-mail address. (In the meantime, if you feel really geeky, you can type "https://www.google.com/accounts/o8/id" into an OpenID 2.0 compliant login box and see the directed identity workflow in action.)

However, as we we noted in the Designing a Login User Interface section of our documentation, we do not place any requirements on the design of a federated login box on a relying party website. There are many approaches used by websites today, and the community is still experimenting with new approaches.

One other question that a lot of people asked yesterday is when a large provider like Google will become a relying party. There is one big problem that stands in the way of doing that, but fortunately it is more of a technology problem than a usability issue. That problem is that rich-client apps (desktop apps and mobile apps) are hard-coded to ask a user for their username and password. As an example, all Google rich-client apps would break if we supported federated login for our consumer users, and in fact they do break for the large number of our enterprise E-mail outsourcing customers who run their own identity provider, and for which Google is a relying party today. This problem with rich-client apps also affects other sites like Plaxo who are already relying parties.

Google is committed to working on this problem. If community members also want to help in this area, please take a look at our research on combining rich-client apps with federated login which was discussed at the recent UX summit and discussed further in a blog post here. A key thing to notice is that this research is about another open source technology called OAuth, and is agnostic to the particular federated login technology used, i.e. SAML or OpenID. It is also agnostic to the type of strong authentication method (if any) that is used to authenticate the user.

To further increase the adoption of federated login, we need standard open-source components on as many platforms as possible to enable those rich-client apps to support OAuth. That includes a lot more platforms then just Windows and Mac. The harder part is mobile devices (Blackberry, Symbian, Windows Mobile, iPhone, and yes even Android), and other Internet connected devices like Tivos, Apple TVs, Playstations, etc. that have rich-client apps that ask users for their passwords to access services like Youtube, Google photos, etc. If the community works together to build these components, they will be useful not only to Google, but also to any other relying parties that have rich-client apps or that expose APIs, and it will also help enterprise SaaS vendors like Salesforce.

If you want to help further these efforts, join the OpenID and OAuth mailing lists and tell people which platform you are targeting in case others want to help. For example, Mike Malone from Pownce did some work a few months ago to use OAuth on an iPhone and described how he got it working. And just yesterday another member of the open source community, Sean Sullivan, built a working OAuth enabled rich-client app for Android and posted the open source code.
 

>Original article
 

By Eric Sachs, Google Security TeamYesterday we announced one step we took to help increase adoption of single-sign on across websites on the Internet. For more details, you can watch today's episode of thesocialweb.tv which covers the launch. While we announced that we would initially provide limited access to our OpenID IDP to make sure it was working properly, we were delighted to see that the number of sites that registered to receive access was significantly more than we had expected. So instead of having our engineers spend time manually maintaining that list of registered sites, we are now taking another step further and removing that restriction so any site can use the API.That registration requirement also led to some confusion because users wanted to be able to use existing websites that accept OpenID 2.0 compliant logins by simply entering "gmail.com" (or in some cases their full E-mail address) into the login boxes on those websites. Normally what would happen after a user typed gmail.com is that the relying party website would look for a special type of file (XRDS) on the gmail.com servers that would check if Gmail run an OpenID identity provider. For yesterday's launch, we specifically chose not to publish that special XRDS file on gmail.com because if we had published the file, users would have received an error at Google if the website they were trying to log into had not registered with us. Now that we have removed the registration requirement, we will work on pushing that XRDS file as quickly as possible. Once the XRDS file is live, end-users should be able to use the service by typing gmail.com in the OpenID field of any login box that supports OpenID 2.0, similar to how Yahoo users can type yahoo.com or their Yahoo E-mail address. (In the meantime, if you feel really geeky, you can type "https://www.google.com/accounts/o8/id" into an OpenID 2.0 compliant login box and see the directed identity workflow in action.)However, as we we noted in the Designing a Login User Interface section of our documentation, we do not place any requirements on the design of a federated login box on a relying party website. There are many approaches used by websites today, and the community is still experimenting with new approaches.One other question that a lot of people asked yesterday is when a large provider like Google will become a relying party. There is one big problem that stands in the way of doing that, but fortunately it is more of a technology problem than a usability issue. That problem is that rich-client apps (desktop apps and mobile apps) are hard-coded to ask a user for their username and password. As an example, all Google rich-client apps would break if we supported federated login for our consumer users, and in fact they do break for the large number of our enterprise E-mail outsourcing customers who run their own identity provider, and for which Google is a relying party today. This problem with rich-client apps also affects other sites like Plaxo who are already relying parties.Google is committed to working on this problem. If community members also want to help in this area, please take a look at our research on combining rich-client apps with federated login which was discussed at the recent UX summit and discussed further in a blog post here. A key thing to notice is that this research is about another open source technology called OAuth, and is agnostic to the particular federated login technology used, i.e. SAML or OpenID. It is also agnostic to the type of strong authentication method (if any) that is used to authenticate the user.To further increase the adoption of federated login, we need standard open-source components on as many platforms as possible to enable those rich-client apps to support OAuth. That includes a lot more platforms then just Windows and Mac. The harder part is mobile devices (Blackberry, Symbian, Windows Mobile, iPhone, and yes even Android), and other Internet connected devices like Tivos, Apple TVs, Playstations, etc. that have rich-client apps that ask users for their passwords to access services like Youtube, Google photos, etc. If the community works together to build these components, they will be useful not only to Google, but also to any other relying parties that have rich-client apps or that expose APIs, and it will also help enterprise SaaS vendors like Salesforce.If you want to help further these efforts, join the OpenID and OAuth mailing lists and tell people which platform you are targeting in case others want to help. For example, Mike Malone from Pownce did some work a few months ago to use OAuth on an iPhone and described how he got it working. And just yesterday another member of the open source community, Sean Sullivan, built a working OAuth enabled rich-client app for Android and posted the open source code.