The post [1] hints about the concept of social white listing as a mechanism for avoiding spams and restricting access to a set of trusted users, in a much scalable manner.
This concept can be further extended with an OpenID Provider and OpenID relying party components. Let me suggest...
With this, OpenID Provider will enable it's users to maintain (a) white list(s) under their corresponding accounts.
A given white list contains a set of OpenIDs where the corresponding user trusts.
A white list entry also can be either an OpenID [prabath.myopenid.com] or a wild card entry [*.myopenid.com --> I trust all the users from myopenid.com].
The user can add entries to the white list manually one by one or can be imported from a file [e.g: [2] shares a set of white-listed OpenIDs].
OpenID Provider defines an attribute under the OpenID Attribute Exchange to contain a white list of a given user [http://axschema.org/whitelist - yet to propose].
OpenID relying party components will enable the support;
1. To maintain a white list at the RP end
2. Request users' white list at the time they log in
3. Share the white list with the rest.
Flow
----
1. User registers him self with an OpenID Provider. [user gets an OpenID]
2. User logs into the OpenID Provider and populates his white list.
3. User visits RP web site and types his OpenID for login.
4. RP finds the given user is in it's white list [initially the RP admin will populate it's white list with a set of trusted users]
5. User will be redirected to the OpenID Provider for the authentication + request to his white list
6. At OpenID Provider user authenticates successfully and approves the request for the white list
7. User logs into the RP successfully and RP updates it's white list
References:
[1]:
http://simonwillison.net/2007/Jan/22/whitelisting/[2]:
http://simonwillison.net/comments/whitelist/