Every request crosses a boundary

A valid value can still describe an unauthorized change.

What crosses the boundary

A request carries client-supplied claims. Parsing gives those claims structure; validation checks acceptable values. Authentication establishes the caller’s identity. Authorization decides whether that caller may perform this action on this resource. These decisions answer different questions, even when one framework performs several of them.

Assume a booking site lets members edit their own attendance notes, while only staff may change approval status. The server’s booking record is the authority for ownership. A hidden field is a presentation choice, not evidence of permission.

Fictional design record

• B1: The session identifies Maya; the server validates note length and booking-number format.
• B2: The form displays an owner name and hides approval status from members.
• B3: The change handler accepts submitted booking fields. Its review record contains no ownership lookup or permitted-field policy.

Reason from the evidence

B1 supports identity and format checks. B2 explains the interface. Neither establishes that the selected booking belongs to Maya or that the submitted change stays within her authority. B3 leaves those controls unverified; it does not demonstrate that an unauthorized change occurred.

The review should require the server to compare the authenticated caller with current ownership and apply an explicit policy for changeable fields. Fields outside that policy must not acquire authority merely because they are present. Recheck relevant state when committing the change if ownership can change during the workflow.

Review note: Identity and format checks are documented. Approval awaits evidence of resource ownership and permitted-field enforcement.