<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText75090 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>A few issues are worth bringing up.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>If the script is filling in the openid field form, acting as a form filler, it will evolve to supply hidden sreg fields to some RPs, too. Why would it not do so? That is obviously as much an RP and end-use benefit as is the openid field's form-filling activity.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I do think we should de-personalize the discussion though - and focus on the merits and demerits of the feature and options for delivery vehicles for such services. For purely formal reasons, there should be a formal delivery of IP to a WG, too - to at least show "consistency with" the main mantras the Foundation has promoted on, thus heading off IPR issues at the pass.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>We can focus on comparing what it is that OpenID auth would be providing (in the sreg area) that such a RP-plug-in will not be providing - one given the RP the opportunity to go around what an OpenID2 OP is all about (enforcing law#4).</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>1. Its pretty obvious that OpenID RPs need a general solution to the initial usability problem (filling a login field in, be it URL or XRI) . And, we can note that XRI may be the really big winner here. Given the nature of OpenID tech in requiring and leveraging discovery as its distinguishing breakthrough, can we afford to make a distinction between the URL - as a personal, traceable data field by the megaplex Googles of the world - and the other sreg fields?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>2. I'd venture that the OpenID movement will benefit from B2C models <FONT face=Arial size=2>that clearly distinguish it from B2B federation models like SAML2 websso associates itself with. The B2C theme is obvious. Its </FONT>rewarding brands with greater exposure, once they bring on users or adopt openid services. Its also rewarding those management bureau players that perform the intermediation and factoring, brokering OP brands and RP brands like "Reuters" does in the financial world.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>The final issue in my mind is that of money. </FONT><FONT face=Arial size=2>We have to note that the topic is also stressing the "no one is trying to make money from this" mantra . The way we saw this particular feature rollout was very commercial: folks admit its designed as a brand reward system, it promotes folks to adopt the vendor's identity management services and some but not other RPs were pre-exposed to the feature when vetting its nature . Now, I personally have not the slightest objection to any of those practices, or the indirect $$ or intangible asset value flow that attaches to any of the participants. Good luck! I do think it shows that the mantra about non-commercialism is somewhat of a sham (and shams are never good news ), as folks ARE making money or gaining value from the technology indirectly. I don't think anyone is fooled on this. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I also don't really understand why the policy continues to be in place. OpenID seems to have already grown up and out of evangelism-based processes where it was useful and typical, and perhaps ought no longer to be constrained from engaging in explosive growth that pecuniary motivations tend to do rather well at engendering. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>OpenID has obviously passed its tipping point and doesn't need artificial idealistic constraints that could well make it miss the window of mass exposure that fortune has granted the movement.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2><SPAN style="FONT-SIZE: 7.5pt">_________________________<BR></SPAN><B>Peter Williams<BR></B></FONT><BR></DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr><FONT face=Tahoma size=2><B>From:</B> Sam Alexander<BR><B>Sent:</B> Mon 4/21/2008 12:22 AM<BR><B>To:</B> Peter Watkins<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">>
> I do think something like ideslector is a good idea. As I said
> earlier, I'd been
> thinking about this sort of thing for making it easier for regular
> AOL and Yahoo!
> users to use OpenID on the sites I'm responsible for. I can only
> hope that your
> remote scripting model "fails in the marketplace" as we Yanks like
> to say. No malice
> intended, I just think hosting the resources outside the RPs is the
> wrong approach.
Lets be fair here, I think its safe to compare this to, say, Google's
Urchin analytics scripts. That script is hosted off-site, and is
gathering and tracking a helluva lot more data than JanRain's
idselector.com. [1]
Is this an anti-pattern? Perhaps, but it is one that website
developers are aware of and either completely avoid (as Peter has
brought up), or knowingly submit to. We should probably decry Google
as well, but my point is that judging by the sheer volume of those who
use Urchin, there are some sites for which this is not a concern.
All of the information about the providers listed in the idselector is
publicly available, and most of it is actually listed on OpenID.net.
To create your own in-house-only version of idselector.com would
require very little expertise. In fact, the script provided by
JanRain is kindly not obfuscated at all, so if one needs help, one may
just take-a-peak. You should probably ask JanRain first, but judging
from their community record, I bet they'd jump at the chance to help.
I actually hope this approach will do quite well. Why? Because
JanRain has provided the most "crutch-less" solution available today.
They have created a very usable, click-friendly, logo-happy solution
-- all without hiding the fact that your OpenID is (gasp) a URL!
While a user can still do things in just a few clicks, they are not
completely in-the-dark about the process.
While interaction designers are trained to hide as much of the
'implementation model' (meaning whats really going on) as possible --
I think that we ALL win when Uncle Cletus shows up at your website
(which doesn't have the idselector.com script) yet still remembers to
type in http://unclecletus.myopenid.com because thats what he's used
to seeing in the input field when he clicks the "Sign In" button.
-Sam
[1] Which, lets not forget, should by its very nature only be included
on non-logged-in user's pages, creating a much less attractive honey
pot should the very worst happen
_______________________________________________
general mailing list
general@openid.net
http://openid.net/mailman/listinfo/general
</PRE></DIV></BODY></HTML>