 | This is an
essay. It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of
Wikipedia's policies or guidelines, as it has not been
thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints. |
Configurability
With respect to account verification functionality, system administrative options for configuring installations of MediaWiki are envisioned to include, but to not be limited to:
- Whether or not to activate the account verification features for a MediaWiki installation or upgrade.
- Whether account verification is required or optional for their new and existing end users.
- Which from an extensible list of social login or OpenID Connect providers can their end-users utilize to verify their account.
- How many social login or OpenID Connect providers must their end users link to their account for corroborative account verification.
- Whether their verified end users can choose whether to display their real names or utilize pseudonymous usernames.
- Whether their verified end users can choose whether to provide hyperlinks to their connected account pages on their user pages.
- Whether their administrators have a page protection mode such that only verified end users can edit a thusly protected page.
- Whether their administrators can suspend or revoke verified end-users' account verification privileges.
- Whether to display a verification checkmark next to the edits of verified end-users and next to their usernames on their user pages and which graphic icons to utilize.
Configuration options for MediaWiki system administrators and subsequently contingent configuration options for end users can maximize utility for all parties concerned across a large number of MediaWiki use case scenarios.
With highly configurable MediaWiki functionality, Wikipedia could choose whether and configurable how to utilize account verification features in a manner that exactly aligns with their policy.
Page protection
With account verification, Wikipedia administrators could be equipped with a page protection mode such that only verified accounts could edit a protected article or category of articles. Rationale for such page protection modes include the rationales of semi-protection and extended confirmed protection.
Good standing
With account verification, Wikipedia administrators could be equipped with the capability to suspend or revoke end-users' account verification statuses.
Proponents
Proponents of account verification on Wikipedia maintain that it, and resultant administrative tools, would mitigate:
- Sock puppetry
- Multiple accounts
- Conflict of interest editing
- Advocacy editing
- Propaganda
- Bots
- Griefing
- Trolling
- Spamming
- Vandalism
- Fake news
- Misinformation / Disinformation
- Political manipulation
- Election interference
Opponents
Opponents of account verification on Wikipedia have concerns including:
- Protecting anonymous contribution
- Protecting data privacy ( account verification processes may entail the storage of end users' real names as users choose to verify their accounts)
- Real-name policies run afoul of long-standing Internet culture and conventions
- Real-name policies may disadvantage or endanger marginalized users or victims of violence or harassment
- Real-name policies are insufficient for preventing spam
- Real-name policies are insufficient for preventing trolls
OpenID Connect
The OpenID Connect 1.0 specification defines a set of standard claims. They can be requested to be returned either in the UserInfo Response, per Section 5.3.2, or in the ID Token, per Section 2.
The table below indicates the set of standard claims and is from Section 5.1 of the OpenID Connect 1.0 specification.
| Member | Type | Description |
|---|---|---|
| sub | string | Subject - Identifier for the End-User at the Issuer. |
| name | string | End-User's full name in the displayable form including all name parts, possibly including titles and suffixes, ordered according to the End-User's locale and preferences. |
| given_name | string | Given name(s) or first name(s) of the End-User. Note that in some cultures, people can have multiple given names; all can be present, with the names being separated by space characters. |
| family_name | string | Surname(s) or last name(s) of the End-User. Note that in some cultures, people can have multiple family names or no family name; all can be present, with the names being separated by space characters. |
| middle_name | string | Middle name(s) of the End-User. Note that in some cultures, people can have multiple middle names; all can be present, with the names being separated by space characters. Also note that in some cultures, middle names are not used. |
| nickname | string | Casual name of the End-User that may or may not be the same as the given_name. For instance, a nickname value of Mike might be returned alongside a given_name value of Michael. |
| preferred_username | string | Shorthand name by which the End-User wishes to be referred to at the RP, such as janedoe or j.doe. This value MAY be any valid JSON string including special characters such as @, /, or whitespace. The RP MUST NOT rely upon this value is unique, as discussed in Section 5.7. |
| profile | string | URL of the End-User's profile page. The contents of this Web page SHOULD be about the End-User. |
| picture | string | URL of the End-User's profile picture. This URL MUST refer to an image file (for example, a PNG, JPEG, or GIF image file), rather than to a Web page containing an image. Note that this URL SHOULD specifically reference a profile photo of the End-User suitable for displaying when describing the End-User, rather than an arbitrary photo taken by the End-User. |
| website | string | URL of the End-User's Web page or blog. This Web page SHOULD contain information published by the End-User or an organization that the End-User is affiliated with. |
| string | End-User's preferred e-mail address. Its value MUST conform to the RFC 5322 [RFC5322] addr-spec syntax. The RP MUST NOT rely upon this value is unique, as discussed in Section 5.7. | |
| email_verified | boolean | True if the End-User's e-mail address has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this e-mail address was controlled by the End-User at the time the verification was performed. The means by which an e-mail address is verified is context-specific and dependent upon the trust framework or contractual agreements within which the parties are operating. |
| gender | string | End-User's gender. Values defined by this specification are female and male. Other values MAY be used when neither of the defined values is applicable. |
| birthdate | string | End-User's birthday, represented as an ISO 8601:2004 [ISO8601-2004] YYYY-MM-DD format. The year MAY be 0000, indicating that it is omitted. To represent only the year, the YYYY format is allowed. Note that depending on the underlying platform's date related function, providing just a year can result in varying months and days, so the implementers need to take this factor into account to correctly process the dates. |
| zoneinfo | string | String from zoneinfo [zoneinfo] time zone database representing the End-User's time zone. For example, Europe/Paris or America/Los_Angeles. |
| locale | string | End-User's locale, represented as a BCP47 [RFC5646] language tag. This is typically an ISO 639-1 Alpha-2 [ISO639-1] language code in lowercase and an ISO 3166-1 Alpha-2 [ISO3166-1] country code in uppercase, separated by a dash. For example, en-US or fr-CA. As a compatibility note, some implementations have used an underscore as the separator rather than a dash, for example, en_US; Relying Parties MAY choose to accept this locale syntax as well. |
| phone_number | string | End-User's preferred telephone number. E.164 [E.164] is RECOMMENDED as the format of this Claim, for example, +1 (425) 555-1212 or +56 (2) 687 2400. If the phone number contains an extension, it is RECOMMENDED that the extension be represented using the RFC 3966 [RFC3966] extension syntax, for example, +1 (604) 555-1234;ext=5678. |
| phone_number_verified | boolean | True if the End-User's phone number has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this phone number was controlled by the End-User at the time the verification was performed. The means by which a phone number is verified is context-specific and dependent upon the trust framework or contractual agreements within which the parties are operating. When true, the phone_number Claim MUST be in E.164 format and any extensions MUST be represented in RFC 3966 format. |
| address | JSON object | End-User's preferred postal address. The value of the address member is a JSON [RFC4627] structure containing some or all of the members defined in Section 5.1.1. |
| updated_at | number | Time the End-User's information was last updated. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. |
Corroborative account verification works with the standard set of claims. The OpenID Connect 1.0 specification indicates in Section 5.3.2 that the claims defined in Section 5.1 (the table above) can be returned as can additional claims not specified there. See also: Section 5.5.
Some ideas for additional claims are indicated:
| Member | Type | Description |
|---|---|---|
| name_verified | boolean | True if the End-User's name has been verified, otherwise false. When this claim value is true, this means that the OP took affirmative steps to ensure that this was the name of the End-User at the time the verification was performed. The means by which a name is verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating. |
| account_verified | boolean | True if the End-User's account has been verified, otherwise false. |
| account_verification_score | number | A value between 0 and 1 which represents an identity score. |
| created_at | number | Time the End-User's account was created. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. |
Facebook Login
From the Facebook default fields ( https://developers.facebook.com/docs/facebook-login/permissions/v3.0#reference-default_fields):
| Field Name |
|---|
| id |
| first_name |
| last_name |
| middle_name |
| name |
| name_format |
| picture |
| short_name |
A field from the basic permissions category ( https://developers.facebook.com/docs/facebook-login/permissions/v3.0#basic-permissions):
| Field Name | Description |
|---|---|
| Provides access to the person's primary email address via the email property on the user object. |
A field from the larger set of the Facebook extended profile ( https://developers.facebook.com/docs/facebook-login/permissions/v3.0#reference-extended-profile):
| Field Name | Description |
|---|---|
| user_link | Provides access to the Facebook profile URL for another user of the app. |
LinkedIn Login
From the LinkedIn basic profile (
https://developer.linkedin.com/docs/fields/basic-profile) data, to access any of the following basic profile fields, your app must request the r_basicprofile member permission:
| Field Name | Description |
|---|---|
| id | A unique identifying value for the member. This value is linked to your specific application. Any attempts to use it with a different application will result in a "404 - Invalid member id" error. |
| first-name | The member's first name. |
| last-name | The member's last name. |
| maiden-name | The member's maiden name. |
| formatted-name | The member's name, formatted based on language. |
| phonetic-first-name | The member's first name, spelled phonetically. |
| phonetic-last-name | The member's last name, spelled phonetically. |
| formatted-phonetic-name | The member's name, spelled phonetically and formatted based on language. |
| headline | The member's headline. |
| location | An object representing the user's physical location. See Location Fields for a description of the fields available within this object. |
| industry | The industry the member belongs to. See Industry Codes for a list of possible values. |
| current-share | The most recent item the member has shared on LinkedIn. If the member has not shared anything, their 'status' is returned instead. |
| num-connections | The number of LinkedIn connections the member has, capped at 500. See 'num-connections-capped' to determine if the value returned has been capped. |
| num-connections-capped | Returns 'true' if the member's 'num-connections' value has been capped at 500', or 'false' if 'num-connections' represents the user's true value. |
| summary | A long-form text area describing the member's professional profile. |
| specialties | A short-form text area describing the member's specialties. |
| positions | An object representing the member's current position. See Position Fields for a description of the fields available within this object. |
| picture-url | A URL to the member's formatted profile picture, if one has been provided. |
| picture-urls::(original) | A URL to the member's original unformatted profile picture. This image is usually larger than the picture-url value above. |
| site-standard-profile-request | The URL to the member's authenticated profile on LinkedIn. You must be logged into LinkedIn to view this URL. |
| api-standard-profile-request | A URL representing the resource you would request for programmatic access to the member's profile. |
| public-profile-url | The URL to the member's public profile on LinkedIn. |
The following member fields require the r_emailaddress member permission:
| Field Name | Description |
|---|---|
| email-address | The LinkedIn member's primary email address. Secondary email addresses associated with the member are not available via the API. |
| This is an
essay. It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of
Wikipedia's policies or guidelines, as it has not been
thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints. |
Configurability
With respect to account verification functionality, system administrative options for configuring installations of MediaWiki are envisioned to include, but to not be limited to:
- Whether or not to activate the account verification features for a MediaWiki installation or upgrade.
- Whether account verification is required or optional for their new and existing end users.
- Which from an extensible list of social login or OpenID Connect providers can their end-users utilize to verify their account.
- How many social login or OpenID Connect providers must their end users link to their account for corroborative account verification.
- Whether their verified end users can choose whether to display their real names or utilize pseudonymous usernames.
- Whether their verified end users can choose whether to provide hyperlinks to their connected account pages on their user pages.
- Whether their administrators have a page protection mode such that only verified end users can edit a thusly protected page.
- Whether their administrators can suspend or revoke verified end-users' account verification privileges.
- Whether to display a verification checkmark next to the edits of verified end-users and next to their usernames on their user pages and which graphic icons to utilize.
Configuration options for MediaWiki system administrators and subsequently contingent configuration options for end users can maximize utility for all parties concerned across a large number of MediaWiki use case scenarios.
With highly configurable MediaWiki functionality, Wikipedia could choose whether and configurable how to utilize account verification features in a manner that exactly aligns with their policy.
Page protection
With account verification, Wikipedia administrators could be equipped with a page protection mode such that only verified accounts could edit a protected article or category of articles. Rationale for such page protection modes include the rationales of semi-protection and extended confirmed protection.
Good standing
With account verification, Wikipedia administrators could be equipped with the capability to suspend or revoke end-users' account verification statuses.
Proponents
Proponents of account verification on Wikipedia maintain that it, and resultant administrative tools, would mitigate:
- Sock puppetry
- Multiple accounts
- Conflict of interest editing
- Advocacy editing
- Propaganda
- Bots
- Griefing
- Trolling
- Spamming
- Vandalism
- Fake news
- Misinformation / Disinformation
- Political manipulation
- Election interference
Opponents
Opponents of account verification on Wikipedia have concerns including:
- Protecting anonymous contribution
- Protecting data privacy ( account verification processes may entail the storage of end users' real names as users choose to verify their accounts)
- Real-name policies run afoul of long-standing Internet culture and conventions
- Real-name policies may disadvantage or endanger marginalized users or victims of violence or harassment
- Real-name policies are insufficient for preventing spam
- Real-name policies are insufficient for preventing trolls
OpenID Connect
The OpenID Connect 1.0 specification defines a set of standard claims. They can be requested to be returned either in the UserInfo Response, per Section 5.3.2, or in the ID Token, per Section 2.
The table below indicates the set of standard claims and is from Section 5.1 of the OpenID Connect 1.0 specification.
| Member | Type | Description |
|---|---|---|
| sub | string | Subject - Identifier for the End-User at the Issuer. |
| name | string | End-User's full name in the displayable form including all name parts, possibly including titles and suffixes, ordered according to the End-User's locale and preferences. |
| given_name | string | Given name(s) or first name(s) of the End-User. Note that in some cultures, people can have multiple given names; all can be present, with the names being separated by space characters. |
| family_name | string | Surname(s) or last name(s) of the End-User. Note that in some cultures, people can have multiple family names or no family name; all can be present, with the names being separated by space characters. |
| middle_name | string | Middle name(s) of the End-User. Note that in some cultures, people can have multiple middle names; all can be present, with the names being separated by space characters. Also note that in some cultures, middle names are not used. |
| nickname | string | Casual name of the End-User that may or may not be the same as the given_name. For instance, a nickname value of Mike might be returned alongside a given_name value of Michael. |
| preferred_username | string | Shorthand name by which the End-User wishes to be referred to at the RP, such as janedoe or j.doe. This value MAY be any valid JSON string including special characters such as @, /, or whitespace. The RP MUST NOT rely upon this value is unique, as discussed in Section 5.7. |
| profile | string | URL of the End-User's profile page. The contents of this Web page SHOULD be about the End-User. |
| picture | string | URL of the End-User's profile picture. This URL MUST refer to an image file (for example, a PNG, JPEG, or GIF image file), rather than to a Web page containing an image. Note that this URL SHOULD specifically reference a profile photo of the End-User suitable for displaying when describing the End-User, rather than an arbitrary photo taken by the End-User. |
| website | string | URL of the End-User's Web page or blog. This Web page SHOULD contain information published by the End-User or an organization that the End-User is affiliated with. |
| string | End-User's preferred e-mail address. Its value MUST conform to the RFC 5322 [RFC5322] addr-spec syntax. The RP MUST NOT rely upon this value is unique, as discussed in Section 5.7. | |
| email_verified | boolean | True if the End-User's e-mail address has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this e-mail address was controlled by the End-User at the time the verification was performed. The means by which an e-mail address is verified is context-specific and dependent upon the trust framework or contractual agreements within which the parties are operating. |
| gender | string | End-User's gender. Values defined by this specification are female and male. Other values MAY be used when neither of the defined values is applicable. |
| birthdate | string | End-User's birthday, represented as an ISO 8601:2004 [ISO8601-2004] YYYY-MM-DD format. The year MAY be 0000, indicating that it is omitted. To represent only the year, the YYYY format is allowed. Note that depending on the underlying platform's date related function, providing just a year can result in varying months and days, so the implementers need to take this factor into account to correctly process the dates. |
| zoneinfo | string | String from zoneinfo [zoneinfo] time zone database representing the End-User's time zone. For example, Europe/Paris or America/Los_Angeles. |
| locale | string | End-User's locale, represented as a BCP47 [RFC5646] language tag. This is typically an ISO 639-1 Alpha-2 [ISO639-1] language code in lowercase and an ISO 3166-1 Alpha-2 [ISO3166-1] country code in uppercase, separated by a dash. For example, en-US or fr-CA. As a compatibility note, some implementations have used an underscore as the separator rather than a dash, for example, en_US; Relying Parties MAY choose to accept this locale syntax as well. |
| phone_number | string | End-User's preferred telephone number. E.164 [E.164] is RECOMMENDED as the format of this Claim, for example, +1 (425) 555-1212 or +56 (2) 687 2400. If the phone number contains an extension, it is RECOMMENDED that the extension be represented using the RFC 3966 [RFC3966] extension syntax, for example, +1 (604) 555-1234;ext=5678. |
| phone_number_verified | boolean | True if the End-User's phone number has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this phone number was controlled by the End-User at the time the verification was performed. The means by which a phone number is verified is context-specific and dependent upon the trust framework or contractual agreements within which the parties are operating. When true, the phone_number Claim MUST be in E.164 format and any extensions MUST be represented in RFC 3966 format. |
| address | JSON object | End-User's preferred postal address. The value of the address member is a JSON [RFC4627] structure containing some or all of the members defined in Section 5.1.1. |
| updated_at | number | Time the End-User's information was last updated. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. |
Corroborative account verification works with the standard set of claims. The OpenID Connect 1.0 specification indicates in Section 5.3.2 that the claims defined in Section 5.1 (the table above) can be returned as can additional claims not specified there. See also: Section 5.5.
Some ideas for additional claims are indicated:
| Member | Type | Description |
|---|---|---|
| name_verified | boolean | True if the End-User's name has been verified, otherwise false. When this claim value is true, this means that the OP took affirmative steps to ensure that this was the name of the End-User at the time the verification was performed. The means by which a name is verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating. |
| account_verified | boolean | True if the End-User's account has been verified, otherwise false. |
| account_verification_score | number | A value between 0 and 1 which represents an identity score. |
| created_at | number | Time the End-User's account was created. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. |
Facebook Login
From the Facebook default fields ( https://developers.facebook.com/docs/facebook-login/permissions/v3.0#reference-default_fields):
| Field Name |
|---|
| id |
| first_name |
| last_name |
| middle_name |
| name |
| name_format |
| picture |
| short_name |
A field from the basic permissions category ( https://developers.facebook.com/docs/facebook-login/permissions/v3.0#basic-permissions):
| Field Name | Description |
|---|---|
| Provides access to the person's primary email address via the email property on the user object. |
A field from the larger set of the Facebook extended profile ( https://developers.facebook.com/docs/facebook-login/permissions/v3.0#reference-extended-profile):
| Field Name | Description |
|---|---|
| user_link | Provides access to the Facebook profile URL for another user of the app. |
LinkedIn Login
From the LinkedIn basic profile (
https://developer.linkedin.com/docs/fields/basic-profile) data, to access any of the following basic profile fields, your app must request the r_basicprofile member permission:
| Field Name | Description |
|---|---|
| id | A unique identifying value for the member. This value is linked to your specific application. Any attempts to use it with a different application will result in a "404 - Invalid member id" error. |
| first-name | The member's first name. |
| last-name | The member's last name. |
| maiden-name | The member's maiden name. |
| formatted-name | The member's name, formatted based on language. |
| phonetic-first-name | The member's first name, spelled phonetically. |
| phonetic-last-name | The member's last name, spelled phonetically. |
| formatted-phonetic-name | The member's name, spelled phonetically and formatted based on language. |
| headline | The member's headline. |
| location | An object representing the user's physical location. See Location Fields for a description of the fields available within this object. |
| industry | The industry the member belongs to. See Industry Codes for a list of possible values. |
| current-share | The most recent item the member has shared on LinkedIn. If the member has not shared anything, their 'status' is returned instead. |
| num-connections | The number of LinkedIn connections the member has, capped at 500. See 'num-connections-capped' to determine if the value returned has been capped. |
| num-connections-capped | Returns 'true' if the member's 'num-connections' value has been capped at 500', or 'false' if 'num-connections' represents the user's true value. |
| summary | A long-form text area describing the member's professional profile. |
| specialties | A short-form text area describing the member's specialties. |
| positions | An object representing the member's current position. See Position Fields for a description of the fields available within this object. |
| picture-url | A URL to the member's formatted profile picture, if one has been provided. |
| picture-urls::(original) | A URL to the member's original unformatted profile picture. This image is usually larger than the picture-url value above. |
| site-standard-profile-request | The URL to the member's authenticated profile on LinkedIn. You must be logged into LinkedIn to view this URL. |
| api-standard-profile-request | A URL representing the resource you would request for programmatic access to the member's profile. |
| public-profile-url | The URL to the member's public profile on LinkedIn. |
The following member fields require the r_emailaddress member permission:
| Field Name | Description |
|---|---|
| email-address | The LinkedIn member's primary email address. Secondary email addresses associated with the member are not available via the API. |