Round 9 adds production-policy enforcement inside three storage factories, fixes ignored typed encryption configuration and wallet path traversal, and shares strict credential validation between import and verification. Both requested custody models have experimental adapters and adversarial tests. They are not activated production wallet profiles. The SDK correctness score gains 0.5 for the bounded profile and storage fixes; no hardware-custody credit is awarded. SaaS retains its prior score and validation scope.
Scores are engineering judgments against the same 30/25/20/15/10 rubric. They are not percentages of bug-free code or a security certification. Historical scores are preserved.
Category
Maximum
TrustWeave
SaaS
Security
30
29
29
Correctness
25
24.5
24.5
Architecture
20
19.5
19
Testing
15
15
14
Experience
10
10
9.5
Remaining deductions
trustweave
Security -1: current wallet enrollment/presentation still uses browser keys. Passkey and managed-KMS adapters require application enrollment, durable authorization/recovery, issuer/verifier integration and actual hardware/service qualification. Attestation-none WebAuthn does not prove hardware provenance.
Correctness -0.5: bounded import/verifier profiles are stricter and tested; hosted-provider authentication, recovery and operational behavior remain unqualified.
Architecture -0.5: file/database/cloud factories now enforce typed deployment policy before resources are opened. Other providers/direct constructors remain outside that integration, and no catalog provider has sufficient evidence for supported maturity.
Experience retains prior credit for replacement/reissuance UX; corruption remains distinct from missing keys and cannot silently rotate identity.
Testing receives full local-validation credit for the full JVM suite, lint, database/HTTP contracts and production browser regressions. This does not certify optional hosted providers; those limitations remain in correctness/architecture.
trustweave-saas
Security -1: the reviewed local SDK fingerprint changed with this patch. The immutable pin still points to the earlier commit; a new coordinated commit/pin/publication and exact-pair remote Linux/staging validation remain required.
Correctness -0.5: application/tenant/subscriber/payment-metadata contracts passed against real Accountly/Kill Bill; PSP setup, paid subscriptions, settlement and production service-account authentication remain unvalidated.
Architecture -1: release coupling and hosted recovery/alert integration remain outstanding.
Testing -1: two live-contract skips and no exact-pair remote Linux/staging evidence.
Experience -0.5: admins can inspect and page through recovery events without database/payload access; live provider redelivery still requires manual operations, and supported credential formats remain limited.
Validation evidence
Area
Result
Scope and limits
SDK storage and wallet modules
104 tests passed; no failures or skips
File 24; database 28; cloud 24; wallet-core 23; wallet-core-mp 5. These are targeted tests, not a full SDK rerun.
Kotlin lint
Five targeted modules passed
Existing lint baselines retained; no new baseline entries added. Formatting restricted to changed files.
12 Chromium tests and production build/TypeScript passed
Virtual WebAuthn authenticator plus existing browser workflows. No hardware attestation is claimed.
Source and documentation gates
Local SDK fingerprint and generated capability documentation verified; 2 fingerprint-verifier tests passed
Fingerprint 6a0b5d2d58c1b1875410dba4571019394a97114cadd63092c866f2d5e95c6ae8. A new immutable SDK/SaaS commit pair is still required.
Production custody
Open, explicitly not promoted
Application enrollment, authorization/recovery persistence, presentation integration, actual managed service and physical hardware qualification remain.
Results distinguish local database/HTTP fixtures from hosted-service validation. Optional tests that did not run remain reported as skips. Timing excludes fixture setup.
Storage factories enforce deployment policy before side effects
Added a typed LEGACY / EXPERIMENTAL / SUPPORTED_ONLY policy to wallet options and their builder. File, database and cloud factories apply the maturity gate before opening files, pools or clients.
Evidence: Direct factory tests verify production refusal occurs before missing configuration or resource creation. Explicit experimental encrypted storage is tested through create/store/reopen.
Limit: Compatibility default is LEGACY. Direct constructors and other domain providers are not automatically covered. No provider was promoted; SDK consumers must rebuild against changed options.
Typed encryption key and file-wallet path isolation
The factory previously ignored the typed encryption key and accepted wallet IDs that could escape the storage root. It now honors the key, refuses conflicting/invalid key configuration and restricts IDs to a safe path component.
Evidence: Regression verifies ciphertext does not expose issuer data, decrypts correctly after reopen, rejects invalid typed keys and blocks traversal, separators and empty IDs.
Limit: IDs outside 1?128 ASCII letters/digits/underscore/hyphen need an explicit migration. The configured storage directory is operator-controlled; no local-administrator or hostile-filesystem isolation is claimed.
One bounded issuer profile at import and verification
Rejects VC/SD-JWT format confusion, arbitrary key fragments, conflicting issuer/holder bindings, unsupported confirmation keys, invalid time intervals and unsupported array disclosures. The demo verifier now uses the same validation as import.
Evidence: Fifteen new credential-profile cases exercise valid and adversarial signed inputs. Existing issuer/disclosure browser regressions remain covered.
Limit: This is a deliberately bounded Ed25519 did:key profile, not general VC or SD-JWT conformance. Existing supported browser claim-encryption behavior remains separate from new custody adapters.
Explicit dispatch has no browser fallback. Passkey proof checks RP/origin, user presence/verification, backup policy, challenge and signature; the payload verifier requires an atomic nonce-consumption callback. Managed signing checks authorization configuration, exact returned payload, pinned key and algorithm, with timeouts, bounded streaming and no redirects.
Evidence: Chromium virtual-authenticator enrollment/signing test and adversarial signature/challenge/credential/UV checks. Local cryptographic fixtures cover EdDSA and ES256 responses, substitution, authorization/network failures and response limits.
Limit: Experimental primitives only. WebAuthn assertions are not JWT signatures. The existing wallet UI is not switched to these adapters, and no production managed service, physical authenticator attestation or hardware KMS was validated.
Complete production custody integration and provider qualification
Both custody models are selected. Remaining work includes trusted enrollment, durable authorization/nonces, recovery and audit persistence, issuer/verifier presentation compatibility, user-facing integration and actual device/service qualification. A non-production HSM/KMS target and existing credential profile were requested but not supplied.
Evidence: No hardware/provider maturity promotion is claimed. Current adapter tests use a virtual authenticator and software cryptographic fixtures.
Limit: This remains open. The adapters do not justify a perfect score or a claim that production custody is finished.
The reviewed SDK runtime changed locally; the fingerprint was deliberately updated and verified. The immutable revision remains the prior commit. Coordinate a new SDK commit and SaaS pin, publication and exact-pair remote Linux/staging validation.
Evidence: No publication or staging execution is claimed.
Limit: A matching local fingerprint cannot substitute for a reviewed, published and tested immutable pair.
Real local Accountly/Kill Bill application, tenant, subscriber and payment-metadata behavior is now verified. External PSP setup/collection, settlement, service-account authentication, hosted alerts and the supported legacy Stripe cutover still require validation.
Evidence: Dedicated deployed contract passed. Original two Accountly tests requiring the PSP stand-in remain unexecuted in this pass.
Limit: The supported Accountly cutover/legacy Stripe workflow needs to be defined and exercised before claiming completeness.