The Google announcement of this new OpenID service has now been formally posted at http://googlecode.blogspot.com/2009/07/google-apps-openid-identity-hub-for.html
On Wed, Jul 8, 2009 at 11:47 AM, Eric Sachs <[email protected]> wrote: > Yes, I now realize I mistakenly posted this to the public instead or > private board mailing list :-) Not a particularly big deal since we have > been discussing this planned launch in the discovery community. > Feel free to respond on either the public or private mailing list. > > On Wed, Jul 8, 2009 at 11:05 AM, Eric Sachs <[email protected]> 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 [email protected] http://openid.net/mailman/listinfo/board
