A credential is one part of a decision
A protected browser action has several questions to answer. Did this request arrive with valid proof? Is that proof still usable? Is the account allowed to perform the action? Has the operation already happened? Those questions are related, but a single credential does not answer all of them.
A signature can help establish that a credential came from its issuer and has not been changed. It cannot, on its own, establish everything that has happened since issuance. A request may have already used the credential, the surrounding session may have changed, or the application may have completed the intended operation.
Freshness requires context
An expiry time places a bound on how long proof can be considered. Within that interval, the system still needs a way to reason about use. A short lifetime is useful, but it is not the same control as detecting that a particular request has already been consumed.
MANDATE’s hosted verification design treats opaque proof as a reference to server-side truth. The service cross-references current state when it makes a decision, including replay markers and session continuity. Applications do not decode a browser credential into a permanent trust label.
The distinction matters when a credential is captured or a request is repeated. The relevant question is not only whether the bytes are valid. It is whether this use is consistent with what the service currently knows.
Browser evidence does not grant authority
The application owns authentication and authorization. A successful browser verification does not choose a tenant, grant an administrative role, validate a price, or confirm that the user owns a payment method. Those checks must remain at the operation boundary.
The reverse is also true: an authenticated account does not make every request from its session safe. A useful integration brings browser evidence and application rules together without confusing either for the other.
Availability is an explicit design choice
Consulting a hosted service introduces a dependency into the request path. The integration must define what happens when that dependency is unavailable, too slow, or returns an error. An error must not quietly become a claim that verification succeeded.
MANDATE’s local verification path is an emergency fallback or legacy compatibility option. It does not have all the current context of a hosted check. A fallback therefore needs a deliberately constrained scope and a clear way to return to normal operation.
Review the whole action
Start by mapping the browser request to the server operation it can trigger. Identify the independent authorization checks, the point at which proof is checked, and the outcome that is stored after success. Then test response loss, retries, and expired proof as part of the same journey.
The goal is a decision that uses current evidence and preserves application authority. It is not to assign a permanent label to a browser or to claim that a real browser must be operated by a human.
Engineering explanation · Product availability is described on the linked capability pages.