Using Session Permissions

Once the user passes the age gate check, either because they are of age to proceed or consent has been granted by a parent, then the game can retrieve all of the jurisdiction-specific permissions for the current player. This is done either from the result of the /age-gate/check call when the status field is PASS, or, if the Session was previously created and cached, invoking /session/get.

A Session contains Permissions. Each Permission has a name, a boolean enabled field, and a managedBy field, which describes whether and how the permission can be enabled for this player.

Below is an example of a particular permission, text-chat-private within a Session.

{
        "enabled": true,
        "managedBy": "PLAYER",
        "name": "text-chat-private"
}

Who Can Enable a Permission?

The game code should use each k-ID Permission to control access to the corresponding features in the game. If the enabled field is true for a permission, this means that the feature can be enabled for the player in the game. If the enabled field is false, the feature must be disabled. Some jurisdictions require that games disable certain features by default if the player is a certain age even if it is acceptable for the player to access the feature (this is sometimes referred to as a “privacy by default” requirement). In this case enabled is false and the managedByfield contains PLAYER. If a feature may only be enabled or disabled by a parent, then the value of the managedBy field will be GUARDIAN. If a feature is never allowed for the current player in the current location regardless of their parent’s consent, the managedBy field will contain the value PROHIBITED. In this last case, it may be appropriate for the game to just remove the prohibited feature entirely from the user experience rather than show it in a disabled state.