Trust Domains: Bounded and Verifiable Trust

• Trust Domains are clearly defined bounded contexts that specify trust assumptions, participants, resources, and permissible flows.
• They integrate policy-based guidance with mechanisms like dynamic role conversion and threshold cryptography to secure cross-domain interactions.
• Implementations range from secure information-sharing containers to hardware-enforced VMs, ensuring isolated, verifiable, and accountable trust environments.

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” (Arachchilage et al., 2015). In cloud access control, a TD is a security management domain under a single local policy authority (Ullah et al., 2013). In segmented networks, a TD or “zone” is a set of devices that jointly generate and share fragments of a single EdDSA key-pair (Grierson et al., 2023). In confidential computing, the term denotes either a privacy-and-integrity-protected virtual machine in Intel TDX (Cheng et al., 2023) or a low-level abstraction for partitioning, sharing, attesting, and reclaiming resources in Tyche (Ghosn et al., 16 Jul 2025). 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 (Arachchilage et al., 2015). 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 (Arachchilage et al., 2015).

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$ (Ullah et al., 2013). 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 (Grierson et al., 2023). In Intel TDX, a TD is “a privacy-and-integrity-protected virtual machine running in Intel’s Secure-Arbitration Mode (SEAM)” (Cheng et al., 2023). 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 (Ghosn et al., 16 Jul 2025).

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, $$X=\{\mathrm{EnT}_1,\mathrm{EnT}_2,\dots,\mathrm{EnT}_n\},$$0 the set of Data assets, $$X=\{\mathrm{EnT}_1,\mathrm{EnT}_2,\dots,\mathrm{EnT}_n\},$$1 Policies, $$X=\{\mathrm{EnT}_1,\mathrm{EnT}_2,\dots,\mathrm{EnT}_n\},$$2 Actions, $$X=\{\mathrm{EnT}_1,\mathrm{EnT}_2,\dots,\mathrm{EnT}_n\},$$3 Controls, and $$X=\{\mathrm{EnT}_1,\mathrm{EnT}_2,\dots,\mathrm{EnT}_n\},$$4 Evidence (Arachchilage et al., 2015). 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 (Arachchilage et al., 2015).

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 (Arachchilage et al., 2015). 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 (Arachchilage et al., 2015). 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 (Arachchilage et al., 2015).

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 $$X=\{\mathrm{EnT}_1,\mathrm{EnT}_2,\dots,\mathrm{EnT}_n\},$$5 is realizable if there exist a Control $$X=\{\mathrm{EnT}_1,\mathrm{EnT}_2,\dots,\mathrm{EnT}_n\},$$6 and Evidence $$X=\{\mathrm{EnT}_1,\mathrm{EnT}_2,\dots,\mathrm{EnT}_n\},$$7 such that $$X=\{\mathrm{EnT}_1,\mathrm{EnT}_2,\dots,\mathrm{EnT}_n\},$$8 monitors the Actions related to $$X=\{\mathrm{EnT}_1,\mathrm{EnT}_2,\dots,\mathrm{EnT}_n\},$$9 and $X$0 satisfies audit or completeness criteria (Arachchilage et al., 2015).

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 $X$1, aggregate Quality of Service, Direct Trust Degree, reputation, and overall Trust Degree (Ullah et al., 2013). The update rules are given as

$X$2

$X$3

and

$X$4

For cross-domain interaction, the model defines cross-domain direct trust, cross-domain reputation, and overall inter-domain trust: $X$5

$X$6

$X$7

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 $X$8 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 (Ullah et al., 2013).

Role conversion is modeled by a role-correlation relation

$X$9

where $Y$0 means that guest-domain role $Y$1 maps to local role $Y$2. The paper distinguishes transitive and non-transitive correlation, and defines three policy styles: Default Correlation, Clear Correlation, and Partial Correlation. The conversion algorithm returns $Y$3 when no mapping exists, and otherwise returns the lowest or most-specific role among the mapped local roles (Ullah et al., 2013). 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 (Grierson et al., 2023). Once membership is fixed, the $Y$4 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 $Y$5 samples a secret share $Y$6, random coefficients $Y$7, defines

$Y$8

commits to the coefficients as $Y$9, optionally generates a Schnorr-style proof $PK$0, and broadcasts $PK$1. In Round 2, each participant sends private sub-shares $PK$2, verifies received shares by checking

$PK$3

sets

$PK$4

computes $PK$5, and derives the group public key

$PK$6

Any $PK$7 honest nodes suffice for key reconstruction or for signing, and up to $PK$8 nodes may fail or act maliciously without blocking the TD (Grierson et al., 2023).

Threshold signing follows a two-round FROST-style protocol on Ed25519. Participants generate nonce commitments $PK$9, compute binding factors $n$0, form the joint commitment

$n$1

compute the challenge

$n$2

derive Lagrange coefficients $n$3, and produce partial signatures

$n$4

Any node can aggregate $n$5 valid partials into $n$6, while external verifiers check a standard EdDSA-style equation,

$n$7

The complexity analysis is explicit. DKG Round 1 requires $n$8 total group elements and $n$9 broadcasts; Round 2 requires $t$0 total scalar sends and $t$1 verification exponentiations per node; total communication is approximately $t$2 field elements. The signing phase requires $t$3 group elements and $t$4 scalars, and costs $t$5 point operations per node if all partials are verified. A small-world gossip can reduce broadcast complexity to $t$6 messages, with each node verifying only $t$7 partials on average. In the cited AWS t2.medium prototype with $t$8 and $t$9, DKG Round 2 took approximately $n$0 seconds, whereas each EdDSA group signature took less than $n$1 ms (Grierson et al., 2023).

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

$n$2

Measurements include build-time $n$3, extended as

$n$4

and runtime $n$5. 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 (Cheng et al., 2023).

Tyche uses TDs as a unified low-level abstraction for composable isolation. A trust domain is

$n$6

where $n$7 is a set of physical CPU cores, $n$8 a set of memory-region capabilities, $n$9 interrupt policies mapping each vector to Deliver, Report, or NotReport, $$\mathrm{TD}=\bigl(R,\;D,\;P,\;A,\;C,\;E,\; \mathit{owns},\;\mathit{establishes},\;\mathit{constrains},\; \mathit{performedBy},\;\mathit{monitors},\;\mathit{produces}\bigr),$$0 the permitted Tyche-API calls, and $$\mathrm{TD}=\bigl(R,\;D,\;P,\;A,\;C,\;E,\; \mathit{owns},\;\mathit{establishes},\;\mathit{constrains},\; \mathit{performedBy},\;\mathit{monitors},\;\mathit{produces}\bigr),$$1 a cryptographic hash of the initial register state. Each region capability $$\mathrm{TD}=\bigl(R,\;D,\;P,\;A,\;C,\;E,\; \mathit{owns},\;\mathit{establishes},\;\mathit{constrains},\; \mathit{performedBy},\;\mathit{monitors},\;\mathit{produces}\bigr),$$2 is

$$\mathrm{TD}=\bigl(R,\;D,\;P,\;A,\;C,\;E,\; \mathit{owns},\;\mathit{establishes},\;\mathit{constrains},\; \mathit{performedBy},\;\mathit{monitors},\;\mathit{produces}\bigr),$$3

with $$\mathrm{TD}=\bigl(R,\;D,\;P,\;A,\;C,\;E,\; \mathit{owns},\;\mathit{establishes},\;\mathit{constrains},\; \mathit{performedBy},\;\mathit{monitors},\;\mathit{produces}\bigr),$$4, $$\mathrm{TD}=\bigl(R,\;D,\;P,\;A,\;C,\;E,\; \mathit{owns},\;\mathit{establishes},\;\mathit{constrains},\; \mathit{performedBy},\;\mathit{monitors},\;\mathit{produces}\bigr),$$5, and $$\mathrm{TD}=\bigl(R,\;D,\;P,\;A,\;C,\;E,\; \mathit{owns},\;\mathit{establishes},\;\mathit{constrains},\; \mathit{performedBy},\;\mathit{monitors},\;\mathit{produces}\bigr),$$6. 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 $$\mathrm{TD}=\bigl(R,\;D,\;P,\;A,\;C,\;E,\; \mathit{owns},\;\mathit{establishes},\;\mathit{constrains},\; \mathit{performedBy},\;\mathit{monitors},\;\mathit{produces}\bigr),$$7 up to $$\mathrm{TD}=\bigl(R,\;D,\;P,\;A,\;C,\;E,\; \mathit{owns},\;\mathit{establishes},\;\mathit{constrains},\; \mathit{performedBy},\;\mathit{monitors},\;\mathit{produces}\bigr),$$8, SWITCH overheads of $$\mathrm{TD}=\bigl(R,\;D,\;P,\;A,\;C,\;E,\; \mathit{owns},\;\mathit{establishes},\;\mathit{constrains},\; \mathit{performedBy},\;\mathit{monitors},\;\mathit{produces}\bigr),$$9 on x86 and $R$0 on RISC-V, TD$R$1 CVM throughput less than $R$2 below native VM, and real workloads within $R$3 of native; the TD$R$4 LLM inference case study reports approximately $R$5 overhead versus bare metal and approximately $R$6 faster execution than SGX (Ghosn et al., 16 Jul 2025).

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 (Arachchilage et al., 2015).

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” (Arachchilage et al., 2015). 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 $R$7 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 (Arachchilage et al., 2015).

Tyche extends the scenario repertoire into composable confidential computing. Its mutually distrustful LLM inference example nests TD$R$8 as an LLM enclave inside TD$R$9 as a user CVM, itself created by TD$$X=\{\mathrm{EnT}_1,\mathrm{EnT}_2,\dots,\mathrm{EnT}_n\},$$00, with separate attestations for the model owner, the user, and the cloud service provider (Ghosn et al., 16 Jul 2025). 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 (Arachchilage et al., 2015). 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 (Cheng et al., 2023). Tyche states security invariants and an attestation mechanism, but also states that it does not include a full mechanized proof (Ghosn et al., 16 Jul 2025). In segmented networks, the one-off DKG remains $$X=\{\mathrm{EnT}_1,\mathrm{EnT}_2,\dots,\mathrm{EnT}_n\},$$01 in communication, even though subsequent signatures are comparatively cheap (Grierson et al., 2023).

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.