UserPreferences

CommentAuthentication


CommentAuthentication

CommentAuthentication is a feature of an AtomApi that seeks to verify that a comment is by the entity (person, organization, or system) it claims to be from. In turn, authorization systems can be layered over authentication to determine what that commenter is allowed to do (whitelisted, blacklisted, hold for review, etc.)

The most visible cause to support authentication and authorization is "spam", common in email and a growing concern in website comment systems, and weblogs specifically.

Examples of the problem:

Various solutions to the problem:

MarkPilgrim paraphrases [WWW]Jeremy Bowers, saying, "(a) this problem is not new, (b) this problem is not specific to this domain, and (c) this problem has not been solved by technological solutions in other domains." While true, there is a difference in setting the context for solving a problem. In the right context, one can play with solutions that start out with, "if everyone" and not worry about the case of "not enough people will participate" and focus on the specific issues of whether or not "everyone" can participate.

References:

Authentication

Authentication is the basis of several approaches to spam control -- being able to repeatedly identify the source of a message (irrespective of whether the physical identity of the source is known, ie. supporting anonymity). Once the source of a message is known, it is then possible to classify or authorize that source for posting.

Authentication mechanisms:

Authentication techniques have a range of authenticity from virtually none (user enters their name in the comment box), to an email check (user responds to an email), to a cryptographically unique identifier (such as a PGP private key), to a cryptographic key certified by another individual who vouches for the signed key.

For all techniques short of certified keys, there is the issue of how easy it is to generate unique identifiers. Many registration systems are easily scripted to produce new identities (such as email addresses) or people can be hired to register for identities (where, for example, [WWW]Captcha techniques are used). "Disposable" identities are effectively equivalent to unknown identity.

Public-key and third-party authentication generally require a tool on the user's machine to generate the proper "response" to a "challenge" sent by the server. This response can be entered into a comment form (using JavaScript, browser plug-in, or via a desktop application) or provided by a posting tool (an aggregator based comment poster, for example).

Authentication can be used in one or both of 1) authenticating to a single server to be allowed to post to that server, and 2) authenticating, or signing, the content to be or that has been posted and potentially syndicated. The former is often more directed at allowing access where the latter is more directed at confirming the source of an entry (EntrySigning).

Discussion

[AsbjornUlsberg] Does anyone have an idea of how to solve this? An example of the process, the possible serialized XML to send, etc? It would be nice to have something hands-on to work with.

[WWW]Chris Just added the image verification links - it looks easy! I wish I knew php *G*

[KenMacLeod] The simplest way is HTTP/Atom authentication in the API. HTTP auth is well-defined and supported already by most tools and support libraries. Using HTTP auth also makes it easy for the weblog author to choose whatever means they want to allow new registrations, including signed email or web form, a registration page with [WikiPedia]Captcha, or manual registration.