[OpenID] When will Google become a relying party...
esachs at google.com
Wed Oct 29 17:47:29 PDT 2008
This message is being sent to both the OpenID and the OAuth mailing lists.
As you have probably heard, Google's OpenID IDP is now live (for details
though for a short period of time we are requiring RPs to register before
they use it, so we do not yet support automatic discovery.
Of course, I expect one other question a lot of people will ask is when
might a large provider like Google become a relying party. Unfortunately
there is one big, Huge, ENORMOUS PROBLEM! However it is fortunately mostly
a problem of technology, and not as much usability. That problem
is rich-client apps (desktop apps and mobile apps). All those Google
rich-client apps would break if we supported federated login for our
consumer users, and in fact they do break for our enterprise E-mail
outsourcing customers who run a SAML IDP, 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.
If community members want to help in this area, please take a look at the
research link below which we briefly discussed at the UX
A key thing to notice is that this research is about 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.
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 we build these components,
they will be useful not only to Google, but also to any other relying
parties which have rich-client apps or exposes APIs, and it will also help
enterprise SaaS vendors like Salesforce.
If you want to help, send mail to the OpenID/OAuth mailing list to tell
people what platform you are targeting in case others want to help. For
example, Mike from Pownce did some work a few months ago to use OAuth on an
iPhone and described<http://immike.net/blog/2008/09/08/oauth-on-the-iphone/>
he got it working. Google has been working on a Windows C# implementation
as described in that research documentation, so let us know if you want a
copy of the code. Once you have identified a platform, then try to build an
OAuth client app that accesses any OAuth enabled API from a vendor which
supports OAuth today.
One such OAuth vendor is Google. For documentation on our OAuth support,
see http://code.google.com/apis/gdata/auth.html#OAuth. However, you will
notice that documentation only talks about web applications, and not
rich-client applications. Google still has some work to do so that we
properly support rich-client applications that want to use OAuth. For
example, today developers of a rich-client app will need to register a web
domain with us as the OAuth consumer, and then embed the OAuth Consumer
Key/Secret in your app. In addition, the OAuth approval page we show will
reference that website, instead of your app. The last key thing to note is
that if you tried to make your client app available to a large set (100s of
thousands) of end-users, the OAuth process on our side might break if a
large set of them try to signup at the same time.
We plan to fix those UI and scaling shortcomings in the coming months, as
well as probably support an anonymous Consumer Key/Secret since a commonly
installed application would otherwise have the Key/Secret embedded in the
code, and thus something a hacker could extract out of the app. But in the
meantime, you can work around these limitations to build prototypes.
You may also notice that the prototype in our Desktop App research uses a
Google proprietary API called
cases where the user is not authenticated via federated login. There
has been some interest in the community to create a standard for that type
of API using some parts of OAuth as well. So if you are interested in that
topic, please share your ideas.
Product Manager, Google Security
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the general