A selector for OpenID

[Scott Kveton-3]

On Fri, Apr 18, 2008 at 7:15 PM, David Recordon <drecordon@...> wrote:
> While generally I like it, I think your choice in domain name is
>  innapropriate and not in support of the OpenID community. By choosing
>  to use the domain OpenIDSelector.com you're creating the impression
>  that this is *the* OpenID selector which I highly doubt you guys
>  intended to do.  I did provide JanRain with this feedback directly,
>  but I guess you guys disagreed. I'm so used to JanRain doing great
>  things for the OpenID community that this move really surprises me.

The #1 barrier to adoption of OpenID in 2008 will be usability ... its
a conversation we've got to have as a community and I think the ID
Selector is a great way to start.  Its not perfect, but props to the
JanRain guys for getting this started.

Let's remember that the creation of OpenID in-and-of-itself has always
been a conversation ... OpenID 1.0 was certainly not ideal but the
dialog that happened on this list made it into what it is today.  I
think the same thing has to happen with respect to usability.

We (Vidoop) is going to be deploying this for our affiliates program
and we're hoping that the feedback we get from actual users using this
will help shape its direction, etc.

- Scott
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Peter Watkins-2]

On Sun, Apr 20, 2008 at 06:32:43AM -0700, larry drebes wrote:

> Max,
> The primary goal is to make is to improve the end-user experience for
> OpenID.  There is a large user education problem that is throttling OpenID
> growth.  We were also trying to make it simple for the RP, and neutral for
> the OPs.
>
> 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.
>
> larry-

So that's "no" to making the code available for "local" OP installs?

As a site admin & developer, that's disappointing. Not terrible -- we
can always roll our own as I'd imagined anyway (which would also allow
us complete control over what OPs to list/suggest).

As a user, I think there's a privacy danger inherent in your current model
that folks should think about. The 3rd-party widget approach means that
idselector could amass information about where & when individual users hit
OpenID login pages. And it means iselector can learn what identities
individual users attempt to claim. It's not just a single point of failure,
it's a single point of data funnelling. If many RPs chose to use something
like this, it could undermine the privacy benefits of the otherwise very
decentralized/federated OP/RP model -- think doubleclick for OpenID.

-Peter

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[larry drebes]

Peter,
The  tools is configurable from the idselector.com site.  Yes, you can create a custom list of OP's, it's an easy drag & drop interface, check it out.  Feedback on additional customizations is welcome.

Just to state the obvious, The mission of the idselector is not to gather a bunch of data for Janrain so that it can be exploited or abused.   We talked to many RP's & OP's  in the last weeks to make sure it was a neutral offering.  We have added the same level of security around idselector as our myopenid OP.  It's one of the few widgets on the internet that loads entirely over ssl.   We see the widget as an ecosystem enabler, just as our opensource libraries are.

larry-

On Sun, Apr 20, 2008 at 7:49 AM, Peter Watkins <peterw@...> wrote:

On Sun, Apr 20, 2008 at 06:32:43AM -0700, larry drebes wrote:
> Max,
> The primary goal is to make is to improve the end-user experience for
> OpenID.  There is a large user education problem that is throttling OpenID
> growth.  We were also trying to make it simple for the RP, and neutral for
> the OPs.
>
> 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.
>
> larry-

So that's "no" to making the code available for "local" OP installs?

As a site admin & developer, that's disappointing. Not terrible -- we
can always roll our own as I'd imagined anyway (which would also allow
us complete control over what OPs to list/suggest).

As a user, I think there's a privacy danger inherent in your current model
that folks should think about. The 3rd-party widget approach means that
idselector could amass information about where & when individual users hit
OpenID login pages. And it means iselector can learn what identities
individual users attempt to claim. It's not just a single point of failure,
it's a single point of data funnelling. If many RPs chose to use something
like this, it could undermine the privacy benefits of the otherwise very
decentralized/federated OP/RP model -- think doubleclick for OpenID.

-Peter

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Thomas Roessler]

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@...>
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Peter Williams-15]

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)

 

Two immature things have gone on, I think:

 

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)?

 

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.

 

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.

 

_________________________
Peter Williams

---

From: Thomas Roessler
Sent: Sun 4/20/2008 10:00 AM
To: larry drebes
Cc: general@...
Subject: Re: [OpenID] A selector for OpenID

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@...>
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Thomas Roessler]

On 2008-04-20 19:00:44 +0200, Thomas Roessler 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

I mis-typed: That should have been the OpenID identity *selector*,
as implemented in this case, not the OpenID identity *provider*.

> dreadful "two sites, one DOM" anti-pattern.

On 2008-04-20 11:13:52 -0700, Peter Williams wrote:

> 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 point is precisely that the way in which this identity selector
is being deployed goes beyond the amount of centralized control
that's the nature of the beast.

Regards,
--
Thomas Roessler, W3C  <tlr@...>  [phone]
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Eddy Nigg (StartCom Ltd.)]

Peter Williams:

 

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)?

 

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.

There is certainly something in what you say...I think that's perhaps a quite correct analysis about the current state of the OpenID foundation. Interesting!

 

_________________________
Peter Williams

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Peter Watkins-2]

On Sun, Apr 20, 2008 at 08:21:25AM -0700, larry drebes wrote:

> Peter,
> The  tools is configurable from the idselector.com site.  Yes, you can
> create a custom list of OP's, it's an easy drag & drop interface, check it
> out.  Feedback on additional customizations is welcome.
>
> Just to state the obvious, The mission of the idselector is not to gather a
> bunch of data for Janrain so that it can be exploited or abused.   We talked
> to many RP's & OP's  in the last weeks to make sure it was a neutral
> offering.  We have added the same level of security around idselector as our
> myopenid OP.  It's one of the few widgets on the internet that loads
> entirely over ssl.   We see the widget as an ecosystem enabler, just as our
> opensource libraries are.
>
> larry-

Thanks for the clarification. Loading over https is immaterial -- the privacy,
security, and availability concerns remain. I'm not sure why you seem drawn
to the remote scripting model, as opposed to offering a link or attribution
model that would resolve all social and technical concerns about idselector
*and* reduce your infrastructure costs, but I don't want to drag this out.
I think I've made clear already for whatever it's worth that
 1) As an admin, I'd never use a remote scripting service like this.
 2) I think wide adoption of idselector could adversely affect OpenID's uptake
    given the intrinsic privacy problems with your model. As Thomas said,
    your model goes far beyond any regular OpenID "nature of the beast" concerns.

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.

Not trying to be sarcasatic at all -- it does look quite nice.

-Peter

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Eddy Nigg (StartCom Ltd.)]

Peter Watkins:

On Sun, Apr 20, 2008 at 08:21:25AM -0700, larry drebes wrote:
  

Peter,
The  tools is configurable from the idselector.com site.  Yes, you can
create a custom list of OP's, it's an easy drag & drop interface, check it
out.  Feedback on additional customizations is welcome.

Just to state the obvious, The mission of the idselector is not to gather a
bunch of data for Janrain so that it can be exploited or abused.   We talked
to many RP's & OP's  in the last weeks to make sure it was a neutral
offering.  We have added the same level of security around idselector as our
myopenid OP.  It's one of the few widgets on the internet that loads
entirely over ssl.   We see the widget as an ecosystem enabler, just as our
opensource libraries are.

larry-
    

Thanks for the clarification. Loading over https is immaterial -- the privacy, 
security, and availability concerns remain. I'm not sure why you seem drawn
to the remote scripting model, as opposed to offering a link or attribution
model that would resolve all social and technical concerns about idselector 
*and* reduce your infrastructure costs, but I don't want to drag this out. 
I think I've made clear already for whatever it's worth that 
 1) As an admin, I'd never use a remote scripting service like this.
 2) I think wide adoption of idselector could adversely affect OpenID's uptake 
    given the intrinsic privacy problems with your model. As Thomas said,
    your model goes far beyond any regular OpenID "nature of the beast" concerns.

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.

Not trying to be sarcasatic at all -- it does look quite nice. 
  

I too think it does look quite nice. I'm not sure what Larry's intentions really are, but for many it doesn't matter where it's hosted and therefore provides an excellent service. For others there might be an option to download an archive and serve it locally? I think that would be the killer app for all OpenID RP implementations and would provide a familiar face for future common login facilities....

Larry, do you have such intentions?



_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[SitG Admin]

>I'm not sure what Larry's intentions really are, but for many it
>doesn't matter where it's hosted and therefore provides an excellent
>service.

Are we speaking of RP's or users here? It's easy to say "oh security
doesn't matter" when you're not the one who stands to lose out, but I
think that regardless of the confidence we (as Relying Parties) may
have, it's important to notify our users when something like this is
happening. Even though the privacy this abandons isn't (and shouldn't
be) part of the specs, OpenID can still lead the user to *expect*
such privacy, and going against the "spirit" of OpenID while
appearing to merely provide convenience for users looks like a recipe
for disaster. Not just in the form of backlash against sites that do
this, but against OpenID's reputation; sure, we can say "This isn't
part of OpenID and is not required to implement OpenID, so it doesn't
reflect poorly on OpenID itself.", but how much good will that be
when a 3rd-party ID Selector is popular enough to be considered *the*
OpenID Selector?

-Shade
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Grant Monroe]

On Sun, Apr 20, 2008 at 5:11 PM, Peter Watkins <peterw@...> wrote:
>  Thanks for the clarification. Loading over https is immaterial -- the privacy,
>  security, and availability concerns remain. I'm not sure why you seem drawn
>  to the remote scripting model, as opposed to offering a link or attribution
>  model that would resolve all social and technical concerns about idselector
>  *and* reduce your infrastructure costs, but I don't want to drag this out.

One technical reason why the ID Selector is centralized is because the
ID Selector will auto-fill forms on sites a user has never visited. If
you've visited one RP using the ID Selector, your openid will be
auto-filled when you visit any other new RP (provided that the new RP
is using the ID Selector).

--
 Grant Monroe
 JanRain, Inc.
 Pibb Me: https://pibb.com/me/grant.myopenid.com
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Sam Alexander-4]

>
> 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@...
http://openid.net/mailman/listinfo/general

[Eddy Nigg (StartCom Ltd.)]

SitG Admin:

Even though the privacy this abandons isn't (and shouldn't 
be) part of the specs, OpenID can still lead the user to *expect* 
such privacy, and going against the "spirit" of OpenID...

LOL... about which spirit are you talking about? About having the exchange between OP-RP and client-RP in plain text?

but how much good will that be when a 3rd-party ID Selector is popular enough to be considered *the* 
OpenID Selector?
  

Make your own and compete... :-)



_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Peter Watkins-2]

On Sun, Apr 20, 2008 at 08:37:50PM -0700, Grant Monroe wrote:
>
> One technical reason why the ID Selector is centralized is because the
> ID Selector will auto-fill forms on sites a user has never visited. If
> you've visited one RP using the ID Selector, your openid will be
> auto-filled when you visit any other new RP (provided that the new RP
> is using the ID Selector).

That makes sense, but raises another privacy issue -- it seems likely
that code from the RP could detect this autocompletion and learn more
than the user wanted to disclose. I have a number of different OpenID
URLs, and I might not want one RP seeing the identifier I claimed on
another RP. You should give users the option of disabling this, and you
should consider remembering the last identifier claimed per RP -- if
I used my AIM screenname when I visited Site X last week, that's the
identifier I'll probably use again today; Site X does not need to know
the Blogger identity I used at Site Y yesterday.

Even if Site X didn't try to capture that data, I might be spooked that
Site X displayed my Site Y identity and therefore *appeared* to know it.
What happens when an activist visits the FBI site and sees it autocomplete
to whistleblower.blogger.com or some such? I'm thinking about some slides
from a presentation that, IIRC, David R gave a long time ago about the
value of users having different nyms in different contexts. "New site"
autocomplete threatens David's multiple-nym model in both appearance
and fact. With RP-hosted code you could trivially get intelligent
per-RP autocompletion that didn't have that drawback.

And it doesn't need to be either-or. I believe there could be "Save" and
"Lookup" buttons in RP-hosted code that would use simple DOM tricks to
pass info to/from idselector via pixel shims & querystrings so the
activist could click Lookup on the FBI site if she really wanted to
autofill the OpenID identity she last used online. But absent a click on
Lookup or Save, there wouldn't be any traffic to idselector. Admittedly
worse for ease of use than always trying to autocomplete, but better
in some other regards.

And of course there's the option of client-side code: Firefox and IE Add-Ons,
something more like the CardSpace client-side ID selector.

-Peter

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Peter Williams-15]

A few issues are worth bringing up.

 

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.

 

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.

 

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).

 

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?

 

2. I'd venture that the OpenID movement will benefit from B2C models that clearly distinguish it from B2B federation models like SAML2 websso associates itself with. The B2C theme is obvious. Its 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.

 

The final issue in my mind is that of money. 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.

 

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.

 

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.

 

_________________________
Peter Williams

---

From: Sam Alexander
Sent: Mon 4/21/2008 12:22 AM
To: Peter Watkins
Cc: general@...
Subject: Re: [OpenID] A selector for OpenID

>
> 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@...
http://openid.net/mailman/listinfo/general

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Martin Atkins-2]

Peter Williams wrote:

>  
> 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)?

In general, the foundation is about publishing specifications, not
implementations. While it is expected that individuals and organisations
will comply with the Foundation's IPR policy in contributions to
published specifications, implementors are under no obligation to go
through the foundation for their implementations. (However, it is true
to say that the Foundation has attempted to encourage implementation
though initiatives such as the bounty program.)

> 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.
>  

It is true that the Foundation has thus far been unable to put
significant resource into usability issues. However, there is clear
interest in forming a user experience work group as one of the first
work groups ratified by the foundation once the voting system for
members is in place. This work is underway as we speak.

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[SitG Admin]

Some parts of this message have been removed. Learn more about Nabble's security policy.

>Even though the privacy this abandons isn't (and shouldn't
>be) part of the specs, OpenID can still lead the user to *expect*
>such privacy, and going against the "spirit" of OpenID...
>

>

>LOL... about which spirit are you talking about? About having

>the exchange between OP-RP and client-RP in plain text?

No, about the *privacy* that results from *DEcentralization*!

The users of OpenID have good reason to expect such a level of privacy. The widget would remove that level of privacy. If we tried to promote OpenID by widespread adoption of this widget, we'd be giving our detractors more ammunition with which to declare that OpenID is just an attempt to make everything available in one location so "Big Brother" (or any other interested parties) need merely target ONE entity to achieve their ends - and our arguments that the lack of any central Provider for our OpenID identities prevents such a scenario would no longer be true.

>Make your own and compete... :-)

I'm taking a minimalist approach to site design, so I probably wouldn't *use* it, but I'll see if I can find the spare time.

To learn Java ;)

-Shade

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[SitG Admin]

>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.

I prefer to think of this as a more of a "profit of opportunity" than
a deliberate deception - at least for some of us. I don't think
OpenID (or the movement around it) BEGAN as an idea for how to make
money.

>I also don't really understand why the policy continues to be in place.

Because some of us still believe in it?

>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.

They may be idealistic but then again they may be in accordance with
the intended spirit of the technology - the question is, will this
community sell-out in the name of popularity and money, or accept a
slower growth rate in exchange for keeping OpenID as it was
originally meant to be?

-Shade
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general