Google last week put extensive documentation behind its effort to build a community of relying parties to jump start OpenID on the Web.
In fact, the company said the documentation incorporates everything it has learned about being an OpenID relying party, including a list of best practices.
Also included, was a demo of Google's OpenID relying party effort showing how it all might work. The demo was presented at last week’s IIW (formerly called Internet Identity Workshop). Google admits that the OpenID relying party effort still needs work, but is fishing for feedback.
Last spring, Eric Sachs, senior product manager for Google Security, said the company planned to become a relying party as a way to show others how it is done.
In September, Google began functioning as an OpenID relying party (RP) for Yahoo! users, and a day later revealed it had become a SAML RP for all of the services it provides to companies and schools via its premium Google Apps package.
Sachs showed last week that Google is making its greatest push to date on the OpenID relying party issue, and that the company has become the dominant vendor voice behind OpenID.
In short, without a Web site (i.e. relying party) to accept identities generated by Identity Providers (IdP) then the system has a fatal flaw. And as Murphy's Law would have it, setting up as a RP is much more difficult than becoming an IdP
Google’s move to educate those that can help fill the gap, however, is not without some holes, such as accommodating family members signing in from the same computer or end-users with multiple Google accounts.
And Sachs also mentioned some “creepiness factors” for end-users who might feel the system knows just a bit too much about them. Google is trying to engineer around those issues.
The bottom line is that OpenID still has a lot of growing pains before it streamlines into the overall landscape for consumer and enterprise identity. Last week at IIW, there was plenty of talk about OpenID Connect and OpenID Artifact Binding, topics for another time, but issues that no doubt will raise more questions as they help refine the technology.
For now, however, it’s likely a good strategy to remain standing on the bridge as there is plenty more water that will flow underneath.
In fact, Google included this disclaimer in its RP best practices: “The usability benefits of single-sign-on and federated login are powerful, but they can also create security and usability problems if implemented without understanding some of the tricky issues involved.