Why Auths

Concept / motivation

Authentication establishes who controls an account, key, or workload identity. It does not, by itself, prove that the principal may perform the exact action a service is about to execute.

Conventional systems often spread authorization across bearer tokens, policy services, application conditionals, identity-provider configuration, and runtime state. The enforcement point receives a request but may not receive a portable explanation of the complete authority path.

What changes

Auths binds together:

• the exact canonical action;
• its audience and challenge;
• the grants that delegated authority;
• the principal-control evidence for signed statements;
• status and assurance evidence;
• the authorization plan; and
• explicit verifier trust and resource limits.

The service resolves those inputs into Authorized, Denied, or Indeterminate without a network call from the kernel.

Auths does not replace identity

Principal methods establish control of a principal. They do not define the principal’s authority. Auths remains agnostic to which supported identity or key-control system supplies that fact.

The practical result

A deployment gateway can approve an exact artifact and strategy. An MCP server can authorize one canonical tool call. An internal service can make a local decision without depending on a request-time authorization daemon. In each case, the verifier evaluates the same protocol model.