Open table of contents
Conclusion
Tie each verification claim to a model, implementation and explicit assumptions throughout development.
Context
Authentication and authorization span state transitions, permissions and protocol assumptions. Different layers require different forms of evidence.
Design and verification scope
Assess the following responsibilities and boundaries when designing and verifying a configuration.
- Unit and property tests
- Kani harnesses and bounds
- Tamarin protocol models
- Implementation correspondence
- Assurance boundaries
Decision rationale
Tests exercise concrete examples; Kani checks Rust implementations under harness constraints; Tamarin examines properties of abstract protocol models. Their targets and assumptions differ. Map each change to the evidence that must be rerun or reviewed, rather than collapsing all three into “verified.”
Trade-offs
Smaller models and harnesses are easier to run and understand but cover less behavior. Expose abstraction, loop bounds and idealized cryptography, alongside the cost of maintaining proofs and correspondence as implementation changes.
Limitations
Collect commits, tool versions, commands, harnesses, lemmas, counterexamples and exclusions. Do not extrapolate to unbounded or production guarantees.
Related case context
These cases provide attributed design context. They do not establish that the proposed experiments or configurations were delivered in those engagements.