<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText48247 dir=ltr>
<DIV dir=ltr><FONT face=Arial size=2>Oh well, its now hopefully an irrelevant topic for now. JanRain just made an obvious community-spirited effort by not enabling anyone to argue (much further) over their choice of name for a fascinating new feature! Hopefully, we can focus on the feature itself! </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>In my view JanRain are possibly hearing and properly reacting what we hear back from our pilot groups: the average business user will not adopt the default OpenID GUI while users have to type in a damn URL, several times a day. The cost of Sxipper to have their FF plugin post the form field is (im guessing) 2 months service revenue (in our market), and would cost $15-20 per user in support/installation cost for the bottom 25% of the user community. That's pretty prohibitive adoption economics (in our market). In terms of JanRain's adwords-like dynamic applied to OpenID, that is just a smart move. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I think we need a buzzword name for this "adword" practice, and a framework for warning: the concept is very similar in essence to an (abandoned) RFP tender issued last year in realty to let the presentation order of SSO links be "paid for", as indirect advertising/brand-promotion of the many home conveyancing/closing services seeking out clients in a trillion dollar business. The problem is that its preceived as influencing the very realtors, who inevitably recommend services to homeowners (did you choose your own title company!!? Last time) . Unfortunately its also their job to be a trusworthy counsel to homeowners... creating and ethical council conflict, which needed to address the conflicting issues of trust and impropriety - in a professional space)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>-----------</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Lets turn to what we learned about trandemarks specifically tho, and test what happens.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I suppose I ought to now expect the Foundation's legal notice, concerning "my" UN-authorized use of openid2.blogspot.com (setup to see what blogspot did and did not do, re OpenID1 and OpenID2 support). Presumably, the paralegal's nastygram would actually go to Google, who will surely dump me as a subscriber faster than a photon moves. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>If I now think as a security specialist and focus on the compromise recovery phase use cases, I suppose that the impact of such an account suspension/removal for the blog - on my UCI delegation setup - would be 100% up to me to fight out with this and any other trademark owner who merely _asserts_ infringement. Any commercial entity like a Live.com, Google or Yahoo will act on it regardless of little ol #me; and notice time will be zero, I have little doubt, to minimize risk to the operator. Generally, fightingthe notice will takes time, in the meatime one needs to ensure there can be little impact. Obviously, one needs to ensure there _is_ a real, per-notice cost to the asserting/servicing party, as a dis-incentive against wide area abuse.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>At first glance, it looks like OpenID and the reliance on redundant discovery got things right tho - as a critical infrastructure design with compomise recovery capabilities. The design seems to ensure that its cheap and easy to have several delegation points setup with redundant security contexts - and pre-keyed session caches at the supporting OPs. These can be pushed into service and pre-made for folks, ready for such events (new startup business model!!?). Such preparations do not withstand generalized legal shutdown/take-down orders (and they are not meant to). In taking such precautions, one is simply being a responsible UCI-comprehending consumer, preparing to cope with impact on #your OPenID discovery that the inevitable self-interest of those commercial parties providing ad-funded "free blog services" would have. In business this would be an issue of intangible goodwill asset, with accountable value and risk - since your contractors parties can now influence <FONT face=Arial size=2>those via their impact on #your connectivity and #your responsiveness properties #</FONT>your OpenID reputation, in the openid trust model.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV></DIV>
<DIV id=idSignature9500>
<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> Brian Ellin<BR><B>Sent:</B> Sat 4/19/2008 10:33 AM<BR><B>To:</B> Dick Hardt; drecordon@sixapart.com; Johannes Ernst<BR><B>Cc:</B> openid-general List<BR><B>Subject:</B> Re: [OpenID] A selector for OpenID<BR></FONT><BR></DIV></DIV>
<DIV><PRE style="WORD-WRAP: break-word">Thanks for the feedback on the name. Just wanted to let everyone know
that we'll be changing it from openidselector.com to idselector.com so
as not to infringe on the OpenID mark.
This change will be made over the next few days. Stay tuned for an update.
Brian
> on behalf of the foundation, I would echo Johannes diplomatic request
>
> -- Dick
_______________________________________________
general mailing list
general@openid.net
http://openid.net/mailman/listinfo/general
</PRE></DIV></BODY></HTML>