Important Concepts
To integrate k-ID into a game, the following steps need to be taken:
- Determine how the game will get the player location and date of birth
- Define the under-age experience before consent has been granted
- Match k-ID Permissions to features in the game
Getting Player Location and Date of Birth
In order to implement k-ID age verification and consent workflows, the game must acquire two pieces of information about the player: the player’s location (or jurisdiction), and the player's date of birth.
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://ipinfo.io/json, which produces results similar to the json shown below.
{
"ip": "136.62.180.67",
"hostname": "XX-XX-XX-XX.googlefiber.net",
"city": "Austin",
"region": "Texas",
"country": "US",
"timezone": "America/Chicago",
"readme": "https://ipinfo.io/missingauth"
}
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.
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.
Handling Under-Age Users Without Parental Consent
If a player gives an age that requires parental consent, the game must determine what to do before consent is granted by a parent. There are several possible approaches, including blocking access entirely and waiting on the parental consent challenge screen, or granting limited access to a “data-lite” experience of the game.
In the example below, the player is blocked from continuing while a Consent Challenge window is displayed.
Matching k-ID Permissions to Game Features
Permissions in the k-ID Global Compliance Database represent classifications of game features that are addressed in regulations in one or more jurisdisctions worldwide. Permissions are configured in the Publisher Portal for the game. Each k-ID Permission that matches a game feature should be enabled in the k-ID Developer Portal (shown below). The k-ID Permissions chosen will be presented to parents to enable or disable when they give consent for a child to play a game.
Below is an example of what a parent sees when granting consent in the k-ID Family Portal.
When displaying features in the game that are mapped to k-ID Permissions, the Session should be checked to see whether the feature is enabled, and whether the player is allowed to turn it on. More details about how to handle k-ID permissions are covered in the Permissions section of the documentation.
The table below lists the avaialble permissions that can be managed in the Publisher Portal:
| Group | Permission |
|---|---|
| ai-customization | ai-generated-avatars |
| ai-chatbot | |
| communication | text-chat-private |
| voice-chat | |
| video-chat | |
| link-to-third-party-chat | |
| community | forums |
| chat-rooms-public | |
| join-groups | |
| virtual-events | |
| content-moderation | mature-language |
| mods | |
| content-sharing | gameplay-streaming |
| gameplay-recording | |
| share-game-clips-screenshots | |
| link-to-third-party-streaming-app | |
| game-controls | haptic-feedback |
| movement-speed-adjustment | |
| smooth-locomotion | |
| disable-boundary-settings | |
| augmented-reality | |
| gameplay | multiplayer |
| pvp | |
| leaderboard-and-rankings | |
| marketing | direct-marketing |
| targeted-ads | |
| contextual-ads | |
| notification | push-notifications |
| disable-safety-prompts | |
| privacy | profiling |
| motion-data | |
| camera-access | |
| real-time-location-sharing | |
| photo-video-sharing | |
| profile-customization | custom-username |
| custom-avatar | |
| profile-visibility | public-profile |
| online-status | |
| recommendations | personalized-recommendations |
| social | public-friend-list |
| send-accept-friend-requests | |
| social-media | share-to-social-media |
| link-to-social-media-account | |
| virtual-economy | in-game-purchases |
| in-game-currency | |
| loot-boxes | |
| send-gifts | |
| auctions | |
| virtual-property-ownership | |
| virtual-marketplace |