Skip to main content

Permissions

Permissions in the k-ID Regulatory Hub represent classifications of game features that are addressed in regulations in one or more jurisdictions worldwide. Permissions are configured in the Compliance Studio for the game. Each k-ID Permission that matches a game feature should be enabled in the Compliance Studio.

What are permissions?

Permissions represent features or capabilities in your game that might require parental consent or have age restrictions. Each permission can be enabled or disabled for a player based on:

  • Their age and jurisdiction
  • Parental consent (if required)
  • The permission's configuration in Compliance Studio

Permission structure

Each permission in a session has the following structure:

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

Some permissions also carry a verifiedAgeThreshold field when the jurisdiction requires a verified age before the feature can be unlocked:

{
"enabled": false,
"managedBy": "PLAYER",
"name": "loot-boxes-paid-gameplay-impacting",
"verifiedAgeThreshold": 18
}

Permission fields

FieldTypeDescription
namestringThe identifier of the permission (for example, text-chat-private, loot-boxes-paid-gameplay-impacting)
enabledbooleanWhether the permission is currently enabled for the player
managedBystringWho controls this permission. One of PLAYER, GUARDIAN, or PROHIBITED (see below)
verifiedAgeThresholdintegerPresent only on high-risk permissions. The minimum verified age required to enable this permission. enabled stays false until the player's verified age meets or exceeds this threshold, regardless of consent. See Age assurance for high-risk features

managedBy values:

  • PLAYER: The player can enable or disable this permission without parental consent. If verifiedAgeThreshold is present, the player must also pass age assurance before enabled becomes true.
  • GUARDIAN: Only a trusted adult can enable or disable this permission.
  • PROHIBITED: This permission isn't allowed for the current player, either because it's unavailable in their jurisdiction or because their age is below the verifiedAgeThreshold and can't be unlocked through any means at their current age.
managedBy can change over time

The managedBy field isn't static. When a player ages up and no longer requires parental consent, permissions that were previously managedBy: "GUARDIAN" might change to managedBy: "PLAYER". When a player requests to enable a PLAYER-managed permission via the /session/upgrade API, it's automatically enabled without creating a challenge. Your application should handle these changes by comparing sessions over time.

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 turned off.

Some jurisdictions require that games turn off certain features by default if the player is a certain age even if it's 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 managedBy field contains PLAYER.

If a feature can only be turned on or off by a trusted adult, then the value of the managedBy field is GUARDIAN. If a feature isn't available for the current player, the managedBy field is PROHIBITED. This happens either because the feature is banned in the player's jurisdiction or because the player's age is below the verifiedAgeThreshold and can't be satisfied at their current age. When a permission is PROHIBITED, remove the feature entirely from the user experience rather than show it as disabled.

When a player ages up and no longer requires parental consent, permissions that were previously managedBy: "GUARDIAN" might change to managedBy: "PLAYER", allowing the player to control them directly. When a player requests to enable a PLAYER-managed permission via the /session/upgrade API, it's automatically enabled without creating a challenge. Your game should provide UI controls that allow players to manage these permissions themselves.

High-risk permissions and age assurance

Some permissions require more than consent: they require a verified age. A verified age is one confirmed through a strong verification path (such as a government-ID-checked platform signal or an AgeKit+ challenge), not simply a self-reported date of birth.

These permissions carry a verifiedAgeThreshold integer field. Currently this applies in Brazil (BR):

PermissionverifiedAgeThreshold
profiling18
targeted-ads18
loot-boxes-paid-cosmetic-only18
loot-boxes-paid-gameplay-impacting18
direct-marketing12

How they differ from standard permissions

BehaviourStandard (GUARDIAN-managed)High-risk (verifiedAgeThreshold)
Guardian consent alone unlocks itYesNo
Verified platform signal at age gate can satisfy itNoYes
Requires age assurance challenge if not already satisfiedNoYes
Shows as PROHIBITED when player is too youngYes (jurisdiction ban)Yes (age below threshold)

Satisfying a verifiedAgeThreshold

There are two ways for a permission's threshold to be satisfied:

  1. Verified platform signal at the age gate. If a platform age signal is passed to POST /age-gate/check and the signal is considered verified (for example, Apple iOS governmentIDChecked or Google Play VERIFIED) with ageLow >= verifiedAgeThreshold, k-ID records an ageVerification on the session and the permission becomes enabled: true immediately.

  2. Age assurance via /session/upgrade. If the threshold isn't already satisfied, calling POST /session/upgrade with the permission name triggers a CHALLENGE_SESSION_UPGRADE_BY_AGE_ASSURANCE challenge rather than a standard parental-consent challenge. The player completes age verification through AgeKit+, and the permission is unlocked on success.

Recovery flow

If a player initially provided an age below the threshold and later wants to appeal, see Age assurance for high-risk features for the full recovery flow, including how to use a k-ID platform signal from a successful appeal to restart the age gate.

Matching permissions to game features

Permissions in the k-ID Regulatory Hub represent classifications of game features that are addressed in regulations in one or more jurisdictions worldwide. Permissions are configured in the Compliance Studio for the game. Each k-ID Permission that matches a game feature should be enabled in the Compliance Studio. The k-ID Permissions chosen are presented to parents when they give consent for a child to play a game.

info

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.

Available permissions

The following permissions are available in the Compliance Studio:

Social permissions

  • Online Multiplayer (multiplayer)
  • Leaderboard and rankings (leaderboards-and-rankings)
  • Join Groups (join-groups)
  • Public Profile (public-profile)
  • Custom Avatar (custom-avatar)
  • Custom Username (custom-username)
  • Text Chat (Private) (text-chat-private)
  • Text Chat (Public) (text-chat-public)
  • Voice Chat (voice-chat)
  • Video Chat (video-chat)
  • Online Status (online-status)
  • Public Friend List (public-friend-list)
  • Send Accept Friend Requests (send-accept-friend-requests)
  • Link to Third Party Chat (link-to-third-party-chat)
  • Virtual Events (virtual-events)
  • Share to Social Media (share-to-social-media)

Marketing permissions

  • Personalized Recommendations (personalized-recommendations)
  • Targeted Ads (targeted-ads): requires verifiedAgeThreshold: 18 in Brazil
  • Profiling (profiling): requires verifiedAgeThreshold: 18 in Brazil
  • Push Notifications (push-notifications)
  • Direct Marketing (direct-marketing): requires verifiedAgeThreshold: 12 in Brazil
  • Forums (forums)

Commerce permissions

  • In-Game Purchases (in-game-purchases)
  • Loot Boxes Paid Cosmetic Only (loot-boxes-paid-cosmetic-only): requires verifiedAgeThreshold: 18 in Brazil
  • Loot Boxes Paid Gameplay Impacting (loot-boxes-paid-gameplay-impacting): requires verifiedAgeThreshold: 18 in Brazil
  • Loot Boxes Kompu Gacha (loot-boxes-kompu-gacha)
  • Send Gifts (send-gifts)
  • Simulated Gambling (simulated-gambling)
  • Virtual Property Ownership (virtual-property-ownership)

Create content or share data permissions

  • Camera Access (camera-access)
  • Share Game Clips Screenshots (share-game-clips-screenshots)
  • Photo Video Sharing (photo-video-sharing)
  • Precise Location Sharing (real-time-location-sharing)
  • User-generated content (mods)
  • Gameplay streaming (gameplay-streaming)
  • Gameplay recording (gameplay-recording)
  • Link to Third-Party Streaming App (link-to-third-party-streaming-app)

Advanced permissions

  • AI Generated Avatars (ai-generated-avatars)
  • Augmented Reality (augmented-reality)
  • Mature Language (mature-language)
  • Motion Data (motion-data)
  • AI chatbot (ai-chatbot)

Requesting additional permissions

After a player has received a session with permissions, they might want to allow additional permissions. Permissions can be disallowed for reasons such as:

  1. They're below the age threshold for the permission to be enabled by default.
  2. They're below the absolute minimum required age for the permission.
  3. The permission can only be enabled with a parent/guardian's consent, and it wasn't enabled during the consent process.
  4. The permission has a verifiedAgeThreshold that hasn't been satisfied yet (no verified platform age signal on record for the session).

Using the session upgrade API

The /session/upgrade API can be used to enable additional permissions. The type of challenge created depends on the permission:

  • PLAYER-managed permissions are enabled immediately with no challenge.
  • GUARDIAN-managed permissions create a CHALLENGE_PARENTAL_CONSENT challenge for the trusted adult to complete.
  • Permissions with verifiedAgeThreshold create a CHALLENGE_SESSION_UPGRADE_BY_AGE_ASSURANCE challenge. The player completes age verification through AgeKit+ rather than parental consent. See Age assurance for high-risk features for the full flow.

Example request

POST /api/v1/session/upgrade
Content-Type: application/json
Authorization: Bearer your-api-key

{
"sessionId": "608616da-4fd2-4742-82bf-ec1d4ffd8187",
"requestedPermissions": [
{
"name": "voice-chat"
}
]
}

Example response with challenge

If a permission requires guardian consent, the response includes a challenge:

{
"status": "CHALLENGE",
"challenge": {
"challengeId": "683409f1-2930-4132-89ad-827462eed9af",
"oneTimePassword": "ABC123",
"type": "CHALLENGE_PARENTAL_CONSENT",
"url": "https://family.k-id.com/authorize?otp=ABC123"
}
}

Example response without challenge

If all requested permissions can be enabled by the player, the response includes the updated session:

{
"status": "PASS",
"session": {
"sessionId": "608616da-4fd2-4742-82bf-ec1d4ffd8187",
"permissions": [
{
"enabled": true,
"managedBy": "PLAYER",
"name": "voice-chat"
}
]
}
}

When trusted adult consent is needed to enable a permission, a challenge is included in the response. This challenge can be shared similarly to the initial age gate process, by using a QR code, OTP, or email. For more information, see Challenges.

Email notification for permission upgrades

One quality-of-life difference is that it's possible to use the /challenge/send-email API without specifying an email address, and the API sends an email to the trusted adult who most recently approved a permission for the player. This enables players to request permission changes without specifying an email address themselves. You can check the hasApproverEmail flag in the Session to determine if the session already has an associated email address before calling the API. If no associated email address is found, the /challenge/send-email API responds with an INVALID_EMAIL error code, and you must fall back to another method, such as providing a QR code, OTP, or asking the player to enter their trusted adult's email address.

Handling the upgrade flow

  1. Check permissions: Before requesting an upgrade, check the current session to see which permissions are available and which require guardian consent
  2. Request upgrade: Call /session/upgrade with the requested permissions
  3. Handle challenge: If a challenge is returned, follow the same workflow as the initial VPC flow
  4. Update session: Once consent is granted, retrieve the updated session using /session/get