Authn and Authz

Purpose

This page defines governance-level rules for authentication (authn) and authorization (authz) terminology, boundaries, and documentation requirements.

It is a control and policy reference only. It does not define system behavior, security guarantees, or operational outcomes.

Definitions

Authentication (authn): Establishing an identity claim (who is requesting).

Authorization (authz): Evaluating permission for an action on a resource (what is allowed).

Credential: A proof used to support an identity claim (e.g., key, token, secret).

Principal: The entity being authenticated (user, service, operator identity).

Policy: The declared rules that govern permission evaluation.

Interpretation Rules

Authn and authz must be documented as separate concerns. Authn establishes identity; authz evaluates permission.

Do not use “authenticated” as a substitute for “authorized.” Being authenticated does not imply permission.

Do not use “authorized” to imply identity verification. Authorization does not prove who the principal is.

Every protected action must have an explicit authorization rule reference (policy name, role, capability, or equivalent label).

Disallowed Inferences

Do not infer that an authentication mechanism provides security, safety, or correctness guarantees.

Do not infer that authorization implies enforcement completeness or absence of bypasses.

Do not infer that the existence of roles, permissions, or policies implies compliance, certification, or audit approval.

Do not infer that “least privilege” is achieved unless explicitly defined and validated by a stated method.

Boundary Conditions

This page governs how authn/authz are specified and reviewed as documentation artifacts.

It does not describe implementation choices, cryptographic strength, threat resistance, uptime, or incident handling.

It does not establish normative requirements for external identities, third-party providers, or legal obligations.

Non-Guarantees

This document does not guarantee that access is correctly restricted, that credentials cannot be compromised, or that privilege escalation is impossible.

This document does not guarantee that any policy is enforced, complete, or sufficient for any security objective.

Validation Checklist

Are authn and authz described as separate concerns with non-overlapping meanings?

For each protected action, is there an explicit authorization rule reference (role/capability/policy label)?

Are “authenticated” and “authorized” used consistently without implying guarantees?

Are boundary statements present that prevent claims of compliance, certification, or absolute security?

Are terms like “secure,” “ensures,” “prevents,” or “guarantees” avoided unless explicitly scoped as non-guarantees?

Forbidden Patterns

Avoid statements that collapse authn into authz (e.g., “authenticated users can do X” without an authorization rule).

Avoid statements that imply outcomes (e.g., “authz prevents abuse,” “authn guarantees legitimacy”).

Avoid attributing compliance or audit conclusions to the presence of authn/authz controls.