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
| Field | Type | Description |
|---|---|---|
name | string | The identifier of the permission (for example, text-chat-private, loot-boxes-paid-gameplay-impacting) |
enabled | boolean | Whether the permission is currently enabled for the player |
managedBy | string | Who controls this permission. One of PLAYER, GUARDIAN, or PROHIBITED (see below) |
verifiedAgeThreshold | integer | Present 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. IfverifiedAgeThresholdis present, the player must also pass age assurance beforeenabledbecomestrue.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 theverifiedAgeThresholdand can't be unlocked through any means at their current age.
managedBy can change over timeThe 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):
| Permission | verifiedAgeThreshold |
|---|---|
profiling | 18 |
targeted-ads | 18 |
loot-boxes-paid-cosmetic-only | 18 |
loot-boxes-paid-gameplay-impacting | 18 |
direct-marketing | 12 |
How they differ from standard permissions
| Behaviour | Standard (GUARDIAN-managed) | High-risk (verifiedAgeThreshold) |
|---|---|---|
| Guardian consent alone unlocks it | Yes | No |
| Verified platform signal at age gate can satisfy it | No | Yes |
| Requires age assurance challenge if not already satisfied | No | Yes |
Shows as PROHIBITED when player is too young | Yes (jurisdiction ban) | Yes (age below threshold) |
Satisfying a verifiedAgeThreshold
There are two ways for a permission's threshold to be satisfied:
-
Verified platform signal at the age gate. If a platform age signal is passed to
POST /age-gate/checkand the signal is considered verified (for example, Apple iOSgovernmentIDCheckedor Google PlayVERIFIED) withageLow >= verifiedAgeThreshold, k-ID records anageVerificationon the session and the permission becomesenabled: trueimmediately. -
Age assurance via
/session/upgrade. If the threshold isn't already satisfied, callingPOST /session/upgradewith the permission name triggers aCHALLENGE_SESSION_UPGRADE_BY_AGE_ASSURANCEchallenge rather than a standard parental-consent challenge. The player completes age verification through AgeKit+, and the permission is unlocked on success.
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.
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): requiresverifiedAgeThreshold: 18in Brazil - Profiling (
profiling): requiresverifiedAgeThreshold: 18in Brazil - Push Notifications (
push-notifications) - Direct Marketing (
direct-marketing): requiresverifiedAgeThreshold: 12in Brazil - Forums (
forums)
Commerce permissions
- In-Game Purchases (
in-game-purchases) - Loot Boxes Paid Cosmetic Only (
loot-boxes-paid-cosmetic-only): requiresverifiedAgeThreshold: 18in Brazil - Loot Boxes Paid Gameplay Impacting (
loot-boxes-paid-gameplay-impacting): requiresverifiedAgeThreshold: 18in 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:
- They're below the age threshold for the permission to be enabled by default.
- They're below the absolute minimum required age for the permission.
- The permission can only be enabled with a parent/guardian's consent, and it wasn't enabled during the consent process.
- The permission has a
verifiedAgeThresholdthat 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 aCHALLENGE_PARENTAL_CONSENTchallenge for the trusted adult to complete.- Permissions with
verifiedAgeThresholdcreate aCHALLENGE_SESSION_UPGRADE_BY_AGE_ASSURANCEchallenge. 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"
}
]
}
}
Asking for parental consent
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.
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
- Check permissions: Before requesting an upgrade, check the current session to see which permissions are available and which require guardian consent
- Request upgrade: Call
/session/upgradewith the requested permissions - Handle challenge: If a challenge is returned, follow the same workflow as the initial VPC flow
- Update session: Once consent is granted, retrieve the updated session using
/session/get