Executable Trust: A Formal Model and Architecture for Verifiable Digital Interactions

Abstract

Digital trust in online interactions is commonly established through mechanisms such as decentralized identifiers (DIDs), verifiable credentials (VCs), and digital wallets. While these technologies support the correctness of individual components, they do not by themselves establish that an interaction as a whole is trustworthy. This limitation arises because real-world interactions consist of sequences of dependent steps, where inconsistencies may arise even when each step is locally valid. In this paper, we introduce the concept of executable trust, which models trust as a verifiable property of execution across complete interaction sequences. We formalize interactions as chains of TrustEvidence objects that capture step-level validity, constraint satisfaction, and cross-step dependencies. Based on this model, we show that step-level correctness alone is insufficient to characterize interaction-level trust under the stated execution assumptions. We further clarify the definition-induced modular structure of interaction-level trust and use a local failure-witness characterization to connect the formal model with scenario-based validation. We also present the Executable Trust Architecture (ETA), a five-layer architecture that operationalizes the proposed model through components for evidence generation, constraint enforcement, secure communication, and auditability. The feasibility of the approach is examined through scenario-based evaluation covering key trust properties—authenticity, integrity, privacy, and accountability—across nine scenarios comprising 68 test cases. The evaluation illustrates cases in which cross-step violations that pass conventional step-level verification are reflected as failures of ETA’s sequence-aware trust conditions under the evaluated assumptions.

1. Introduction

Trust is a fundamental requirement in digital systems, particularly in environments where interactions span multiple entities, domains, and execution steps. In digital wallet ecosystems, trust is commonly established through mechanisms such as cryptographic verification, credential validation, and access control policies, including Decentralized Identifiers (DIDs) [1], Verifiable Credentials (VCs) [2], and digital wallets [3]. These mechanisms support the verification of individual components.

However, verifying individual components does not necessarily establish that an entire interaction is trustworthy, especially in dynamic and cross-domain environments involving multiple execution steps. In such settings, dependencies between steps may introduce inconsistencies—such as credential replay, inconsistent authorization contexts, or tampering with execution logs—that are not captured by isolated verification. These observations highlight the need for a model that explicitly captures both per-step validity and cross-step dependencies across the full execution sequence.

To address this limitation, we introduce the concept of executable trust, in which trust-related conditions are defined and evaluated over the entire execution of an interaction. We formalize this idea through a trust model based on TrustEvidence, which captures the outcome of each execution step along with its associated constraints and linkage to previous steps. This model distinguishes between step-level validity and interaction-level trust, and defines trust in terms of both correctness and cross-step consistency.

Based on this model, we present the Executable Trust Architecture (ETA), a five-layer architecture that operationalizes the formal conditions of trust. Each layer of ETA contributes to the generation, validation, and linkage of TrustEvidence through mechanisms for evidence generation, constraint enforcement, secure communication, and auditability, supporting the consistent evaluation of trust conditions throughout the interaction lifecycle.

The contributions of this paper are as follows:

• Formal model. We formalize executable trust as a sequence-aware property defined over TrustEvidence objects and distinguish baseline step-level verification from interaction-level trust. Theorem 1 establishes their separation under the proposed model.
• Architecture. We present ETA, a five-layer architecture that operationalizes the formal trust model by supporting the generation, validation, and linkage of TrustEvidence, enabling the evaluation of the conditions $verify\left({\mathit{TE}}_i\right)$, $constraint\_ok(E_i,{\mathcal{X}}_i)$, $link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$, and $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$ throughout the interaction lifecycle.
• Evaluation. We evaluate the proposed model through scenario-based analysis across nine scenarios comprising 68 test cases. Among 38 adversarial cases, 30 (Group A) pass conventional step-level verification but are reflected as failures under ETA’s sequence-aware trust conditions in the evaluated scenarios, illustrating the separation discussed in Theorem 1.

The remainder of this paper is organized as follows. Section 2 reviews related work on digital trust and credential-based systems. Section 3 presents the formal executable trust model. Section 4 describes ETA and its layered design. Section 5 provides scenario-based validation of the model. Section 6 discusses implications, and Section 7 concludes the paper and discusses future work.

2. Related Work

2.1. Foundations of Digital Trust

Trust in digital systems refers to the degree of confidence that one party can place in another based on expectations of authenticity, integrity, and reliability. In technical environments, these expectations are realized through mechanisms that enable secure and verifiable interactions.

Digital trust is typically established through a combination of trust principles and trust mechanisms [4]. Trust principles define the desired properties of a system, such as authenticity, integrity, and accountability, while trust mechanisms provide technical means to support, evaluate, or provide evidence for these properties. For example, cryptographic protocols provide mechanisms for checking data integrity and authenticity, and authentication systems support the verification of entities participating in an interaction.

Historically, digital trust has been implemented through centralized models, such as Public Key Infrastructure (PKI) [5], where trusted authorities are responsible for identity issuance and validation. More recently, decentralized approaches have emerged to address the limitations of centralized control. Technologies such as Decentralized Identifiers (DIDs) [1] and Verifiable Credentials (VCs) [2] enable entities to create and manage their own identifiers and credentials in a distributed manner.

These developments provide the foundation for modern digital trust systems, where trust can be supported through verifiable data and cryptographic proofs.

2.2. Decentralized Identity and Digital Wallets

Decentralized identity [6,7,8] has emerged as a key approach for enabling trust in distributed digital environments. Unlike traditional identity systems that rely on centralized authorities, decentralized identity allows entities to create, manage, and control their own identifiers and credentials across multiple domains.

Decentralized Identifiers (DIDs) provide a mechanism for generating and resolving globally unique identifiers without requiring centralized registration. A DID is associated with a DID document that contains cryptographic material and service endpoints, enabling secure and verifiable interactions.

Verifiable Credentials (VCs) extend this model by allowing issuers to create digitally signed claims about a subject. These credentials can be independently verified using cryptographic proofs, providing evidence of their authenticity and integrity without requiring direct communication with the issuer at the time of verification.

Digital wallets [3] act as the primary interface for managing decentralized identity artifacts. They store cryptographic keys, manage credentials, and enable selective disclosure of information during interactions. Through these capabilities, wallets allow users to control how their identity data is presented and shared.

Together, DIDs, VCs, and digital wallets form a foundational layer for decentralized identity systems, supporting secure, verifiable, and user-centric data exchange.

2.3. Digital Trust Architecture

To support trust in complex digital environments, several architectural frameworks have been proposed to organize trust relationships and system components. These architectures define how trust-related functions are distributed across different layers and entities.

The Trust over IP (ToIP) model [9,10] introduces a layered architecture that separates governance, assurance, and technical infrastructure. This structure supports interoperability across domains by clearly defining responsibilities for identity, credential management, and verification processes.

Zero Trust Architecture (ZTA) [11] adopts a different approach by emphasizing continuous verification of entities and resources. Instead of assuming trust, based on network location or prior authentication, ZTA requires that each access request be evaluated based on contextual information and security policies.

Other frameworks, such as Digital Trust Ecosystem Frameworks (DTEF) [12], focus on coordinating trust relationships across organizations by defining shared policies, governance models, and interoperability requirements.

These architectural approaches provide systematic ways to structure trust in digital systems, enabling scalable and interoperable deployments across multiple domains.

2.4. Trust Verification Methods

A wide range of techniques has been developed to support the verification of trust-related properties in digital systems. These techniques provide mechanisms for validating data, identities, and system states under defined security assumptions.

Cryptographic mechanisms form the foundation of trust verification. Digital signatures are widely used to provide evidence of data authenticity and integrity, while public key infrastructures and decentralized key management systems support the verification of entity identities.

In decentralized identity systems, verification is typically performed through the validation of verifiable credentials, including signature verification, issuer authenticity checks, and revocation status validation.

Privacy-preserving techniques further enhance trust verification by enabling proofs of validity without revealing underlying data. Methods such as zero-knowledge proofs and selective disclosure allow users to demonstrate specific attributes while minimizing information exposure.

Additional mechanisms, including revocation registries, distributed ledgers, and secure communication protocols, contribute to maintaining the integrity and auditability of digital interactions.

2.5. Execution-Aware Verification and Auditability

Beyond credential-centric trust mechanisms, several research areas address the verification of execution behavior across sequences of events. Runtime verification checks whether an executing system satisfies specified properties during operation, while workflow verification examines whether multi-step processes comply with predefined constraints. Protocol state machines similarly model valid transitions between protocol states and can be used to detect invalid message sequences or unexpected transitions.

Secure audit logging, transparency logs, and provenance systems provide complementary mechanisms for recording and verifying execution histories. Secure audit logs and transparency logs support tamper-evident or append-only recording of events, while provenance systems capture the origin and transformation history of data. Distributed tracing also records causal relationships among events in distributed systems and is widely used to reconstruct execution paths across services.

These approaches are closely related to ETA because they address aspects of execution ordering, trace integrity, and post-hoc auditability. However, they do not by themselves provide a unified trust model that connects credential validity, revocation checking, consent binding, proof-to-transaction binding, cross-step consistency, and end-to-end interaction trust. ETA builds on these ideas by representing each execution step as TrustEvidence and by evaluating both per-step validity and cross-step consistency within a single formal model.

Blockchain systems and smart contracts provide a related context for execution-level trust because they involve multi-step execution, state transitions, and auditability in decentralized environments. Consensus mechanisms can provide an agreed ordering of transactions, and blockchain ledgers can provide tamper-resistant records of committed state transitions. However, these properties do not by themselves eliminate execution-level risks arising from the ordering of internal operations, external calls, state updates, and off-chain dependencies. In this sense, blockchain-based auditability and executable trust address related but different problems: the former provides a record of agreed execution, whereas the latter asks whether the sequence of trust-relevant steps satisfies the intended conditions of the interaction.

Smart contract re-entrancy provides an example of such a cross-step execution risk. An external call may occur before the intended state update is completed, allowing the callee to re-enter the contract while the contract remains in an intermediate state. Although each call may satisfy syntactic or access-control checks, the ordering between the external call and the state update violates the intended execution invariant. This example illustrates why locally valid operations may fail to compose into a trustworthy execution sequence, and aligns with the distinction in this paper between step-level correctness and interaction-level trust (Maturi et al., 2025 [13]).

ETA does not replace blockchain consensus or smart contract verification. It is complementary: blockchain systems can provide ordering or anchoring, and smart contract verification can analyze contract-level vulnerabilities, while ETA represents credential validity, consent binding, revocation status, proof-to-transaction binding, and cross-step consistency as TrustEvidence. The comparison, as summarized in Table 1, indicates that the main gap is not the absence of individual verification, logging, or monitoring mechanisms, but the lack of a common model that connects these mechanisms across a complete credential-based interaction sequence.

Table 1. Comparison of Related Approaches for Execution-Level Trust.

Approach	Credential Lifecycle	Binding	Execution Trace	E2E Trust
DID/VC verification	Yes	Partial	No	No
Digital wallets	Yes	Partial	No/Partial	No/Partial
ToIP/DTEF	Partial	Partial	Partial	Partial
Zero Trust Architecture	Partial	No	Partial	No/Partial
Runtime verification	No	No	Yes	Partial
Protocol state machines	No	No	Yes	Partial
Secure audit logging	No	No	Partial	Partial
Transparency logs	Partial	No	Yes	Partial
Provenance systems	No	No	Yes	Partial
Distributed tracing	No	No	Yes	Partial
Blockchain/smart contracts	Partial	Partial	Yes	Partial
ETA	Yes	Yes	Yes *	Yes **

Credential lifecycle includes credential verification and revocation checking. Binding includes consent binding and proof-to-transaction binding. Execution trace includes cross-step consistency and trace integrity. Blockchain and smart contract systems provide consensus-backed ordering and state-transition records, but do not by themselves model credential validity, consent binding, revocation status, or wallet-level TrustEvidence consistency. * Under stated logging assumptions. ** Under the proposed model assumptions.

2.6. Limitations of Existing Approaches

Taken together, the reviewed approaches provide important mechanisms for credential verification, selective disclosure, execution monitoring, trace recording, and auditability. However, they do not provide a common model that jointly links credential validity, consent binding, revocation state, proof-to-transaction binding, and cross-step consistency across a complete interaction sequence.

This limitation is particularly relevant to credential-based digital wallet interactions, where each individual step may be locally valid while the overall interaction violates a trust-relevant dependency between steps. This gap motivates the sequence-aware TrustEvidence model introduced in Section 3.

3. Problem Formulation: Executable Trust

3.1. Formal Model of Executable Trust

Building on this gap, we model an interaction as a sequence of dependent steps and introduce TrustEvidence as a step-wise abstraction for representing evidence, constraints, and inter-step linkage.

Formally, an interaction I is represented as:

$$I=(s_1,s_2,\dots ,s_n)$$

(1)

where each step $s_i$ corresponds to an operation such as identity verification, credential presentation, consent confirmation, revocation checking, or subsequent action execution. In conventional approaches, trust is typically evaluated at the level of individual steps:

$$\forall s_i\in I,verify(s_i,{\mathcal{B}}_i)=\mathrm{true}$$

(2)

where ${\mathcal{B}}_i$ denotes the baseline conditions considered for step-level verification. These conditions may include cryptographic correctness, credential signature validity, issuer authenticity, and schema validity.

However, this condition does not necessarily imply that the interaction as a whole satisfies the intended trust requirements:

$${\displaystyle \underset{i=1}{\overset{n}{\bigwedge }}}verify(s_i,{\mathcal{B}}_i)\nRightarrow verify(I,\mathcal{C})$$

(3)

This limitation arises because certain violations, such as time-of-check-to-time-of-use (TOCTOU) inconsistencies, stale revocation state, replayed presentations, or mismatches between consent scope and actual usage, may only become observable when the dependencies between steps are examined.

To address this limitation, we define a sequence-aware representation using TrustEvidence. TrustEvidence is generated step-wise: each execution step $s_i$ produces a corresponding TrustEvidence object ${\mathit{TE}}_i$, and an interaction is represented as a sequence $({\mathit{TE}}_1,{\mathit{TE}}_2,\dots ,{\mathit{TE}}_n)$ linked across execution steps. Accordingly, in the proposed model, TrustEvidence is better understood as a sequence of step-wise evidence objects rather than as a single monolithic evidence object for the entire interaction.

For each step $s_i$, we define:

$${\mathit{TE}}_i=(E_i,H\left({\mathit{TE}}_{i-1}\right),{\mathcal{C}}_i)$$

(4)

where $E_i$ denotes the evidence generated or observed at step i, $H\left({\mathit{TE}}_{i-1}\right)$ represents a verifiable linkage to the previous TrustEvidence object, and ${\mathcal{C}}_i$ denotes the constraint set applicable to step $s_i$.

The TrustEvidence structure is defined at the level of the formal model and is independent of any particular serialization or implementation format. The evidence component $E_i$ denotes the set of observable artifacts or outcomes available for verification at step $s_i$. Such evidence may include cryptographic proofs, credential verification outcomes, consent receipts, revocation-check results, or audit-log references, depending on the implementation.

The linkage term $H\left({\mathit{TE}}_{i-1}\right)$ denotes an abstract verifiable linkage to the previous TrustEvidence object. In a concrete implementation, the linkage may be realized using a hash value, a signed reference, a Merkle proof, an append-only log reference, or another verifiable linking mechanism. In the formal model, the linkage relation is represented by a predicate, such as $link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$. For the initial step $s_1$, no predecessor exists; by convention, $H\left({\mathit{TE}}_0\right)$ is taken as a distinguished genesis value ⊥, and $link({\mathit{TE}}_0,{\mathit{TE}}_1)=\mathrm{true}$, so that $verify\left({\mathit{TE}}_1\right)$ reduces to $verify\left(E_1\right)\wedge constraint\_ok(E_1,{\mathcal{X}}_1)$.

The formal model is serialization-independent; concrete formats such as JSON-LD, JWT, CBOR, or database records are implementation-oriented instantiations of the abstract TrustEvidence structure.

We introduce the following definitions to clarify the relationship between conventional step-level verification and TrustEvidence-based verification.

Definition 1

(Constraint Model). Let ${\mathcal{C}}_i$ denote the set of constraints applicable to step $s_i$. We define:

$${\mathcal{C}}_i:=({\mathcal{B}}_i,{\mathcal{X}}_i),$$

where ${\mathcal{B}}_i$ denotes baseline step-level conditions, such as cryptographic correctness, credential signature validity, issuer authenticity, and schema validity. The term ${\mathcal{X}}_i$ denotes execution-level constraints, such as authorization scope, revocation status, temporal validity, audience restriction, nonce freshness, and policy constraints. The global constraint set is:

$$\mathcal{C}:=\{C_1,{\mathcal{C}}_2,\dots ,{\mathcal{C}}_n\}.$$

Definition 2

(Step-Level Validity). We say that

$$verify(s_i,{\mathcal{B}}_i)=\mathrm{true}$$

if step $s_i$ satisfies the baseline conditions ${\mathcal{B}}_i$. Step-level verification refers specifically to baseline conditions and does not, by itself, evaluate execution-level constraints ${\mathcal{X}}_i$ or dependencies between steps.

Definition 3

(Evidence Validity). Let $E_i$ denote the set of observable artifacts or outputs associated with step $s_i$. We say that

$$verify\left(E_i\right)=\mathrm{true}$$

if the evidence associated with $s_i$ is valid under the relevant verification rules. This evidence serves as the observable basis for verifying step-level validity under ${\mathcal{B}}_i$. The model does not require $E_i$ to be stored in a specific data format. It may include credentials, cryptographic proofs, verification outcomes, log references, or other implementation-specific artifacts, provided that the required validity conditions can be evaluated under the stated assumptions.

Definition 4

(TrustEvidence Validity). For each step $s_i$, the corresponding TrustEvidence object is verified as:

$$verify\left({\mathit{TE}}_i\right):=verify\left(E_i\right)\wedge link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)\wedge constraint\_ok(E_i,{\mathcal{X}}_i).$$

(5)

This condition checks evidence validity, linkage across steps, and satisfaction of execution-level constraints. Under the proposed model, TrustEvidence-based verification can be interpreted as a refinement of conventional step-level verification because it also checks linkage and execution-level constraints.

Two levels of linkage verification are distinguished within $link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$. Structural verification checks only that ${\mathit{TE}}_i$ contains a well-formed hash field $H\left({\mathit{TE}}_{i-1}\right)$, and can be performed from ${\mathit{TE}}_i$ alone. Referential verification—which $link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$ in this definition requires—additionally checks that the stored hash matches the computed hash of the actual ${\mathit{TE}}_{i-1}$ object, and therefore requires access to the adjacent pair $\{{\mathit{TE}}_{i-1},{\mathit{TE}}_i\}$ or a trusted anchor recording $H\left({\mathit{TE}}_{i-1}\right)$. This distinction provides the basis for the inspection scope characterization in Remark 2. For the boundary case $i=1$, $H\left({\mathit{TE}}_0\right)$ is taken as a genesis value ⊥ and $link({\mathit{TE}}_0,{\mathit{TE}}_1)=\mathrm{true}$ by convention.

3.2. Execution State and Cross-Step Consistency

To capture dependencies between consecutive TrustEvidence objects, we define execution state, step preconditions, and cross-step consistency.

Definition 5

(Execution State). We define the execution state derived from a TrustEvidence object as:

$$state\left({\mathit{TE}}_i\right):=(statu{s}_i,scop{e}_i,tim{e}_i,contex{t}_i)$$

where $statu{s}_i$, $scop{e}_i$, $tim{e}_i$, and $contex{t}_i$ represent credential status, authorized scope, temporal constraints, and execution context at step $s_i$, respectively. We denote by $\mathcal{S}$ the space of possible execution states.

The function $state\left({\mathit{TE}}_i\right)$ should be interpreted as an abstract derivation function rather than as a requirement that the state be stored as a separate field in every implementation. In practice, the execution state may be derived from verified evidence, constraint evaluation results, temporal information, policy inputs, and execution context metadata. For example, ${\mathit{status}}_i$ may be derived from credential validity and revocation checks, ${\mathit{scope}}_i$ from consent receipts and disclosure policies, ${\mathit{time}}_i$ from timestamps or validity windows, and ${\mathit{context}}_i$ from transaction identifiers, verifier identifiers, audience values, nonces, or session metadata.

Algorithm 1 summarizes one implementation-oriented procedure for deriving the four components of $state\left({\mathit{TE}}_i\right)$.

Algorithm 1 $\mathsf{DeriveState}\left({\mathit{TE}}_i\right)$

Require: TrustEvidence object ${\mathit{TE}}_i=\left(E_i,H\left({\mathit{TE}}_{i-1}\right),{\mathcal{C}}_i\right)$, where ${\mathcal{C}}_i=({\mathcal{B}}_i,{\mathcal{X}}_i)$ Ensure: Execution state $\mathsf{state}\left({\mathit{TE}}_i\right)=\left({\mathit{status}}_i,{\mathit{scope}}_i,{\mathit{time}}_i,{\mathit{context}}_i\right)$ ▹ Component 1: Credential and constraint status 1: if $\mathsf{verify}\left(E_i\right)=\mathbf{true}$ and $\mathsf{constraint}\_\mathsf{ok}(E_i,{\mathcal{X}}_i.\mathsf{revocation})=\mathbf{true}$ then 2:     ${\mathit{status}}_i\leftarrow \mathsf{passed}$ 3: else 4:     ${\mathit{status}}_i\leftarrow \mathsf{failed}$ 5: end if ▹ Component 2: Scope information and authorization boundary 6: ${\mathit{disclosed}}_i\leftarrow E_i.\mathsf{disclosedClaims}$ 7: ${\mathit{authorized}}_i\leftarrow E_i.\mathsf{consentScope}$ 8: ${\mathit{required}}_i\leftarrow {\mathcal{X}}_i.\mathsf{requiredScope}$ ▹ Preserve both actual disclosure and authorization boundary 9: ${\mathit{scope}}_i\leftarrow (\mathsf{disclosed}:{\mathit{disclosed}}_i,\mathsf{authorized}:{\mathit{authorized}}_i,\mathsf{required}:{\mathit{required}}_i)$ ▹ Component 3: Temporal validity 10: ${\mathit{time}}_i.\mathsf{created}\leftarrow E_i.\mathsf{created}$ 11: ${\mathit{time}}_i.\mathsf{validityWindow}\leftarrow {\mathcal{X}}_i.\mathsf{freshness}.\mathsf{validityWindow}$ 12: ${\mathit{time}}_i.\mathsf{nonceRequired}\leftarrow {\mathcal{X}}_i.\mathsf{freshness}.\mathsf{nonceRequired}$ ▹ Component 4: Transaction-proof binding context 13: ${\mathit{context}}_i.\mathsf{transactionId}\leftarrow E_i.\mathsf{transactionId}$ 14: ${\mathit{context}}_i.\mathsf{audience}\leftarrow E_i.\mathsf{audience}$ 15: ${\mathit{context}}_i.\mathsf{verifierId}\leftarrow E_i.\mathsf{verifierId}$ 16: ${\mathit{context}}_i.\mathsf{nonce}\leftarrow E_i.\mathsf{nonce}$ 17: return $\mathsf{state}\left({\mathit{TE}}_i\right):=\left({\mathit{status}}_i,{\mathit{scope}}_i,{\mathit{time}}_i,{\mathit{context}}_i\right)$

Algorithm 1 should be read as an implementation-oriented projection procedure rather than as a requirement that all systems store an explicit execution-state object. The procedure identifies the fields that are used to derive the status, scope, time, and context components. Implementations may encode these fields differently, provided that the selected serialization and extraction profile preserves the information needed for subsequent precondition selection and cross-step consistency checks.

Unlike a projection that stores only the intersection between disclosed claims and the authorized consent scope, the derivation rule keeps the disclosed, authorized, and required scope components distinguishable. This distinction is useful for detecting over-disclosure, because the verifier can compare the actual disclosed attribute set with the authorization boundary and the required scope. Thus, ${\mathit{scope}}_i$ is represented as a structured value containing ${\mathit{disclosed}}_i$, ${\mathit{authorized}}_i$, and ${\mathit{required}}_i$, rather than as a single set obtained by intersection.

Definition 6

(Precondition). We define the precondition of step $s_i$ as a predicate over execution states:

$$precondition\left({\mathit{TE}}_i\right):\mathcal{S}\to \{\mathrm{true},\mathrm{false}\}$$

The precondition specifies the conditions under which step $s_i$ can be executed, and is evaluated against the execution state derived from ${\mathit{TE}}_{i-1}$.

The precondition of a step is modeled as a policy-derived predicate rather than as a fixed implementation field. It may be derived from the applicable policy, consent scope, protocol context, transaction-specific requirements, or verifier requirements. A concrete implementation may materialize this predicate through explicit fields, such as required status, authorized scope, freshness, audience, or nonce requirements. The formal model abstracts from the concrete representation and assumes that the predicate can be evaluated against the derived execution state. Algorithm 2 summarizes how this predicate is derived for a given pair of consecutive TrustEvidence objects.

Algorithm 2 $\mathsf{SelectPrecondition}$$({\mathit{TE}}_{i-1},{\mathit{TE}}_i,{\mathit{scope}}_{i-1}^{auth},\mathrm{\Phi },\mathrm{\Pi })$

Require: Consecutive TrustEvidence objects ${\mathit{TE}}_{i-1}$ and ${\mathit{TE}}_i$ Require: Authorized consent scope carried forward from the preceding step, ${\mathit{scope}}_{i-1}^{auth}:=state\left({\mathit{TE}}_{i-1}\right).\mathit{scope}.\mathsf{authorized}$ Require: Shared policy store $\mathrm{\Phi }$ for resolving policy-defined predicate templates Require: Protocol transition rule set $\mathrm{\Pi }$ for the interaction type Ensure: Predicate $P_i=precondition\left({\mathit{TE}}_i\right):S\to \{\mathbf{true},\mathbf{false}\}$ ▹ Step 1: Select a policy-defined predicate template 1: ${\rho }_i\leftarrow {\mathcal{X}}_i.\mathsf{policyRef}$ 2: $T_i\leftarrow \mathsf{LoadPredicateTemplate}(\mathrm{\Phi },{\rho }_i)$ ▹ Step 2: Select the applicable protocol transition rule 3: ${\tau }_i\leftarrow \mathsf{SelectTransitionRule}(\mathrm{\Pi },{\mathit{TE}}_{i-1},{\mathit{TE}}_i)$ ▹ Step 3: Instantiate the selected predicate template 4: $P_i\leftarrow \mathsf{Instantiate}(T_i,\{\mathsf{requiredStatus}:{\mathcal{X}}_i.\mathsf{requiredStatus},$      $\mathsf{requiredScope}:{\mathcal{X}}_i.\mathsf{requiredScope},$      $\mathsf{authorizedScope}:{\mathit{scope}}_{i-1}^{auth},$      $\mathsf{audience}:{\mathcal{X}}_i.\mathsf{audience},$      $\mathsf{freshness}:{\mathcal{X}}_i.\mathsf{freshness},$      $\mathsf{nonceRequired}:{\mathcal{X}}_i.\mathsf{freshness}.\mathsf{nonceRequired},$      $\mathsf{transitionRule}:{\tau }_i\left\}\right)$ ▹ Step 4: Return the selected and instantiated predicate 5: return $P_i$

Algorithm 2 should be read as a selection and instantiation procedure. It selects a predicate template via the policy reference in ${\mathcal{X}}_i$, instantiates it with the authorized consent scope from the preceding step and the execution-level constraints of the current step, and refines it with the applicable protocol transition rule. The reproducibility of this procedure depends on two shared-context assumptions: (1) a shared policy store $\mathrm{\Phi }$, from which $\mathsf{LoadPredicateTemplate}$ retrieves a fixed template for a given $\mathsf{policyRef}$, and (2) a shared protocol transition rule set $\mathrm{\Pi }$, from which $\mathsf{SelectTransitionRule}$ selects a fixed rule for a given $({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$ pair. Under these assumptions, independent verifiers operating on the same TrustEvidence sequence can instantiate equivalent predicate $P_i$ and reach equivalent consistency decisions under the same verification context.

Definition 7

(Cross-Step Consistency). We define cross-step consistency between two consecutive TrustEvidence objects as:

$$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i):=state\left({\mathit{TE}}_{i-1}\right)\vDash precondition\left({\mathit{TE}}_i\right).$$

(6)

This condition holds if the execution state at step $s_{i-1}$ satisfies the precondition of step $s_i$.

Thus, cross-step consistency is defined as a relationship between consecutive TrustEvidence objects, rather than as a property of an isolated step. This condition captures cases where a step may be locally valid but inconsistent with the state produced by previous steps. For example, a credential presentation may contain a valid cryptographic proof, but a subsequent access or action step may still be inconsistent if the credential has been revoked, if the consent scope has expired, or if the presentation is replayed in a different transaction context.

The formal condition does not depend on a particular storage layout. In an implementation-oriented representation, the state and precondition may be materialized using fields such as credential status, authorized scope, timestamp, transaction identifier, audience value, verifier identifier, and nonce. These fields support the evaluation of freshness, revocation validity, scope consistency, and proof-to-transaction binding under the stated assumptions. Nevertheless, such fields are implementation-level realizations of the abstract state and precondition functions, not additional assumptions of the formal model itself. The explicit checks shown below should be understood as representative implementation-level clauses of $P_i$, separated for readability and auditability.

The output of Algorithm 2 is the predicate $P_i=precondition\left({\mathit{TE}}_i\right)$. Algorithm 3 then evaluates this predicate against the execution state derived from the preceding TrustEvidence object. Thus, the operational consistency decision corresponds to Definition 7:

$$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)⟺P_i\left(state\left({\mathit{TE}}_{i-1}\right)\right)=\mathbf{true}.$$

Finally, the interaction-level verification procedure can be viewed as an application of the preceding procedures to a TrustEvidence sequence. Algorithm 4 summarizes one implementation-oriented procedure for evaluating the interaction-level trust condition. The procedure checks step-level TrustEvidence validity for each ${\mathit{TE}}_i$ and cross-step consistency for each adjacent pair $({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$, reflecting the formal conditions in Equations (5) and (6), whose conjunction defines Equation (7).

Algorithms 1–4 are intended to provide an implementation-oriented interpretation of the formal model. Under a fixed serialization format, a fixed extraction profile, a fixed policy profile, fixed protocol transition rules, and the same verification context, independent verifiers can derive equivalent execution-state values and reach equivalent interaction-level trust decisions under the same verification context for the same TrustEvidence sequence.

Algorithm 3 $\mathsf{EvaluateCrossStepConsistency}$$({\mathit{TE}}_{i-1},{\mathit{TE}}_i,P_i,N_{\mathrm{consumed}})$

Require: Consecutive TrustEvidence objects ${\mathit{TE}}_{i-1}$ and ${\mathit{TE}}_i$ Require: Predicate $P_i=precondition\left({\mathit{TE}}_i\right)$ selected by Algorithm 2 Require: Session-scoped nonce registry $N_{\mathrm{consumed}}$, maintained per verifier per interaction Ensure: $\mathbf{true}$ if $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$ holds; $\mathbf{false}$ otherwise 1: $stat{e}_{i-1}\leftarrow \mathsf{DeriveState}\left({\mathit{TE}}_{i-1}\right)$ 2: $stat{e}_i\leftarrow \mathsf{DeriveState}\left({\mathit{TE}}_i\right)$ ▹ Check 1: Predecessor status continuity 3: if $stat{e}_{i-1}.\mathit{status}\ne \mathsf{passed}$ then 4:     return $\mathbf{false}$ 5: end if ▹ Check 2: Scope containment and no over-disclosure 6: if $stat{e}_i.\mathit{scope}.\mathsf{disclosed}⊈stat{e}_i.\mathit{scope}.\mathsf{authorized}$ then 7:     return $\mathbf{false}$ 8: end if 9: if $stat{e}_i.\mathit{scope}.\mathsf{disclosed}⊈stat{e}_{i-1}.\mathit{scope}.\mathsf{authorized}$ then 10:     return $\mathbf{false}$ 11: end if 12: if $stat{e}_i.\mathit{scope}.\mathsf{required}⊈stat{e}_i.\mathit{scope}.\mathsf{disclosed}$ then 13:     return $\mathbf{false}$ 14: end if ▹ Check 3: Temporal validity 15: if $t_{\mathrm{now}}>stat{e}_{i-1}.\mathit{time}.\mathsf{validityWindow}$ then 16:     return $\mathbf{false}$ 17: end if ▹ Check 4: Transaction-proof binding 18: if $stat{e}_i.\mathit{context}.\mathsf{transactionId}\ne stat{e}_{i-1}.\mathit{context}.\mathsf{transactionId}$ then 19:     return $\mathbf{false}$ 20: end if 21: if $stat{e}_i.\mathit{context}.\mathsf{audience}\ne stat{e}_{i-1}.\mathit{context}.\mathsf{audience}$ then 22:     return $\mathbf{false}$ 23: end if ▹ Check 5: Nonce freshness 24: if $stat{e}_i.\mathit{context}.\mathsf{nonce}=\perp$ then 25:     return $\mathbf{false}$ 26: end if 27: if $stat{e}_i.\mathit{context}.\mathsf{nonce}\in N_{\mathrm{consumed}}$ then 28:     return $\mathbf{false}$ 29: else 30:     $N_{\mathrm{consumed}}\leftarrow N_{\mathrm{consumed}}\cup \{stat{e}_i.\mathit{context}.\mathsf{nonce}\}$ 31: end if ▹ Check 6: Evaluate the selected precondition 32: if $P_i\left(stat{e}_{i-1}\right)=\mathbf{false}$ then 33:     return $\mathbf{false}$ 34: end if 35: return $\mathbf{true}$

Algorithm 4 $\mathsf{VerifyInteractionChain}$$({\mathit{TE}}_1,\dots ,{\mathit{TE}}_n,\mathrm{\Phi },\mathrm{\Pi })$.

Require: TrustEvidence sequence $({\mathit{TE}}_1,\dots ,{\mathit{TE}}_n)$ Require: Protocol transition rule set $\mathrm{\Pi }$ for the interaction type Require: Shared policy store $\mathrm{\Phi }$ for resolving policy-defined predicate templates Require: Session-scoped nonce registry $N_{\mathrm{consumed}}$, maintained per verifier per interaction Ensure: $\mathbf{true}$ if $\mathsf{verify}(I,\mathcal{C})=\mathbf{true}$; $\mathbf{false}$ otherwise 1: for $i\leftarrow 1$ to n do ▹ Step 1: Derive the execution state of the current TrustEvidence 2:     $stat{e}_i\leftarrow \mathsf{DeriveState}\left({\mathit{TE}}_i\right)$ ▹ Step 2: Check step-level TrustEvidence validity 3:     if $\mathsf{verify}\left({\mathit{TE}}_i\right)=\mathbf{false}$ then 4:         return $\mathbf{false}$ 5:     end if ▹ Step 3: Check cross-step consistency for adjacent pairs 6:     if $i>1$ then 7:         ${\mathit{scope}}_{i-1}^{auth}\leftarrow stat{e}_{i-1}.\mathit{scope}.\mathsf{authorized}$ 8:         $P_i\leftarrow \mathsf{SelectPrecondition}({\mathit{TE}}_{i-1},{\mathit{TE}}_i,{\mathit{scope}}_{i-1}^{auth},\mathrm{\Phi },\mathrm{\Pi })$ 9:         if $\mathsf{EvaluateCrossStepConsistency}({\mathit{TE}}_{i-1},{\mathit{TE}}_i,P_i,N_{\mathrm{consumed}})=\mathbf{false}$ then 10:            return $\mathbf{false}$ 11:         end if 12:     end if 13: end for 14: return $\mathbf{true}$

Remark 1.

Evaluation Context of state() and precondition().

In the intended verification setting, the function $state\left({\mathit{TE}}_i\right)$ can be evaluated by the verifying party from the serialized ${\mathit{TE}}_i$ object, using the fixed extraction profile described above. Specifically:

• Holder. Upon completing execution step $s_i$, ${\mathit{TE}}_i=(E_i,H\left({\mathit{TE}}_{i-1}\right),C_i)$ and may bind the derived execution state using an integrity mechanism. In Listing 1, this is represented by the mandatory recordProof field, although the formal model does not prescribe a specific integrity mechanism.
• Verifier. Upon receiving ${\mathit{TE}}_i$, the verifier independently derives $state\left({\mathit{TE}}_i\right)$ from the evidence, constraint, and context fields of ${\mathit{TE}}_i$ by applying the fixed extraction profile described in Definition 5 and Algorithm 1. The verifier then evaluates $precondition\left({\mathit{TE}}_i\right)$ against $state\left({\mathit{TE}}_{i-1}\right)$ to check $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$ as defined in Definition 7.

The nonce registry ${\mathcal{N}}_{\mathit{consumed}}$ is maintained per verifier per interaction session and does not require synchronization across verifiers. Under the stated model assumptions, Check 4 reflects cross-verifier replay attempts as audience-binding failures, which requires the audience field of ${\mathit{TE}}_i$ to match the receiving verifier’s identifier; a presentation replayed to a different verifier, therefore, fails before reaching Check 5. Under the stated model assumptions, a session-scoped ${\mathcal{N}}_{\mathit{consumed}}$ is sufficient.

• Listing 1. Implementation-Oriented JSON-LD Example of a Step-Level TrustEvidence Object.
•   
• {
•   "@context": [{
•     "eta": "https://example.org/eta#",
•     "sec": "https://w3id.org/security#",
•     "id": "@id",
•     "type": "@type"
•   }],
•   "id": "urn:uuid:te-0002",
•   "type": "eta:TrustEvidence",
•   "interactionId": "urn:uuid:interaction-1234",
•   "actorId": "did:example:pairwise-holder-7f3a",
•   "credentialRef": "urn:sha256:cred8f4a2b91…",
•   "created": "2025-05-10T09:12:35Z",
•   "step": {"index": 2, "id": "s2"},
•   
•   "evidence": {
•     "proofMechanism": "SD-JWT-ES256",
•     "disclosedClaims": ["given_name", "degree"],
•     "sdHash": "sha256-WyJzYWx0…",
•     "verificationResult": { "signatureValid": true, "schemaValid": true,
•       "issuerAuthentic": true,
•       "revocationStatus": {
•         "mechanism": "StatusList2021",
•         "statusListRef": "https://issuer.example/status/1",
•         "statusListIndex": 42,
•         "checkedAt": "2025-05-10T09:12:35Z",
•         "status": "valid"
•        }
•      }
•   },
•   
•   "previousTrustEvidence": {
•     "id": "urn:uuid:te-0001",
•     "hash": "sha256-e3b4d2a1…f2e1d0c9"
•   },
•   
•   "constraints": {
•     "policyRef": "eta:PrivacyPolicy-v1",
•     "consentScope": ["given_name", "degree"],
•     "requiredScope": ["given_name", "degree"],
•     "audience": "did:example:verifier-1",
•     "verifierId": "did:example:verifier-1",
•     "freshness": {"nonceRequired": true}
•     },
•   
•   "executionState": {
•     "status": "passed",
•     "authorizedScope": ["given_name", "degree"],
•     "validAt": "2025-05-10T09:12:35Z",
•     "context": {
•       "transactionId": "urn:uuid:tx-5678",
•       "audience": "did:example:verifier-1",
•       "verifierId": "did:example:verifier-1",
•       "nonce": "b7e2d5f0a1c384"
•     },
•     "stateHash": "sha256-9a8b7c6d…"
•   },
•   
•   "precondition": {
•     "requires": "s1",
•     "requiredStatus": "passed",
•     "requiredScope": ["given_name", "degree"],
•     "requiredAudience": "did:example:verifier-1",
•     "requiredVerifierId": "did:example:verifier-1"
•   },
•   
•   "recordProof": {
•     "type": "JsonWebSignature2020", "created": "2025-05-10T09:12:36Z",
•     "verificationMethod": "did:example:pairwise-holder-7f3a#key-1",
•     "proofPurpose": "assertionMethod", "jws": "<JWS>"}
• }

3.3. Threat Model and Assumptions

3.3.1. Adversary Capabilities

We consider an adversary that may observe, replay, delay, modify, or forge messages exchanged during a digital interaction, including TrustEvidence objects, credential presentations, and consent receipts. The adversary may also resubmit nonce-bound consent tokens, alter execution records, compromise selected infrastructure components, or collude with malicious participants, subject to the scope restrictions described below.

3.3.2. Cryptographic and Freshness Assumptions

ETA operates under the following assumptions. Secure primitives: ECDSA P-256 [14], SHA-256 [15], and AES-128-GCM [16] are assumed computationally secure; forged signatures or proofs are expected to be reflected as invalid under the stated cryptographic assumptions. Private key integrity: Private keys are assumed not to be extracted from trusted key storage; hardware-level compromise falls outside the current model scope. Freshness and revocation integrity: Timestamps, nonces, and revocation status are assumed to be obtained from sources satisfying the stated availability and integrity requirements, subject to the freshness constraints in ${\mathcal{X}}_i$.

3.3.3. ETA Response Categories

We classify adversarial conditions into four categories, summarized in Table 2.

Table 2. Threat Classification and ETA Response Scope.

Threat	ETA Classification	Formal Condition/Note
Credential/proof forgery	Rejects	$verify\left(E_i\right)=\mathrm{false}$; crypto assumptions
Credential replay	Reflects	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$; Algorithm 3, Check 4
Consent-token reuse	Reflects	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$; Algorithm 3, Check 5
Revocation change (TOCTOU)	Reflects	$constraint\_ok(E_i,{\mathcal{X}}_i)=\mathrm{false}$; freshness constraint
Stale cached data	Reflects	$constraint\_ok(E_i,{\mathcal{X}}_i)=\mathrm{false}$; freshness constraint
Scope/consent violation	Reflects	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$; scope containment check
Log modification/reordering	Reflects	$link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$; SHA-256 recomputation
Malicious verifier (disclosure)	Partially mitigates	Selective disclosure, consent binding, and scope checks; post-disclosure misuse is out of scope.
Malicious verifier (post-disclosure)	Out of scope	Governance or legal framework required
Compromised wallet/host	Out of scope	Trust-base assumption violated
Untrusted logger (modification)	Reflects	$link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$; within observed sequence
Untrusted logger (deletion/fork)	Out of scope	External anchoring required
Network partitions	Out of scope	Replication or consensus required
Byzantine faults	Out of scope	Distributed consensus required

ETA Classification—Rejects: $verify\left(E_i\right)=\mathrm{false}$ under crypto assumptions. Reflects: observable as a failure of a named formal condition in Equations (5)–(7). Partially mitigates: ETA addresses selected aspects but cannot prevent all forms. Out of scope: requires mechanisms beyond the current model (Section 3.3.4).

(1)

Rejected under the stated cryptographic assumptions: attacks involving forged credentials, invalid signatures, or tampered proofs result in $verify\left(E_i\right)=\mathrm{false}$.

(2)

Reflected as failures of formal trust conditions in Equations (5)–(7): invalid evidence ($verify\left(E_i\right)$), revocation and freshness violations ($constraint\_ok(E_i,{\mathcal{X}}_i)$), log modification or reordering ($link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$), and credential replay, consent-token reuse, and scope violations ($consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$). Consent-token reuse is reflected via the nonce freshness check (Algorithm 3 Check 5), which is structurally distinct from credential replay detection via the transaction binding and audience checks (Check 4).

(3)

Partially mitigated: disclosure-time malicious verifier behavior (over-requesting, replay, or scope violation) is partially addressed through selective disclosure, consent binding, scope checks, and audit evidence. Such disclosure-time violations may be reflected by $constraint\_ok(E_i,{\mathcal{X}}_i)$ or $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$. Post-disclosure misuse falls outside the current model (category 4).

(4)

Outside the current formal scope: The adversarial conditions listed in the Scope Limitations below are outside the scope of the current ETA model.

3.3.4. Scope Limitations

The following conditions are outside the scope of the current ETA model.

• Compromised wallet and host. Host compromise, malware-controlled wallets, and private-key extraction violate the trust-base assumption on key storage integrity. Under such conditions, the cryptographic validity of generated TrustEvidence objects cannot be relied upon. Hardware-backed key storage or remote attestation would be required to address this class of threat.
• Malicious verifier—post-disclosure misuse. ETA partially mitigates disclosure-time behavior through selective disclosure, consent binding, and audit evidence, but does not prevent misuse of data after a successful presentation. Such post-disclosure misuse falls outside the current model and would require data governance or regulatory mechanisms.
• Untrusted logger—deletion, suppression, and forked histories. Hash-linked logs support detection of modification and reordering within an observed sequence ($link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$), but log deletion, suppression, or forked histories require external anchoring, append-only storage, or transparency-log techniques.
• Network partitions and message delivery failures. ETA assumes that TrustEvidence objects can be delivered and verified by the intended parties. Network partitions that prevent this fall outside the current scope; addressing them would require replication or consensus protocols.
• Byzantine faults and consensus failures. Byzantine behavior, consensus failures, and ledger-level forks in distributed infrastructure are outside the current ETA model unless externally represented as TrustEvidence violations or handled by an underlying consensus or transparency-log mechanism. The role of the logging assumption is further discussed in Section 4.3.5.

The purpose of ETA is not to eliminate all adversarial behavior, but to support the observability and auditability of trust-relevant conditions under the stated assumptions.

3.4. Properties of the Model

Proposition 1

(Refinement of Step-Level Verification). For any execution step $s_i$, if

$$verify\left({\mathit{TE}}_i\right)=\mathrm{true},$$

then

$$verify(s_i,{\mathcal{B}}_i)=\mathrm{true}.$$

However, the converse does not necessarily hold; that is, there exist cases where

$$verify(s_i,{\mathcal{B}}_i)=\mathrm{true}\mathit{but}verify\left({\mathit{TE}}_i\right)=\mathrm{false}.$$

Proof. 

The forward implication follows from Definition 4, since $verify\left({\mathit{TE}}_i\right)$ requires $verify\left(E_i\right)$, which provides evidence supporting the baseline validity of step $s_i$ under ${\mathcal{B}}_i$.

To show that the converse does not necessarily hold, consider a case where

$$verify(s_i,{\mathcal{B}}_i)=\mathrm{true}$$

but an execution-level constraint in ${\mathcal{X}}_i$ is violated (e.g., revocation or scope constraints). In such a case,

$$constraint\_ok(E_i,{\mathcal{X}}_i)=\mathrm{false}.$$

Therefore,

$$verify\left({\mathit{TE}}_i\right)=\mathrm{false}.$$

Therefore, under Definition 4, TrustEvidence-based verification can be interpreted as a refinement of step-level verification under the proposed model.    □

Proposition 2

(Existence of Hidden Cross-Step Violation). There exist execution sequences in which all individual steps satisfy step-level verification, yet the interaction violates cross-step consistency. Formally, there exists an interaction

$$I=(s_1,s_2,\dots ,s_n)$$

such that

$$\forall i,verify(s_i,{\mathcal{B}}_i)=\mathrm{true},$$

but

$$\exists i>1\mathit{such}\mathit{that}consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}.$$

Proof. 

Consider two consecutive steps $s_{i-1}$ and $s_i$ such that both satisfy their baseline verification conditions:

$$verify(s_{i-1},{\mathcal{B}}_{i-1})=\mathrm{true},verify(s_i,{\mathcal{B}}_i)=\mathrm{true}.$$

Consider a case where the execution state produced by ${\mathit{TE}}_{i-1}$ violates the precondition required for step $s_i$, i.e.,

$$state\left({\mathit{TE}}_{i-1}\right)⊭precondition\left({\mathit{TE}}_i\right).$$

Such a situation can arise, for example, when a credential is valid at the time of verification but becomes invalid at the time of use, or when the actual usage exceeds the authorized scope. This provides a concrete instance of an execution sequence satisfying the baseline step-level conditions while violating the cross-step consistency condition.

By Definition 7, this implies:

$$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}.$$

Thus, there exists an execution sequence in which all individual steps satisfy step-level verification, yet cross-step consistency is violated.    □

Implications of Propositions 1 and 2. Together, Propositions 1 and 2 provide the basis for the interaction-level definition below, which combines per-step validity with cross-step consistency.

3.5. Interaction-Level Trust and Counterexamples

We define interaction-level trust as:

$$verify(I,\mathcal{C}):=\forall iverify\left({\mathit{TE}}_i\right)\wedge \forall i>1consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$$

(7)

This definition requires both step-level validity and cross-step consistency. We illustrate the necessity of execution-level constraint checking and cross-step consistency using two counterexamples.

3.5.1. Counterexample 1: Time-of-Check to Time-of-Use (TOCTOU) Violation

Let $s_1$ denote credential verification and $s_2$ a subsequent resource access. Suppose the credential is valid at $s_1$ but revoked before $s_2$ is executed. If $s_2$ relies on the stale state from $s_1$, both steps may satisfy baseline step-level verification. However, the precondition of $s_2$ requires a currently valid credential. This can be captured as:

$$state\left(T{E}_1\right)⊭precondition\left(T{E}_2\right),$$

and thus

$$consistent({\mathit{TE}}_1,{\mathit{TE}}_2)=\mathrm{false}.$$

This illustrates a violation arising from cross-step dependency rather than individual step validity.

3.5.2. Counterexample 2: Scope Violation

Let $s_3$ denote the issuance of a consent token with scope $R_1$, and $s_4$ a selective disclosure step. Both steps may satisfy step-level verification.

If the disclosed attribute set exceeds the authorized scope, i.e.,

$$attr\left(s_4\right)⊈\mathit{scope}\left(s_3\right),$$

the interaction violates the cross-step constraint.

This is captured as:

$$state\left({\mathit{TE}}_3\right)⊭precondition\left({\mathit{TE}}_4\right),$$

and thus

$$consistent({\mathit{TE}}_3,{\mathit{TE}}_4)=\mathrm{false}.$$

3.6. Theoretical Results

Theorem 1

(Separation of Step-Level and Interaction-Level Trust). Step-level verification does not characterize interaction-level trust. Formally, there exists an interaction $I=(s_1,\dots ,s_n)$ such that

$$\forall i,verify(s_i,{\mathcal{B}}_i)=\mathrm{true},$$

but

$$verify(I,\mathcal{C})=\mathrm{false}.$$

Proof. 

The result follows from the counterexamples presented earlier. In each case, all steps satisfy baseline step-level verification, while a violation of cross-step consistency occurs:

$$\exists i>1\mathrm{such}\mathrm{that}consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}.$$

By Equation (7), interaction-level trust requires both per-step TrustEvidence validity and cross-step consistency. Therefore,

$$verify(I,\mathcal{C})=\mathrm{false}.$$

Step-level verification alone is therefore insufficient to characterize interaction-level trust under the proposed model.    □

Significance of Theorem 1.

Theorem 1 provides a separation result within the proposed model: local step-level correctness does not necessarily compose into interaction-level trust. This result supports evaluating complete interactions using both per-step validity and cross-step consistency.

Remark 2

(Structural Properties of Equation (7): Modular Characterization and Failure-Diagnosis Locality). The following observations are direct consequences of Equation (7) and the pairwise-linked structure of TrustEvidence. They are not presented as independent theorems, but are included to clarify the operational interpretation of the formal model and its relationship to the scenario classification used in Section 5.

Part 1: Definition-Induced Modular Characterization. The following equivalence is a direct structural consequence of Equation (7):

$$\begin{array}{cc}\hfill verify(I,\mathcal{C})=\mathrm{true}⟺& \left(\forall i,verify\left({\mathit{TE}}_i\right)=\mathrm{true}\right)\hfill \\ & \wedge \left(\forall i>1,consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{true}\right).\hfill \end{array}$$

Under the proposed definition, interaction-level trust is, therefore, characterized in terms of per-step TrustEvidence validity and pairwise cross-step consistency. This statement should be understood as a modular characterization induced by the definition of interaction-level trust, rather than as an independent mathematical theorem. Its role is to make explicit how Equation (7) relates to the sequence-aware verification procedure used in the proposed ETA model.

Part 2: Locality of Failure Diagnosis. The pairwise-linked structure of TrustEvidence provides a basis for reasoning about the inspection scope needed to examine failures. Failures of $verify\left(E_i\right)$ or $constraint\_ok(E_i,{\mathcal{X}}_i)$ can be examined from a single TrustEvidence object ${\mathit{TE}}_i$, because these checks depend on the evidence and constraints associated with the current step. In contrast, failures of $link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$ or $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$ require the adjacent pair $\{{\mathit{TE}}_{i-1},{\mathit{TE}}_i\}$, because these checks depend on the linkage and state relationship between consecutive TrustEvidence objects.

Accordingly, a single ${\mathit{TE}}_i$ is the relevant inspection unit for evidence-validity or constraint-related failures, whereas the adjacent pair $\{{\mathit{TE}}_{i-1},{\mathit{TE}}_i\}$ is the relevant inspection unit for linkage or cross-step consistency failures. This observation does not introduce an additional verification condition, but clarifies how failures under the proposed definition can be localized for sequential inspection. It also explains why the verification procedure in Algorithm 3 follows the pairwise-linked structure of TrustEvidence objects.

Corollary 1

(Local Failure Witness for Scenario Classification). If $verify(I,\mathcal{C})=\mathrm{false}$, then there exists an index i such that $verify\left({\mathit{TE}}_i\right)=\mathrm{false}$, or there exists an index $i>1$ such that $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$.

Proof. 

By Equation (7), $verify(I,\mathcal{C})=\mathrm{true}$ is characterized as the conjunction of all step-level TrustEvidence validity conditions and all pairwise cross-step consistency conditions. Therefore, if $verify(I,\mathcal{C})=\mathrm{false}$, De Morgan’s law implies that at least one step-level condition or at least one pairwise consistency condition does not hold. This yields the stated result.    □

Role in Scenario Classification Corollary 1 is derived from Equation (7) through a logical transformation using De Morgan’s law. It differs from the modular characterization in Remark 2, Part 1 in that it produces an existence statement for a local failure witness, rather than restating the biconditional structure of the definition.

The corollary identifies two failure modes under the proposed model: a step-level failure, in which some ${\mathit{TE}}_i$ does not satisfy $verify\left({\mathit{TE}}_i\right)=\mathrm{true}$, and a cross-step failure, in which some adjacent pair does not satisfy $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{true}$.

These two failure modes provide a formal link to the adversarial scenario classification in Section 5, where Group A cases illustrate scenarios in which individual steps may pass step-level verification but the interaction fails under a cross-step ETA condition and Group B cases illustrate scenarios where the interaction fails at the step level. The locality observation in Remark 2, Part 2 further clarifies that such failures can be inspected at the level of the relevant step or adjacent pair, rather than treating the full interaction as a single indivisible diagnostic unit.

4. Executable Trust Architecture

4.1. Architectural Overview of Executable Trust

The ETA provides a system-level realization of the formal executable trust model defined in Section 3. The architecture is organized into five functional layers, as shown in Figure 1: Key Management, Privacy-Preserving Presentation, Verification and Revocation, Secure Protocol and Consent, and Logging and Auditability.

Figure 1. Executable Trust Architecture (ETA) aligned with the formal executable trust model. The architecture supports the generation and validation of TrustEvidence across execution steps, enabling the verification conditions in Equations (5)–(7) to be evaluated throughout the interaction lifecycle.

These layers collectively support the generation, validation, and linkage of TrustEvidence across an interaction sequence. Rather than treating trust as a collection of independent checks, ETA organizes these mechanisms so that step-level validity and cross-step consistency can be evaluated across the interaction lifecycle. The detailed mapping between each layer and the formal conditions of the model is described in Section 4.3.

4.2. Trust Execution Model and TrustEvidence

Formally, an interaction is represented as a sequence of execution steps (Equation (1)), and trust is evaluated based on the conditions defined in Equations (5) and (6). Rather than treating verification outputs as independent artifacts, ETA models them as structured TrustEvidence that captures both per-step validity and cross-step dependencies.

For each execution step $s_i$, a corresponding TrustEvidence object $T{E}_i$ is generated as defined in Equation (4). The evidence component $E_i$ encapsulates the observable and verifiable outputs of the system, including:

• Cryptographic Proof (${\mathit{Proof}}_{\mathrm{crypto}}$): digital signatures and selective disclosure proofs providing evidence of authenticity and integrity;
• Consent Receipt (${\mathit{Receipt}}_{\mathrm{consent}}$): cryptographically bound user consent associated with a specific transaction;
• Verification Result (${\mathit{Proof}}_{\mathrm{verify}}$): validation outcomes including schema compliance, issuer authenticity, and revocation status;
• Audit Log Entry (${\mathit{Log}}_{\mathrm{audit}}$): tamper-evident execution records maintained via hash chains.

These components do not exist as independent entities; rather, they are integrated within the structured evidence representation $E_i$ and evaluated through the step-level verification condition in Equation (5). This formulation enables each step to be evaluated not only in isolation but also in relation to its execution context.

4.2.1. Illustrative Representation of TrustEvidence

Listing 1 provides an implementation-oriented JSON-LD example of a step-level TrustEvidence object. The example illustrates one way to materialize the abstract structure $T{E}_i=(E_i,H\left(T{E}_{i-1}\right),C_i)$ as a concrete execution record for Step 2, where a holder presents a selectively disclosed credential to a verifier. It includes representative fields used to support auditability and cross-step verification, such as actor identifier, credential reference, creation timestamp, nonce, transaction identifier, audience, verifier identifier, consent scope, policy reference, revocation status, previous TrustEvidence hash, precondition, and record-level signature. The fragment is illustrative and is not intended to define a normative JSON-LD vocabulary, a new credential format, or a replacement for existing VC, DID, or audit-log data models.

In this representation, the evidence field corresponds to the evidence component $E_i$, the previousTrustEvidence.hash field represents the verifiable linkage $H\left({\mathit{TE}}_{i-1}\right)$, and the constraints field corresponds to the constraint set ${\mathcal{C}}_i=({\mathcal{B}}_i,{\mathcal{X}}_i)$. The created field serves as the timestamp of the TrustEvidence record. The verificationResult.revocationStatus object records how, where, and when the credential status was checked. The fields transactionId, audience, verifierId, and nonce provide implementation-level material for checking transaction binding, audience restriction, verifier binding, and replay resistance. The recordProof field signs the TrustEvidence record itself, whereas credential-level proofs are represented or referenced inside the evidence field.

Table 3 maps the representative fields of the illustrative TrustEvidence object to refined elements of the formal model. Since the formal model abstracts TrustEvidence as ${\mathit{TE}}_i=(E_i,H\left({\mathit{TE}}_{i-1}\right),{\mathcal{C}}_i)$, several implementation-level fields may materialize different aspects of the same abstract component. The table, therefore, refines $E_i$, ${\mathcal{C}}_i$, and ${\mathcal{X}}_i$ into credential references, disclosed claims, verification results, policy constraints, consent scope, audience binding, verifier binding, freshness, and transaction context.

Table 3. TrustEvidence Fields and Refined Formal Model Mapping.

TrustEvidence Field	Refined Formal Model Element	Req.
id, type	TrustEvidence object ${\mathit{TE}}_i$	M
interactionId	Interaction sequence I	M
step	Current interaction step $s_i$	M
actorId	Actor associated with step $s_i$	M
created	Timestamp of ${\mathit{TE}}_i$	M
evidence	Evidence component $E_i$	M
proofMechanism	Verification mechanism for $E_i$	M
credentialRef	Credential reference within $E_i$	O
disclosedClaims	Disclosed-claim component of $E_i$	O
sdHash	Selective-disclosure commitment in $E_i$	O
verificationResult	Baseline verification result ${\mathcal{B}}_i$	O
revocationStatus	Credential-status constraint in $X_i$	O
previousHash	Hash linkage $H\left({\mathit{TE}}_{i-1}\right)$	O
constraints	Constraint set $C_i=({\mathcal{B}}_i,{\mathcal{X}}_i)$	M
policyRef	Policy reference in ${\mathcal{C}}_i$	M
consentScope	Consent-scope constraint in ${\mathcal{X}}_i$	O
requiredScope	Required-scope constraint in ${\mathcal{X}}_i$	O
audience	Audience-binding constraint in ${\mathcal{X}}_i$	O
verifierId	Verifier-binding constraint in ${\mathcal{X}}_i$	O
freshness	Freshness constraint in ${\mathcal{X}}_i$	O
transactionId	Transaction context of ${\mathit{TE}}_i$	O
nonce	Freshness context of ${\mathit{TE}}_i$	O
executionState	Materialized $state\left({\mathit{TE}}_i\right)$	O
precondition	Materialized precondition of ${\mathit{TE}}_i$	O
recordProof	Record-level integrity proof for ${\mathit{TE}}_i$	M

M = mandatory; O = optional within the illustrative JSON-LD profile in Listing 1. Field names are representative and may appear inside nested JSON-LD objects. Optional fields may become necessary depending on the step type, trust mechanism, policy, or interaction context. This table provides an illustrative implementation-oriented profile based on Listing 1; it does not define a normative schema or a mandatory formal-model field set.

Table 4 organizes the TrustEvidence fields into seven verification groups, each corresponding to a distinct formal condition in the proposed model.

Table 4. Group Structure of TrustEvidence Field Verification.

Group	TrustEvidence Fields	Verification Basis
G1	id, type, interactionId, step	Object identity and interaction binding
G2	actorId, credentialRef, created	Actor and credential binding; clock freshness check using the creation timestamp in Algorithm 1 (line 10)
G3	evidence, proofMechanism, sdHash, verificationResult	Evidence validity: $\mathit{verify}\left(E_i\right)$, Definition 4
G4	revocationStatus, previousHash	Revocation constraint and chain linkage: $constraint\_ok(E_i,{\mathcal{X}}_i.\mathit{revocation})$ and $link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$, Definition 4
G5	constraints, policyRef, consentScope, requiredScope, audience, verifierId, freshness	Constraint enforcement: $constraint\_ok(E_i,{\mathcal{X}}_i)$, Definition 4, Algorithm 3 (Checks 2)
G6	transactionId, nonce, executionState	Cross-step consistency: $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$, Definition 7, Algorithm 3 (Checks 1, 4, 5)
G7	precondition, recordProof	Precondition evaluation and record-level integrity: $precondition\left({\mathit{TE}}_i\right)$, Definition 6; JWS verification over serialized ${\mathit{TE}}_i$

Fields within each group share the same verification basis and are evaluated together under the indicated formal condition. Group labels G1–G7 correspond to the groups defined in Table 3. Formal conditions refer to Equations (5)–(7).

Groups G1 and G2 address object-level integrity and binding. G1 checks that each TrustEvidence object is uniquely identified and correctly positioned within the interaction sequence, while G2 verifies the actor identity, credential reference, and creation timestamp associated with the evidence, corresponding to the creation timestamp used in Algorithm 1 (line 10).

Groups G3 and G4 cover step-level evidence validity. G3 evaluates the cryptographic correctness of the evidence component $E_i$ through signature verification, schema compliance, issuer authenticity, and selective-disclosure hash checks, collectively satisfying $verify\left(E_i\right)$ under Definition 4. G4 addresses revocation status and chain linkage: the revocationStatus field is checked against the StatusList2021 bitmap, with checkedAt verified against the applicable validity window to guard against TOCTOU violations (S3); the previousHash field is verified by SHA-256 recomputation of the canonicalized serialization of $T{E}_{i-1}$—using a deterministic canonicalization procedure such as JSON Canonicalization Scheme for JSON-based representation—supporting the evaluation of $link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$ under Definition 4.

Group G5 covers constraint enforcement, evaluating $constraint\_ok(E_i,{\mathcal{X}}_i)$ through policy applicability, consent, and required-scope containment (disclosedClaims ⊆ consentScope and requiredScope ⊆ consentScope), and freshness requirements specified in $X_i$. In the representative implementation, scope containment is operationalized by Algorithm 3 (Check 2), while the transaction and audience binding checks used for replay detection are treated as cross-step consistency checks in Group G6.

Group G6 addresses cross-step consistency, evaluating $consistent(T{E}_{i-1},T{E}_i)$ through predecessor status continuity, transaction identifier matching, audience matching, nonce freshness against the session-scoped registry $N_{\mathrm{consumed}}$, and deterministic execution state derivation via Algorithm 1. These checks support Definition 7 and are represented in Algorithm 3 (Checks 1, 4, and 5).

Group G7 covers precondition evaluation and record-level integrity. The precondition field is selected or instantiated as described in Algorithm 2, and evaluated against $state\left({\mathit{TE}}_{i-1}\right)$ via Algorithm 3. If the selected predicate or any representative consistency check fails, then $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$.

The recordProof field is verified as a JWS signature over the serialized ${\mathit{TE}}_i$ object using the key identified by verificationMethod (type: JsonWebSignature2020, proofPurpose: assertionMethod), with recordProof.created required to be no earlier than the top-level created field.

Together, the seven groups provide a structured mapping from implementation-level fields to the formal conditions $verify\left({\mathit{TE}}_i\right)$, $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$, and $verify(I,\mathcal{C})$ defined in Equations (5)–(7).

Other encodings, such as plain JSON, CBOR, JWT-based records, VC-compatible containers, database records, or protocol-specific audit logs, may also be used, provided that they preserve the three essential elements of TrustEvidence: verifiable evidence, constraint information, and linkage to the previous TrustEvidence object. This separation between the abstract model and its concrete serialization allows ETA to remain independent of a specific data format while still supporting practical implementation and auditability.

The execution state $state\left({\mathit{TE}}_i\right)$ is materialized through the aggregated evidence $E_i$ and system metadata, including credential status, authorization scope, temporal validity, and execution context.

Together, these components support the evaluation of both per-step validity (Equation (5)) and cross-step consistency (Equation (6)), enabling the end-to-end trust condition $verify(I,\mathcal{C})$ in Equation (7) to be assessed across the full interaction sequence.

Table 5 summarizes the structure of TrustEvidence and its relationship to system components and trust properties.

Table 5. TrustEvidence Components, Execution Roles, and Checked Conditions.

Component	Evidence Item/Source	Execution Role	Checked Condition
Cryptographic proof	${\mathit{Proof}}_{\mathrm{crypto}}$; Key Mgmt. and Presentation	Supports authenticity and integrity checks for each step	$verify\left(E_i\right)$
Consent receipt	${\mathit{Receipt}}_{\mathrm{consent}}$; Secure Protocol	Binds the authorized scope to the interaction context	$consistent(·)$
Verification result	${\mathit{Proof}}_{\mathrm{verify}}$; Verification Layer	Checks schema, status, freshness, and policy constraints	$constraint\_ok(E_i,{\mathcal{X}}_i)$
Audit log entry	${\mathit{Log}}_{\mathrm{audit}}$; Logging Layer	Records traceability and adjacent-step linkage	$link(·)$
Aggregated evidence	$E_i$; all ETA layers	Integrates step-level evidence into a verifiable object	Equation (5)

4.2.2. Component-Level Trust Assumptions

The trust base of ETA is defined by the threat model and assumptions in Section 3.3. The purpose of the component-level view in this section is not to introduce additional assumptions, but to clarify how those assumptions apply to the architectural components of ETA. Table 6 distinguishes trusted execution assumptions, semi-trusted infrastructure components, and potentially malicious participants, and indicates the scope under which the formal conditions in Equations (5)–(7) are interpreted.

Table 6. Component-Level Trust Assumptions in ETA.

Component	Trust Assumption	Role and Scope
Wallet	Semi-trusted	May attempt scope violation, nonce replay, or credential reuse; host compromise is out of scope.
Issuer	Semi-trusted	May use invalid keys or tampered content; such deviations may be reflected as signature or authenticity verification failures.
Verifier	Potentially malicious	May over-request attributes, replay evidence, or misuse disclosed data; partially mitigated through selective disclosure and consent binding. Post-disclosure misuse prevention is out of scope.
Revocation registry	Semi-trusted	May serve stale status; reflected as a constraint or consistency failure under freshness assumptions.
Logging service	Semi-trusted	Hash linking supports detection of modification or reordering within observed logs; deletion, suppression, and forks require external anchoring.
Execution environment	Trusted (assumed)	Cryptographic operations, key storage, and system clock assumed correct; hardware compromise and key extraction are out of scope.

Trusted: correct operation assumed; violations are out of scope. Semi-trusted: follows the protocol by default; selected deviations may be reflected as failures under Equations (5)–(7). Potentially malicious: may actively violate trust conditions; ETA provides partial mitigation only (Section 3.3).

4.3. Layered Execution of Trust Mechanisms

This section details how each ETA layer contributes to the formal conditions defined in Section 3. In particular, the layers are mapped to the generation of the evidence component $E_i$, the enforcement of constraints ${\mathcal{C}}_i$, the linkage term $H\left({\mathit{TE}}_{i-1}\right)$, and the evaluation of cross-step consistency. The following subsections describe the role of each layer in this mapping.

4.3.1. Key Management Layer

The Key Management Layer provides the cryptographic foundation for the generation of valid evidence $E_i$ within the TrustEvidence structure defined in Equation (4). It provides mechanisms for securely executing the cryptographic operations required for evidence generation and verification.

This layer supports the evaluation of $verify\left(E_i\right)$ in Equation (5) by supporting the correctness and integrity of digital signatures and cryptographic proofs. Secure key generation, storage, and usage mechanisms—such as hardware-backed keystores and secure enclaves—are intended to protect private keys and reduce the risk of unauthorized access.

From the perspective of the formal model, this layer provides the cryptographic basis for assessing the authenticity and integrity of the evidence component $E_i$, forming the basis for step-level verification. Without these supporting assumptions and mechanisms, the condition $verify\left({\mathit{TE}}_i\right)$ in Equation (5) cannot be reliably evaluated or satisfied.

4.3.2. Privacy-Preserving Presentation Layer

The Privacy-Preserving Presentation Layer is responsible for generating verifiable credential presentations while enforcing privacy constraints within the TrustEvidence structure defined in Equation (4). Specifically, this layer contributes to the construction of the evidence component $E_i$ and supports the satisfaction of both the validity and constraint conditions in Equation (5).

To achieve this, the layer employs privacy-preserving cryptographic techniques. In the prototype evaluated in Section 5, selective disclosure is realized using Selective Disclosure JWTs (SD-JWT) [17] and Fiat-Shamir-based Zero-Knowledge Proofs (ZKPs) with SHA-256 commitments [18]. BBS+ signatures [19], which offer unlinkable multi-attribute proofs without requiring per-disclosure interaction with the issuer, are not instantiated in the current prototype and are identified as a direction for future extension.

From the perspective of the formal model, these techniques serve two key roles. First, they provide cryptographic evidence that can be checked against the condition $verify\left(E_i\right)$ by producing cryptographically verifiable proofs bound to the issuer and the original credential. Second, they support the enforcement and checking of privacy-related constraints embedded in ${\mathcal{C}}_i$, such as data minimization and disclosure policies, thereby contributing to the condition $constraint\_ok(E_i,{\mathcal{X}}_i)$.

Importantly, privacy preservation is not treated as an independent objective but as an integral component of trust validation. In particular, selective disclosure helps limit disclosure to policy-authorized attributes when combined with consent and constraint checks, reducing the risk of over-disclosure while preserving verifiability.

This layer thus supports the satisfaction of the step-level verification condition in Equation (5) under strict data minimization requirements.

4.3.3. Verification and Revocation Layer

The Verification and Revocation Layer supports constraint validation by implementing the condition $constraint\_ok(E_i,{\mathcal{X}}_i)$ in Equation (5). It checks whether the evidence generated at each execution step satisfies all required validity conditions.

This includes verification of digital signatures, schema compliance, issuer authenticity, credential expiration, and revocation status using mechanisms such as Status List 2021 [20] and decentralized registries. These checks provide evidence for whether presented credentials satisfy validity, compliance, and revocation constraints.

Within the formal model, this layer is responsible for enforcing the constraint component ${\mathcal{C}}_i$ associated with each TrustEvidence instance.

This layer thereby supports checking $constraint\_ok(E_i,{\mathcal{X}}_i)$, which is required by $verify\left({\mathit{TE}}_i\right)$ in Equation (5).

4.3.4. Secure Protocol and Consent Layer

The Secure Protocol and Consent Layer checks whether execution steps satisfy the preconditions required for subsequent steps, thereby supporting the cross-step consistency condition defined in Equation (6).

This layer governs secure communication using protocols such as DIDComm v2 [21] and enforces authorization constraints by binding user consent to specific transactions through cryptographically protected tokens. In the prototype evaluated in Section 5, network-level communication is not instantiated. The evaluation of this layer therefore focuses on the authorization enforcement logic rather than the transport protocol: specifically, nonce-bound consent token generation and verification, authorization scope containment checks, and the detection of replayed or scope-violating consent tokens. These mechanisms are designed to operationalize the formal condition consistent(${\mathit{TE}}_{i-1}$, ${\mathit{TE}}_i$) in Equation (6), as they check whether the execution state produced at step $s_{i-1}$ satisfies the preconditions required for step $s_i$. Scenario S5 evaluates this layer by examining whether credential replay (detected via transactionId and audience mismatch in Check 4 of Algorithm 3), consent-token reuse (detected via nonce freshness in Check 5), and consent scope violations are reflected as cross-step consistency failures, independently of the underlying communication channel.

4.3.5. Logging and Auditability Layer

The Logging and Auditability Layer maintains the linkage between TrustEvidence objects by implementing the hash reference $H\left({\mathit{TE}}_{i-1}\right)$ in Equation (4) and supporting the evaluation of $link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$ in Equation (5). Each execution step is recorded as a hash-linked entry, forming a tamper-evident sequence of evidence under the assumption that the relevant log sequence remains available for verification. This structure supports the detection of modifications and reordering within an observed log sequence and provides evidence for checking whether execution records remain consistently linked across steps.

As discussed in Section 3.3, the hash-linked structure does not by itself guarantee log immutability against deletion, suppression, replacement, or forked log histories. Such stronger properties require additional assumptions or mechanisms beyond the Logging and Auditability Layer.

From the perspective of the formal model, this layer supports the representation of cross-step linkage and helps reconstruct the execution trace when the corresponding log records are available. It thereby provides a basis for auditing both step-level verification and cross-step consistency under the stated logging assumptions.

Privacy Considerations for TrustEvidence and Audit Logs

The TrustEvidence chain and audit logs can introduce privacy risks if they store persistent identifiers, raw credential attributes, consent contents, or detailed interaction metadata. ETA, therefore, distinguishes between traceability within a single interaction and unlinkability across different interactions. In the intended design, TrustEvidence stores only the minimum information required for verification, such as verification results, policy identifiers, consent bindings, timestamps or validity windows, nonces, proof references, and hash references to previous TrustEvidence objects. Raw credential attributes and complete credential presentations should not be stored in audit logs.

Audit logs should store hash-linked records, verification outcomes, and encrypted or commitment-based references rather than plaintext personal data. Access to logs should be restricted to authorized parties under a defined governance policy, and logs should be protected through access control and encryption at rest where sensitive metadata is included. Retention should be limited to the minimum period required for dispute resolution, compliance, or application-specific audit requirements.

Under this design, auditability is limited to the scope of a specific interaction, while cross-interaction linkability is reduced through pairwise identifiers, per-session nonces, selective disclosure, and data minimization. Thus, ETA aims to support accountable verification without requiring global traceability of the holder across unrelated interactions.

4.3.6. Cross-Layer Execution Perspective

Failures in any layer may propagate across the execution sequence, affecting both step-level verification (Equation (5)) and cross-step consistency (Equation (6)). This property helps the system reflect violations that may not be observable within isolated components.

Because each layer contributes to a distinct component of $verify\left({\mathit{TE}}_i\right)$ in Equation (5), a failure at any layer can affect the interaction through a sequence of formal conditions: a violation of $verify\left(E_i\right)$, $link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$, or $constraint\_ok(E_i,{\mathcal{X}}_i)$ causes $verify\left({\mathit{TE}}_i\right)=\mathrm{false}$ by Definition 4, which in turn triggers $state\left({\mathit{TE}}_i\right).\mathit{status}=\mathit{failed}$ in Algorithm 1. For non-final steps, this failed status may cause $consistent({\mathit{TE}}_i,{\mathit{TE}}_{i+1})=\mathrm{false}$ via Check 1 of Algorithm 3 when the next step depends on it. In all cases, the failed required condition contributes to $verify(I,\mathcal{C})=\mathrm{false}$ by Equation (7).

4.4. Mapping ETA Layers to Scenario-Based Validation

To validate the Trust Execution Model defined in Section 4.2, it is necessary to establish a clear correspondence between the formal conditions and the validation scenarios. In ETA, each layer contributes to specific components of the formal model, and the validation scenarios are designed to examine whether these conditions hold in selected scenarios. Table 7 summarizes the mapping between ETA layers, formal conditions, and validation scenarios.

Table 7. Mapping of ETA Layers, Formal Conditions, and Validation Scenarios.

Layer/Case	Formal Condition	Scenarios	Validation Purpose
Key Management	$verify\left(E_i\right)$	S2, S4	Cryptographic correctness and key lifecycle validation
Privacy-Preserving Presentation	$verify\left(E_i\right)$, $constraint\_ok(E_i,{\mathcal{X}}_i)$	S1	Selective disclosure and privacy constraint checking
Verification & Revocation	$constraint\_ok(E_i,{\mathcal{X}}_i)$	S3, S7	Revocation enforcement and status freshness checking
Secure Protocol & Consent	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$	S5	Cross-step consistency and consent enforcement
Logging & Auditability	$link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$	S6	Tamper-evident trace linkage
Cross-layer evaluation	$verify\left({\mathit{TE}}_i\right)$, $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$	S8	Multi-issuer and multi-format credential interoperability
Integrated execution	$verify(I,\mathcal{C})$	S9	End-to-end trust evaluation

The first five rows are ETA functional layers. S8 and S9 are evaluation cases rather than additional architectural layers.

As shown in Table 7, each scenario is associated with one or more formal conditions defined in Equations (5)–(7). Some layers are exercised by multiple scenarios, and S8 spans multiple layers to examine multi-issuer and multi-format credential interoperability at the credential level. In particular, S5 and S9 address cross-step consistency (Equation (6)) and end-to-end trust (Equation (7)), which cannot be captured by step-level verification alone.

4.5. End-to-End Trust Execution Flow

Figure 2 illustrates how ETA realizes the layered architecture as a concrete interaction flow linking credential issuance, wallet storage, selective disclosure, consent-bound communication, verification, and audit logging. Each interaction step corresponds to the generation or validation of a TrustEvidence instance ${\mathit{TE}}_i$, forming a chain of dependent execution states.

Figure 2. Sequence diagram of the end-to-end trust execution flow. Each interaction step produces a TrustEvidence instance ${\mathit{TE}}_i$, which is validated and linked across the sequence to support the evaluation of step-level correctness and cross-step consistency.

In Figure 2, the horizontal arrows represent the flow of messages and cryptographic artifacts (such as VCs and TrustEvidence objects) between the entities, while the vertical sequence of these arrows illustrates the progression of execution stages. Each arrow initiates a process that generates a new TrusteEvidence instance(${\mathit{TE}}_i$), which is hash-linked to its predecessor to form a verifiable exection trace.

A typical interaction flow in ETA consists of the following six stages:

• Credential Issuance (Key Management Layer): An issuer generates and signs a credential using cryptographic keys, producing the initial evidence component $E_i$ associated with the issuance step.
• Secure Storage (Digital Wallet): The credential is stored in the holder’s digital wallet, where secure key management mechanisms support the protection of stored evidence in terms of integrity and confidentiality.
• Selective Disclosure (Privacy-Preserving Presentation Layer): The holder selectively discloses required attributes, generating verifiable proofs that contribute to the construction of $E_i$ while enforcing privacy constraints in ${\mathcal{C}}_i$.
• Consent-Bound Communication (Secure Protocol Layer): The credential and associated proofs are transmitted through secure protocols, with explicit user consent cryptographically bound to the interaction, providing evidence for checking whether preconditions for subsequent steps are satisfied.
• Verification and Validation (Verification Layer): The verifier evaluates the validity of the presented evidence by checking signatures, schema compliance, and revocation status, enforcing $constraint\_ok(E_i,{\mathcal{X}}_i)$ as defined in Equation (5).
• Audit Logging (Logging Layer): The interaction is recorded in tamper-evident logs, establishing the hash-linked structure $H\left({\mathit{TE}}_{i-1}\right)$ and enabling traceability across execution steps.

As the interaction proceeds, each stage contributes to the construction or validation of a TrustEvidence instance. The resulting sequence provides the execution trace used to evaluate the formal conditions described in Section 3 and mapped to layers in Section 4.3. This flow provides the architectural basis for the validation scenarios in Section 5.

5. Evaluation and Validation

The objective of this section is to evaluate the formal trust model introduced in Section 3.1 and realized through the ETA presented in Section 4. The evaluation is designed as a scenario-based logical validation rather than a comprehensive empirical system evaluation. Each scenario is constructed to examine whether the implemented mechanisms behave consistently with the formal trust conditions defined in Equations (5)–(7) under selected normal and adversarial execution cases.

5.1. Evaluation Framework

The validation is organized around four evaluation targets derived from the formal model:

• Step-level correctness: validation of $verify\left({\mathit{TE}}_i\right)$
• Constraint enforcement: validation of $constraint\_ok(E_i,{\mathcal{X}}_i)$
• Cross-step consistency: validation of $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$
• End-to-end trust: validation of $verify(I,\mathcal{C})$

Remark 2 and Corollary 1 provide the formal basis for relating the evaluated scenarios to the conditions in Equations (5)–(7). Accordingly, each adversarial case is described in terms of the condition in which the violation is reflected, such as TrustEvidence validity, constraint satisfaction, linkage integrity, cross-step consistency, or the end-to-end interaction condition.

A scenario is considered to provide positive evidence when the implemented mechanism accepts valid execution traces and reflects injected violations as failures in a manner consistent with the corresponding formal condition.

5.1.1. Implementation Environment

The formal trust conditions were operationalized in a prototype implementation to assess the feasibility of the proposed approach. Table 8 summarizes the implementation environment. All operations were executed locally with no network I/O, and timing measurements reflect the computational overhead of the cryptographic and verification operations only.

Table 8. Prototype Implementation Environment.

Item	Specification
Hardware	Apple Silicon M1 (ARM64), 8 GB RAM
OS/Runtime	macOS, Python 3.12.3
Libraries	cryptography 46.0.5; sd-jwt 0.10.4 (RFC 9901); bitarray 2.9; pytest 7.0+
Algorithms	ECDSA P-256, SHA-256, AES-128-GCM, and Fiat–Shamir ZKP with SHA-256 commitment
Credential formats	W3C VCDM v1.1, SD-JWT, JSON-LD
Network assumption	Local execution only; no network I/O †
Trials	68 cases across 9 scenarios; 30 runs/scenario ($n=29$ after warm-up) ‡

^† Secure communication protocols are not instantiated in the prototype. ^‡ The first run is excluded as warm-up.

The prototype uses concrete cryptographic operations for signature generation, verification, and revocation checking, rather than mock or flag-based substitutions. Baseline comparisons with alternative implementations are outside the scope of this feasibility assessment and are left for future work.

5.1.2. Scope of Adversarial Conditions

The scenarios are based on the component-level trust assumptions described in Section 4.2 and are used to illustrate how selected violations may be represented as failures of the formal trust conditions. They are representative validation cases, not an exhaustive attack taxonomy or a basis for estimating general detection rates. The specific threat scenarios, their underlying assumptions, and the expected ETA responses are detailed in Table 9.

Table 9. Threat Scenarios, Assumptions, and ETA Response in Evaluated Scenarios.

Threat Scenario	Assumption	ETA Response	Formal Condition
Credential/proof forgery	Keys and crypto primitives are protected	Not accepted under cryptographic assumptions	$verify\left(E_i\right)$
Credential replay (cross-transaction/cross-verifier)	Credential presentation may be reused across different transactions or verifiers	Reflected as failure in selected cases (S5; Check 4)	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$
Consent-token reuse	Nonce-bound consent token may be resubmitted within a session	Reflected as failure in selected cases (S5; Check 5)	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$
Revocation change	Status may change between steps	Reflected as a constraint failure under freshness assumptions	$constraint\_ok(E_i,{\mathcal{X}}_i)$
Stale cached data	Outdated status or policy may be used	Reflected as a constraint-checking failure	$constraint\_ok(E_i,{\mathcal{X}}_i)$
Scope/consent violation	Use may exceed authorized scope	Reflected as failure in selected cases	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$
Log modification/reordering (incl. untrusted logger modification)	Log sequence is available for checking; logger may attempt modification or reordering within the observed sequence	Reflected as linkage failure within observed logs (S6)	$link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$
Malicious verifier (disclosure-time)	Verifier may over-request attributes or replay evidence at disclosure time	Partially mitigated via selective disclosure and scope checks (S1, S5)	$constraint\_ok(E_i,{\mathcal{X}}_i)$, $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$
Scenarios outside ETA formal verification scope
Log deletion/suppression/fork	Logging service may be compromised	Requires additional mechanisms	Beyond the $link(·)$ condition
Malicious verifier (post-disclosure)	Verifier may misuse data after successful presentation	Out of scope; requires data governance or legal framework	Beyond ETA formal conditions
Host compromise/key extraction	Execution environment is compromised	Out of scope	Trust-base assumption violated

Formal conditions refer to Equations (5)–(7). Credential replay (cross-transaction/cross-verifier) is detected via transactionId and audience mismatch (Algorithm 3, Check 4), independently of consent-token reuse detection via nonce freshness (Check 5). Scenarios in the lower section fall outside the formal verification scope of ETA and are listed to clarify the boundary of the proposed approach. See Table 6 for component-level trust assumptions

Scenario-to-Model Mapping

The validation scenarios follow the architecture-level mapping summarized in Table 7. S1 and S2 examine evidence validity, S3 and S7 examine constraint enforcement, S5 examines cross-step consistency, S6 examines linkage integrity, S8 examines credential-level interoperability across heterogeneous issuers and formats, and S9 examines the end-to-end trust condition. This mapping allows each scenario to be interpreted as either satisfying or violating one of the formal conditions defined in Equations (5)–(7).

5.1.3. Comparison with Conventional Step-Level Verification

The adversarial cases in this evaluation are used to compare conventional step-level verification with ETA’s sequence-aware verification conditions. In each adversarial case, the individual execution steps are constructed to satisfy their baseline conditions $B_i$; that is, a conventional DID/VC verification pipeline operating step-by-step would accept every individual step. ETA reflects the same interaction as a failure by evaluating the formal conditions $verify\left({\mathit{TE}}_i\right)$, $constraint\_ok(E_i,X_i)$, $link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$, or $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$ across the full execution sequence.

Table 10 makes this comparison explicit for the representative adversarial cases evaluated in Section 5.2, Section 5.3, Section 5.4 and Section 5.5. The table distinguishes two groups: cross-step violations (Group A), where the interaction passes step-level verification but fails an ETA condition, and step-level violations (Group B), where both approaches reject the interaction. Group A cases illustrate the separation discussed in Theorem 1 and the counterexamples in Section 3.5. Among the 38 adversarial cases in this evaluation, 30 belong to Group A and 8 belong to Group B. Group A cases arise across multiple scenarios: scope and disclosure violations (S1, S5, S8), revocation failures (S3), hash-linkage failures (S2, S6), cache and freshness failures (S7), and multi-phase interaction failures (S9).

Table 10. Representative Adversarial Case Types for Baseline Comparison.

S	Violation	Step-Level	ETA Failure Condition	ETA
Group A—step-level verification passes, but ETA rejects through sequence-aware trust conditions
S1	Attribute over-disclosure	Pass a	$constraint\_ok(E_i,{\mathcal{X}}_i)=\mathrm{false}$	Reject
S2	Valid signature with tampered hash linkage	Pass h	$link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$	Reject
S3	Revoked credential (TOCTOU)	Pass b	$constraint\_ok(E_i,{\mathcal{X}}_i)=\mathrm{false}$	Reject
S5	Credential replay (cross-transaction)	Pass g	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$; Check 4 (transactionId mismatch)	Reject
S5	Credential replay (cross-verifier)	Pass g	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$; Check 4 (audience mismatch)	Reject
S5	Consent token reuse	Pass c	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$; Check 5 (nonce reuse)	Reject
S5	Expired consent scope	Pass c	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$	Reject
S6	Log entry tampering	Pass d	$link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$	Reject
S6	Log entry reordering	Pass d	$link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$	Reject
S7	Stale cache poisoning	Pass e	$constraint\_ok(E_i,{\mathcal{X}}_i)=\mathrm{false}$	Reject
S8	Cross-issuer scope mismatch	Pass a	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$	Reject
S9	Multi-phase fault (B1–B8)	Pass f	$verify(I,\mathcal{C})=\mathrm{false}$	Reject
Group B—both approaches reject at step level
S2	Forged ECDSA signature	Reject	$verify\left(E_i\right)=\mathrm{false}$	Reject
S4	Invalid/stale trust anchor	Reject	$verify\left({\mathit{TE}}_i\right)=\mathrm{false}$	Reject

^a Credential signature is valid; scope violation is detected across steps. ^b Credential is valid at $s_1$ but revoked before $s_2$. ^c Consent token signature is valid; nonce reuse is detected via Check 5; scope expiry requires temporal and scope containment comparison with the previous step. ^d Individual ${\mathit{TE}}_i$ objects are internally consistent; chain integrity requires adjacent-pair inspection. ^e Cached status appears valid locally; the freshness constraint fails temporally. ^f Local phase checks pass; the interaction-level condition fails. ^g Credential signature is valid and nonce is fresh; replay is detected via transactionId or audience mismatch (Algorithm 3, Check 4), independently of Check 5. ^h Credential signature is valid; the hash linkage field is tampered after signing. Step-level verification accepts the signature; ETA rejects via $link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$. The rows summarize representative adversarial case types rather than listing all 38 adversarial test instances. The full scenario-level test composition is summarized in Table 11.

Table 10. Representative Adversarial Case Types for Baseline Comparison.

S	Violation	Step-Level	ETA Failure Condition	ETA
Group A—step-level verification passes, but ETA rejects through sequence-aware trust conditions
S1	Attribute over-disclosure	Pass a	$constraint\_ok(E_i,{\mathcal{X}}_i)=\mathrm{false}$	Reject
S2	Valid signature with tampered hash linkage	Pass h	$link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$	Reject
S3	Revoked credential (TOCTOU)	Pass b	$constraint\_ok(E_i,{\mathcal{X}}_i)=\mathrm{false}$	Reject
S5	Credential replay (cross-transaction)	Pass g	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$; Check 4 (transactionId mismatch)	Reject
S5	Credential replay (cross-verifier)	Pass g	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$; Check 4 (audience mismatch)	Reject
S5	Consent token reuse	Pass c	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$; Check 5 (nonce reuse)	Reject
S5	Expired consent scope	Pass c	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$	Reject
S6	Log entry tampering	Pass d	$link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$	Reject
S6	Log entry reordering	Pass d	$link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$	Reject
S7	Stale cache poisoning	Pass e	$constraint\_ok(E_i,{\mathcal{X}}_i)=\mathrm{false}$	Reject
S8	Cross-issuer scope mismatch	Pass a	$consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$	Reject
S9	Multi-phase fault (B1–B8)	Pass f	$verify(I,\mathcal{C})=\mathrm{false}$	Reject
Group B—both approaches reject at step level
S2	Forged ECDSA signature	Reject	$verify\left(E_i\right)=\mathrm{false}$	Reject
S4	Invalid/stale trust anchor	Reject	$verify\left({\mathit{TE}}_i\right)=\mathrm{false}$	Reject

^a Credential signature is valid; scope violation is detected across steps. ^b Credential is valid at $s_1$ but revoked before $s_2$. ^c Consent token signature is valid; nonce reuse is detected via Check 5; scope expiry requires temporal and scope containment comparison with the previous step. ^d Individual ${\mathit{TE}}_i$ objects are internally consistent; chain integrity requires adjacent-pair inspection. ^e Cached status appears valid locally; the freshness constraint fails temporally. ^f Local phase checks pass; the interaction-level condition fails. ^g Credential signature is valid and nonce is fresh; replay is detected via transactionId or audience mismatch (Algorithm 3, Check 4), independently of Check 5. ^h Credential signature is valid; the hash linkage field is tampered after signing. Step-level verification accepts the signature; ETA rejects via $link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$. The rows summarize representative adversarial case types rather than listing all 38 adversarial test instances. The full scenario-level test composition is summarized in Table 11.

Table 11. Per-Scenario Validation Scope and Test Composition.

S	Formal Check	Validation Target	Tests
S1	$verify\left(E_i\right)$, constraints	Selective disclosure	9 (3/6)
S2	$verify\left(E_i\right)$	Cryptographic proof	6 (1/5)
S3	$constraint\_ok(·)$	Revocation †	6 (3/3)
S4	$verify\left({\mathit{TE}}_i\right)$	Key lifecycle	7 (5/2)
S5	$consistent(·)$	Consent enforcement	9 (3/6)
S6	$link(·)$	Log integrity	7 (4/3)
S7	$constraint\_ok(·)$	Cache consistency ‡	7 (5/2)
S8	$verify(·)$, consistency	Multi-issuer and multi-format credential interoperability	7 (4/3)
S9	$verify(I,\mathcal{C})$	End-to-end trust	9 (1/8)
Total			68 (30/38)

Tests = total cases (normal/adversarial). ^† S3 includes a 1,000-credential StatusList2021 bitmap. ^‡ S7 includes full-verification baseline. S2 includes four Group B cases (forged or invalid signatures rejected at step level) and one Group A case (valid signature with tampered hash linkage, rejected by ETA via the linkage condition).

Table 11. Per-Scenario Validation Scope and Test Composition.

S	Formal Check	Validation Target	Tests
S1	$verify\left(E_i\right)$, constraints	Selective disclosure	9 (3/6)
S2	$verify\left(E_i\right)$	Cryptographic proof	6 (1/5)
S3	$constraint\_ok(·)$	Revocation †	6 (3/3)
S4	$verify\left({\mathit{TE}}_i\right)$	Key lifecycle	7 (5/2)
S5	$consistent(·)$	Consent enforcement	9 (3/6)
S6	$link(·)$	Log integrity	7 (4/3)
S7	$constraint\_ok(·)$	Cache consistency ‡	7 (5/2)
S8	$verify(·)$, consistency	Multi-issuer and multi-format credential interoperability	7 (4/3)
S9	$verify(I,\mathcal{C})$	End-to-end trust	9 (1/8)
Total			68 (30/38)

Tests = total cases (normal/adversarial). ^† S3 includes a 1,000-credential StatusList2021 bitmap. ^‡ S7 includes full-verification baseline. S2 includes four Group B cases (forged or invalid signatures rejected at step level) and one Group A case (valid signature with tampered hash linkage, rejected by ETA via the linkage condition).

A performance-level comparison—such as the latency overhead of constructing and verifying a TrustEvidence chain relative to a plain DID/VC pipeline—is left for future work, as the present evaluation is designed as a scenario-based logical validation of the formal model rather than a system benchmarking study.

5.2. Validation of Step-Level Correctness

This section evaluates whether each execution step produces valid and verifiable evidence according to $verify\left({\mathit{TE}}_i\right)$.

Normal cases. Scenarios S1–S4 illustrate that the implemented mechanisms behave consistently with $verify\left({\mathit{TE}}_i\right)$ under the evaluated conditions. Selective disclosure (S1) supports proof validation while checking the associated constraints. Cryptographic verification (S2) supports the assessment of authenticity and integrity. Revocation handling (S3) evaluates whether invalid credentials are rejected; since $verify\left({\mathit{TE}}_i\right)$ subsumes $constraint\_ok(E_i,{\mathcal{X}}_i)$ by Definition 4, S3 appears in both Section 5.2 and Section 5.3. Key lifecycle management (S4) provides evidence that key rotation and trust anchor validation behave consistently with the expected behavior under the evaluated conditions.

Adversarial cases. Four cases (S2-A1–A4) involve forged or invalid credentials in which the signature, proof, schema, or issuer authenticity check fails at the step level, resulting in $verify\left(E_i\right)=\mathrm{false}$ (Group B). One case (S2-A5) involves a valid signature with a tampered hash linkage field: step-level verification passes, while ETA reflects a failure via $link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}$ (Group A).

Formal interpretation:

$$\begin{array}{cc}\hfill verify\left(E_i\right)=\mathrm{false}& \Rightarrow verify\left({\mathit{TE}}_i\right)=\mathrm{false}(\mathrm{S}2-\mathrm{A}1–\mathrm{A}4)\hfill \\ \hfill link({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}& \Rightarrow verify\left({\mathit{TE}}_i\right)=\mathrm{false}(\mathrm{S}2-\mathrm{A}5)\hfill \end{array}$$

In both cases, $verify\left({\mathit{TE}}_i\right)=\mathrm{false}$ under the evaluated scenarios.

5.3. Validation of Constraint Enforcement

This section examines whether constraint conditions are enforced consistently through $constraint\_ok(E_i,{\mathcal{X}}_i)$.

Normal cases. S1 checks whether attribute disclosure remains within the authorized scope under the evaluated conditions.

Adversarial cases. S3 (revoked credentials) and S7 (stale cached data) violate constraint conditions.

Formal interpretation:

$$constraint\_ok(E_i,{\mathcal{X}}_i)=\mathrm{false}\Rightarrow verify\left({\mathit{TE}}_i\right)=\mathrm{false}$$

This indicates that the implemented constraint checks reflected the injected policy-violating cases as failures of the corresponding formal conditions in the evaluated scenarios.

5.4. Validation of Cross-Step Consistency

This section examines whether execution steps remain consistent across the interaction using $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$.

Normal cases. Valid execution sequences maintain consistent transitions between steps.

Adversarial cases. S5 introduces four adversarial cases corresponding to failures of cross-step consistency: credential replay across different transaction contexts (detected via transactionId mismatch, Check 4), credential replay directed at a different verifier (detected via audience mismatch, Check 4), consent-token reuse within a session (detected via nonce freshness check, Check 5), and expired consent scope (detected via scope containment and temporal checks). Check 4 and Check 5 operate independently: Check 4 detects replay via transaction binding and audience fields without consulting the nonce registry, while Check 5 detects reuse via nonce freshness.

Formal interpretation:

$$\exists i\mathrm{such}\mathrm{that}consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)=\mathrm{false}\Rightarrow verify(I,\mathcal{C})=\mathrm{false}$$

In the evaluated scenarios, cross-step violations are reflected as interaction-level failure under the formal condition in Equation (7).

5.5. Validation of End-to-End Trust

This section examines whether trust holds across the entire interaction sequence using $verify(I,\mathcal{C})$.

Normal cases. S8 evaluates cross-domain interoperability in the sense of multi-issuer and multi-format credential interactions, not network-level domain separation. Specifically, S8 examines whether TrustEvidence validity and cross-step consistency conditions are maintained when credentials are issued by three distinct issuers using different credential formats (W3C VC JSON-LD, JWT, and SD-JWT). This scenario does not involve networked communication across administrative domains; rather, it assesses whether the formal conditions $verify\left({\mathit{TE}}_i\right)$ and $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$ hold when credential evidence originates from heterogeneous sources with differing schemas and proof mechanisms.

Adversarial cases. S9 introduces eight adversarial fault conditions (B1–B8), each injected at a specific execution phase. The evaluated S9 cases illustrate how injected faults can be reflected as failures of $verify(I,\mathcal{C})$ under the corresponding formal conditions. As illustrated in Figure 3, these fault condition (B1–B8) are mapped to specific executaion phases, showing exactly where the trust is broken.

Figure 3. End-to-end trust validation in ETA. Each execution step generates a TrustEvidence instance ${\mathit{TE}}_i=(E_i,H\left({\mathit{TE}}_{i-1}\right),{\mathcal{C}}_i)$, validated through $verify\left({\mathit{TE}}_i\right)$ and consistency checks. The final trust decision is determined by $verify(I,\mathcal{C})$.

Formal interpretation:

$$verify(I,\mathcal{C})=\underset{i}{\bigwedge }verify\left({\mathit{TE}}_i\right)\wedge \underset{i>1}{\bigwedge }consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$$

When a required step-level or pairwise consistency condition fails, the interaction-level condition in Equation (7) evaluates to false.

5.6. Feasibility Assessment

To assess the feasibility of the prototype, we measure the computational cost of each scenario under the implementation environment described in Section 5.1.1. These measurements are limited to a single-machine setting without network I/O and are not intended as a general performance characterization or a baseline comparison against alternative implementations.

Table 11 summarizes the per-scenario validation scope and test composition. Table 12 separates the timing statistics so that the validation logic and performance observations remain readable without forcing a wide table.

Table 12. Per-Scenario Timing Summary (30 Trials, Warm-up Excluded).

S	Latency (ms)	95% CI	CV	Note
S1	$2.27\pm 0.06$	$\pm 0.02$	0.026	Selective disclosure checks
S2	$1.00\pm 0.16$	$\pm 0.06$	0.160	Signature verification variance; includes one linkage-failure case (S2-A5)
S3	$150.88\pm 4.33$	$\pm 1.65$	0.029	Includes StatusList2021 bitmap; step-level checks are <1 ms
S4	$2.14\pm 0.10$	$\pm 0.04$	0.049	Trust-anchor validation
S5	$2.73\pm 0.12$	$\pm 0.05$	0.045	Transaction binding and consent/nonce checks
S6	$18.55\pm 0.25$	$\pm 0.10$	0.014	Hash-linked log verification
S7	$164.71\pm 5.71$	$\pm 2.17$	0.035	Full-verification baseline; cache-hit checks are <1 ms
S8	$1.58\pm 0.08$	$\pm 0.03$	0.053	Multi-issuer validation
S9	$30.77\pm 0.53$	$\pm 0.20$	0.017	End-to-end chain evaluation

$n=29$ stable trials are reported (30 total; first excluded as warm-up). CI uses $t_{0.025,28}\times \mathrm{SD}/\sqrt{29}$ with $t=2.048$. No network I/O; single machine (Table 8).

Table 12 reports the timing statistics collected across 30 trials per scenario (first trial excluded as warm-up). Seven of nine scenarios exhibit a coefficient of variation (CV) below 0.06, indicating stable and reproducible measurement conditions. S2 shows a slightly higher CV of 0.160, reflecting timing variability across heterogeneous ECDSA P-256 operations: the six test cases include both signature generation and verification paths, as well as early-rejection paths for tampered inputs, producing a wider spread of per-case execution times. S3 and S7 report higher absolute latencies (150.88 ms and 164.71 ms, respectively) due to large-scale workloads included in those scenarios: S3 evaluates a 1000-credential StatusList2021 bitmap and S7 measures a full-verification baseline.

Within the evaluated adversarial cases and repeated runs, the injected violations were reflected as failures of the corresponding formal conditions. Among the valid execution cases, no false positives were observed. This observation is limited to the evaluated cases and should not be interpreted as a general false-positive-rate claim.

The present feasibility assessment focuses on computational overhead under a single-machine environment. Byte-level overheads of TrustEvidence objects, including proof sizes, disclosure sizes, log-entry sizes, and storage growth over long interaction chains, are not fully characterized in this prototype and are left for future work.

Validation Summary

• In the evaluated valid cases, $verify\left({\mathit{TE}}_i\right)$ was observed to hold consistently across the scenarios considered.
• $constraint\_ok(E_i,{\mathcal{X}}_i)$ was evaluated through the implemented constraint mechanisms in the assessed scenarios.
• Violations of $consistent({\mathit{TE}}_{i-1},{\mathit{TE}}_i)$ are reflected as failures in the evaluated adversarial scenarios.
• $verify(I,\mathcal{C})$ fails when one or more required conditions are violated under the evaluated scenarios.

Overall, these results should be interpreted as prototype-level feasibility evidence, not deployment readiness. Broader claims require additional evaluation in networked environments, resource-constrained wallets, distributed logging infrastructures, and larger credential ecosystems.

6. Discussion

The proposed ETA frames trust not only as a design-time assumption, but also as a property that can be evaluated during and after system execution. The results suggest that ETA is most useful as a diagnostic and audit framework for sequence-dependent trust failures.

In this sense, ETA is intended not to replace credential verification, runtime verification, or secure logging, but to connect their outputs into a common TrustEvidence chain that can be inspected through local and pairwise conditions. This structure can support the analysis of where a trust-relevant failure is reflected under the proposed model, such as in evidence validity, constraint satisfaction, linkage integrity, or cross-step consistency.

The evaluated scenarios provide limited prototype-level evidence for this diagnostic use, rather than deployment-level assurance. They illustrate how selected violations can be represented as failures of the corresponding formal conditions under the evaluated assumptions.

At the same time, ETA should not be interpreted as providing complete trust under arbitrary distributed-system failures. Its trust assessment is conditional on the stated cryptographic, logging, freshness, and execution assumptions; Byzantine faults, network partitions, and consensus failures require additional mechanisms or are outside the current model scope.

Overall, the proposed approach suggests that trust can be treated as a continuous and composable property of execution, rather than a one-time verification outcome.

7. Conclusions

This paper formalized executable trust as a sequence-aware property of digital interactions and showed, through Theorem 1, that step-level verification alone is insufficient to characterize interaction-level trust under the proposed formal model. The Executable Trust Architecture operationalizes this model through five functional layers, each contributing to the generation, constraint enforcement, linkage, and consistency evaluation of TrustEvidence across the interaction lifecycle.

Prototype-level validation across 68 test cases provided limited evidence that the implemented checks behave consistently with the proposed trust conditions under local execution conditions. Among the evaluated adversarial cases, 30 of 38 cases illustrate situations in which conventional step-level verification accepts the individual steps, while ETA’s sequence-aware conditions reflect an interaction-level failure.

Several directions remain open for future work. First, extending ETA to stronger adversary models—including Byzantine infrastructure, compromised logging services, and forked log histories—requires additional mechanisms such as external anchoring or transparency-log integration. Second, BBS+ unlinkable multi-attribute proofs are identified as a direction for future extension. Third, supporting scalable and automated verification mechanisms and characterizing the byte-level overhead of TrustEvidence chains across networked environments and resource-constrained wallets remain as directions for future work.