Parent: #85
TS's verifier (ts/packages/core/src/domain/token-predicates.ts) evaluates token-claims.conditions via trilean's own evaluatePredicate. Rust's verify_capability_token (rust/crates/wire-mesh-core/src/domain/tokens.rs) has no equivalent evaluator -- trilean has no Rust port -- so it currently refuses any token where conditions is present (TokenRejection::ConditionsUnsupported), rather than silently ignoring the field the way an earlier gap let valid-until go unenforced.
That's correct and safe (fail-closed), but it also means a Rust-side verifier can't accept any token that uses conditions at all, even when the condition would evaluate to true. Nothing in the mesh actually mints tokens with conditions yet (no domain-specific predicate exists beyond the mechanism itself -- see #85's own scope note that a TTL or #84's revoke-authorization check are future work), so this has no real-world impact today, but it will block interop the moment a TS peer mints a conditioned token a Rust peer needs to verify.
Real fix needs one of:
- A Rust port of trilean's evaluator (PredicateNode/ExpressionNode + delegate/compare/etc dispatch), even a minimal subset covering just what wire-mesh's own conditions actually use.
- Or, if trilean itself ever grows a Rust/WASM target, binding to that instead of a hand-rolled port.
Scope this once a real domain condition (TTL, revoke-authorization) actually needs cross-language interop -- until then the fail-closed refusal is the correct, safe behaviour, not a bug to rush.
Parent: #85
TS's verifier (ts/packages/core/src/domain/token-predicates.ts) evaluates token-claims.conditions via trilean's own evaluatePredicate. Rust's verify_capability_token (rust/crates/wire-mesh-core/src/domain/tokens.rs) has no equivalent evaluator -- trilean has no Rust port -- so it currently refuses any token where conditions is present (TokenRejection::ConditionsUnsupported), rather than silently ignoring the field the way an earlier gap let valid-until go unenforced.
That's correct and safe (fail-closed), but it also means a Rust-side verifier can't accept any token that uses conditions at all, even when the condition would evaluate to true. Nothing in the mesh actually mints tokens with conditions yet (no domain-specific predicate exists beyond the mechanism itself -- see #85's own scope note that a TTL or #84's revoke-authorization check are future work), so this has no real-world impact today, but it will block interop the moment a TS peer mints a conditioned token a Rust peer needs to verify.
Real fix needs one of:
Scope this once a real domain condition (TTL, revoke-authorization) actually needs cross-language interop -- until then the fail-closed refusal is the correct, safe behaviour, not a bug to rush.