<div class="gmail_quote">On Mon, Dec 8, 2008 at 9:11 AM, Hans Granqvist <span dir="ltr"><<a href="mailto:hans@granqvist.com">hans@granqvist.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><br></div><div>I was merely pointing out that the Google group feature, while technically </div><div>very usable, may have some issues in ease-of-signup for people who</div>
<div>want to use emails from Google hosted domains. For some that itself may </div><div>make them not participate. </div></blockquote><div><br></div><div>This is something that really is painful about Google Groups and in the groups that I administer, I offer to add non-Google hosted accounts manually. Given the spam that all centrally hosted mailing lists attract, I presume that the change had something to do with that.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>I still want to know why there isn't enough money within OIDF to independently</div>
<div>operate these lists using open and free technology. Last time I checked, those kind</div><div>of things were kinda central to the OpenID philosophy. </div></blockquote><div><br></div><div>I don't think it's a matter of cost, per se, but of motivation, resources, expertise and focus.</div>
<div><br></div><div>We already operate the lists using free and open technology (mailman). It works fine. It's just that the interface is straight out of 1992. Google Groups provides a much more elegant user experience; if we could simply port the Google Groups UI to mailman, I'd be satisfied (enabling OpenID on mailman also seems like an imperative that someone with copious free time should take on).</div>
<div><br></div><div>Markmail is cool -- and I'd forgotten that it existed. It's certainly a nicer UI than the existing default mailman UI, and that it provides XML-representations of messages means that we could, again, with motivation and time, develop a seamless message-browsing interface on <a href="http://openid.net">openid.net</a> built on open technologies. In the scheme of things, it just seems more cost and time effective to use existing solutions, even if they're less than flawless.</div>
<div><br></div><div>Chris</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div></div><div><br></div><font color="#888888"><div>Hans<br></div></font><div>
<div></div><div class="Wj3C7c"><div><div><br></div><div><br>
</div><div><br><div class="gmail_quote">On Mon, Dec 8, 2008 at 7:52 AM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p><span style="font-size:11.0pt;color:#1F497D">Hans:</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">Re: Per your memo (enclosed below)</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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).</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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. </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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. </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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 2<sup>nd</sup>-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.</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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.</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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. </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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.</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt">
<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a> [mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>] <b>On Behalf Of </b>Hans
Granqvist<br>
<b>Sent:</b> Sunday, December 07, 2008 10:25 PM<br>
<b>To:</b> openid-general General<br>
<b>Subject:</b> Re: [OpenID] We Need Less Bureaucracy But Also More
Transparency</span></p>
</div>
<p> </p>
<p>Google groups are broken. I can't sign up to groups with any
email address I want.</p>
<div>
<p>My main domain is hosted by Google Apps and I cannot sign up
with any email</p>
</div>
<div>
<p>address on this domain. Though I suppose I should be able
to, the Google reps</p>
</div>
<div>
<p>I've spoken or emailed to (several) can't fix it. I
wonder how many else </p>
</div>
<div>
<p>would be in the same situation.</p>
</div>
<div>
<p> </p>
</div>
<div>
<p>Regardless, you cannot have dependencies if you want to stay
open, right?</p>
</div>
<div>
<p> </p>
</div>
<div>
<p>If there is more money needed to keep mailman and servers
going, and OIDF is</p>
</div>
<div>
<p>unable to pay (are they?), why not
politely request a cut from the conferences </p>
</div>
<div>
<p>making money around the standard?</p>
</div>
<div>
<p> </p>
</div>
<div>
<p style="margin-bottom:12.0pt"> </p>
<div>
<p>On Fri, Dec 5, 2008 at 5:36 PM, Peter Williams <<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>> wrote:</p>
<p>Does the foundation resolve to deem acceptable google's
privacy practices (since thats the indirect endorsement).<br>
<br>
Can't whine about janrain without doing the same to all.<br>
<br>
has anyone even reviewed them yet for political correctness (while facebook
meantime cleansup).<br>
<br>
Satire.</p>
<div>
<div>
<p><br>
-----Original Message-----<br>
From: SitG Admin <<a href="mailto:sysadmin@shadowsinthegarden.com" target="_blank">sysadmin@shadowsinthegarden.com</a>><br>
Sent: Friday, December 05, 2008 6:31 PM<br>
To: David Recordon <<a href="mailto:drecordon@sixapart.com" target="_blank">drecordon@sixapart.com</a>><br>
Cc: <a href="mailto:general@openid.net" target="_blank">general@openid.net</a> <<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><br>
Subject: Re: [OpenID] We Need Less Bureaucracy But Also More Transparency<br>
<br>
<br>
>I keep wanting to see us move to Google Groups<br>
<br>
So long as we can make clear that it isn't an endorsement? ;)<br>
<br>
I understand that Google has an interest in *their* system being<br>
used, and offering a mere publicly searchable archive (open Gmail<br>
account subscribed to the list) wouldn't stop users from using their<br>
*other* systems, but the topology of such a solution resembles the<br>
idea of UCI: instead of going with a single central interface, users<br>
go with the list (their 'open' choice) and can login to Google with<br>
their OpenID's to see an aggregated dataset (or, if they like what<br>
Google is marketing, opt to upgrade to a Gmail account so they can<br>
begin integrating their private messages with that dataset, too).<br>
<br>
-Shade<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a></p>
</div>
</div>
</div>
<p> </p>
</div>
</div>
</div>
</blockquote></div><br></div></div>
</div></div><br>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Chris Messina<br>Citizen-Participant &<br> Open Technology Advocate-at-Large<br><a href="http://factoryjoe.com">factoryjoe.com</a> # <a href="http://diso-project.org">diso-project.org</a><br>
<a href="http://citizenagency.com">citizenagency.com</a> # <a href="http://vidoop.com">vidoop.com</a><br>This email is: [ ] bloggable [X] ask first [ ] private<br>