{"id":"5ee375db-dfa5-4567-b58d-52764e284adf","arxiv_id":"2502.10281","paper_version":2,"verdict":"REJECT","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"high","formal_verification":"none","parameter_count":0,"one_line_summary":"TrustZero proposes a trust token made of server signatures and a trust score that counts them, with a proof-of-concept, but the score is defined so that valid signatures are the same as trust.","lead":"This paper describes TrustZero, a zero-trust security system that scores users by the number of signed attestations they collect from servers. It includes a proof-of-concept with a web application firewall and latency tests, but the trust model and scalability claims are not backed by the experiments.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Trust score in Eq. (2) counts valid signatures, but Section IV-A never defines the issuance condition and the PoC does not use the score; without a meaningful issuance policy the web-of-trust claim is unsupported.","rationale":"Good-faith reading: TrustZero is a proof-of-concept for a portable trust token; if the score were a well-defined, Sybil-resistant measure and experiments showed it being used, the paper would support a modest claim. But the manuscript does not provide that. The reader's weakest assumption is correct and is the same one I would stress: the only link between 'signature' and 'trustworthy' is the undefined 'good request' phrase. My proposed test directly probes that link. I also note the paper's own statement that score usage is not implemented, which means the Section VII claim that experiments 'validated the efficiency of the trust scoring mechanism' is not supported: latency of signature verification is not validation of a trust mechanism. The scalability claim is additionally undermined by Figure 9 (latency rises from roughly 0.08 s at 200 users to about 3.9 s at 600 and over 17 s at 1800), but the score-semantics flaw is more fundamental because it voids the security purpose of the architecture, not just its performance. No formal verification or parameter-free derivation rescues the paper; the trust model is a counting function. Therefore I agree with the reader's REJECT verdict; no adjustment is needed. The concrete test is feasible because the repository and container deployment are described and cited.","tokens_in":14854,"tokens_out":4511,"duration_ms":44694,"concrete_test":"Run the published GitHub PoC with two clients: (A) a legitimate client that collects signatures from 5 servers using the project's normal flow, and (B) an attacker that controls 5 server containers modified only in that their issuance condition is 'always sign'. Compute Eq. (2) for both and send each client's token through the deployed ModSecurity reverse proxy. If B reaches the same score as A and receives the same service, the trust score carries no trustworthiness information and the central claim fails; if B is blocked or scored differently, the paper needs to state the mechanism that produced that distinction.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central security claim requires Eq. (2)'s trust score to track trustworthiness, but Eq. (2) is only a count: Vf() returns 1 for any signature that verifies against the issuer's public key. The issuance condition is never specified. Section IV-A says a server issues a signature 'if the previous step passed (or is renewing it)' and Section IV-B says signatures are given 'in exchange for a good request', but 'good' is undefined. Consequently, an attacker can create k servers under their control, have each sign the attacker's public key, and obtain the same score as a legitimate user with k endorsements; nothing in the protocol or score distinguishes these cases. The paper's own implementation confirms the gap: Section VI states 'While the usage of the score is not implemented in this POC', so the experiments measure signature-processing latency, not the security benefit of scoring. This is load-bearing because the abstract, introduction, and conclusion all present TrustZero as a secure web-of-trust framework that mitigates attacks, yet the one quantity that is supposed to encode trust has no defined semantics and is not exercised in the evaluation. Secondary inconsistency: Section IV-B first calls the token non-revocable, then says any server can revoke it after abnormal access and that a server can change its key pair to invalidate all its signatures; even setting that aside, the missing score semantics are decisive.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"TrustZero proposes a zero-trust security layer built around a self-sovereign \"trust token\": a public key with a list of signatures from servers that the user has interacted with. The trust score in Equation (2) counts the number of valid signatures on the user's public key. The paper describes a protocol in which servers verify prior signatures and issue their own, a ModSecurity-based proof-of-concept implementation, latency experiments comparing users with zero and five signatures, a simulated DDoS experiment with up to 2000 concurrent users, and an Android integration app. The abstract and conclusion claim that the framework is a secure, scalable web-of-trust, with minimal latency and practical applicability under denial-of-service conditions.","tokens_in":15156,"tokens_out":3725,"duration_ms":37331,"significance":"If the trust model were sound, the paper would provide a useful open-source reference point for transparent, verifiable zero-trust systems. The authors do ship open-source code, use simple cryptographic primitives, and report reproducible experiments, which is a positive step for a field where detailed public implementations are rare. However, the central security claim is not established: the trust score's semantics are undefined, the evaluation never exercises the score, and the reported DDoS experiment contradicts the scalability claim. These are foundational gaps rather than presentation issues, so the current manuscript does not meet the bar for publication in its present form.","major_comments":[{"comment":"This is not a cosmetic issue: the abstract, introduction, and conclusion all present the trust score as the mechanism that improves security, yet the score's semantics are not specified and no experiment measures whether the score correlates with honest behavior.","section":"Section IV-A / IV-B / Eq. (2)"},{"comment":"Additionally, the experiment floods the servers from the same host that runs the servers, so the measured latency may be dominated by resource contention rather than by the TrustZero protocol; either way, the data do not support the claimed resilience.","section":"Section VI, Figure 9"},{"comment":"If revocation is intended, the authors should explain how it coexists with the non-revocable self-sovereign identity claim; if revocation is not intended, the conflicting text must be corrected.","section":"Section IV-B"},{"comment":"To support the web-of-trust claim, the paper would need to define an issuance policy and then test whether the score distinguishes honest from dishonest behavior under that policy.","section":"Section VI, Figure 5"},{"comment":"At a minimum, the authors should specify what prevents an attacker from obtaining many signatures from colluding or compromised servers and explain how the score is meaningful when issuers are heterogeneous.","section":"Section IV-A / IV-C"}],"minor_comments":[{"comment":"Please clarify which eIDAS or other assurance level is claimed and how the implementation meets it.","section":"Abstract / Section II"},{"comment":"Please report the setup per experiment or explain why the choice does not affect the conclusions.","section":"Section VI"},{"comment":"Additionally, \"asses the trust score\" should be \"assess the trust score\".","section":"Section VI"},{"comment":"Adding labels would improve readability.","section":"Figure 7"},{"comment":"Please provide full bibliographic information, including authors and publication venue where available.","section":"References"},{"comment":"A short discussion of the trade-off between token size and verification cost would strengthen the analysis.","section":"Section VI"}],"recommendation":"reject","confidential_remarks":"The manuscript reads as an undergraduate thesis rather than a completed research paper. The central security claim — that the trust score meaningfully distinguishes trustworthy from untrustworthy users — is unsupported by the design (no issuance policy) and by the experiments (the score is not used). The DDoS experiment, as reported, contradicts the advertised scalability. These are not local presentation fixes; they require a substantive redesign of the trust semantics and a new evaluation that exercises the score. I would encourage the authors to address these points and resubmit, as the open-source implementation and reproducible experiments are a useful starting point."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Bottom line: this is a web-of-trust rehash with a ModSecurity integration, and the central security claim doesn't survive contact with its own equations.\n\nWhat's genuinely here: a working open-source proof of concept (GitHub repo), a clear description of a header-based trust token, latency measurements on real hardware, and an Android integration demo. The paper is transparent that the trust score is not actually used in the PoC—that admission is buried in Section VI, but it's there. The related work section is reasonably thorough and correctly cites TrustGuard, which already does flow-level reputation scoring.\n\nThe soft spots are load-bearing, not cosmetic. Equation (2) defines trust as the number of valid signatures, but nothing in Section IV defines what makes a request \"good\" enough to earn a signature. A server signs \"in exchange for a good request\"—that's the entire issuance policy. So the score counts endorsements from servers regardless of what the user actually did. If I spin up k servers under my control, I get the same score as someone with k honest endorsements. The protocol has no way to tell the difference. The paper's own experiments make the circularity explicit: a \"bad\" user is defined as one whose signatures are corrupted, so of course their score is lower. That's signature verification, not trust evaluation.\n\nThe scalability claim is also contradicted by Figure 9: latency goes from 0.07s at 200 users to 35s at 2000 users, a 500x degradation. The paper calls the experiment a \"DDoS\" and then claims practical applicability; that doesn't follow. There's a smaller inconsistency where the token is called non-revocable in one paragraph and then revocable by servers in the next, but that's minor compared to the score semantics problem.\n\nWho is this for? Someone looking for a minimal, reproducible implementation of a signature-counting trust token on ModSecurity. As a zero-trust security claim, it's not supported. If I were an editor, I'd send it to a reviewer because the artifact is concrete and the claims are falsifiable, but I'd expect the review to come back negative unless the authors add a real issuance policy and a proper security analysis.","headline":"A web-of-trust signature counter with a ModSecurity demo; the trust score has no defined issuance policy and the paper's own load test contradicts its scalability claims.","tokens_in":15646,"tokens_out":2511,"would_cite":false,"duration_ms":23795,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"TrustZero proposes a trust token that turns server signatures into a global, verifiable trust score for users.","keywords":["zero trust architecture","trust token","web of trust","digital signatures","self-sovereign identity","ModSecurity","trust score","decentralized authentication"],"falsifier":"Run a Sybil test: spin up a handful of colluding server instances, have a brand-new identity collect valid signatures from all of them within minutes, and check whether that identity is then granted access to a resource reserved for long-standing trusted users; if the score cannot distinguish the colluding identity from a genuinely vetted one, the central claim fails.","tokens_in":14670,"feed_emoji":"🔐","tokens_out":4879,"duration_ms":47989,"temperature":0.7,"pith_summary":"TrustZero argues that zero-trust security can be made portable and global by encoding a user's reputation as a non-revocable self-sovereign identity: a public key signed by every server the user has interacted with. The central claim is that a trust score equal to the number of valid signatures on that key gives a mathematically grounded, verifiable trust attestation that any server can check with public-key operations alone. Because the token travels in an HTTP header and is validated by a reverse-proxy firewall before requests reach the server, the scheme promises to upgrade legacy systems and cross-organizational communication without rewriting server code. The paper backs this with an open-source proof of concept and latency measurements showing small overhead for normal traffic, though sustained flooding degrades response times sharply.","feed_headline":"Server signatures become a portable trust score","feed_subtitle":"TrustZero scores users by how many independent servers signed their key, adding zero-trust checks without rewriting server code.","key_machinery":"The load-bearing object is the trust token: an ordered list of signatures $\\text{sign}_{S_1} \\| \\ldots \\| \\text{sign}_{S_N}$, each a signature by server $S_i$ over the user's public key $pk_U$. A user's trust score is computed as $\\sum_i V_f(\\text{sign}_{S_i}, pk_{S_i}, pk_U)$, where $V_f$ is a signature-verification function returning 1 for a valid signature and 0 otherwise. The token is carried in the `User-Key-Signatures` HTTP header and checked by ModSecurity, acting as a policy enforcement point in reverse-proxy mode, before the request reaches the server. The protocol's two-step server behaviour—verify all existing signatures, then append one of its own—is what lets trust accumulate across independent servers without a central authority.","core_discovery":"The paper's discovery claim is that trust can be relocated from organizations to a portable token. TrustZero defines a trust token as a concatenation of digital signatures, one per server that has vouched for the user's public key, and defines the user's trust score as the number of those signatures that verify against the issuing servers' public keys. Servers issue a signature in exchange for a request they deem good and are expected to verify all prior signatures before adding their own, so the token accumulates and carries a verifiable interaction history. This turns a web of servers into a decentralized attestation layer: any participant can recompute the score from public information, and a WAF positioned as a reverse proxy can deny requests with invalid or insufficient tokens before they reach the application. The authors present this as an open-source, reproducible alternative to closed zero-trust deployments such as Google's BeyondCorp.","pith_inferences":["If TrustZero were deployed with the 'good request' criterion left to each server, the trust score would measure a server's willingness to sign rather than the user's actual behavior; a standard for vetting would be needed before the score can be read as a reputation.","The architecture could be extended so that organizations, rather than individual servers, act as signing authorities, effectively creating a decentralized public-key infrastructure where the token becomes a passport-level identity for cross-border or cross-organization access.","A natural test of the model is to compare TrustZero scores against observed rates of abuse (fraud, spam, policy violations) in a real deployment; the paper does not report such a comparison, but the model's value depends on the correlation holding.","The token's linear size growth with each signature could be bounded by capping the number of signatures while letting servers prioritize the most reputable issuers, preserving portability without unbounded headers."],"forward_implications":["Any server, without a central authority, can compute a user's trust score from public keys and signatures before granting access.","Legacy applications can gain zero-trust checking by inserting the token header and a reverse-proxy rule, leaving the application code untouched.","Because reputation is tied to accumulated signatures from distinct servers, building a useful identity takes time and many independent interactions, which raises the cost of Sybil identities.","A server can withdraw a user's reputation by refusing to renew signatures or by rotating its key pair, making the system revocable in practice even though the identity itself is non-revocable.","The measured latency of a request grows from roughly 0.08 seconds at 200 concurrent users to tens of seconds beyond 1800 users, so the current verification path, not the application, becomes the bottleneck under flooding."],"supporting_citations":[{"why":"introduces the zero-trust network architecture that TrustZero builds on.","marker":"[32]"},{"why":"supplies the NIST Policy Enforcement Point, Policy Administrator, and Policy Engine component model used in the design.","marker":"[53]"},{"why":"describes Google's BeyondCorp, the reference practical zero-trust deployment TrustZero contrasts with and aims to generalize.","marker":"[58]"},{"why":"defines ModSecurity, the web application firewall that serves as TrustZero's reverse-proxy policy enforcement point.","marker":"[45]"},{"why":"is the open-source proof-of-concept repository implementing the TrustZero protocol and experiments.","marker":"[7]"},{"why":"presents the European Digital Identity Wallet that TrustZero's passport-level trust token is designed to complement.","marker":"[40]"},{"why":"argues that complete zero trust is unachievable, motivating TrustZero's approach of establishing portable trust instead.","marker":"[23]"},{"why":"documents the migration difficulties of BeyondCorp, motivating TrustZero's header-based integration that avoids server changes.","marker":"[24]"}],"fun_headline_variants":["Trust score from server signatures","Portable trust token from server vouches","Count signatures, get a trust score","Web of servers becomes trust attestation","Zero-trust via signed token accumulation"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The protocol assumes that a server's signature on a user's public key is a meaningful attestation of good behavior, but it never defines what makes a request 'good' or shows that the number of signatures correlates with trustworthiness; if servers sign indiscriminately, the score reflects only the willingness to sign.","fun_headline_variants_meta":{"raw":{"variants":["Trust score from server signatures","Portable trust token from server vouches","Count signatures, get a trust score","Web of servers becomes trust attestation","Zero-trust via signed token accumulation"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000163,"raw_usage":{"total_tokens":1196,"prompt_tokens":851,"completion_tokens":345,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":467,"completion_tokens_details":{"reasoning_tokens":285}},"tokens_in":467,"tokens_out":345,"duration_ms":3964,"temperature":1.0,"reasoning_tokens":285,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T18:40:53.021511+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a Sybil test: spin up a handful of colluding server instances, have a brand-new identity collect valid signatures from all of them within minutes, and check whether that identity is then granted access to a resource reserved for long-standing trusted users; if the score cannot distinguish the colluding identity from a genuinely vetted one, the central claim fails.","supporting_citations":[{"cited_title":"Build security into your network’s dna: The zero trust network architecture","cited_arxiv_id":null,"evidence_quote":"introduces the zero-trust network architecture that TrustZero builds on."},{"cited_title":"Zero trust architecture","cited_arxiv_id":null,"evidence_quote":"supplies the NIST Policy Enforcement Point, Policy Administrator, and Policy Engine component model used in the design."},{"cited_title":"Beyondcorp: A new approach to enterprise security","cited_arxiv_id":null,"evidence_quote":"describes Google's BeyondCorp, the reference practical zero-trust deployment TrustZero contrasts with and aims to generalize."},{"cited_title":"Modsecurity handbook","cited_arxiv_id":null,"evidence_quote":"defines ModSecurity, the web application firewall that serves as TrustZero's reverse-proxy policy enforcement point."},{"cited_title":"https://github.com/AdiDumi/TrustZero","cited_arxiv_id":null,"evidence_quote":"is the open-source proof-of-concept repository implementing the TrustZero protocol and experiments."},{"cited_title":"Eu- ropean digital identity","cited_arxiv_id":null,"evidence_quote":"presents the European Digital Identity Wallet that TrustZero's passport-level trust token is designed to complement."},{"cited_title":"Zero trust in zero trust","cited_arxiv_id":null,"evidence_quote":"argues that complete zero trust is unachievable, motivating TrustZero's approach of establishing portable trust instead."},{"cited_title":"Beyond- corp and the long tail of zero trust","cited_arxiv_id":null,"evidence_quote":"documents the migration difficulties of BeyondCorp, motivating TrustZero's header-based integration that avoids server changes."}],"review_version":1}