Privacy Boundaries

This page explains only the integration boundary that is already clear today: what belongs to the TiRTC platform, what belongs to your business system, and what belongs to your end users.

It does not cover data retention, deletion, regions, compliance, or privacy-policy wording.

The Three Parties

• TiRTC platform: provides connection capability, token validation, real-time media capability, and the public SDKs.
• Your business system: includes your app, backend, device management system, account system, and authorization rules.
• Your end users: the people using your application, such as device owners, family members, tenant members, or operators.

Who Decides Access

The TiRTC platform validates whether the token in a connection request matches the protocol requirements.

Your business system decides whether a specific user should be allowed to access a specific device or remote endpoint.

In short:

• the platform validates the connection request
• you decide business authorization
• the user initiates access within the permissions you define

Whether a user should access a device depends on your backend making that decision first and then issuing a short-lived token, not on the TiRTC platform making that business decision for you.

Who Should Hold What

TiRTC Platform

The platform carries the connection and media capabilities, but it should not be treated as your account system or device authorization system.

Questions like these should stay in your own business system:

• which home, organization, or tenant a user belongs to
• whether a user can access a device
• whether an account has been disabled or had access revoked

Your Backend

Your backend should hold or control access to:

• access_id
• secret_key
• the target device's device_secret_key when signing or verification requires it
• the relationship between users, devices, and authorization rules

This is the correct place to make authorization decisions and issue token values.

User-side Client

The user-side client should usually receive only the minimum information needed for the current connection, such as:

• remote_id
• a short-lived token
• the display data and stream IDs needed by the current page

The user-side client and ordinary business flows should not directly receive:

• secret_key
• device_secret_key
• the full license

Device Side

The device side may use the following when required:

• device_id
• device_secret_key
• license

But these values should remain inside a controlled device-side environment. They should not be spread into clients, screenshots, logs, or ticket content just to make debugging easier.

Common Mistakes

Treating Platform Validation as Business Authorization

Platform validation answers whether the connection request is valid.

Business authorization answers whether this user should be allowed to access this target.

These are different responsibilities.

Sending Secrets to the Client for Convenience

If the client can directly read secret_key or device_secret_key, the boundary is already wrong.

The client should receive a short-lived token, not the underlying signing secrets.

Do Not Treat Your Business User as an Account Managed by TiRTC

In the current integration model, user identity belongs primarily to your own business system.

From the TiRTC side, the user is usually just the subject you encode when issuing a token, and the person whose access you decided before issuing it.

Related Pages

• Glossary
• Connection
• Secret Handling Requirements