Tuesday, December 19, 2006

How can this be?

The OpenID extension for MediaWiki allows for differentiated trust. Configuration options include
  • $wgOpenIDConsumerAllow -- an array of regular expressions that match OpenIDs you want to allow to log in. For example, "@^(http://)?wikitravel.org/@" will allow OpenIDs from the Wikitravel domain.
  • $wgOpenIDConsumerDeny -- an array of regular expressions that match OpenIDs you want to deny access to. This is mostly useful for servers that are known to be bad. Example: #^(http://)?example.com/#".
  • $wgOpenIDServerForceAllowTrust -- an array of regular expressions that match trust roots that you want to skip trust checks for when the user logs in from those sites.
Isn't this breaking some unwritten OpenID Best Practice for IDP selection?

Can an OpenID RP be anything other than completely promiscuous? If not, what happens to 'internet scale'?

5 comments:

Anonymous said...

Isn't this accepted as inevitable? With the specter of spammer-hosted IDPs routinely discussed in the context of OpenID security concerns, such a explicit trust definition seemed to be a forgone conclusion.

Paul Madsen said...

Anon, I agree completely. But some within the OpenID community appear to see this progression as breaking the 'spirit' of OpenID.

Personally, I think 'relevance and scope' will win out over 'spirit'.

thanks

Anonymous said...

Apologies, I didn't catch the rhetoric in the post.

As a newcomer in this field, I have been elated to see the escalation in ID federation technologies, though mentality you mention has been particularly troubling. (Thus my motivation to post on this entry) It is somewhat reassuring to see the pragmatism in some of the implementation, though.

Unknown said...

As the creator of the extension in question, I'll say this: if I am turning over some of my site's security decisions to a third party, I damn well better have the right to blacklist and whitelist which of those third parties I entrust those decisions to.

For Wikitravel, in particular, I have yet to need to blacklist anyone, but I'd much rather have the option in a configuration file than remove all OpenID support the first time I have an ill-behaved, poorly-programmed, or simply hostile IdP to deal with.

damnian said...

Suppose a site admin accidentally discovered a security vulnerability in an imaginary IdP. How would he secure his site?

As the creator of phpbb-openid, I fully agree with Evan. I had the IdP blacklist/whitelist capability built into it, as it was essentially similar to the email blacklist/whitelist readily available in phpBB.