<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText1942 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Like message brokering, hosted id brokering in the cardspace model has been guilty of having a potential control and tracking model. Its the nature of the beast. The trick is of course to present the deployment options in a manner that allows anyone to be the broker (which is another Peter's main point) -- which ameliorates the analogy with centralized Passport (by the openid backdoor)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Two immature things have gone on, I think:</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>First, this was apparently not a Foundation-led initiative, discussed before launch through WGs and having gone through at least some consensus processes deciding on technical specs. Its was a pre-Foundation-days evangelist-grade activity, apparently, where consensus was established (if actually any) using non Foundation channels. This suggest the Foundation process is not working well in the US branch, since.. why was this NOT first put through the emerging processes and the associated IPR controls (much like the openid+cardspace stuff is doing)?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Second, perhaps the Foundation's immaturity and "unmanaged" approach in determining the priority of issues is itself a bit to blame, since it evidently just can NOT focus on the non-usability of the dominant OpenID experience to date. Various dogmatic positions are oft repeated, and reinforced, like a religious mantra. Perhaps one has to use such shots across the bow, to get attention and put issues on the table.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>These whines of mine are only about growing pains at the end of the day. It all looks very healthy and vibrant overall. The more that argument overflows from the commercial backrooms to open lists, the better a community process is working.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV></DIV>
<DIV id=idSignature49737>
<DIV><FONT face=Arial color=#000000 size=2><SPAN style="FONT-SIZE: 7.5pt">_________________________<BR></SPAN><B>Peter Williams<BR></B></FONT><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Thomas Roessler<BR><B>Sent:</B> Sun 4/20/2008 10:00 AM<BR><B>To:</B> larry drebes<BR><B>Cc:</B> general@openid.net<BR><B>Subject:</B> Re: [OpenID] A selector for OpenID<BR></FONT><BR></DIV></DIV>
<DIV><PRE style="WORD-WRAP: break-word">On 2008-04-20 06:32:43 -0700, larry drebes wrote:
> The javascript attaches to an existing OpenID login form. In the
> (rare) case the javascript could not load from the (high
> available) idselector server, the form will continue to work,
> just with out a default value.
Unfortunately, the OpenID identity provider is another case of the
dreadful "two sites, one DOM" anti-pattern: Embedding the selector
widget means loading an arbitrary script from idselector.com,
running with an origin of the relying party service; in lots of use
cases, it means that the relying party web application will end up
being under the control of janrain.com - or, more precisely,
whatever party will control the idselector.com domain name or the
web server that's operting that site.
The flaw here isn't just about the possibility for idselector.com to
gather data about use of OPs in a centralized sopt: It's about
idselector.com becoming a central point of control for
OpenID-enabled web applications.
Regards,
--
Thomas Roessler, W3C <tlr@w3.org>
_______________________________________________
general mailing list
general@openid.net
http://openid.net/mailman/listinfo/general
</PRE></DIV></BODY></HTML>