[OpenID board] upcoming Google announcement regarding OpenID

Will Norris will at willnorris.com
Thu Jul 9 19:02:00 UTC 2009


So it sounds like this was actually intended to go to the board- 
private list, but since it is public I'm going to throw in my two  
cents.  I talked with Eric about this briefly at the last IIW in  
March, and I'm happy to see that some of my previous concerns have  
been addressed.  Without seeing the actual discovery protocol  
document, I can't be sure what is being proposed, but based on  
previous conversations and what is mentioned in Eric's post here, I  
have a pretty good idea.

The way I understand it, the idea is that a relying party would  
attempt normal OpenID discover on the claimed identifier provided by  
the user.  If that was successful, then OpenID authentication  
continues as normal... nothing unusual here.  But if the relying party  
is unable to discover an OpenID provider through normal discovery  
means, they make an API call to Google asking if Google hosts OpenID  
services for that domain.  (As best as I can tell, the path of the  
claimed ID is ignored, and the domain must match exactly.  If Google  
hosts services for "example.com", then "https://example.com:8443/foo"  
would match, but "www.example.com" would not.  I'm sure the  
expectation is that users will simply enter "example.com")

Having spent two years at USC helping to build both the policy and  
technical side of their identity management infrastructure, I do have  
very strong reservations about Google's actual product.  But the more  
concerning matter is that the OpenID Foundation is being asked to  
endorse one specific vendor as THE fallback for OpenID discovery.  Now  
in practice, I'm not sure that there is anyone else offering a service  
like Google has.  I know JanRain has OPX, but I would imagine it uses  
traditional OpenID discovery... I'm not sure.

I understand that the existing discovery methods are a bit lacking.   
My primary focus for the past four weeks or so has been getting XRD to  
a Committee Draft which people can start implementing.  Google has  
been very active in that effort, and Eric mentioned that in his post.   
But endorsing a vendor-specific fallback in the meantime is absolutely  
not something the foundation should be doing.  While it is not set in  
stone that the next version of OpenID Discovery is going to use XRD,  
that seems to be the general consensus.  Publicizing this Google- 
specific discovery method, only to turn around in a couple of months  
and start promoting XRD, is going to create a lot of confusion with  
implementors.

-will

On Jul 8, 2009, at 11:05 AM, Eric Sachs wrote:

> Below are drafts of two blog posts we will make in the upcoming  
> weeks about
> the fact that we are now operating an OpenID IDP for the million+
> schools/enterprise/ISPs that are outsourcing their email to Google  
> Apps.  We
> would appreciate this not being circulated beyond the board until it  
> is
> public.  This new support required that we work with the community  
> to define
> some extensions to the OpenID discovery process.  While those  
> discussions
> have been going on in the community the last few months, those  
> extensions
> are not yet formalized and probably won't be until they are proven in
> production environments.  There is the potential for some community  
> members
> (or press) to assume (or at least imply in articles) some evil  
> intent by
> Google to co-opt OpenID with these extensions.  It would be nice to  
> have a
> blog post on the formal OpenID blog that was supportive of our  
> approach, so
> I wanted to see if the board members are comfortable with that.
>
> On a somewhat related point, I also expect this will further  
> increase the
> pressure on us as a community to find more scalable UI options since  
> the
> Nascar style approach obviously cannot include buttons for these  
> million new
> IDPs.  We have also just posted a set of summary UI guidelines that  
> we will
> be referencing from our API documentation at
> http://sites.google.com/site/oauthgoog/UXFedLogin/summary.  The goal  
> was to
> keep it to one-page which forced us to cut additional background
> information, but if you think we cut something critical, let me know.
>
> Enterprise blog: Google Apps + OpenID = identity hub for all your SaaS
>
> We are happy to announce that the Google OpenID Federated Login
> API<http://code.google.com/apis/apps/sso/openid_reference_implementation.html 
> >
> has
> been extended to Google Apps accounts used by businesses, schools,  
> and other
> organizations. The service is important not only to the individuals  
> in those
> organizations, who can interact with a variety of consumer websites  
> with a
> single credential <add link to Google code post>, but also to the
> organizations themselves, who are increasingly reliant on multiple  
> Software
> as a Service (SaaS) solutions from different vendors.
>
>
> For these organizations, Google Apps can now become an identity and  
> data hub
> for multiple SaaS providers. When integrated with partner solutions  
> such as
> XXX from XXX, the Google Open ID Federated Login API enables a  
> single Google
> Apps login to provide secure access to services like Salesforce.com,
> SuccessFactors, and WebEX, as well as B2B partners, internal  
> applications,
> and of course consumer web sites. See XXX's post <add link> to learn  
> more
> about their implementation and view the demo and case study <add  
> links>.
>
>
> Another early adopter is XXX, a SaaS project management vendor who  
> uses the
> new service to make it easier for any organization using Google Apps  
> to sign
> up for and deploy XXX o their users:
>
> < INSERT SCREEN SHOTS>
>
>
> Activating the OpenID Federated Login service for your domain is  
> simple and
> secure. To achieve that, we introduced a new experimental discovery
> protocol<http://groups.google.com/group/google-federated-login-api/web/openid-discovery-for-hosted-domains 
> >
> addressing
> some of the challenges with the current version (2.0) of
> OpenID<http://openid.net/specs/openid-authentication-2_0.html>
> :
>
>
>
>   - Reducing the hassle of hosting discovery documents on the domain
>   web-site - the discovery protocol offer a solution that allows a  
> hosted
>   domain to become an OpenID Provider without hosting any documents  
> at all.
>   Optionally, a domain may choose to host one simple file to support  
> a more
>   complete discovery flow.
>
>
>
>   - Being an OpenID Identity Provider requires strong security  
> protection
>   again attacks that could modify web pages on the site. To avoid that
>   requirement for businesses and organizations, we introduced digital
>   signatures on the discovery documents and a verification flow to  
> support
>   that.
>
>
> You can find more details in our
> API<http://code.google.com/apis/apps/sso/openid_reference_implementation.html 
> >
> and Discovery<http://groups.google.com/group/google-federated-login-api/web/openid-discovery-for-hosted-domains 
> >
> documentation,
> or join the discussions in the Google Federated Login API
> Group<http://groups.google.com/group/google-federated-login-api/web/oauth-support-in-googles-federated-login-api 
> >,
> where you can ask any question and get answers from with other  
> Identity
> Providers, Relying Parties and Google engineers.
>
>
> *The OpenID Federated Login Service is available for all Google Apps
> editions. However, it is disabled by default for the Premier and  
> Education
> and editions  , and it requires the Domain Admin to manually enable  
> it from
> the Control Panel. So Admins - go turn this today for your
> users<http://code.google.com/apis/apps/sso/openid_reference_implementation.html#cpanel 
> >.
> At Google.com - we already enabled it for our employees... *
>
>
> Google Code blog: Over a million new OpenID Identity Providers !We  
> are happy
> to announce that the Google OpenID Federated Login
> API<http://code.google.com/apis/apps/sso/openid_reference_implementation.html 
> >
> has been extended to Google Apps accounts used by businesses,  
> schools, and
> other organizations.  Individuals in these organizations can now  
> sign in to
> 3rd party websites using their Google Apps account, without giving  
> away
> their credentials. In addition to the value for the end-users, the new
> service also benefits the organizations themselves, who are  
> increasingly
> reliant on multiple Software as a Service (SaaS) solutions from  
> different
> vendors. For example, XXX is an early adopter, allowing any  
> organization
> running Google Apps to more quickly sign up for and adopt their  
> service:
>
> << INSERT SCREEN SHOTS>
>
>
> See our post on the Google Enterprise Blog <add link> to learn more  
> about
> the opportunities for the organizations.
>
>
> Supporting the API for Google Apps accounts is exciting news for the  
> OpenID
> community <http://www.openid.net/>, as it adds numerous new  
> trustworthy
> Identity Provider (IDP) domains and increases the OpenID end user  
> base by
> millions. In order to allow web-sites to easily become Relying  
> Parties for
> these many new IDPs and users, we defined a new discovery
> protocol<http://groups.google.com/group/google-federated-login-api/web/openid-discovery-for-hosted-domains 
> >.
> The protocol allows Relying Parties to identify that a given domain is
> hosted on Google Apps and securely access its OpenID Provider End  
> Point. The
> current proposal is an interim solution, and we are participating in  
> several
> standardization organizations, such as OASIS <http://www.oasis-open.org/ 
> > and
> the OpenID Foundation <http://openid.net/foundation/>, to generate a
> next-generation standard. Since the current protocol proposal is not
> supported by the standard OpenID libraries, we provided an  
> implementation of
> the Relying Party pieces at the Open Source project -
> step2.googlecode.com<http://code.google.com/p/step2/>.
> Google is also offering a set of resource addressing the issues of  
> designing
> a scalable Federated Login User Interface. You are welcome to visit  
> the User
> Experience summary for Federated
> Login<http://sites.google.com/site/oauthgoog/UXFedLogin/summary>
> Google
> Sites page, where you can find links do demos, mocks and usabilty  
> research
> data.
>
> Prefer an out-of-the-box solution? We have been working with
> JanRain<http://www.janrain.com/>,
> a provider of OpenID solutions, which already support the new API as  
> part of
> their RPX product <http://rpxnow.com/>. As demonstrated by
> UserVoice<http://uservoice.com/session/new>
> using JanRain's RPX <http://rpxnow.com/>, a user simply types in her  
> Google
> Apps hosted domain name in the OpenID login box and everything else  
> is being
> taken care of:
>
>
> <Add UserVoice (or other proposed RPX website) screenshots>
>
>
>
> You can find more details in our
> API<http://code.google.com/apis/apps/sso/openid_reference_implementation.html 
> >
> and Discovery<http://groups.google.com/group/google-federated-login-api/web/openid-discovery-for-hosted-domains 
> >
> documentation,
> or join the discussions in the Google Federated Login API
> Group<http://groups.google.com/group/google-federated-login-api/web/oauth-support-in-googles-federated-login-api 
> >,
> where you can ask any question and get answers from with other  
> Identity
> Providers, Relying Parties and Google engineers.
>
> *The OpenID Federated Login Service is available for all Google Apps
> editions. However, it is disabled by default for the Premier  and  
> Education
> editions, and it requires the Domain Admin to manually enable it  
> from the
> Control Panel. So Admins - go turn this today for your
> users<http://code.google.com/apis/apps/sso/openid_reference_implementation.html#cpanel 
> >.
> At Google.com - we already enabled it for our employees... *
> _______________________________________________
> board mailing list
> board at openid.net
> http://openid.net/mailman/listinfo/board




More information about the board mailing list