---
title: 'Trust Domains: Bounded and Verifiable Trust'
url: https://www.emergentmind.com/topics/trust-domains-tds
type: topic
---

# Trust Domains: Bounded and Verifiable Trust

Trust Domains (TDs) denote bounded contexts in which trust assumptions, participants, resources, and permissible flows are made explicit. In the information-sharing literature, a TD is defined as “a security–enhanced, distributed container in which a set of collaborating parties (humans, organizations or automated agents) share digital Assets under explicit Policies, enforced by technical and social Controls, so as to generate verifiable Evidence that the intended information-flow constraints are respected” [1512.06307]. In cloud access control, a TD is a security management domain under a single local policy authority [1305.2865]. In segmented networks, a TD or “zone” is a set of devices that jointly generate and share fragments of a single EdDSA key-pair [2310.04898]. In confidential computing, the term denotes either a privacy-and-integrity-protected virtual machine in Intel TDX [2303.15540] or a low-level abstraction for partitioning, sharing, attesting, and reclaiming resources in Tyche [2507.12364]. This suggests that the unifying idea of a TD is not a single implementation, but a delimited scope within which trust, authority, isolation, and verifiability are jointly specified.

## 1. Definitional scope and historical formulations

Early TD formulations in this corpus are anchored in secure information sharing. Arachchilage and Martin formalize a TD as a structure over Roles, Data, Policies, Actions, Controls, and Evidence, with explicit relations such as ownership, policy establishment, action attribution, monitoring, and evidence production [1511.04541]. The later taxonomy development generalizes this into a distributed container model, emphasizes separation of concerns, and adds the claim that TDs may intersect or nest while each Policy’s scope remains confined to its own TD [1512.06307].

A different lineage appears in cloud computing. In the TCloud framework, a TD \(X\) is defined simply as the set of entities under one local policy authority,
\[
X=\{\mathrm{EnT}_1,\mathrm{EnT}_2,\dots,\mathrm{EnT}_n\},
\]
with cross-domain interactions modeled between domains \(X\) and \(Y\) [1305.2865]. Here the emphasis is not on evidence-centric collaboration, but on trust calculation and dynamic cross-domain role conversion.

Later systems literature reuses the term for cryptographic and hardware isolation boundaries. In segmented networks, a TD is externally an ordinary Ed25519 signer with public key \(PK\), while internally no single device ever holds the full private key and the signing key is split among \(n\) participants with a \(t\)-of-\(n\) threshold [2310.04898]. In Intel TDX, a TD is “a privacy-and-integrity-protected virtual machine running in Intel’s Secure-Arbitration Mode (SEAM)” [2303.15540]. In Tyche, every isolated computation is a TD characterized by controlled cores, memory-region capabilities, interrupt policies, monitor operations, and an attestation-relevant register hash [2507.12364].

| Context | TD definition | Primary mechanism |
|---|---|---|
| Information sharing | Security-enhanced, distributed container | Policies, Controls, Evidence |
| Cloud access control | Security management domain | Trust evaluation, role conversion |
| Segmented networks | Set of devices sharing a threshold EdDSA key-pair | Leaderless DKG, threshold signing |
| Intel TDX | Privacy-and-integrity-protected VM in SEAM | Encrypted memory, attestation |
| Tyche | Isolated computation with capability-governed resources | Capabilities, recursive composition |

The definitional spread is substantial. A common misconception is that “Trust Domain” names a single standardized architecture. The record here instead shows several technically distinct but structurally related uses of the term.

## 2. Taxonomic core: roles, policies, controls, assets, actions, and evidence

The most explicit ontology appears in the 2015 taxonomy work. The preliminary model defines
\[
\mathrm{TD}=\bigl(R,\;D,\;P,\;A,\;C,\;E,\;
\mathit{owns},\;\mathit{establishes},\;\mathit{constrains},\;
\mathit{performedBy},\;\mathit{monitors},\;\mathit{produces}\bigr),
\]
where \(R\) is the set of Roles, \(D\) the set of Data assets, \(P\) Policies, \(A\) Actions, \(C\) Controls, and \(E\) Evidence [1511.04541]. The fundamental relations are stated in both the preliminary and developed taxonomy: Role owns Asset, Role establishes Policy, Policy constrains Action, Control monitors Action, and Control produces Evidence [1512.06307].

Several invariants are explicit. Each policy is authored by exactly one role; each action is attributed to exactly one role; every control monitors at least one action; every piece of evidence has a unique producer control; and each asset must be owned by at least one role [1511.04541]. The developed taxonomy refines this into higher-level categories: Domain and DomainEntities; Roles and Agents; Policies and Policy Decision Infrastructure; Controls and Evidence; Assets and Services; and Messaging and Delivery [1512.06307]. DomainEntity is specialized into Person, Organization, System, Process, Agent, and Resource; a PolicyDecisionPoint consumes Policy and produces PolicyDecisions; a PolicyEnforcementPoint enforces PolicyDecisions; and Evidence is a subtype of AuditEvent, ProvenanceRecord, or IntegrityMeasurement.

The corresponding purposes are also explicit. DomainEntity and Role delimit who may participate and what responsibilities they have. Policy declares what may happen and what must never happen inside the domain. Control technically or socially enforces how Policies are upheld. Evidence explains why participants can trust that Policies are adhered to. Asset classification into Data, Service, and Resource determines the technical enforcement, including encryption and access control [1512.06307].

The same literature motivates measurable trust characteristics but deliberately stops short of formal metrics. Integrity is described as assurance that Data or State has not been tampered with, confidentiality as assurance that only authorized Roles or Agents may access Data, and accountability as the degree to which Evidence links Actions to Roles unequivocally. No explicit trust-metric formulas are given. Instead, the general approach is a logical one: a TrustCharacteristic \(TC\) is realizable if there exist a Control \(C\) and Evidence \(E\) such that \(C\) monitors the Actions related to \(TC\) and \(E=C.\mathrm{produces}()\) satisfies audit or completeness criteria [1512.06307].

## 3. Cross-domain trust evaluation and dynamic role conversion

The TCloud model extends TD reasoning from single-domain collaboration to multi-domain cloud access control. Within one TD, it distinguishes direct assessment \(E_x(\mathrm{EnT}_i,\mathrm{EnT}_j)^k\in(-1,1)\), aggregate Quality of Service, Direct Trust Degree, reputation, and overall Trust Degree [1305.2865]. The update rules are given as
\[
\mathit{QoS}(\mathrm{EnT}_i,\mathrm{EnT}_j)^k
=
\alpha\,\mathit{QoS}(\mathrm{EnT}_i,\mathrm{EnT}_j)^{k-1}
+
(1-\alpha)\,E_x(\mathrm{EnT}_i,\mathrm{EnT}_j)^k,
\]
\[
\mathit{DTD}(\mathrm{EnT}_i,\mathrm{EnT}_j)^k
=
\beta\,\mathit{QoS}(\mathrm{EnT}_i,\mathrm{EnT}_j)^{k-1}
+
(1-\beta)\,E_x(\mathrm{EnT}_i,\mathrm{EnT}_j)^k,
\]
and
\[
TD(\mathrm{EnT}_i,X)^k
=
\theta\;\bigl(\tfrac1{n-1}\sum_{j\neq i}\mathit{DTD}(\mathrm{EnT}_i,\mathrm{EnT}_j)^k\bigr)
+
(1-\theta)\;Rp(\mathrm{EnT}_i,X)^k.
\]

For cross-domain interaction, the model defines cross-domain direct trust, cross-domain reputation, and overall inter-domain trust:
\[
\mathit{DTD}(X,Y)^k
=
\frac{1}{m}\sum_{j=1}^{m}
\mathit{DTD}\bigl(\mathrm{EnT}_j^Y,X\bigr)^{k},
\]
\[
Rp(X,Y)^k
=
\sum_{j=1}^{m}
\omega_j\;\mathit{QoS}\bigl(\mathrm{EnT}_j^Y,X\bigr)^{k},
\qquad
\sum_j\omega_j=1,
\]
\[
TD(X,Y)^k
=
\vartheta\,\mathit{DTD}(X,Y)^k
+
(1-\vartheta)\,Rp(X,Y)^k.
\]

Operationally, the framework layers trust modules onto an XACML-style architecture. The named components are Cloud User, Role Assignment Center, Local Authentication & Authorization Center, Policy Enforcement Point, Policy Decision Point, Policy Information Point, Trust Management Point, Trust Evaluation Point, Advanced AAC for inter-TD coordination, Policy Databases, and Cloud Resource or Service Provider. In the cross-domain sequence, the requester obtains a role from its home-domain Role Assignment Center, sends \(\langle \mathrm{ID}, \mathrm{role}, \mathrm{resourceID}\rangle\) to the remote-domain AAC, passes local trust evaluation, then passes inter-domain trust evaluation, receives a signed certificate, and finally presents the certificate and mapped local role to the PEP for admission or denial [1305.2865].

Role conversion is modeled by a role-correlation relation
\[
\mathcal{C}\subseteq R_Y\times R_X,
\]
where \((r_Y,r_X)\in\mathcal{C}\) means that guest-domain role \(r_Y\) maps to local role \(r_X\). The paper distinguishes transitive and non-transitive correlation, and defines three policy styles: Default Correlation, Clear Correlation, and Partial Correlation. The conversion algorithm returns \(\mathrm{Guest}_X\) when no mapping exists, and otherwise returns the lowest or most-specific role among the mapped local roles [1305.2865]. This framework treats TDs less as self-contained containers and more as policy authorities linked by quantified trust and dynamic role semantics.

## 4. Leaderless trust domains in segmented networks

In segmented networks, a TD is a cryptographic trust zone rather than a policy ontology. Membership is decided by a management service “out of band, by policy or a simple gossip,” and each TD is an overlay on the physical network, so nodes can overlap between domains [2310.04898]. Once membership is fixed, the \(n\) participating nodes run a Pedersen-style distributed key generation protocol and thereafter use threshold signing to reach leaderless consensus.

The DKG proceeds in two rounds. In Round 1, each participant \(P_j\) samples a secret share \(s_j\), random coefficients \(a_{j,1},\dots,a_{j,t-1}\), defines
\[
f_j(x)=s_j+a_{j,1}\cdot x+\dots+a_{j,t-1}\cdot x^{t-1}\pmod q,
\]
commits to the coefficients as \(C_{j,i}=G^{a_{j,i}}\), optionally generates a Schnorr-style proof \(\pi_j\), and broadcasts \((C_j,\pi_j)\). In Round 2, each participant sends private sub-shares \(\mu_{j\to \ell}=f_j(\ell)\), verifies received shares by checking
\[
G^{\mu_{i\to j}}\stackrel?=
\prod_{k=0}^{t-1}(C_{i,k})^{j^k},
\]
sets
\[
sk_j=\sum_{i=1}^{n}\mu_{i\to j}\pmod q,
\]
computes \(PK_j=sk_jG\), and derives the group public key
\[
PK=\sum_{j=1}^{n}C_{j,0}=\sum_{j=1}^{n}s_jG.
\]
Any \(t\) honest nodes suffice for key reconstruction or for signing, and up to \((n-t)\) nodes may fail or act maliciously without blocking the TD [2310.04898].

Threshold signing follows a two-round FROST-style protocol on Ed25519. Participants generate nonce commitments \((A_j,B_j)\), compute binding factors \(\beta_i\), form the joint commitment
\[
R=\sum_{i=1}^{n}(A_i+\beta_iB_i),
\]
compute the challenge
\[
c=H_2(R\parallel PK\parallel m),
\]
derive Lagrange coefficients \(\lambda_j\), and produce partial signatures
\[
z_j=a_j+\beta_jb_j+c\cdot \lambda_j\cdot sk_j \pmod q.
\]
Any node can aggregate \(t\) valid partials into \(\sigma=(R,z)\), while external verifiers check a standard EdDSA-style equation,
\[
zG =? R + H_2(R\parallel PK\parallel m)\,PK.
\]

The complexity analysis is explicit. DKG Round 1 requires \(O(n\cdot t)\) total group elements and \(O(n)\) broadcasts; Round 2 requires \(O(n^2)\) total scalar sends and \(O(n\cdot t)\) verification exponentiations per node; total communication is approximately \(O(n^2)\) field elements. The signing phase requires \(O(n)\) group elements and \(O(n)\) scalars, and costs \(O(n)\) point operations per node if all partials are verified. A small-world gossip can reduce broadcast complexity to \(O(n\log^2 n)\) messages, with each node verifying only \(O(\log n)\) partials on average. In the cited AWS t2.medium prototype with \(n=255\) and \(t=3\), DKG Round 2 took approximately \(30\) seconds, whereas each EdDSA group signature took less than \(10\) ms [2310.04898].

## 5. Trust domains in confidential computing

Intel TDX uses the term for a hardware-enforced VM boundary. A TD is a privacy-and-integrity-protected virtual machine running in Secure-Arbitration Mode, with confidentiality of TD memory and CPU state, integrity of TD memory, CPU state, and execution, and remote attestation as its stated security goals. The threat model assumes an adversary that controls the entire host software stack, can reconfigure the IOMMU, issue malicious DMA, read or write arbitrary physical memory, and manipulate VM entry or exit, but cannot extract CPU-fused secret keys or break the cryptographic primitives. The root of trust consists of immutable microcode and fuses plus the Intel-signed TDX Module and SEAM loaders. The key control structures are the Trust Domain Root, Trust Domain Control Structure, Trust Domain Virtual Processor State, Secure EPT, and Shared EPT. Private memory is protected by a TD-Owner bit and AES-XTS encryption, with cache-line encryption
\[
C_i = AES_{k_1}(P_i \oplus Tweak_i)\oplus Tweak_i,
\qquad
Tweak_i = AES_{k_2}(SectorID\parallel i).
\]
Measurements include build-time \(MRTD\), extended as
\[
MRTD_{\mathrm{new}} = SHA384(MRTD_{\mathrm{old}}\parallel \text{“MEM.PAGE.ADD”}\parallel GPA\parallel page\_data),
\]
and runtime \(RTMR[0..3]\). Local attestation packages REPORTDATA, TEE\_TCB\_INFO, TD\_INFO, and a MAC, while quote generation relies on the Quoting Enclave, Provisioning Certificate Enclave, and Intel’s certificate chain. The lifecycle spans FREE, INIT, READY, RUN, SUSPENDED, and RETIRED states [2303.15540].

Tyche uses TDs as a unified low-level abstraction for composable isolation. A trust domain is
\[
TD_i=(C_i,R_i,I_i,M_i,\mathcal{R}_i),
\]
where \(C_i\) is a set of physical CPU cores, \(R_i\) a set of memory-region capabilities, \(I_i\) interrupt policies mapping each vector to Deliver, Report, or NotReport, \(M_i\) the permitted Tyche-API calls, and \(\mathcal{R}_i\) a cryptographic hash of the initial register state. Each region capability \(r\in R_i\) is
\[
r=([a,b], rights, excl, attrs),
\]
with \(rights\subseteq\{R,W,X\}\), \(excl\in\{\mathrm{true},\mathrm{false}\}\), and \(attrs\subseteq\{\mathrm{CLEAN},\mathrm{HASH},\mathrm{VITAL}\}\). Tyche enforces two invariants: monotonic resource subdivision and preservation of exclusivity unless explicitly split via CARVE and SHARE (SEND). Its platform-independent Capability Engine maintains Region-CDT and TD-CDT structures, while the backend enforces decisions through EPT or PMP programming, interrupt routing, IPI-based synchronization, and a trap-based command channel. The API comprises CREATE, SET, GET, SEND, SEAL, ATTEST, ENUMERATE, SWITCH, ALIAS, CARVE, REVOKE, and GETCHAN. TDs can recursively create child TDs, yielding a tree of TDs in the TD-CDT, and attestation reports combine a TPM quote with a Tyche-signed snapshot of configuration and direct children. On an Intel Core i7-10700, reported microbenchmarks include ALIAS or CARVE from \(2\,\mu s\) up to \(75\,\mu s\), SWITCH overheads of \(0.49\,\mu s\) on x86 and \(0.25\,\mu s\) on RISC-V, TD\(_1\) CVM throughput less than \(1\%\) below native VM, and real workloads within \(10\%\) of native; the TD\(_2\) LLM inference case study reports approximately \(10\%\) overhead versus bare metal and approximately \(10\times\) faster execution than SGX [2507.12364].

The confidential-computing usage of “trust domain” is therefore narrower and more mechanistic than the information-sharing taxonomy. It refers to enforceable resource isolation, state confidentiality, and attestable execution, rather than primarily to social and organizational policy.

## 6. Scenarios, empirical investigation, and unresolved issues

The healthcare and conference-management scenarios in the taxonomy literature illustrate how TDs structure concrete sharing relationships. In the Health Care Service Scenario, the paper describes intersecting TDs such as SS1–SS3–Demo–TDom for bidirectional patient demographics exchange, SS1–SS2–Findings–TDom for sharing Diagnostics and Scans, SS3–Internal–TDom for one-way flow from SS3.Demographics to SS3.Births, and MS1–MS2–Stats–TDom for monitoring statistics. In each domain, the DomainManagementAgent publishes policy to a DomainPolicyStore, the PolicyDecisionPoint checks each query, the PolicyEnforcementPoint allows or rejects, and the DomainAuditAgent emits AuditEvents to a CentralAuditStore [1512.06307].

The ConfiChair scenario serves both as an application case and as an empirical validation setting. The relevant roles are Author, Reviewer, ConferenceChair, and ConferenceSystemAdministrator. Policies include “Reviewers cannot see other reviews until after their own is submitted,” “Chair sees all submissions and meta-reviews, but not raw system logs,” “Chair can assign reviewers; reviewers cannot reassign themselves,” and “SysAdmin may manage user-accounts but not decrypt submissions or scores” [1512.06307]. In the preliminary investigation, six Computer-Science participants, all experienced as Authors, Reviewers, or Chairs, were interviewed using semi-structured interviews and thematic analysis. The reported finding is that \(100\%\) of participants independently confirmed the need for each of Role, Policy, Action, Control, Evidence, and Asset; they also emphasized “no-read” policies, at-rest encryption, provenance quality, and lifecycle-bounded data retention [1511.04541].

Tyche extends the scenario repertoire into composable confidential computing. Its mutually distrustful LLM inference example nests TD\(_2\) as an LLM enclave inside TD\(_1\) as a user CVM, itself created by TD\(_0\), with separate attestations for the model owner, the user, and the cloud service provider [2507.12364]. This is a substantially different deployment setting from ConfiChair or healthcare data exchange, but it preserves the core idea that trust claims must be bounded and externally checkable.

Several limitations recur across the literature. A common misconception is that TDs inherently provide numerical trust scoring. The 2015 taxonomy papers explicitly motivate quantifiable trust attributes such as integrity, confidentiality, and accountability, yet do not formalize trust metrics or trust-scoring functions [1512.06307]. Another misconception is that TDs automatically resolve all adversarial behavior. Intel TDX explicitly excludes protection against Denial-of-Service and invasive side-channel or fault attacks beyond integrity, notes that side-channels and speculative attacks are not fully addressed by TDX 1.0, and identifies live migration, secure I/O integration, nested virtualization, and peripheral-device attestation as remaining research challenges [2303.15540]. Tyche states security invariants and an attestation mechanism, but also states that it does not include a full mechanized proof [2507.12364]. In segmented networks, the one-off DKG remains \(O(n^2)\) in communication, even though subsequent signatures are comparatively cheap [2310.04898].

Taken together, these works indicate that TDs are best understood as a family of bounded trust abstractions rather than a single doctrine. The family includes policy-scoped collaboration containers, trust-evaluated access-control domains, threshold-cryptographic zones, hardware-protected virtual machines, and recursively composable isolation compartments. What persists across these variants is the insistence that participation, authority, sharing, and evidence or attestation be made explicit.

Source: https://www.emergentmind.com/topics/trust-domains-tds