[OpenID board] upcoming Google announcement regarding OpenID

Thu Jul 9 20:16:46 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.
Feel free to discuss it on the main mailing list.  The discovery discussions
are not meant to be private.

I recently posted a pointer in such a thread that says

For nitty gritty details, see
http://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery

>> 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
The doc above has more details, including defining a way for a domain who
outsources their IDP (or RP in the case of someone like Janrain) to publish
a single simple file pointing to that SaaS provider.  An RP could also
choose to pole the SaaS providers directly, but that is a policy/UI decision
for them, and by definition that type of one-off doesn't seem like it could,
or needs to be, standardized.

>> But the more concerning matter is that the OpenID Foundation is being
asked to endorse one specific vendor as THE fallback for OpenID discovery.
Sorry if it sounded like that is what we I was suggesting.  I was suggesting
the OIDF could be supportive of the "approach" we are taking of working with
the community these last 6-9 months to establish standards for these types
of use cases.  Even our documentation specifies that the current
implementation is just a proof-of-concept for how to do discovery when a
SaaS provider is involved, and describes a method that does NOT require "one
specific vendor as the fallback for OpenID discovery" though I agree some
RPs may choose to do one-off polling of a few SaaS providers.

On Thu, Jul 9, 2009 at 12:02 PM, Will Norris <will at willnorris.com> wrote:

> 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
>>
>
> _______________________________________________
> board mailing list
> board at openid.net
> http://openid.net/mailman/listinfo/board
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-board/attachments/20090709/dd782e16/attachment.htm>