User:Jeblad/verified contact

An user can be a verified contact for some named entity, by sending an email from the entity given that the email contain a valid domain name. This domain name will be used for a WHOIS lookup, and will be used for extraction of the registrants name or organization. Only when the extract matches the given name for the entity will the user be listed as a verified contact.

The meaning of a verified contact is to be a known contact point for matters relating to the given named entity, thereby minimizing misunderstandings relating to said named entity. This is somewhat similar to benutzerverifizierung, but without the policy part and without any involvement of OTRS teams.

This solution makes it possible to verify if a user can be contacted from the wiki itself, and respond from an account at the named entity, but it does not imply that the user is allowed to act as a contact for the named entity.

Algorithm
The user act as a verified contact for a single entity, and should set up the email for this purpose. The user goes to a special page "Verified contact" containing a single button, and pushing this button sends a specially formatted email to the user. The email contains an access code, and the user should then enter this on the special page, which has now added a field for this code. When the code is entered and verified as valid by the system the user is verified for this domain.

When an user account is verified a small text saying which named entity the user has verified against is added after the title on the user page. That is an excerpt from the WHOIS-report. The report is divided into blocks on multiple new lines, or on leading part-names, and each block is scanned for some keywords. Sets of keywords can be chosen given matches on other keywords, such that registrant-specific layouts can be detected and handled. As default comments are stripped off, and lines with some leading keywords like. The domain name may not exist in the block used for the registrant. The user itself gives the name of the registrant, and only if it matches a whois line will it be accepted.

That text is clickable, and will purge the verification. This makes it possible to force an employee to stop acting like a verified contact for a specific named entity. Only admins or other users listed as verified contacts for the same domain should be able to purge the verification for another user. Requests to create and purge verified contacts are logged and listed on recent changes to avoid abuse.

If the email is known, the only thing necessary to start the verification is a HMAC or TOTP token. If the code is lost the user could make a new request, as the cost is pretty low. Usually the page would be open during the process, making it even simpler for the user to request a new token.

A verified contact is placed in a special user group, which may not have any additional rights at all, but could act similar to autoconfirmed users.

A user should be autoconfirmed to be able to start the verification process. It could be an idea to use a special group "verifiable", as this makes it possible to remove offending users from the group and thus blocking them from self assigning as a verified contact.

To make it simpler to find verified contacts a parser function  will list all users acting as contacts for the entity. This parser function could then be added to discussion pages, and also on pages that are not easily recognized as related to the named entity.