Reputation
Meng Weng Wong started this page 20070703 to track perspectives regarding whitelisting, blacklisting, accrediting, and reputing the members of the OpenID ecosystem.
Contents |
Perspectives and Assertions
Combating OpenID-enabled Comment Spam
Original Author: Meng Weng Wong
Assertion: Claimlists will become a popular tool to combat OpenID spam.
Use case, without reputation: Bad guy sets up an OP at http://badguy.net/, and runs off identities http://badguy.net/0001 through http://badguy.net/9999. Bad guy hires a zombie farm to log in to LiveJournal (RP) using the badguy.net credentials, and posts comment spam on every blog he can find.
The Reputation Component: Karmasphere is a service that aggregates third-party whitelists and blacklists the way Technorati aggregates blogs. It also hosts and publishes whitelists and blacklists the way Flickr hosts photos. (Meng works there.)
Use case, with blacklists: LiveJournal queries Karmasphere and finds that badguy.net is blacklisted by ten other RPs. LiveJournal ignores all the posts.
Use case, with whitelists: LiveJournal finds that badguy.net does not appear on any of the whitelists that Karmasphere aggregates. LiveJournal finds, however, that DeadJournal does appear on several whitelists, so comments from DeadJournal users get posted but spam from badguy.net gets blocked.
Discussion: Brad, Dave, and others have said that Trust is meant to be layered on top of Identity and Authentication.
Chilling Effect
Original Author: Mark Atwood
Assertion: The spread of whitelists (as well as poorly discriminating blacklists) will have a chilling effect. A whitelist of "well known OpenID Providers" will have a chilling effect on small, individual OPs run by sophisticated individuals. A whitelist of "well known Relying Parties" will have a chilling effect on Relying Parties that are less well known but no less upstanding.
Elaboration wanted: analogies, examples, anecdotes.
Analogy: (Grahame Cooper) Many Email server blacklisting services such as MAPS include lists of "dynamically allocated" IP addresses, which are then used by mail transport agents (MTAs) to block connections indiscriminately from such addresses. The rationale is that it is not possible for the receiving MTA to establish the reputation of a remote IP address for which there is no reliable way to trace the owner. This makes it impossible for individuals running their own MTAs to send mail directly to recipients who use those receiving MTAs, and this applies to a large number of big mail providers, companies and organizations. SPF allows such small (sender) MTAs to link the IP address of the server to a registered Domian Name, thus providing the necessary traceable link; however, the receiving MTA admins do not bother to take that into account when blocking connections. There is no incentive for the big guys to put in any effort to avoid trampling the little guys ... so called "collateral damage".
OP's Claims Are Trustworthy
Original Author: Mark Atwood
Assertion: Sometimes a reputation system might be useful: a trusted reputation provider may assert that an OP previously unknown to the relying party should be considered credible when it makes claims regarding the OP's endusers.
Exegesis: Hold your copy of Gödel Escher Bach close: we're going to talk about metaclaims: claims about claims. There exist OPs which make claims regarding their end-users. OP2000 asserts that Bob is 21 or older. There exist reputation providers which make claims regarding those OPs. Karmasphere asserts that OP2000 does age verification for a living, and knows what it's talking about. The reputation provider may publish those claims by placing the OPs on a claimlist (analogous to a whitelist or a blacklist). Appearance on that list constitutes a claim by the reputation provider about the OP. Karmasphere.com/OP/ageverifiers?op=op2000.net returns 200 OK
Use case: age verification. Legal name.
Direct Trust of OP by RP is Irrelevant in a truly User-Centric ID System
Original Author: Grahame Cooper
Assertion: Aside from establishing the authenticity of the OP's server (e.g. using SSL server certificate), the trust relationships in a "user-centric" identity system should be: RP trusts EU, EU trusts OP. RP should trust OP simply because EU says so.
Argument: The reputation of the OP should be a concern of the EU, not of the RP, since the EU has a clear interest in making the right choice because it is the EU's identity that could be compromised if they don't. Any expectation of direct trust between RP and OP could be damaging to the user-centric nature of OpenID (see "Chilling Effect" above). Thus, any reputation system should be aimed at helping EUs choose the OP to subscribe to or delegate to, not at helping RPs to decide which ones to trust.
Trusting Attributes in AX: The issue of authenticity of attributes should be handled by a different party than the OP (or by the OP in a clearly different role). Could be by means of attribute certificates, signed by an attribute authority, and could be different AAs for different attributes. This amounts to a separate trust layer as mentioned above.
Counter-argument: It could be argued that EUs cannot be trusted to look after the integrity of their own OpenIDs because they don't understand the issues involved and/or don't take sufficient care and/or are not prepared to accept the responsibility/liability. However, such an argument logically leads to the conclusion that user-centric identity management is not appropriate, which becomes an excuse to remove or deny freedoms as is often the case in other areas (like the email analogy under "Chilling Effect" above).
I'm interested in hearing discussion of this point
Relevant threads
http://openid.net/pipermail/general/2007-July/002718.html
Terminology
The language in this document aims to be consistent with the spec.
An OpenID Provider or OP is the, um, the kinds of folks who show up here. Also known as Identity Provider, IdP, Server, homesite.
A Relying Party (RP) is the site that, thanks to OpenID, no longer needs to set up a username/password table, but can rely on an OP instead. This wiki is a Relying Party because you can log in to it using your OpenID served from elsewhere.
A consumer is software operated by a Relying Party. Often used interchangeably with Relying Party.
An end-user (EU) is represented by an OpenID Identifier.
Attribute Exchange (AX) is the provision of attributes, belonging to the EU, to the RP by the OP.
Meng believes that an Identifier should also in the future be used to refer to RP and OPs, not just EUs. I mean, why not, right?
Claimlists
A claimlist is a general term for a whitelist, blacklist, or other mechanism for making an assertion regarding an Identifier, Relying Party, or OpenID Provider.
Origin: the antispam world of blacklists and, more recently, whitelists. This term was proposed by Meng 20070703.
Expected Usage: an OpenID Provider may appear on a claimlist operated by a Reputation Provider. An Identifier may also appear on a claimlist operated by a Reputation Provider.
Degenerate Case: As a degenerate case, an Identifier may also appear on a claimlist operated by an OpenID Provider, though Meng would be shocked and astonished and dismayed if OpenID/LID/LADIS/XRI/XRDS didn't provide some mechanism for discovery of Identifier metadata attributes.
