talking web X.0

This sounds like a very useful service for the OpenID community. However, for the individual OpenID user, I think there’s a danger of privacy violation. I don’t think part of the implicit “social contract” of OpenID is that trust roots of RPs that a user is logging into get published to another site without their consent. In fact, I don’t think any part of the user’s login should be reported to a third party without their knowledge or consent.

For example, if I were starting a new, unlaunched Web site, and I was testing its OpenID functionality, I’d be pretty mad if its trust root URL showed up in a public directory. If the trust root was for an embarrassing web site, or if it included personally-identifying information, I think it would also be a problem.

I think that there’s a possibility for using this service that would minimize intrusion and privacy concerns. A couple of ideas: an opt-in checkbox on the trust form for when the user first logs in using some trust root (”(Optional) Add this trust root to the OpenID Directory?”), and caching trust roots at the IdP side so it doesn’t ask unless the URL is really new.

Hi Evan,
I absolutely agree on the checkbox idea. I already proposed this on the OpenID general mailinglist. I think it fits in well on the screen you see when you first login to a site.

The caching mechanism could even be improved if we would offer a ping-service that allows you to check if the trustroot is already submitted to the OpenID Directory (after checking that the URL is new to the IdPs own database).

But as we are coming closer to the relaunch of the OIDD we may have to rethink the ping-service again. The new OIDD will have OpenID login (and nothing else ) and the possibility to take control of the title, description, thumbnail etc. of the sites you submitted yourself.

But who should submit sites at all? The webmasters themselfs, I think. For the moment we do not ckeck if the submitter of a site is its owner (by micro-ids e.g.), but this can be an issue if we get complaints about this liberal practice.

So the question is if we should leave it up to the user of an IdP to add a site to the OIDD or should we at least try to catch only the webmasters by simply putting a button there saying “Are you the webmaster of this trustroot? Add your site to the public OpenID Directory for free!”. This could jump to a new window (not interrupting the login process) leading the webmaster to the OIDD submission. Here he can take full control over the represantation of his site.

This would mean less manual work for the editors of the OIDD and better control for webmasters. This would also mean omitting the auto-submission and replacing it by a simple service that returns you a yes or no answer for the question if a trustroot is already listed on the OIDD.

[…] OpenID Directory is launching a ping service for OpenID enabled sites. Each time someone successfully signs in to a website their identity provider will ping OpenID Directory. Good idea to make OpenID more known. Of course, Thomas Huhn has all details. However also read Evan Prodromou’s comment on the announcement, please. 37signals, highrise, openid, openiddirectory, ping, wordpressShare This […]

The privacy aspect of this was also my first concern. However, I’m not sure if it’s necessary to go all the way to the level of “are you the webmaster of this site?”. The problem as I see it is not that a site is listed on OIDD, but rather *how* it is getting listed. A couple of analogies come to mind…

First, this reminds me a little of the emails I occasionally get from people asking permission to link to a site of mine. I find this rather comical, because the very nature of the web is that any page can link to any other… you don’t need permission to create a link on your own page. Google and DMOZ don’t need permission to include sites in their respective collections. The important thing is how do all of these services know that a page even exists? If I create a new site, but don’t link to it from anywhere, Google will never index it because it doesn’t know it exists, but if I publicize its existence then it is fair game for indexing and I have no case against that. If I have content on that site that is truly private, then it should be adequately secured as such.

But it also reminds me of mailing lists. Anyone could submit my email address to a mailing list, but a well-behaved list will require me to verify that subscription request. Though my email address is public, it should not be able to be added to a mailing list without my consent.

I tend to think OIDD leans more towards the former category… if a site is out in the open, it is fair game for being linked to. That being said, users should without a doubt have the option NOT to submit RPs they are visiting to OIDD, and (verified) webmasters should probably have the option to request their site not be listed.

Thanks Will for your great thoughts on this topic.

There´s only one thing I´d like to add: Until now our submission model looks similar to dmoz.org. You submit your site to the editors, they check the site and you get listed (or not). If you want to change something like e.g. description or thumbnail later on, you can only contact OIDD by email, asking the editors to do the changes for you.

After the relaunch this game will change: the submitters of the sites have full control over their presentation on the OIDD at any time. This gives you more comfort as a site owner but also has some implications on whom we would LIKE to see as submitters.

You could see this similar to del.icio.us and say “everybody is free to annotate my site as they want”, but again there´s a difference: submission for a url is allowed only once. That´s why we feel like having to give site owners preferred access to their listing on the OIDD.

The means to proof ownership of a site could be a MicroID or setting a linkback button.

Hi. I think that the standards or Open ID has a lot to improve. If to speak about technical side - very often when I see the forms with OpenID raw - it usually brakes when I try to fulfil it.