Thought this presentation was interesting, especially from a communica= tions/marketing perspective =97 on making messages reusable and global:

http://john.jubjubs.net/2009/01/27/lessons-from-mo= zilla-talk-at-heise/

Chris

--
Chris Messina
Open Web Advocate
<= br>Personal site: http://factoryjoe.com
Twitter: http://twitter.c= om/chrismessina

Diso Project: http://diso-project.o= rg
OpenID Foundation: http://openid.ne= t

This email is: =A0 [X] bloggable =A0 =A0[=A0] ask first =A0 [ = ] private

--0016e642d57a7e644c046df998af-- From postmaster at boxbe.com Sun Jul 5 12:01:11 2009 From: postmaster at boxbe.com (postmaster at boxbe.com) Date: Sun, 5 Jul 2009 12:01:11 -0700 (PDT) Subject: [OpenID board] board Digest, Vol 31, Issue 1 (Action Required) Message-ID: <855904398.51915.1246820471407.JavaMail.prod@app005.boxbe.com> ------=_Part_51914_1143254509.1246820471405 Content-Type: multipart/alternative; boundary="----=_Part_51913_1549163140.1246820471405" Content-Disposition: inline Content-Description: Notification The contents of this message require a modern email client for correct display. If you are reading this message, it may be because your reader is without MIME support. You can visit http://www.boxbe.com for more information about this problem, or consult the provider of your email reader. ------=_Part_51913_1549163140.1246820471405 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear sender, This message serves as notification that you will not receive any more courtesy notices from our members for two days. Messages you have sent will remain in a lower priority queue for our member to review at their leisure. Future messages will be more likely to be viewed if you are on our member's priority Guest List. Thank you, sajjad.a.soomro at gmail.com About Boxbe This courtesy notice is part of a free service to make email more reliable and useful. Boxbe (http://www.boxbe.com) uses your existing social network and that of your friends to keep your inbox clean and make sure you receive email from people who matter to you. Boxbe: Say Goodbye to Email Overload Visit http://www.boxbe.com/how-it-works?tc=198571011_1310433938 ------=_Part_51913_1549163140.1246820471405 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline

Dear sender,

This message serves as notification that you will not receive any more courtesy notices from our members for two days. Messages you have sent will remain in a lower priority queue for our member to review at their leisure.

Future messages will be more likely to be viewed if you are on our member's priority Guest List.

Thank you,
sajjad.a.soomro at gmail.com

About this Notice
This courtesy notice is part of a free service to make email more reliable and useful. Boxbe (www.boxbe.com) uses your existing social network and that of your friends to keep your inbox clean and make sure you receive email from people who matter to you.

Say Goodbye to Email Overload
www.boxbe.com

------=_Part_51913_1549163140.1246820471405-- ------=_Part_51914_1143254509.1246820471405 Content-Type: message/delivery-status Content-Transfer-Encoding: 7bit Content-Description: Delivery report Reporting-MTA: dns; boxbe.com Remote-MTA: dns; yahoo.com Action: failed Arrival-Date: Sun, 5 Jul 2009 12:00:23 -0700 (PDT) Final-Recipient: rfc822; sajjad.a.soomro at gmail.com Diagnostic-Code: X-Boxbe-Notice; Sender not pre-approved, delivery likely delayed. Follow instructions in above notice Status: 4.7.0 ------=_Part_51914_1143254509.1246820471405 Content-Description: Undelivered Message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit An embedded message was scrubbed... From: board-request at openid.net Subject: board Digest, Vol 31, Issue 1 Date: Sun, 05 Jul 2009 12:00:23 -0700 Size: 2376 URL: ------=_Part_51914_1143254509.1246820471405-- From esachs at google.com Wed Jul 8 11:05:24 2009 From: esachs at google.com (Eric Sachs) Date: Wed, 8 Jul 2009 11:05:24 -0700 Subject: [OpenID board] upcoming Google announcement regarding OpenID Message-ID: --0016364eef744df4d5046e35950c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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 , 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 to learn more about their implementation and view the demo and case study . 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 addressing some of the challenges with the current version (2.0) of OpenID : - 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 and Discovery documentation, or join the discussions in the Google Federated Login API Group, 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. 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 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 to learn more about the opportunities for the organizations. Supporting the API for Google Apps accounts is exciting news for the OpenID community , 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. 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 and the OpenID 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. 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 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, a provider of OpenID solutions, which already support the new API as part of their RPX product . As demonstrated by UserVoice using JanRain's RPX , a user simply types in her Google Apps hosted domain name in the OpenID login box and everything else is being taken care of: You can find more details in our API and Discovery documentation, or join the discussions in the Google Federated Login API Group, 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. At Google.com - we already enabled it for our employees... * --0016364eef744df4d5046e35950c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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+ sch= ools/enterprise/ISPs that are outsourcing their email to Google Apps. =A0We= would appreciate this not being circulated beyond the board until it is pu= blic. =A0This new support required that we work with the community to defin= e some extensions to the OpenID discovery process. =A0While those discussio= ns have been going on in the community the last few months, those extension= s are not yet formalized and probably won't be until they are proven in= production environments. =A0There is the potential for some community memb= ers (or press) to assume (or at least imply in articles) some evil intent b= y Google to co-opt OpenID with these extensions. =A0It would be nice to hav= e 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 fu= rther increase the pressure on us as a community to find more scalable UI o= ptions since the Nascar style approach obviously cannot include buttons for= these million new IDPs. =A0We have also just posted a set of summary UI gu= idelines that we will be referencing from our API documentation at=A0http://sites.google.com/site/oauthgoog/UXFedLogin/summary. =A0Th= e goal was to keep it to one-page which forced us to cut additional backgro= und information, but if you think we cut something critical, let me know.

Enterprise blog: Google Apps= + OpenID =3D identity hub for all your SaaS

We are happy to announce that the=A0Google OpenID Federated Login API= =A0has been extended to Google Apps accounts used by businesses, schools, a= nd other organizations. The service is important not only to the individual= s in those organizations, who can interact with a variety of consumer websi= tes with a single credential <add link to Google code post>, but also to the organizati= ons themselves, who are increasingly reliant on multiple Software as a Serv= ice (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 sol= utions such as XXX from=A0XXX, the Google Open ID Federated Login API enabl= es a single Google Apps login to provide secure access to services like Sal= esforce.com, SuccessFactors, and WebEX, as well as B2B partners, internal a= pplications, and of course consumer web sites. See=A0XXX's post <add link> to learn= more about their implementation and view the demo and case study <add links>.

Another early adopter is=A0XXX, a SaaS project management vendo= r who uses the new service to make it easier for any organization using Goo= gle Apps to sign up for and deploy=A0XXX=A0o their users:

<= div style=3D"margin-top:0px;margin-bottom:0px;text-align:center">< INSER= T SCREEN SHOTS>

Activating the OpenID Federated Login service for your domain is simple and= secure. To achieve that, we introduced a new experimental=A0discove= ry protocol=A0addressing some of the challenges with the=A0current version (2.0) of OpenID= :

=A0

Reducing the hassle of hosting discovery documents on the domain web-site -= the discovery protocol offer a solution that allows a hosted domain to bec= ome an OpenID Provider without hosting any documents at all. Optionally, a = domain may choose to host one simple file to support a more complete discov= ery flow.

Being an OpenID Identity Provider requires stro= ng security protection again attacks that could modify web pages on the sit= e. To avoid that requirement for businesses and organizations, we introduce= d digital signatures on the discovery documents and a verification flow to = support that.

You can find more details in our=A0API=A0and=A0Discovery=A0documentation, or join the discus= sions in the=A0Google Federated Login API Gro= up, where you can ask any question and get answers from with other Iden= tity Providers, Relying Parties and Google engineers.

The OpenID Federated Login Service is available for all Goog= le Apps editions. However, it is disabled by default for the Premier and Ed= ucation and editions =A0, and it requires the Domain Admin to manually enab= le it from the Control Panel. So Admins -=A0go turn this today for you= r users. At Google.com - we already enabled it for our employees...=A0<= /b>

Google Code blog: Over a million new O= penID Identity Providers !
We are happy to announce that the=A0Google Op= enID Federated Login API=A0 has been extended to Google Apps accounts u= sed by businesses, schools, and other organizations. =A0Individuals in thes= e organizations can now sign in to 3rd party websites using their Google Ap= ps account, without giving away their credentials. In addition to the value= for the end-users, the new service also benefits the organizations themsel= ves, who are increasingly reliant on multiple Software as a Service (SaaS) = solutions from different vendors. For example, XXX=A0is an= early adopter, allowing any organization running Google Apps to more quick= ly sign up for and adopt their service:

<< INSERT SCREEN SHOTS>

See our post on the Google Enterprise Blog <<= span style=3D"background-color:rgb(255, 255, 0)">add link> to lea= rn more about the opportunities for the organizations.=A0

Supporting the API for Google Apps accounts is exciting news for the=A0OpenID community, as it adds numerous= new trustworthy Identity Provider (IDP) domains and increases the OpenID e= nd user base by millions. In order to allow web-sites to easily become Rely= ing Parties for these many new IDPs and users, we defined a new=A0= discovery protocol. The protocol allows Relying Parties to identify tha= t a given domain is hosted on Google Apps and securely access its OpenID Pr= ovider End Point. The current proposal is an interim solution, and we are p= articipating in several standardization organizations, such as=A0OASIS=A0= and the=A0OpenID Foundation, to generate a next-generation standard. Since the current protocol prop= osal is not supported by the standard OpenID libraries, we provided an impl= ementation of the Relying Party pieces at the Open Source project -=A0 step2.googlecode.com. Goo= gle is also offering a set of resource addressing the issues of designing a= scalable Federated Login User Interface. You are welcome to visit the=A0User Experience summary for Federated Login=A0Go= ogle Sites page, where you can find links do demos, mocks and usabilty rese= arch data.=A0

Prefer an out= -of-the-box solution? We have been working with=A0JanRain, a provider of OpenID solutions, which already support the= new API as part of their=A0RPX product. A= s demonstrated by=A0UserVoice= =A0using=A0JanRain's RPX, a user simply types in her Google Apps = hosted domain name in the OpenID login box and everything else is being tak= en care of:

<Add UserV= oice (or other proposed RPX website) screenshots>

=A0

You can find more details in our=A0API=A0and=A0Discovery= =A0documentation, or join the discussions in the=A0Google Federated Login API Group, where you can ask any que= stion and get answers from with other Identity Providers, Relying Parties a= nd Google engineers.=A0=A0

The OpenID Federated Login Service is available for all Google Apps = editions. However, it is disabled by default for the Premier =A0and Educati= on editions, and it requires the Domain Admin to manually enable it from th= e Control Panel. So Admins -=A0go turn this today for your users. = At Google.com - we already enabled it for our employees...=A0

--0016364eef744df4d5046e35950c-- From will at willnorris.com Thu Jul 9 12:02:00 2009 From: will at willnorris.com (Will Norris) Date: Thu, 9 Jul 2009 12:02:00 -0700 Subject: [OpenID board] upcoming Google announcement regarding OpenID In-Reply-To: References: Message-ID: 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 > > 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 , 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 to learn > more > about their implementation and view the demo and case study 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 > > addressing > some of the challenges with the current version (2.0) of > OpenID > : > > > > - 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 > > and Discovery > > documentation, > or join the discussions in the Google Federated Login API > Group >, > 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 >. > 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 > > 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 to learn more > about > the opportunities for the organizations. > > > Supporting the API for Google Apps accounts is exciting news for the > OpenID > community , 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 >. > 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 > and > the OpenID 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. > 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 > 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, > a provider of OpenID solutions, which already support the new API as > part of > their RPX product . As demonstrated by > UserVoice > using JanRain's RPX , a user simply types in her > Google > Apps hosted domain name in the OpenID login box and everything else > is being > taken care of: > > > > > > > You can find more details in our > API > > and Discovery > > documentation, > or join the discussions in the Google Federated Login API > Group >, > 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 >. > At Google.com - we already enabled it for our employees... * > _______________________________________________ > board mailing list > board at openid.net > http://openid.net/mailman/listinfo/board From esachs at google.com Thu Jul 9 13:16:46 2009 From: esachs at google.com (Eric Sachs) Date: Thu, 9 Jul 2009 13:16:46 -0700 Subject: [OpenID board] upcoming Google announcement regarding OpenID In-Reply-To: References: Message-ID: --0016e64695acf3ebe4046e4b880b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >> 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 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 , 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 to learn more >> about their implementation and view the demo and case study . >> >> >> 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 >> : >> >> >> >> - 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 to learn more about >> the opportunities for the organizations. >> >> >> Supporting the API for Google Apps accounts is exciting news for the >> OpenID >> community , 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 >> and >> the OpenID 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. >> 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 >> 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, >> a provider of OpenID solutions, which already support the new API as part >> of >> their RPX product . As demonstrated by >> UserVoice >> using JanRain's RPX , a user simply types in her >> Google >> Apps hosted domain name in the OpenID login box and everything else is >> being >> taken care of: >> >> >> >> >> >> >> 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 > --0016e64695acf3ebe4046e4b880b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>=A0So 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 m= ailing list. =A0The discovery discussions are not meant to be private. =A0<= /div>

I recently posted a pointer in such a thread that says= =A0
For nitty gritty details, see=A0http://sites.google.com/site/oauthgoog/fedlogi= ninterp/openiddiscovery

>>=A0But if the relying party is unable to discover an OpenID pr= ovider through normal discovery means, they make an API call to Google aski= ng 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 pub= lish a single simple file pointing to that SaaS provider. =A0An RP could al= so choose to pole the SaaS providers directly, but that is a policy/UI deci= sion for them, and by definition that type of one-off doesn't seem like= it could, or needs to be, standardized.

>>=A0But the more concerning matter is that the OpenI= D 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. =A0I was sugges= ting 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. =A0Even 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 requ= ire "one specific vendor as the fallback for OpenID discovery" th= ough I agree some RPs may choose to do one-off polling of a few SaaS provid= ers.

On Thu, Jul 9, 2009 at 1= 2: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 t= hrow in my two cents. =A0I talked with Eric about this briefly at the last = IIW in March, and I'm happy to see that some of my previous concerns ha= ve been addressed. =A0Without seeing the actual discovery protocol document= , I can't be sure what is being proposed, but based on previous convers= ations 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 nor= mal OpenID discover on the claimed identifier provided by the user. =A0If t= hat was successful, then OpenID authentication continues as normal... nothi= ng unusual here. =A0But if the relying party is unable to discover an OpenI= D provider through normal discovery means, they make an API call to Google = asking if Google hosts OpenID services for that domain. =A0(As best as I ca= n tell, the path of the claimed ID is ignored, and the domain must match ex= actly. =A0If Google hosts services for "example.com", then "https://example.com:8443/foo"= would match, but "www.example.com" would not. =A0I'm sure the expectation is t= hat users will simply enter "example.com")

Having spent two years at USC helping to build both the policy and technica= l side of their identity management infrastructure, I do have very strong r= eservations about Google's actual product. =A0But the more concerning m= atter is that the OpenID Foundation is being asked to endorse one specific = vendor as THE fallback for OpenID discovery. =A0Now in practice, I'm no= t sure that there is anyone else offering a service like Google has. =A0I k= now JanRain has OPX, but I would imagine it uses traditional OpenID discove= ry... I'm not sure.

I understand that the existing discovery methods are a bit lacking. =A0My p= rimary focus for the past four weeks or so has been getting XRD to a Commit= tee Draft which people can start implementing. =A0Google has been very acti= ve in that effort, and Eric mentioned that in his post. =A0But endorsing a = vendor-specific fallback in the meantime is absolutely not something the fo= undation should be doing. =A0While it is not set in stone that the next ver= sion of OpenID Discovery is going to use XRD, that seems to be the general = consensus. =A0Publicizing this Google-specific discovery method, only to tu= rn 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. = =A0We
would appreciate this not being circulated beyond the board until it is
public. =A0This new support required that we work with the community to def= ine
some extensions to the OpenID discovery process. =A0While 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. =A0There is the potential for some community membe= rs
(or press) to assume (or at least imply in articles) some evil intent by Google to co-opt OpenID with these extensions. =A0It 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 ne= w
IDPs. =A0We have also just posted a set of summary UI guidelines that we wi= ll
be referencing from our API documentation at
http://sites.google.com/site/oauthgoog/UXFedLogin/summary.= =A0The 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 =3D 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/op= enid_reference_implementation.html>

has
been extended to Google Apps accounts used by businesses, schools, and othe= r
organizations. The service is important not only to the individuals in thos= e
organizations, who can interact with a variety of consumer websites with a<= br> 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 hu= b
for multiple SaaS providers. When integrated with partner solutions such as=
XXX from XXX, the Google Open ID Federated Login API enables a single Googl= e
Apps login to provide secure access to services like Salesforce.com,
SuccessFactors, and WebEX, as well as B2B partners, internal applications,<= br> and of course consumer web sites. See XXX's post <add link> to le= arn more
about their implementation and view the demo and case study <add links&g= t;.

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 sig= n
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://gro= ups.google.com/group/google-federated-login-api/web/openid-discovery-for-ho= sted-domains>

addressing
some of the challenges with the current version (2.0) of
OpenID<http://openid.net/specs/openid-authentication-2_0.html<= /a>>
:

=A0- Reducing the hassle of hosting discovery documents on the domain
=
=A0web-site - the discovery protocol offer a solution that allows a hosted=
=A0domain to become an OpenID Provider without hosting any documents at al= l.
=A0Optionally, a domain may choose to host one simple file to support a mo= re
=A0complete discovery flow.

=A0- Being an OpenID Identity Provider requires strong security protection=
=A0again attacks that could modify web pages on the site. To avoid that =A0requirement for businesses and organizations, we introduced digital
=A0signatures on the discovery documents and a verification flow to suppor= t
=A0that.

You can find more details in our
API<http://code.google.com/apis/apps/sso/op= enid_reference_implementation.html>

and Discovery<http:= //groups.google.com/group/google-federated-login-api/web/openid-discovery-f= or-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<= br> and editions =A0, and it requires the Domain Admin to manually enable it fr= om
the Control Panel. So Admins - go turn this today for your
users<http://code.google.com/apis/ap= ps/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 happ= y
to announce that the Google OpenID Federated Login
API<http://code.google.com/apis/apps/sso/op= enid_reference_implementation.html>

has been extended to Google Apps accounts used by businesses, schools, and<= br> other organizations. =A0Individuals 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 a= bout
the opportunities for the organizations.

Supporting the API for Google Apps accounts is exciting news for the OpenID=
community <http://w= ww.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<= br> these many new IDPs and users, we defined a new discovery
protocol<http://gro= ups.google.com/group/google-federated-login-api/web/openid-discovery-for-ho= sted-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. Th= e
current proposal is an interim solution, and we are participating in severa= l
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 o= f
the Relying Party pieces at the Open Source project -

step2.googl= ecode.com<http://code.google.com/p/step2/>.

Google is also offering a set of resource addressing the issues of designin= g
a scalable Federated Login User Interface. You are welcome to visit the Use= r
Experience summary for Federated
Login<http://sites.google.com/site/oauthgoog/UXFedLogin/sum= mary>

Google
Sites page, where you can find links do demos, mocks and usabilty research<= br> 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 o= f
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 bein= g
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/op= enid_reference_implementation.html>

and Discovery<http:= //groups.google.com/group/google-federated-login-api/web/openid-discovery-f= or-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 =A0and Educati= on
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/ap= ps/sso/openid_reference_implementation.html#cpanel>.
At Google.com - we already enabled it for our employees... *

_______________________________________________
board mailing list
board at openid.net<= br> http= ://openid.net/mailman/listinfo/board

_______________________________________________
board mailing list
board at openid.net<= br> http= ://openid.net/mailman/listinfo/board

--0016e64695acf3ebe4046e4b880b-- From will at willnorris.com Thu Jul 9 16:21:19 2009 From: will at willnorris.com (Will Norris) Date: Thu, 9 Jul 2009 16:21:19 -0700 Subject: [OpenID board] upcoming Google announcement regarding OpenID In-Reply-To: References: Message-ID: On Jul 9, 2009, at 1:16 PM, Eric Sachs 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. >> > > 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 okay, that is helpful. The only thing linked to in your post was a document on a google group that I couldn't access. This looks very familiar, because we talked about this in depth on various XRI TC calls. >> 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. The document you mention all but actually recommends that approach: > There are two locations where the host-meta document might be found: > > (1) http://example.com/host-meta > (2) https://www.google.com/accounts/o8/host-meta?hd=example.com > > Google's endpoint will return a 400 on endpoint (2) if the domain > provided has not outsourced OpenID IdP funcionality to Google. So > one possible strategy for an RP could be to first try endpoint (2), > and if that returns a 400, try endpoint (1), and if that doesn't > yield anything, give up. Other strategies (fetching both endpoints > in parallel, for example), are possible. The idea of trying endpoint #2 first, and then failing back to #1 should NEVER be proposed or encouraged. Quite the opposite, it should be strongly discouraged. It's language like this that make this feel like a vendor-specific approach that the OpenID Foundation should have nothing to do with. RPs should be instructed to ALWAYS attempt #1 first, otherwise the domain owner is no longer in control. >> 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. The other thing that concerns me is how close we are to having a committee draft of XRD. Admittedly, no we're not there yet. And part of that delay has been because we're making sure that we have a solution that all involved parties can live with, including Google. But I get a bit frustrated when Google claims to be supporting the new standard (and I'll be the first to say how valuable their input has been), but appears to be putting all their resources behind an incompatible approach to the same problem... one that I'm afraid will only lead to great confusion[0] if it gets any kind of widespread adoption. If Google wants to throw it out there as a possible stop- gap solution their customers can use until the next version of OpenID Discovery is written, that is fine. But I just don't believe it's the kind of approach the foundation should be endorsing when we're so close with XRD. -will From mart at degeneration.co.uk Thu Jul 9 16:38:40 2009 From: mart at degeneration.co.uk (Martin Atkins) Date: Thu, 09 Jul 2009 16:38:40 -0700 Subject: [OpenID board] upcoming Google announcement regarding OpenID In-Reply-To: References: Message-ID: <4A567F80.30504@degeneration.co.uk> Will Norris wrote: > > > The document you mention all but actually recommends that approach: > >> There are two locations where the host-meta document might be found: >> >> (1) http://example.com/host-meta >> (2) https://www.google.com/accounts/o8/host-meta?hd=example.com >> >> Google's endpoint will return a 400 on endpoint (2) if the domain >> provided has not outsourced OpenID IdP funcionality to Google. So one >> possible strategy for an RP could be to first try endpoint (2), and if >> that returns a 400, try endpoint (1), and if that doesn't yield >> anything, give up. Other strategies (fetching both endpoints in >> parallel, for example), are possible. > > > The idea of trying endpoint #2 first, and then failing back to #1 should > NEVER be proposed or encouraged. Quite the opposite, it should be > strongly discouraged. It's language like this that make this feel like > a vendor-specific approach that the OpenID Foundation should have > nothing to do with. RPs should be instructed to ALWAYS attempt #1 > first, otherwise the domain owner is no longer in control. > This is also a pretty good argument for why "magic" paths under a domain are bad, and is a good example of the issue I brought up months ago with relying on HTTP for discovery: a domain's website is very often hosted by a completely different organisation than the one that hosts everything else. I even used Google Apps as an example in my original blog post about this back in October: http://www.apparently.me.uk/19059.html From esachs at google.com Thu Jul 9 17:10:26 2009 From: esachs at google.com (Eric Sachs) Date: Thu, 9 Jul 2009 17:10:26 -0700 Subject: [OpenID board] upcoming Google announcement regarding OpenID In-Reply-To: References: Message-ID: --0016364ef40ab9210d046e4ecca7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >> The idea of trying endpoint #2 first, and then failing back to #1 should NEVER be proposed or encouraged.In a publicly documented standard, I agree with you. However, whitelists are common in actual practice. We see them today in the consumer space, though the eventual goal is to minimize that approach. In the case of Google Apps, most of the interest in this feature has come from SaaS vendors who are developing products that ONLY work for existing users of Google Apps, and that also require using the hybrid OAuth/OpenID integration with Google to access our APIs. So by definition, the only IDP/OAuth-SP they can "trust" is Google Apps. >> The other thing that concerns me is how close we are to having a committee draft of XRD. We haven't formally announced it yet :-) We keep delaying internally, but at some point we'll have to launch it and I would be surprised if we can hold off for longer then a few weeks given how many months we have already delayed. But when the drafts get finalized, we're hoping to support it within a small number of days and remove documentation for the proof-of-concept approach. The partners we have already worked with have read the warnings in our documentation that we will be switching the discovery mechanism once the standards gets solidified, so they are prepared to have to make that change on their side. On Thu, Jul 9, 2009 at 4:21 PM, Will Norris wrote: > > On Jul 9, 2009, at 1:16 PM, Eric Sachs 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. >>> >>> >> 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 >> > > okay, that is helpful. The only thing linked to in your post was a > document on a google group that I couldn't access. This looks very > familiar, because we talked about this in depth on various XRI TC calls. > > > 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. >> > > > The document you mention all but actually recommends that approach: > > There are two locations where the host-meta document might be found: >> >> (1) http://example.com/host-meta >> (2) https://www.google.com/accounts/o8/host-meta?hd=example.com >> >> Google's endpoint will return a 400 on endpoint (2) if the domain provided >> has not outsourced OpenID IdP funcionality to Google. So one possible >> strategy for an RP could be to first try endpoint (2), and if that returns a >> 400, try endpoint (1), and if that doesn't yield anything, give up. Other >> strategies (fetching both endpoints in parallel, for example), are possible. >> > > > The idea of trying endpoint #2 first, and then failing back to #1 should > NEVER be proposed or encouraged. Quite the opposite, it should be strongly > discouraged. It's language like this that make this feel like a > vendor-specific approach that the OpenID Foundation should have nothing to > do with. RPs should be instructed to ALWAYS attempt #1 first, otherwise the > domain owner is no longer in control. > > > 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. >> > > The other thing that concerns me is how close we are to having a committee > draft of XRD. Admittedly, no we're not there yet. And part of that delay > has been because we're making sure that we have a solution that all involved > parties can live with, including Google. But I get a bit frustrated when > Google claims to be supporting the new standard (and I'll be the first to > say how valuable their input has been), but appears to be putting all their > resources behind an incompatible approach to the same problem... one that > I'm afraid will only lead to great confusion[0] if it gets any kind of > widespread adoption. If Google wants to throw it out there as a possible > stop-gap solution their customers can use until the next version of OpenID > Discovery is written, that is fine. But I just don't believe it's the kind > of approach the foundation should be endorsing when we're so close with XRD. > > -will > > > _______________________________________________ > board mailing list > board at openid.net > http://openid.net/mailman/listinfo/board > --0016364ef40ab9210d046e4ecca7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>=A0The idea of trying endpoint #2 first, and then failing back to #1 sh= ould NEVER be proposed or encouraged.
In a publicly documented standa= rd, I agree with you.

=
However, whitelists are common in actual practice. =A0We s= ee them today in the consumer space, though the eventual goal is to minimiz= e that approach. =A0In the case of Google Apps, most of the interest in thi= s feature has come from SaaS vendors who are developing products that ONLY = work for existing users of Google Apps, and that also require using the hyb= rid OAuth/OpenID integration with Google to access our APIs. =A0So by defin= ition, the only IDP/OAuth-SP they can "trust" is Google Apps.

=
>>=A0The other thing that concerns me is how close w= e are to having a committee draft of XRD.

= We haven't formally announced it yet :-) =A0We keep delaying internally= , but at some point we'll have to launch it and I would be surprised if= we can hold off for longer then a few weeks given how many months we have = already delayed. =A0But=A0when the drafts get finalized, we're hoping t= o support it within a small number of days and remove documentation for the= proof-of-concept approach. =A0The partners we have already worked with hav= e read the warnings in our documentation that we will be switching the disc= overy mechanism once the standards gets solidified, so they are prepared to= have to make that change on their side.

=

On Thu, Jul 9, 2009 at= 4:21 PM, Will Norris <will at willnorris.com> wrote:

On Jul 9, 2009, at 1:16 PM, Eric Sachs 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.

Feel free to discuss it on the main mailing list. =A0The discovery discussi= ons
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/fedloginint= erp/openiddiscovery

okay, that is helpful. =A0The only thing linked to in your post was a docum= ent on a google group that I couldn't access. =A0This looks very famili= ar, because we talked about this in depth on various XRI TC calls.

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. =A0An RP could also choose to pole the SaaS providers directly, but that is a policy/UI decisio= n
for them, and by definition that type of one-off doesn't seem like it c= ould,
or needs to be, standardized.

The document you mention all but actually recommends that approach:

There are two locations where the host-meta document might be found:

(1) http://examp= le.com/host-meta
(2) https://www.google.com/accounts/o8/host-meta?hd=3Dexam= ple.com

Google's endpoint will return a 400 on endpoint (2) if the domain provi= ded has not outsourced OpenID IdP funcionality to Google. So one possible s= trategy for an RP could be to first try endpoint (2), and if that returns a= 400, try endpoint (1), and if that doesn't yield anything, give up. Ot= her strategies (fetching both endpoints in parallel, for example), are poss= ible.

The idea of trying endpoint #2 first, and then failing back to #1 should NE= VER be proposed or encouraged. =A0Quite the opposite, it should be strongly= discouraged. =A0It's language like this that make this feel like a ven= dor-specific approach that the OpenID Foundation should have nothing to do = with. =A0RPs should be instructed to ALWAYS attempt #1 first, otherwise the= domain owner is no longer in control.

But the more concerning matter is that the OpenID Foundation is being
asked to endorse one specific vendor as THE fallback for OpenID discovery.<= br>

Sorry if it sounded like that is what we I was suggesting. =A0I was suggest= ing
the OIDF could be supportive of the "approach" we are taking of w= orking with
the community these last 6-9 months to establish standards for these types<= br> of use cases. =A0Even 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 &qu= ot;one
specific vendor as the fallback for OpenID discovery" though I agree s= ome
RPs may choose to do one-off polling of a few SaaS providers.

The other thing that concerns me is how close we are to having a committee = draft of XRD. =A0Admittedly, no we're not there yet. =A0And part of tha= t delay has been because we're making sure that we have a solution that= all involved parties can live with, including Google. =A0But I get a bit f= rustrated when Google claims to be supporting the new standard (and I'l= l be the first to say how valuable their input has been), but appears to be= putting all their resources behind an incompatible approach to the same pr= oblem... one that I'm afraid will only lead to great confusion[0] if it= gets any kind of widespread adoption. =A0If Google wants to throw it out t= here as a possible stop-gap solution their customers can use until the next= version of OpenID Discovery is written, that is fine. =A0But I just don= 9;t believe it's the kind of approach the foundation should be endorsin= g when we're so close with XRD.

-will

_______________________________________________
board mailing list
board at openid.net<= br> http= ://openid.net/mailman/listinfo/board

--0016364ef40ab9210d046e4ecca7-- From esachs at google.com Wed Jul 8 11:47:00 2009 From: esachs at google.com (Eric Sachs) Date: Wed, 8 Jul 2009 11:47:00 -0700 Subject: [OpenID board] upcoming Google announcement regarding OpenID In-Reply-To: References: Message-ID: --00163646d40216fd6e046e362a52 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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 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 , 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 to learn more > about their implementation and view the demo and case study . > > > 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 addressing > some of the challenges with the current version (2.0) of OpenID > : > > > > - 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 > and Discovery documentation, > or join the discussions in the Google Federated Login API Group, > 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. > 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 > 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 to learn more about > the opportunities for the organizations. > > > Supporting the API for Google Apps accounts is exciting news for the OpenID > community , 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. > 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 and > the OpenID 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. > 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 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, > a provider of OpenID solutions, which already support the new API as part of > their RPX product . As demonstrated by UserVoice > using JanRain's RPX , a user simply types in her > Google Apps hosted domain name in the OpenID login box and everything else > is being taken care of: > > > > > > > You can find more details in our API > and Discovery documentation, > or join the discussions in the Google Federated Login API Group, > 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. > At Google.com - we already enabled it for our employees... * > --00163646d40216fd6e046e362a52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I now realize I mistakenly posted this to the public instead or privat= e board mailing list :-) =A0Not 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 <esachs at google.com> 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 t= heir email to Google Apps. =A0We would appreciate this not being circulated= beyond the board until it is public. =A0This new support required that we = work with the community to define some extensions to the OpenID discovery p= rocess. =A0While those discussions have been going on in the community the = last few months, those extensions are not yet formalized and probably won&#= 39;t be until they are proven in production environments. =A0There is the p= otential 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 extens= ions. =A0It would be nice to have a blog post on the formal OpenID blog tha= t was supportive of our approach, so I wanted to see if the board members a= re comfortable with that.

On a somewhat related point, I also expect this will fu= rther increase the pressure on us as a community to find more scalable UI o= ptions since the Nascar style approach obviously cannot include buttons for= these million new IDPs. =A0We have also just posted a set of summary UI gu= idelines that we will be referencing from our API documentation at=A0 http://sites.google.com/site/oauthgoog/UXFedLogin/summary. =A0Th= e goal was to keep it to one-page which forced us to cut additional backgro= und information, but if you think we cut something critical, let me know.
Enterprise blog: Google Apps= + OpenID =3D identity hub for all your SaaS

We are happy to announce that the=A0Google OpenID Federated Login API= =A0has been extended to Google Apps accounts used by businesses, schools, a= nd other organizations. The service is important not only to the individual= s in those organizations, who can interact with a variety of consumer websi= tes with a single credential <add link to Google code post>, but also to the organizati= ons themselves, who are increasingly reliant on multiple Software as a Serv= ice (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 sol= utions such as XXX from=A0XXX, the Google Open ID Federated Login API enabl= es a single Google Apps login to provide secure access to services like Sal= esforce.com, SuccessFactors, and WebEX, as well as B2B partners, internal a= pplications, and of course consumer web sites. See=A0XXX's post <add link> to learn= more about their implementation and view the demo and case study <add links>.

Another early adopter is=A0XXX, a SaaS project management vendo= r who uses the new service to make it easier for any organization using Goo= gle Apps to sign up for and deploy=A0XXX=A0o their users:

<= div style=3D"margin-top:0px;margin-bottom:0px;text-align:center">< INSER= T SCREEN SHOTS>

Activating the OpenID Federated Login service for your domain is simple and= secure. To achieve that, we introduced a new experimental=A0discove= ry protocol=A0addressing some of the challenges with the=A0current version (2.0) of OpenID= :

=A0
Reducing the hassle of hosting discovery documents on the domain web-site -= the discovery protocol offer a solution that allows a hosted domain to bec= ome an OpenID Provider without hosting any documents at all. Optionally, a = domain may choose to host one simple file to support a more complete discov= ery flow.

Being an OpenID Identity Provider requires stro= ng security protection again attacks that could modify web pages on the sit= e. To avoid that requirement for businesses and organizations, we introduce= d digital signatures on the discovery documents and a verification flow to = support that.

You can find more details in our=A0API=A0and=A0Discovery=A0documentation, or join the discus= sions in the=A0Google Federated Login API Gro= up, where you can ask any question and get answers from with other Iden= tity Providers, Relying Parties and Google engineers.

The OpenID Federated Login Service is available for all Goog= le Apps editions. However, it is disabled by default for the Premier and Ed= ucation and editions =A0, and it requires the Domain Admin to manually enab= le it from the Control Panel. So Admins -=A0go turn this today for you= r users. At Google.com - we already enabled it for our employees...=A0<= /b>

Google Code blog: Over a million new O= penID Identity Providers !
We are happy to announce that the=A0Google Op= enID Federated Login API=A0 has been extended to Google Apps accounts u= sed by businesses, schools, and other organizations. =A0Individuals in thes= e organizations can now sign in to 3rd party websites using their Google Ap= ps account, without giving away their credentials. In addition to the value= for the end-users, the new service also benefits the organizations themsel= ves, who are increasingly reliant on multiple Software as a Service (SaaS) = solutions from different vendors. For example, XXX=A0is an= early adopter, allowing any organization running Google Apps to more quick= ly sign up for and adopt their service:

<< INSERT SCREEN SHOTS>

See our post on the Google Enterprise Blog <<= span style=3D"background-color:rgb(255, 255, 0)">add link> to lea= rn more about the opportunities for the organizations.=A0

Supporting the API for Google Apps accounts is exciting news for the=A0OpenID community, as it adds numerous= new trustworthy Identity Provider (IDP) domains and increases the OpenID e= nd user base by millions. In order to allow web-sites to easily become Rely= ing Parties for these many new IDPs and users, we defined a new=A0= discovery protocol. The protocol allows Relying Parties to identify tha= t a given domain is hosted on Google Apps and securely access its OpenID Pr= ovider End Point. The current proposal is an interim solution, and we are p= articipating in several standardization organizations, such as=A0OASIS=A0= and the=A0OpenID Foundation, to generate a next-generation standard. Since the current protocol prop= osal is not supported by the standard OpenID libraries, we provided an impl= ementation of the Relying Party pieces at the Open Source project -=A0 step2.googlecode.com. Goo= gle is also offering a set of resource addressing the issues of designing a= scalable Federated Login User Interface. You are welcome to visit the=A0User Experience summary for Federated Login=A0Go= ogle Sites page, where you can find links do demos, mocks and usabilty rese= arch data.=A0

Prefer an out= -of-the-box solution? We have been working with=A0JanRain, a provider of OpenID solutions, which already support the= new API as part of their=A0RPX product. A= s demonstrated by=A0UserVoice= =A0using=A0JanRain's RPX, a user simply types in her Google Apps = hosted domain name in the OpenID login box and everything else is being tak= en care of:

<Add UserV= oice (or other proposed RPX website) screenshots>

=A0

You can find more details in our=A0API=A0and=A0Discovery= =A0documentation, or join the discussions in the=A0Google Federated Login API Group, where you can ask any que= stion and get answers from with other Identity Providers, Relying Parties a= nd Google engineers.=A0=A0

The OpenID Federated Login Service is available for all Google Apps = editions. However, it is disabled by default for the Premier =A0and Educati= on editions, and it requires the Domain Admin to manually enable it from th= e Control Panel. So Admins -=A0go turn this today for your users. = At Google.com - we already enabled it for our employees...=A0

--00163646d40216fd6e046e362a52-- From santrajan at gmail.com Thu Jul 9 20:44:19 2009 From: santrajan at gmail.com (Santosh Rajan) Date: Thu, 9 Jul 2009 20:44:19 -0700 (PDT) Subject: [OpenID board] upcoming Google announcement regarding OpenID In-Reply-To: References: Message-ID: <24421338.post@talk.nabble.com> Will Norris wrote: > > > > > The other thing that concerns me is how close we are to having a > committee draft of XRD. Admittedly, no we're not there yet. And part > of that delay has been because we're making sure that we have a > solution that all involved parties can live with, including Google. > But I get a bit frustrated when Google claims to be supporting the new > standard (and I'll be the first to say how valuable their input has > been), but appears to be putting all their resources behind an > incompatible approach to the same problem... one that I'm afraid will > only lead to great confusion[0] if it gets any kind of widespread > adoption. If Google wants to throw it out there as a possible stop- > gap solution their customers can use until the next version of OpenID > Discovery is written, that is fine. But I just don't believe it's the > kind of approach the foundation should be endorsing when we're so > close with XRD. > > > Are you kidding? XRI TC hasnt even figured how to sign an XRD document. XML DSig has been around for 11 years and it cant reliably sign an XML document? Why don't XRI TC come out with a simple XRD draft as soon as possible and relieve everyone from all this pain. IS the XRI TC waiting for the cows to come home? ----- Santosh Rajan http://santrajan.blogspot.com http://santrajan.blogspot.com -- View this message in context: http://www.nabble.com/upcoming-Google-announcement-regarding-OpenID-tp24396556p24421338.html Sent from the OpenID - Foundation Board mailing list archive at Nabble.com. From will at willnorris.com Fri Jul 10 09:28:46 2009 From: will at willnorris.com (Will Norris) Date: Fri, 10 Jul 2009 09:28:46 -0700 Subject: [OpenID board] upcoming Google announcement regarding OpenID In-Reply-To: <24421338.post@talk.nabble.com> References: <24421338.post@talk.nabble.com> Message-ID: <593F6E9C-E46B-4938-813C-7DC42CFCD2ED@willnorris.com> On Jul 9, 2009, at 8:44 PM, Santosh Rajan wrote: > Are you kidding? XRI TC hasnt even figured how to sign an XRD > document. XML > DSig has been around for 11 years and it cant reliably sign an XML > document? > Why don't XRI TC come out with a simple XRD draft as soon as > possible and > relieve everyone from all this pain. IS the XRI TC waiting for the > cows to > come home? You're welcome to track the progress of XRD in the OASIS svn repository[0]. There is only a docbook version there, we don't have the HTML versions in subversion... unfortunately the OASIS document repository requires authentication. [0]: http://tools.oasis-open.org/version-control/svn/xri/xrd/1.0/trunk/ While this is not really the best place to talk about XRD specifics, I'll address your point about signatures to say that XRD is in fact using XML DSig for signing. More accurately, we're using a constrained profile of DSig using Exclusive Canonicalization that should be much easier to implement than full inclusive c14n. This is the same approach taken in SAML 2.0. One of my personal qualms with Google's recommended discovery extension is that it significantly differs from XRD in this (they are using their own signing method instead of traditional DSig) and other ways , while being strikingly similar in others. I believe this will lead to unnecessary confusion. To be clear, my opposition to a foundation endorsement of this is not based on the merits of the proposed protocol (aside from some specific language I've already pointed out)... the XRI TC is the correct place to debate that. Rather, my opposition is based on my belief that widespread adoption of the proposed protocol will confuse, and possibly fragment, the community if XRD does end up being the solution for OpenID discovery in the not-too-distant future. On Jul 9, 2009, at 5:10 PM, Eric Sachs wrote: > We haven't formally announced it yet :-) We keep delaying > internally, but > at some point we'll have to launch it and I would be surprised if we > can > hold off for longer then a few weeks given how many months we have > already > delayed. But when the drafts get finalized, we're hoping to support > it > within a small number of days and remove documentation for the > proof-of-concept approach. The partners we have already worked with > have > read the warnings in our documentation that we will be switching the > discovery mechanism once the standards gets solidified, so they are > prepared > to have to make that change on their side. This sounds great, it's good to know that you plan on migrating to XRD in a timely fashion when it is ready. I don't mean to discount the contributions Google has made to the community both in helping to develop and implement these standards. And if you need to go forward with a temporary solution in the meantime in order to satisfy existing customers, that's perfectly fine. I understand that Google is free to move forward with whatever is necessary for your business, I'm not suggesting otherwise. But if the work is being done with specific partners, I'm not sure why that necessitates a public announcement including endorsement from the foundation. Is it not sufficient to point implementors to the Google document on an individual basis, which is what I would assume you've been doing thus far? You're absolutely right that a public announcement would likely lead at least some in the community and the press to interpret this move as Google trying to co-opt OpenID. But I'm not sure that the foundation publicly supporting the move is the right solution to that problem. I think my particular horse is pretty well dead enough already, so I'll shut up for now. I've said my piece... it is of course the board's decision to make. -will From santrajan at gmail.com Fri Jul 10 09:46:18 2009 From: santrajan at gmail.com (Santosh Rajan) Date: Fri, 10 Jul 2009 09:46:18 -0700 (PDT) Subject: [OpenID board] upcoming Google announcement regarding OpenID In-Reply-To: <593F6E9C-E46B-4938-813C-7DC42CFCD2ED@willnorris.com> References: <24421338.post@talk.nabble.com> <593F6E9C-E46B-4938-813C-7DC42CFCD2ED@willnorris.com> Message-ID: <24431020.post@talk.nabble.com> I think you are not seeing the real issue here. This is not about Google. This is about a Company (it could have been anyone), who has a problem to solve. It so happens we are already working on a solution. It is just that we can't come up with a solution as fast as they would like it. So why don't we at least give the Company credit for consulting with us, and why don't we try to come up with a good, usefull solution for them? Will Norris wrote: > > > On Jul 9, 2009, at 8:44 PM, Santosh Rajan wrote: > >> Are you kidding? XRI TC hasnt even figured how to sign an XRD >> document. XML >> DSig has been around for 11 years and it cant reliably sign an XML >> document? >> Why don't XRI TC come out with a simple XRD draft as soon as >> possible and >> relieve everyone from all this pain. IS the XRI TC waiting for the >> cows to >> come home? > > > You're welcome to track the progress of XRD in the OASIS svn > repository[0]. There is only a docbook version there, we don't have > the HTML versions in subversion... unfortunately the OASIS document > repository requires authentication. > > [0]: http://tools.oasis-open.org/version-control/svn/xri/xrd/1.0/trunk/ > > While this is not really the best place to talk about XRD specifics, > I'll address your point about signatures to say that XRD is in fact > using XML DSig for signing. More accurately, we're using a > constrained profile of DSig using Exclusive Canonicalization that > should be much easier to implement than full inclusive c14n. This is > the same approach taken in SAML 2.0. > > One of my personal qualms with Google's recommended discovery > extension is that it significantly differs from XRD in this (they are > using their own signing method instead of traditional DSig) and other > ways , while being strikingly similar in others. I believe this will > lead to unnecessary confusion. To be clear, my opposition to a > foundation endorsement of this is not based on the merits of the > proposed protocol (aside from some specific language I've already > pointed out)... the XRI TC is the correct place to debate that. > Rather, my opposition is based on my belief that widespread adoption > of the proposed protocol will confuse, and possibly fragment, the > community if XRD does end up being the solution for OpenID discovery > in the not-too-distant future. > > > On Jul 9, 2009, at 5:10 PM, Eric Sachs wrote: > >> We haven't formally announced it yet :-) We keep delaying >> internally, but >> at some point we'll have to launch it and I would be surprised if we >> can >> hold off for longer then a few weeks given how many months we have >> already >> delayed. But when the drafts get finalized, we're hoping to support >> it >> within a small number of days and remove documentation for the >> proof-of-concept approach. The partners we have already worked with >> have >> read the warnings in our documentation that we will be switching the >> discovery mechanism once the standards gets solidified, so they are >> prepared >> to have to make that change on their side. > > This sounds great, it's good to know that you plan on migrating to XRD > in a timely fashion when it is ready. I don't mean to discount the > contributions Google has made to the community both in helping to > develop and implement these standards. And if you need to go forward > with a temporary solution in the meantime in order to satisfy existing > customers, that's perfectly fine. I understand that Google is free to > move forward with whatever is necessary for your business, I'm not > suggesting otherwise. But if the work is being done with specific > partners, I'm not sure why that necessitates a public announcement > including endorsement from the foundation. Is it not sufficient to > point implementors to the Google document on an individual basis, > which is what I would assume you've been doing thus far? You're > absolutely right that a public announcement would likely lead at least > some in the community and the press to interpret this move as Google > trying to co-opt OpenID. But I'm not sure that the foundation > publicly supporting the move is the right solution to that problem. > > I think my particular horse is pretty well dead enough already, so > I'll shut up for now. I've said my piece... it is of course the > board's decision to make. > > -will > _______________________________________________ > board mailing list > board at openid.net > http://openid.net/mailman/listinfo/board > > ----- Santosh Rajan http://santrajan.blogspot.com http://santrajan.blogspot.com -- View this message in context: http://www.nabble.com/upcoming-Google-announcement-regarding-OpenID-tp24396556p24431020.html Sent from the OpenID - Foundation Board mailing list archive at Nabble.com. From esachs at google.com Fri Jul 10 10:43:36 2009 From: esachs at google.com (Eric Sachs) Date: Fri, 10 Jul 2009 10:43:36 -0700 Subject: [OpenID board] upcoming Google announcement regarding OpenID In-Reply-To: <24431020.post@talk.nabble.com> References: <24421338.post@talk.nabble.com> <593F6E9C-E46B-4938-813C-7DC42CFCD2ED@willnorris.com> <24431020.post@talk.nabble.com> Message-ID: --0016364ef4d619fd67046e5d8329 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit At Google we had some discussion of moving up the data of our formal announcement, but we are going to try to continue to delay the posts until we at least finish some minor functional work we are doing in the Google Apps admin panel. It would certainly be great if the discovery standards discussions evolved between now and then. In the meantime, though, the functionality does work for free Google Apps domains, so feel free to use it for "proof-of-concept" testing if that helps the discovery standards discussions. On Fri, Jul 10, 2009 at 9:46 AM, Santosh Rajan wrote: > > I think you are not seeing the real issue here. This is not about Google. > This is about a Company (it could have been anyone), who has a problem to > solve. It so happens we are already working on a solution. It is just that > we can't come up with a solution as fast as they would like it. > > So why don't we at least give the Company credit for consulting with us, > and > why don't we try to come up with a good, usefull solution for them? > > > Will Norris wrote: > > > > > > On Jul 9, 2009, at 8:44 PM, Santosh Rajan wrote: > > > >> Are you kidding? XRI TC hasnt even figured how to sign an XRD > >> document. XML > >> DSig has been around for 11 years and it cant reliably sign an XML > >> document? > >> Why don't XRI TC come out with a simple XRD draft as soon as > >> possible and > >> relieve everyone from all this pain. IS the XRI TC waiting for the > >> cows to > >> come home? > > > > > > You're welcome to track the progress of XRD in the OASIS svn > > repository[0]. There is only a docbook version there, we don't have > > the HTML versions in subversion... unfortunately the OASIS document > > repository requires authentication. > > > > [0]: http://tools.oasis-open.org/version-control/svn/xri/xrd/1.0/trunk/ > > > > While this is not really the best place to talk about XRD specifics, > > I'll address your point about signatures to say that XRD is in fact > > using XML DSig for signing. More accurately, we're using a > > constrained profile of DSig using Exclusive Canonicalization that > > should be much easier to implement than full inclusive c14n. This is > > the same approach taken in SAML 2.0. > > > > One of my personal qualms with Google's recommended discovery > > extension is that it significantly differs from XRD in this (they are > > using their own signing method instead of traditional DSig) and other > > ways , while being strikingly similar in others. I believe this will > > lead to unnecessary confusion. To be clear, my opposition to a > > foundation endorsement of this is not based on the merits of the > > proposed protocol (aside from some specific language I've already > > pointed out)... the XRI TC is the correct place to debate that. > > Rather, my opposition is based on my belief that widespread adoption > > of the proposed protocol will confuse, and possibly fragment, the > > community if XRD does end up being the solution for OpenID discovery > > in the not-too-distant future. > > > > > > On Jul 9, 2009, at 5:10 PM, Eric Sachs wrote: > > > >> We haven't formally announced it yet :-) We keep delaying > >> internally, but > >> at some point we'll have to launch it and I would be surprised if we > >> can > >> hold off for longer then a few weeks given how many months we have > >> already > >> delayed. But when the drafts get finalized, we're hoping to support > >> it > >> within a small number of days and remove documentation for the > >> proof-of-concept approach. The partners we have already worked with > >> have > >> read the warnings in our documentation that we will be switching the > >> discovery mechanism once the standards gets solidified, so they are > >> prepared > >> to have to make that change on their side. > > > > This sounds great, it's good to know that you plan on migrating to XRD > > in a timely fashion when it is ready. I don't mean to discount the > > contributions Google has made to the community both in helping to > > develop and implement these standards. And if you need to go forward > > with a temporary solution in the meantime in order to satisfy existing > > customers, that's perfectly fine. I understand that Google is free to > > move forward with whatever is necessary for your business, I'm not > > suggesting otherwise. But if the work is being done with specific > > partners, I'm not sure why that necessitates a public announcement > > including endorsement from the foundation. Is it not sufficient to > > point implementors to the Google document on an individual basis, > > which is what I would assume you've been doing thus far? You're > > absolutely right that a public announcement would likely lead at least > > some in the community and the press to interpret this move as Google > > trying to co-opt OpenID. But I'm not sure that the foundation > > publicly supporting the move is the right solution to that problem. > > > > I think my particular horse is pretty well dead enough already, so > > I'll shut up for now. I've said my piece... it is of course the > > board's decision to make. > > > > -will > > _______________________________________________ > > board mailing list > > board at openid.net > > http://openid.net/mailman/listinfo/board > > > > > > > ----- > > Santosh Rajan > http://santrajan.blogspot.com http://santrajan.blogspot.com > -- > View this message in context: > http://www.nabble.com/upcoming-Google-announcement-regarding-OpenID-tp24396556p24431020.html > Sent from the OpenID - Foundation Board mailing list archive at Nabble.com. > > _______________________________________________ > board mailing list > board at openid.net > http://openid.net/mailman/listinfo/board > --0016364ef4d619fd67046e5d8329 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
At Google we had some discussion of moving up the data of our formal a= nnouncement, but we=A0are going to try to continue to delay the posts until we = at least finish some minor functional work we are doing in the Google Apps = admin panel. =A0It would certainly be great if the discovery standards disc= ussions evolved between now and then.

=
In the meantime, though, the functionality does work for f= ree Google Apps domains, so feel free to use it for "proof-of-concept&= quot; testing if that helps the discovery standards discussions.

On Fri, Jul 10, 2009 at 9:46 = AM, Santosh Rajan <santrajan at gmail.com> wrote:

I think you are not seeing the real issue here. This is not about Google. This is about a Company (it could have been anyone), who has a problem to solve. It so happens we are already working on a solution. It is just that<= br> we can't come up with a solution as fast as they would like it.

So why don't we at least give the Company credit for consulting with us= , and
why don't we try to come up with a good, usefull solution for them?

Will Norris wrote:
>
>
> On Jul 9, 2009, at 8:44 PM, Santosh Rajan wrote:
>
>> Are you kidding? XRI TC hasnt even figured how to sign an XRD
>> document. XML
>> DSig has been around for 11 years and it cant reliably sign an XML=
>> document?
>> Why don't XRI TC come out with a simple XRD draft as soon as >> possible and
>> relieve everyone from all this pain. IS the XRI TC waiting for the=
>> cows to
>> come home?
>
>
> You're welcome to track the progress of XRD in the OASIS svn
> repository[0]. =A0There is only a docbook version there, we don't = have
> the HTML versions in subversion... unfortunately the OASIS document > repository requires authentication.
>
> [0]: http://tools.oasis-open.org/version-control= /svn/xri/xrd/1.0/trunk/
>
> While this is not really the best place to talk about XRD specifics, > I'll address your point about signatures to say that XRD is in fac= t
> using XML DSig for signing. =A0More accurately, we're using a
> constrained profile of DSig using Exclusive Canonicalization that
> should be much easier to implement than full inclusive c14n. =A0This i= s
> the same approach taken in SAML 2.0.
>
> One of my personal qualms with Google's recommended discovery
> extension is that it significantly differs from XRD in this (they are<= br> > using their own signing method instead of traditional DSig) and other<= br> > ways , while being strikingly similar in others. =A0I believe this wil= l
> lead to unnecessary confusion. =A0To be clear, my opposition to a
> foundation endorsement of this is not based on the merits of the
> proposed protocol (aside from some specific language I've already<= br> > pointed out)... the XRI TC is the correct place to debate that.
> Rather, my opposition is based on my belief that widespread adoption > of the proposed protocol will confuse, and possibly fragment, the
> community if XRD does end up being the solution for OpenID discovery > in the not-too-distant future.
>
>
> On Jul 9, 2009, at 5:10 PM, Eric Sachs wrote:
>
>> We haven't formally announced it yet :-) =A0We keep delaying >> internally, but
>> at some point we'll have to launch it and I would be surprised= if we
>> can
>> hold off for longer then a few weeks given how many months we have=
>> already
>> delayed. =A0But when the drafts get finalized, we're hoping to= support
>> it
>> within a small number of days and remove documentation for the
>> proof-of-concept approach. =A0The partners we have already worked = with
>> have
>> read the warnings in our documentation that we will be switching t= he
>> discovery mechanism once the standards gets solidified, so they ar= e
>> prepared
>> to have to make that change on their side.
>
> This sounds great, it's good to know that you plan on migrating to= XRD
> in a timely fashion when it is ready. =A0I don't mean to discount = the
> contributions Google has made to the community both in helping to
> develop and implement these standards. =A0And if you need to go forwar= d
> with a temporary solution in the meantime in order to satisfy existing=
> customers, that's perfectly fine. =A0I understand that Google is f= ree to
> move forward with whatever is necessary for your business, I'm not=
> suggesting otherwise. =A0But if the work is being done with specific > partners, I'm not sure why that necessitates a public announcement=
> including endorsement from the foundation. =A0Is it not sufficient to<= br> > point implementors to the Google document on an individual basis,
> which is what I would assume you've been doing thus far? =A0You= 9;re
> absolutely right that a public announcement would likely lead at least=
> some in the community and the press to interpret this move as Google > trying to co-opt OpenID. =A0But I'm not sure that the foundation > publicly supporting the move is the right solution to that problem. >
> I think my particular horse is pretty well dead enough already, so
> I'll shut up for now. =A0I've said my piece... it is of course= the
> board's decision to make.
>
> -will
> _______________________________________________
> board mailing list
> board at openid.net
> http://openid.net/mailman/listinfo/board
>
>

-----

Santosh Rajan
http://santraja= n.blogspot.com http://santrajan.blogspot.com
--

View this message in context: http://www.nabble.com/upcoming-Google-announcement-regarding-OpenI= D-tp24396556p24431020.html

Sent from the OpenID - Foundation Board mailing list arch= ive at Nabble.com.

_______________________________________________

board mailing list
board at openid.net
http= ://openid.net/mailman/listinfo/board

--0016364ef4d619fd67046e5d8329-- From esachs at google.com Tue Jul 28 08:28:04 2009 From: esachs at google.com (Eric Sachs) Date: Tue, 28 Jul 2009 08:28:04 -0700 Subject: [OpenID board] upcoming Google announcement regarding OpenID In-Reply-To: References: Message-ID: --001636456f967cc861046fc5b719 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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 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 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 , 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 to learn more >> about their implementation and view the demo and case study . >> >> >> 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 addressing >> some of the challenges with the current version (2.0) of OpenID >> : >> >> >> >> - 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 >> and Discovery documentation, >> or join the discussions in the Google Federated Login API Group, >> 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. >> 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 >> 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 to learn more about >> the opportunities for the organizations. >> >> >> Supporting the API for Google Apps accounts is exciting news for the OpenID >> community , 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. >> 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 and >> the OpenID 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 . 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 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, >> a provider of OpenID solutions, which already support the new API as part of >> their RPX product . As demonstrated by UserVoice >> using JanRain's RPX , a user simply types in her >> Google Apps hosted domain name in the OpenID login box and everything else >> is being taken care of: >> >> >> >> >> >> >> You can find more details in our API >> and Discovery documentation, >> or join the discussions in the Google Federated Login API Group, >> 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. >> At Google.com - we already enabled it for our employees... * >> > > --001636456f967cc861046fc5b719 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The Google announcement of this new OpenID service has now been formally po= sted at
http://google= code.blogspot.com/2009/07/google-apps-openid-identity-hub-for.html

On Wed, Jul 8, 2009 at 11:47 AM, Eric = Sachs <esachs at google.com> wrote:

Yes, I now realiz= e I mistakenly posted this to the public instead or private board mailing l= ist :-) =A0Not a particularly big deal since we have been discussing this p= lanned 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 <esachs at google.com> wrote:

Below are dr= afts of two blog posts we will make in the upcoming weeks about the fact th= at we are now operating an OpenID IDP for the million+ schools/enterprise/I= SPs that are outsourcing their email to Google Apps. =A0We would appreciate= this not being circulated beyond the board until it is public. =A0This new= support required that we work with the community to define some extensions= to the OpenID discovery process. =A0While those discussions have been goin= g on in the community the last few months, those extensions are not yet for= malized and probably won't be until they are proven in production envir= onments. =A0There is the potential for some community members (or press) to= assume (or at least imply in articles) some evil intent by Google to co-op= t OpenID with these extensions. =A0It 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 fu= rther increase the pressure on us as a community to find more scalable UI o= ptions since the Nascar style approach obviously cannot include buttons for= these million new IDPs. =A0We have also just posted a set of summary UI gu= idelines that we will be referencing from our API documentation at=A0http://sites.google.com/site/oauthgoog/UXFedLogin/summary. =A0Th= e goal was to keep it to one-page which forced us to cut additional backgro= und information, but if you think we cut something critical, let me know.
Enterprise blog: Goo= gle Apps + OpenID =3D identity hub for all your SaaS

We are happy to announce that the=A0Google OpenID F= ederated Login API=A0has 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 var= iety of consumer websites with a single credential <add link to Google code post>, bu= t also to the organizations themselves, who are increasingly reliant on mul= tiple 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 integ= rated with partner solutions such as XXX from=A0XXX, the Google Open ID Fed= erated Login API enables a single Google Apps login to provide secure acces= s to services like Salesforce.com, SuccessFactors, and WebEX, as well as B2= B partners, internal applications, and of course consumer web sites. See=A0= XXX's post <add = link> to learn more about their implementation and view the demo = and case study <add = links>.

Another early adopter is=A0XXX, a SaaS pr= oject management vendor who uses the new service to make it easier for any = organization using Google Apps to sign up for and deploy=A0XXX=A0o their us= ers:

Activating the OpenID Federated Login service for your domain is simple and= secure. To achieve that, we introduced a new experimental=A0discove= ry protocol=A0addressing some of the challenges with the=A0current version (2.0) of OpenID= :

=A0
Reducing the hassle of hosting discovery documents on the domain web-site -= the discovery protocol offer a solution that allows a hosted domain to bec= ome an OpenID Provider without hosting any documents at all. Optionally, a = domain may choose to host one simple file to support a more complete discov= ery flow.

Being an OpenID Identity Provider requi= res strong security protection again attacks that could modify web pages on= the site. To avoid that requirement for businesses and organizations, we i= ntroduced digital signatures on the discovery documents and a verification = flow to support that.

You can find more details in our=A0API=A0and=A0Discovery=A0documentation, or join the discus= sions in the=A0Google Federated Login API Gro= up, where you can ask any question and get answers from with other Iden= tity 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 =A0, and it requires the Domain = Admin to manually enable it from the Control Panel. So Admins -=A0go = turn this today for your users. At Google.com - we already enabled it f= or our employees...=A0

Google Code blog: Over a million new= OpenID Identity Providers !
We are happy to announce that the=A0Google O= penID Federated Login API=A0 has been extended to Google Apps accounts = used by businesses, schools, and other organizations. =A0Individuals in the= se organizations can now sign in to 3rd party websites using their Google A= pps account, without giving away their credentials. In addition to the valu= e for the end-users, the new service also benefits the organizations themse= lves, who are increasingly reliant on multiple Software as a Service (SaaS)= solutions from different vendors. For example, XXX=A0is a= n early adopter, allowing any organization running Google Apps to more quic= kly 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.=A0

Supporting the API for Google Apps accounts is exciting news for the=A0OpenID community, as it adds numero= us new trustworthy Identity Provider (IDP) domains and increases the OpenID= end user base by millions. In order to allow web-sites to easily become Re= lying Parties for these many new IDPs and users, we defined a new=A0= discovery protocol. The protocol allows Relying Parties to identify tha= t a given domain is hosted on Google Apps and securely access its OpenID Pr= ovider End Point. The current proposal is an interim solution, and we are p= articipating in several standardization organizations, such as=A0OASIS=A0= and the=A0OpenID Foundation= , to generate a next-generation standard. Since the current protocol pr= oposal is not supported by the standard OpenID libraries, we provided an im= plementation of the Relying Party pieces at the Open Source project -=A0step2.googlecode.com.= Google is also offering a set of resource addressing the issues of designi= ng a scalable Federated Login User Interface. You are welcome to visit the= =A0User Experience summary for Federated Login=A0Google Sites page, where you can find links do demos, mocks and usabil= ty research data.=A0

Prefer an= out-of-the-box solution? We have been working with=A0 JanRain, a provider of OpenID solutions, which already supp= ort the new API as part of their=A0RPX produ= ct. As demonstrated by=A0Use= rVoice=A0using=A0JanRain's RPX, a user simply types in her Go= ogle 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>= ;

=A0

You can find more details in our=A0API=A0and=A0Discovery=A0documentation, or join the discussions in the= =A0Google Federated Login API Group, wher= e you can ask any question and get answers from with other Identity Provide= rs, Relying Parties and Google engineers.=A0=A0

The OpenID Federated Login Service is available for all Google Apps = editions. However, it is disabled by default for the Premier =A0and Educati= on editions, and it requires the Domain Admin to manually enable it from th= e Control Panel. So Admins -=A0go turn this today for your users. = At Google.com - we already enabled it for our employees...=A0

--001636456f967cc861046fc5b719-- From santrajan at gmail.com Tue Jul 28 08:48:43 2009 From: santrajan at gmail.com (Santosh Rajan) Date: Tue, 28 Jul 2009 21:18:43 +0530 Subject: [OpenID board] upcoming Google announcement regarding OpenID In-Reply-To: References: Message-ID: --001636458338543cb9046fc6013b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hehe! First time Google is formally using the word "OpenID" for their Federated Login!This is also the first positive development for OpenID (technically) I am seeing in months. Gr8 work! On Tue, Jul 28, 2009 at 8:58 PM, Eric Sachs wrote: > 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 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 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 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 , 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 to learn >>> more about their implementation and view the demo and case study >> 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 addressing >>> some of the challenges with the current version (2.0) of OpenID >>> : >>> >>> >>> >>> - 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 >>> and Discovery documentation, >>> or join the discussions in the Google Federated Login API Group, >>> 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. >>> 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 >>> 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 to learn more >>> about the opportunities for the organizations. >>> >>> >>> Supporting the API for Google Apps accounts is exciting news for the OpenID >>> community , 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. >>> 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 and >>> the OpenID 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 . 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 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, >>> a provider of OpenID solutions, which already support the new API as part of >>> their RPX product . As demonstrated by UserVoice >>> using JanRain's RPX , a user simply types in her >>> Google Apps hosted domain name in the OpenID login box and everything else >>> is being taken care of: >>> >>> >>> >>> >>> >>> >>> You can find more details in our API >>> and Discovery documentation, >>> or join the discussions in the Google Federated Login API Group, >>> 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. >>> At Google.com - we already enabled it for our employees... * >>> >> >> > > _______________________________________________ > board mailing list > board at openid.net > http://openid.net/mailman/listinfo/board > > --001636458338543cb9046fc6013b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hehe! First time Google is formally using the word "OpenID" for t= heir Federated Login!
This is also the first positive development for O= penID (technically) I am seeing in months.
Gr8 work!=A0

On Tue, Jul 28, 2009 at 8:58 PM, Eric Sachs <esachs at google.com> wrote:
The Google announcement of this new OpenID service has now been formally po= sted at
http://googlecode.blogspot.com/2009/07/google-apps-openid-identity-hub-f= or.html

On W= ed, Jul 8, 2009 at 11:47 AM, Eric Sachs <esachs at google.com> = wrote:

Yes, I now realize I mi= stakenly posted this to the public instead or private board mailing list :-= ) =A0Not 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 <esachs at google.com> wrote:

Below are drafts o= f 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 th= at are outsourcing their email to Google Apps. =A0We would appreciate this = not being circulated beyond the board until it is public. =A0This new suppo= rt required that we work with the community to define some extensions to th= e OpenID discovery process. =A0While those discussions have been going on i= n the community the last few months, those extensions are not yet formalize= d and probably won't be until they are proven in production environment= s. =A0There is the potential for some community members (or press) to assum= e (or at least imply in articles) some evil intent by Google to co-opt Open= ID with these extensions. =A0It would be nice to have a blog post on the fo= rmal 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 fu= rther increase the pressure on us as a community to find more scalable UI o= ptions since the Nascar style approach obviously cannot include buttons for= these million new IDPs. =A0We have also just posted a set of summary UI gu= idelines that we will be referencing from our API documentation at=A0http://sites.google.com/site/oauthgoog/UXFedLogin/summary. =A0Th= e goal was to keep it to one-page which forced us to cut additional backgro= und information, but if you think we cut something critical, let me know.
Enterprise blog: Google Apps= + OpenID =3D identity hub for all your SaaS

We are happy to announce that the=A0Google OpenID Fed= erated Login API=A0has been extended to Google Apps accounts used by bu= sinesses, schools, and other organizations. The service is important not on= ly to the individuals in those organizations, who can interact with a varie= ty of consumer websites with a single credential <add link to Google code post>, but al= so to the organizations themselves, who are increasingly reliant on multipl= e Software as a Service (SaaS) solutions from different vendors.

For these organizations, Google Apps can no= w become an identity and data hub for multiple SaaS providers. When integra= ted with partner solutions such as XXX from=A0XXX, the Google Open ID Feder= ated 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=A0XX= X's post <add link= > to learn more about their implementation and view the demo and = case study <add links<= /span>>.

Another early adopter is=A0XXX, a SaaS proj= ect management vendor who uses the new service to make it easier for any or= ganization using Google Apps to sign up for and deploy=A0XXX=A0o their user= s:

<= div style=3D"margin-top:0px;margin-bottom:0px;text-align:center">< INSER= T SCREEN SHOTS>

Activating the OpenID Federated Login service for your domain is simple and= secure. To achieve that, we introduced a new experimental=A0discove= ry protocol=A0addressing some of the challenges with the=A0current version (2.0) of OpenID= :

=A0
Reducing the hassle of hosting discovery documents on the domain web-site -= the discovery protocol offer a solution that allows a hosted domain to bec= ome an OpenID Provider without hosting any documents at all. Optionally, a = domain may choose to host one simple file to support a more complete discov= ery flow.

Being an OpenID Identity Provider requires stro= ng security protection again attacks that could modify web pages on the sit= e. To avoid that requirement for businesses and organizations, we introduce= d digital signatures on the discovery documents and a verification flow to = support that.

You can find more details in our=A0API=A0and=A0Discovery=A0documentation, or join the discus= sions in the=A0Google Federated Login API Gro= up, where you can ask any question and get answers from with other Iden= tity Providers, Relying Parties and Google engineers.

The OpenID Federated Login Service is av= ailable for all Google Apps editions. However, it is disabled by default fo= r the Premier and Education and editions =A0, and it requires the Domain Ad= min to manually enable it from the Control Panel. So Admins -=A0go tur= n this today for your users. At Google.com - we already enabled it for = our employees...=A0

Google Code blog: Over a million new O= penID Identity Providers !
We are happy to announce that the=A0Google Op= enID Federated Login API=A0 has been extended to Google Apps accounts u= sed by businesses, schools, and other organizations. =A0Individuals in thes= e organizations can now sign in to 3rd party websites using their Google Ap= ps account, without giving away their credentials. In addition to the value= for the end-users, the new service also benefits the organizations themsel= ves, who are increasingly reliant on multiple Software as a Service (SaaS) = solutions from different vendors. For example, XXX=A0is an= early adopter, allowing any organization running Google Apps to more quick= ly sign up for and adopt their service:

<< INSERT SCREEN SHOTS>

See our post on the Google Enterprise Blog <<= span style=3D"background-color:rgb(255, 255, 0)">add link> to lea= rn more about the opportunities for the organizations.=A0

Supporting the API for Google Apps accounts is exciting news for the=A0OpenID community, as it adds numerous= new trustworthy Identity Provider (IDP) domains and increases the OpenID e= nd user base by millions. In order to allow web-sites to easily become Rely= ing Parties for these many new IDPs and users, we defined a new=A0= discovery protocol. The protocol allows Relying Parties to identify tha= t a given domain is hosted on Google Apps and securely access its OpenID Pr= ovider End Point. The current proposal is an interim solution, and we are p= articipating in several standardization organizations, such as=A0OASIS=A0= and the=A0OpenID Foundation, to generate a next-generation standard. Since the current protocol prop= osal is not supported by the standard OpenID libraries, we provided an impl= ementation of the Relying Party pieces at the Open Source project -=A0 step2.googlecode.com. Goo= gle is also offering a set of resource addressing the issues of designing a= scalable Federated Login User Interface. You are welcome to visit the=A0User Experience summary for Federated Login=A0Go= ogle Sites page, where you can find links do demos, mocks and usabilty rese= arch data.=A0

Prefer an out= -of-the-box solution? We have been working with=A0JanRain, a provider of OpenID solutions, which already support the= new API as part of their=A0RPX product. A= s demonstrated by=A0UserVoice= =A0using=A0JanRain's RPX, a user simply types in her Google Apps = hosted domain name in the OpenID login box and everything else is being tak= en care of:

<Add UserVoice (or other proposed RPX website) screenshots>

=A0

You can find more details in our=A0API=A0and=A0Discovery=A0documentation, or join the discussions in the= =A0Google Federated Login API Group, wher= e you can ask any question and get answers from with other Identity Provide= rs, Relying Parties and Google engineers.=A0=A0

The OpenID Federated Login Service is available for all Google Apps = editions. However, it is disabled by default for the Premier =A0and Educati= on editions, and it requires the Domain Admin to manually enable it from th= e Control Panel. So Admins -=A0go turn this today for your users. = At Google.com - we already enabled it for our employees...=A0

_______________________________________________
board mailing list
board at openid.net
http= ://openid.net/mailman/listinfo/board