<span style="font-family:Verdana"><div style="margin-top:0px;margin-bottom:0px"><div style="margin-top:0px;margin-bottom:0px">This message is being sent to both the OpenID and the OAuth mailing lists.</div>
<div style="margin-top:0px;margin-bottom:0px"><br></div><div style="margin-top:0px;margin-bottom:0px">As you have probably heard, Google's OpenID IDP is now live (for details see <a href="http://google-code-updates.blogspot.com/2008/10/google-moves-towards-single-sign-on.html" style="color:rgb(85, 26, 139)" target="_blank">http://google-code-updates.blogspot.com/2008/10/google-moves-towards-single-sign-on.html</a>) 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.</div>
<div style="margin-top:0px;margin-bottom:0px"><br></div><div style="margin-top:0px;margin-bottom:0px">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.</div>
<div style="margin-top:0px;margin-bottom:0px"><br></div><div style="margin-top:0px;margin-bottom:0px">If community members want to help in this area, please take a look at the research link below which we briefly discussed at the <a href="http://sites.google.com/site/oauthgoog/UXFedLogin/09nov-uxsummit" style="color:rgb(85, 26, 139)" target="_blank">UX summit</a>. 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.</div>
</div></span><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><a href="http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps" target="_blank">http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps</a> <br>
</blockquote><span style="font-family:Verdana"><div style="margin-top:0px;margin-bottom:0px"><div style="margin-top:0px;margin-bottom:0px"><br></div>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.</div>
<br>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 <a href="http://immike.net/blog/2008/09/08/oauth-on-the-iphone/" target="_blank">described</a> how 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. </span><div>
<span style="font-family:Verdana"><br></span></div><div><span style="font-family:Verdana">One such OAuth vendor is Google. For documentation on our OAuth support, see <a href="http://code.google.com/apis/gdata/auth.html#OAuth" target="_blank">http://code.google.com/apis/gdata/auth.html#OAuth</a>. 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.</span></div>
<div><span style="font-family:Verdana"><br></span></div><div><span style="font-family:Verdana">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.</span></div>
<div><span style="font-family:Verdana"><br></span></div><div><span style="font-family:Verdana">You may also notice that the prototype in our Desktop App research uses a Google proprietary API called <a href="http://code.google.com/apis/gdata/auth.html#ClientLogin" target="_blank">ClientLogin</a> for 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.</span></div>
<div><span style="font-family:Verdana"><br></span></div><div><span style="font-family:Verdana">Eric Sachs</span></div><div><span style="font-family:Verdana">Product Manager, Google Security</span></div>
<div>
</div>