[OpenID] Google Apps, dependencies, failover and UCI

Mon Dec 8 17:11:05 UTC 2008

Peter: I have no idea what you're talking about. Sorry.
I was merely pointing out that the Google group feature, while technically
very usable, may have some issues in ease-of-signup for people who
want to use emails from Google hosted domains. For some that itself may
make them not participate.

I still want to know why there isn't enough money within OIDF to
independently
operate these lists using open and free technology. Last time I checked,
those kind
of things were kinda central to the OpenID philosophy.

Hans

On Mon, Dec 8, 2008 at 7:52 AM, Peter Williams <pwilliams at rapattoni.com>wrote:

>  Hans:
>
>
>
> Re: Per your memo (enclosed below)
>
>
>
> In defense of Google, I've had only sterling success with their websso to
> Google Apps. In engineering terms, we can perhaps analyze it, and perhaps
> glimpse at their openid services for their SPs (as they evolve, them).
>
>
>
> The Google SP optionally administers with a local id (allowing
> administrative failover, when the sso links break), and users can (SAML2)
> websso into it as an entirely standards-based SP once the SP->IDP link is
> manually configured. As an SP, it aggregates several applications into its
> local session. However, they can be targeted individually as resources when
> performing websso, since the websso service hooks up nicely with the
> complementary DNS naming and service mappings for the hosted domains.
>
>
>
> All in all, it's well thought through -  through its very, very expensive
> at $50 per annum, per user. I've no doubt there are major price breaks for
> volume of n0,000 users… in which case it would be viable for integration
> with our realty "MLS", for example,once down to $0.50-$1 a month. A large
> percentage of our users choose gmail anyways (where we send about 100G of
> data to gmail accounts every night, after running the users' custom
> data-crawls!)  I'm sure individuals would authorize $0.50 cents a month for
> the convenience of websso to their gmail from their main console. They
> already do that to websso to a dozen other sites, after all. If now paid for
> by search ads on the websso UI, that src of funding might even overcome the
> current, total-resistance to (Google) ads.
>
>
>
> Technically, Google Apps performs sp-initiated websso flow (essentially
> like openid1), and has been tuned so that one IDP aggregator/endpoint can
> host n IDP tenants (all on the same switching entityID/cert). This allows an
> approximation of the OpenID-style delegation, where the level1 IDP acts as a
> delegation/proxy resolver. That first line IDP known to Google performs
> rerouting (though Google are not exploiting SAML2 grade security signed
> requests), and vectors the request upstream to a 2nd-level IDP delegated
> by the user or selected interactively (in our implementation). These
> upstream failover dynamics can all hidden from the SP (unlike in the control
> system design used by OpenID2.) but are clearly intended by the Google
> architecture.
>
>
>
> It's by no means all as cute as a real openid2 SP->OP, with user-controlled
> (signed) XRDS being accessed directly by SPs. But it's the best SAML2 SP
> I've personally seen on a consumer-grade website, where all sso/dns
> configuration can be done without needing specialized engineers. Hey, even I
> could do it.
>
>
>
> WebSSO is all about dependencies. The trick (having managed this kind of
> integration for 2 years now  with a variety of sso folk with a wide range of
> security engineering training) is to ensure all the failovers work – for
> when the public web/internet breaks. This is why I personally  focus on
> failopen, loosely-coupled, user-centered control system designs.. as its
> very orientation has side-effect that take care of vast majority of
> inter-system dependencies. By getting the intelligent human being involved
> in failover (only) early on, we avoid the support phone call that we cannot
> afford to service.
>
>
>
> So, I give Google an A- on websso design and execution (as I've seen it).
> They can go for optional extra credit and be awarded an A, if they would
> sign the auth requests.
>
>
>
>
>
> *From:* general-bounces at openid.net [mailto:general-bounces at openid.net] *On
> Behalf Of *Hans Granqvist
> *Sent:* Sunday, December 07, 2008 10:25 PM
> *To:* openid-general General
> *Subject:* Re: [OpenID] We Need Less Bureaucracy But Also More
> Transparency
>
>
>
> Google groups are broken. I can't sign up to groups with any email address
> I want.
>
> My main domain is hosted by Google Apps and I cannot sign up with any email
>
> address on this domain. Though I suppose I should be able to, the Google
> reps
>
> I've spoken or emailed to (several) can't fix it. I wonder how many else
>
> would be in the same situation.
>
>
>
> Regardless, you cannot have dependencies if you want to stay open, right?
>
>
>
> If there is more money needed to keep mailman and servers going, and OIDF
> is
>
> unable to pay (are they?), why not politely request a cut from the
> conferences
>
> making money around the standard?
>
>
>
>
>
> On Fri, Dec 5, 2008 at 5:36 PM, Peter Williams <pwilliams at rapattoni.com>
> wrote:
>
> Does the foundation resolve to deem acceptable google's privacy practices
> (since thats the indirect endorsement).
>
> Can't whine about janrain without doing the same to all.
>
> has anyone even reviewed them yet for political correctness (while facebook
> meantime cleansup).
>
> Satire.
>
>
> -----Original Message-----
> From: SitG Admin <sysadmin at shadowsinthegarden.com>
> Sent: Friday, December 05, 2008 6:31 PM
> To: David Recordon <drecordon at sixapart.com>
> Cc: general at openid.net <general at openid.net>
> Subject: Re: [OpenID] We Need Less Bureaucracy But Also More Transparency
>
>
> >I keep wanting to see us move to Google Groups
>
> So long as we can make clear that it isn't an endorsement? ;)
>
> I understand that Google has an interest in *their* system being
> used, and offering a mere publicly searchable archive (open Gmail
> account subscribed to the list) wouldn't stop users from using their
> *other* systems, but the topology of such a solution resembles the
> idea of UCI: instead of going with a single central interface, users
> go with the list (their 'open' choice) and can login to Google with
> their OpenID's to see an aggregated dataset (or, if they like what
> Google is marketing, opt to upgrade to a Gmail account so they can
> begin integrating their private messages with that dataset, too).
>
> -Shade
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081208/feea4da7/attachment-0002.htm>