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_idsecret_key- the target device's
device_secret_keywhen 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_keydevice_secret_key- the full
license
Device Side
The device side may use the following when required:
device_iddevice_secret_keylicense
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.