TrustWeave SDK · Round 13 · 6 September 2026
Fresh review: stronger controls, remaining validation defects
7.9 / 10
Five equally weighted categories. Up 0.3 from the independent round-11 baseline (7.6); down 0.2 from the provisional round-12 estimate (8.1), because this review reproduced additional defects. This is an engineering assessment of the uncommitted working tree, not a certification.
| Category | Score |
|---|
| Security | 8.5/10 |
| Correctness | 8.0/10 |
| Architecture | 8.5/10 |
| Testing | 7.5/10 |
| Supply chain / CI | 7.0/10 |
The repository is not at 10/10. The strongest immediate priorities are honest budget-enforcement results, strict amount/currency validation, and safe HTTP error responses.
Validation evidence
75 regression tests passed in this review: Indy 36, BTCR 2, Tezos 2, ThreeBox 2, Verifiable Intent 33; zero failures, errors or skips. The ordinary Verifiable Intent suite passed again after removal of the temporary diagnostic test.
Four diagnostic assertions failed as predicted. Each asked the public constraint checker to reject an invalid case; all four returned satisfied=true. The probes confirm the defects described below. They are separate from regression-suite results and do not demonstrate a deployed payment-network exploit.
Prior evidence retained: 888 targeted tests passed, repository ABI validation passed with 105 reference files, a module SBOM was generated, and documentation checks passed. The broader coverage log was interrupted without a final result and is not counted as a complete pass. Current inventory: 16 modules without conventional Kotlin test sources and 32,692 lint-baseline entries.
Findings, ordered by priority
High · TW-R13-01
Budget constraints are reported as checked without enforcement evidence
credentials/plugins/verifiable-intent/src/main/kotlin/org/trustweave/credential/vi/verification/ConstraintChecker.kt:84
Evidence. Budget, recurrence, agent_recurrence and reference share a branch that appends to checked. A focused runtime probe supplied a budget max of 10 and an amount of 1000; satisfied was true. ChainVerifier maps these entries into checksPerformed and constraints_satisfied.
Impact. A caller relying on SDK verification alone can mistake a structurally valid payment for budget-authorized spending. Payment networks are responsible for cumulative state, but the SDK accepts no state or enforcement result here. This does not demonstrate an exploit against a deployed payment network.
Recommended change. Distinguish externally required checks from completed checks. Require a stateful authorization callback or explicit external enforcement evidence for budget authorization; enforce local amount/currency/minimum checks too. Add concurrency and repeated-payment tests at the enforcement boundary.
Verification. Runtime-confirmed at the public ConstraintChecker boundary; no deployed network tested.
Medium · TW-R13-02
Payment amount and currency schema validation remains permissive
credentials/plugins/verifiable-intent/src/main/kotlin/org/trustweave/credential/vi/verification/ConstraintChecker.kt:109
Evidence. Three runtime probes returned satisfied=true: amount=-1 under a max-only range, amount encoded as the JSON string "50", and an amount_range missing currency. Constraint.parse defaults missing currency to USD; numeric helpers accept string primitives.
Impact. Malformed signed inputs can be classified as valid. The chain requires the L3 currency field, so the missing-currency probe specifically targets L2 constraint parsing; it is not a claim that the chain accepts an absent L3 currency.
Recommended change. Require numeric, non-negative L3 amounts and string currency fields; reject missing/invalid L2 currency and string-encoded bounds. Add boundary and malformed-type regressions.
Verification. Three runtime-confirmed public-checker cases; relevant chain field guards inspected.
Medium · TW-R13-03
Status-list HTTP errors expose exception messages
credentials/plugins/status-list/server/src/main/kotlin/org/trustweave/credential/statuslist/server/StatusListRoutes.kt:63
Evidence. Both routes serialize e.message into INTERNAL_ERROR responses at lines 66 and 104. They catch broad Exception, which also includes cancellation.
Impact. Public status-list clients may receive database, signing-provider or internal implementation details when the backend fails. Actual exposed text depends on the provider exception.
Recommended change. Return a stable generic error and correlation ID, retain appropriate diagnostics on the server, and rethrow cancellation. Test controlled backend failures and assert sensitive details are absent.
Verification. Static finding; no sensitive-data disclosure was induced against a live endpoint.
Medium · TW-R13-04
Checkout support and constraint documentation still overstate completeness
credentials/plugins/verifiable-intent/README.md:95
Evidence. The README describes 8-type constraint enforcement while line_items is explicitly unsupported and budget/recurrence are acknowledged rather than evaluated. The checker reads merchant from the fulfillment object; the chain passes the final mandate rather than extracting merchant identity from checkout_jwt.
Impact. Integrators need a precise capability boundary. Autonomous checkout currently fails closed; that protection must remain until item matching and trusted merchant-token verification are implemented together.
Recommended change. Publish a per-constraint enforcement matrix. Separate local checks, external obligations and unsupported operations; implement signed merchant extraction and item/quantity matching before enabling checkout.
Verification. Static trace and prior passing checkout-rejection regression tests. No current checkout bypass is claimed.
Medium · TW-R13-05
Complete regression and merged coverage evidence is still missing
.github/workflows/ci.yml:51
Evidence. Kover is enabled across Kotlin projects, but the repository-wide retry log ends during anchor tests without BUILD SUCCESSFUL or a final merged report. Sixteen included modules with src/main Kotlin still have no src/test Kotlin files.
Impact. Configuration coverage is not test coverage. The prior interrupted run cannot establish repository-wide correctness or a coverage floor.
Recommended change. Complete the CI coverage run, record skips separately, add meaningful provider/protocol tests, and adopt measured coverage floors for security-critical modules.
Verification. Current source inventory and preserved execution log; module-source inventory excludes multiplatform source sets.
Medium · TW-R13-06
Lint and exception-handling debt remain substantial
build.gradle.kts:90
Evidence. The configured baselines contain 32,692 entries. The prior broad exception-swallow finding has not been fully re-audited. The Indy cancellation case is fixed and its 36-test module suite passes.
Impact. Baselines can hide maintainability problems; network failures and cancellation need case-specific semantics. Baseline entries are not a count of currently active violations.
Recommended change. Shrink baselines through verified formatting and manual fixes. Classify exception paths and preserve cancellation/fatal errors without indiscriminately logging sensitive data.
Verification. Baseline XML count refreshed; no claim that every prior exception site was re-reviewed.
Medium · TW-R13-07
Release and hosted-provider evidence is incomplete
.github/workflows/release-evidence.yml:29
Evidence. Signing guards, SHA-pinned actions, a release-attestation workflow and module SBOMs now exist. A module SBOM was generated and its artifact identity corrected. The aggregate attempt was stopped during Maven metadata resolution; no actual signed publication or hosted attestation was verified.
Impact. The delivery controls are implemented but not yet proven end to end. Placeholder rejection tests do not demonstrate production provider maturity.
Recommended change. Validate the aggregate dependency inventory, run a controlled signed release and verify its attestation, and retain hosted-provider conformance evidence for each supported production claim.
Verification. Configuration review plus prior module-SBOM evidence; no publication or hosted-provider test performed this round.
Changes confirmed since round 11
Fail-closed allowlist and constraint-shape handling; full agent-key comparison and required delegation keys; ABI references and compatibility checks; unused direct test-dependency removal; expanded Kover configuration; SBOM and signing configuration; SHA-pinned CI actions; corrected examples-module coverage task ordering; Indy cancellation propagation; explicit rejection tests for three placeholder DID methods.
Scope and limits
Reviewed the changed SDK verification, build, release, test and status-list paths. This was not an exhaustive reread of every module. Source inventory is limited to included Gradle projects and conventional src/main and src/test Kotlin paths. No SaaS score is assigned. No production deployment, live payment network, signing service or hosted-provider conformance run was exercised. New findings were reviewed, not remediated in this pass.
The amount and budget expectations were checked against the Verifiable Intent constraints draft, sections 4.4 and 4.5. The draft requires integer payment amounts and assigns cumulative tracking to the payment network; the finding distinguishes that external obligation from the SDK's checked result.
Artifacts
Validation evidence · Findings JSON · Scores JSON · Diagnostic results · Reproducer source · Module inventory