[OpenID] Google Removes Relying Party Pre-Registration

[David Recordon]

 From http://google-code-updates.blogspot.com/2008/10/moving-another-step-closer-to-single.html

Moving another step closer to single-sign on
Thursday, October 30, 2008
By Eric Sachs, Google Security Team
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081030/2d0447e0/attachment-0002.htm>