Trust Model
QVTM separates identity, device state, operator authority, and runtime application sessions. This prevents a single bearer credential from becoming the root of trust.
Trust layers
| Layer | Source of truth | Purpose |
|---|---|---|
| Customer/domain | Control Plane | Determines the operational and commercial boundary |
| Operator/user | Control Plane | Determines who may act in a domain or application context |
| Device | QVTM device state and evidence | Determines whether the endpoint is known and acceptable |
| Challenge | Control Plane + mobile approval | Determines whether a specific action was approved |
| Verifier evidence | Trust Verifier API | Determines whether signed evidence and state are acceptable |
| Application session | Customer application | Local session created only after QVTM trust passes |
SaaS developer boundary
The SaaS Developers entity is an operational RBAC concept. It controls what an integration developer can access in the Admin Console and Control Plane. It is separate from the public Developer Portal, which only exposes docs, SDKs, examples, and API reference.
Why this matters
A developer reading docs does not gain tenant/domain authority. A developer registered in the SaaS can be granted scoped access to specific customers/domains. A device approving a challenge does not automatically become a long-lived application session. The application must create its own session after verifying QVTM state.