The architecture in context.

Proposed actors

A relying application makes the decision; a participant interacts with a human-facing checkpoint; a future verification service would issue a bounded result. Each actor has different permissions and responsibilities.

Illustrative lifecycle

1. The server identifies an action that requires human participation and creates a contextual challenge.
2. The participant receives a transparent explanation and completes an accessible flow.
3. A future verifier evaluates the interaction and returns a short-lived, context-bound result.
4. The relying server validates the result, checks its own authorization policy, and records a minimal audit event.

Trust boundaries

Never rely on a browser flag such as verified=true. Require proof tied to an intended action, reject replay, verify expiry, authenticate service calls, and treat unknown outcomes as failures.

Operational expectations

Document network timeouts, upstream unavailability, duplicate callbacks, accessible fallbacks, recovery flows, and retention limits. Integration design is incomplete without handling the negative path.