Skip to main content

Player Location and Age

In order to implement k-ID age verification and consent workflows, the game must acquire two pieces of information about the player: their location (or jurisdiction) and their age.

Location

While location can be self-declared by the player, the preferred way of getting location information is to invoke a service from the game that responds with information about the player's IP address. The location string can be either an ISO 3166-1 alpha-2 country code (e.g. US) or an ISO 3166-2 subdivision code (e.g. US-CA). It is recommended to always provide the subdivision code whenever possible. This is because even if a region currently does not have localized regulations, it may have them in the future. By providing the subdivision code, we can ensure that the player's permissions can be adjusted as regulations change.

Notes:

  • Some games may have their own protections in place to detect and prevent location spoofing (e.g., through players using VPNs). Make sure that the location that is sent to the k-ID API has been validated by these tools as applicable before it is sent in order to avoid an incorrect configuration.

  • As a best practice, a player's jurisdiction is considered static when the player first launches the game, and cannot be changed except if the customer files a support request - this is to discourage players from "forum shopping" to enable features that should otherwise be disabled in their jurisdiction.

One example to get the location for the player's IP address is to call a service like https://ipapi.co/json, which produces results similar to the json shown below.

{
"ip": "76.22.71.171",
"network": "76.22.68.0/22",
"version": "IPv4",
"city": "Issaquah",
"region": "Washington",
"region_code": "WA",
"country": "US",
"country_name": "United States",
"country_code": "US",
"country_code_iso3": "USA",
"country_capital": "Washington",
"country_tld": ".us",
"continent_code": "NA",
"in_eu": false,
"postal": "98027",
"latitude": 47.4998,
"longitude": -122.0086,
"timezone": "America/Los_Angeles",
"utc_offset": "-0800",
"country_calling_code": "+1",
"currency": "USD",
"currency_name": "Dollar",
"languages": "en-US,es-US,haw,fr",
"country_area": 9629091.0,
"country_population": 327167434,
"asn": "AS7922",
"org": "COMCAST-7922"
}

Date of Birth

The date of birth is a string that can be provided to the API in any of the following formats: YYYY, YYYY-MM, or YYYY-MM-DD. The jurisdiction determines whether a game must ask the player their age when first starting to play the game. If the jurisdiction requires that the player give an age, then a user interface element to collect the date of birth should be shown. This is called an age gate.

image

When showing an age gate, a best practice is to show a "neutral age gate", one which does not have an age already set so the user has to take action to set an age. Additionally, if the age gate uses a slider for the age value, it is recommended by the ESRB that the maximum age in a slider age gate should be 35.

If the age gate does not need to be shown in the current jurisdiction, then the player can proceed without further checks and their date of birth will be unassigned.

Assuring Player Age

In jurisdictions where it is allowed, the k-ID Facial Age Estimation feature can be used to estimate a player's age to determine if it matches the date of birth given by the player in an age gate. Use of Facial Age Estimation will significantly increase the chances that a player is truthful about their age. When using this approach, there two several scenarios that need to be addressed.

  • The age range given by Facial Age Estimation contains or is higher than the date of birth given by the player. In this case the date of birth can be used.
  • The age range is lower than the self-declared age. In this case, it is recommended to assume the lowest age in the range. The user should be informed that the age doesn't match, and then the player can be asked to restate a lower age that is in the range, or appeal the age estimation.