Google had the following goals when designing this protocol:
Single approval page for OpenID and OAuth: Many large E-mail providers have become OAuth SPs, and are also experimenting with being OpenID IDPs. However currently the protocols are not integrated, so that if an RP/consumer website wants to both verify a user's identity, and get delegated access to their data at the SP, they have to use two separate process that require numerous redirects between the RP/consumer and IDP/SP. For example, imagine that a photo editing site like Picnik wants to simply have a button on their homepage for Flickr/Yahoo and another for Picasa/Google where the user who clicks one of the buttons is bounced to the selected site, for example Yahoo. If the user has never used Picnik before with Flickr, then Yahoo would ask the user if they were willing to share their identity with Picnik AND they would ask if the user was willing to give Picnik access to their photos. If the user had previously given that approval, and went to Picnik's website, then they could click the Flickr/Yahoo button, and when they were redirected to Yahoo, then Yahoo could detect that the user had previously given their approval, and could redirect them back to Picnik with confirmation of the user's identity.
Easy registration for consumer applications: Google has supported a version of OAuth called AuthSub before the OAuth protocol was created. The majority of 3rd party access to AuthSub is done without registration by the consumer website. Many of those 3rd party sites are also behind firewalls at companies who are prototyping their integration with Google's REST APIs. Depending on the level of registration/security used by the consumer website, Google's displays different types of warning messages to the user on the access approval page, including information on how confident we are in the identity of the website who is requesting access. Google needs to continue to support these scenarios, but would like to do so in a way that is as close as possible to OAuth while providing similar or better security then AuthSub. The goal here is to have reasonable security based on the target of the redirect sent to the user's browser, with additional security possible based on proof of domain ownership.
In developing proposed solutions for these business goals, we also had the following technical goals
Long lived secrets never hit the browser
Stateless consumers/RPs that cannot store or distribute long-term secrets should be supported, with increased warning levels to the user to indicate reduced confidence in the identity of the RP when appropriate.
Support the exchange of long-lived tokens for shorter lived sessions to both improve security, performance, and scalability.
Reuse OAuth and OpenID as much as possible, and try to only extend them, not modify them. In addition, be backwards compatible with OAuth and OpenID if at all possible.