2 posts tagged with "permissions"

We've published end-to-end documentation for platform age signals: how Apple iOS, Google Play, Xbox, Meta Horizon, and k-ID age data flows into k-ID, when the age gate can be skipped, and how verified versus unverified signals interact with high-risk permissions and age assurance.

What's New​

CDK — Platform age signals​

• Platform age signals — Quick integration paths, API map, recommended request sequence, how POST /age-gate/check uses a platform signal, supported platforms and verified declaration types, and verified versus unverified signal behavior.
• Platform signal details — Per-platform field shapes, how to obtain each native signal, endpoint-by-endpoint notes (get-requirements, check, get-default-permissions, session/get, get-platform-age-range, session/upgrade), validation, age conflicts, and k-id signal rules.

Concepts and related documentation​

• Age signals — How platform age signals fit alongside other signal types and where to go for PlatformAgeSignal integration details.
• Age assurance for high-risk features and Permissions — Cross-linked behavior for verifiedAgeThreshold and verified platform signals at the age gate.

API reference (OpenAPI)​

Descriptions for session upgrade, AgeVerification, and platformAgeSignal now use verified platform signal wording consistently with the docs above.

Documentation​

• Platform age signals
• Platform signal details
• Age signals
• Age assurance for high-risk features
• Permissions

We've added a comprehensive guide for managing sessions and permissions, and updated our core concepts documentation with important clarifications.

What's New​

New Guide: Managing Sessions and Permissions​

We've added a new quick start guide: Managing sessions and permissions. This guide provides step-by-step instructions for:

• Detecting permission changes using webhooks and session comparison
• Handling session deletion and revocation
• Communicating permission changes to players
• Implementing permission upgrade flows
• Understanding how challenges relate to sessions

This guide is essential for any integration that needs to respond to permission changes over time, such as when parents modify settings or players age up.

Documentation Updates​

Sessions Documentation​

The Sessions concept page has been updated with important clarifications:

• Session ID persistence: Players have exactly one session per product. The session ID persists through permission changes, but a new session ID is created if a session is revoked and the consent flow is completed again.
• Session deletion behavior: Deleted sessions return HTTP 400 with NOT_FOUND error code (not 404). This is intentional—deleted sessions should be treated as if they never existed.
• Age-up changes: Age-up events don't trigger webhook notifications. You must use session comparison to detect these changes.

Permissions Documentation​

The Permissions concept page has been enhanced with:

• managedBy field changes: Clarified that managedBy can change over time (for example, from GUARDIAN to PLAYER when a player ages up).
• Player-managed permissions: When a player requests to enable a PLAYER-managed permission via the /session/upgrade API, it's automatically enabled without creating a challenge.
• Permissions upgrade content: The permissions upgrade documentation has been merged into the Permissions page for better discoverability.

What Changed​

Merged Documentation​

• The Permissions upgrade concept page has been merged into the Permissions page. All references have been updated to point to the new location.

Next Steps​

• Review the new Managing sessions and permissions guide
• Ensure your integration handles session deletion correctly (HTTP 400 with NOT_FOUND)

If you have any questions about these updates or need assistance with your integration, please don't hesitate to reach out to our support team.