Section 30: Authentication and Authorization¶

TECHSPEC-30 — Section 30 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Security Philosophy¶

Authentication and authorization must be explicit, separate operations.

• Authentication establishes the identity of an entity.
• Authorization determines what that authenticated entity is permitted to do.

The language must never treat a claimed identity as a verified identity or assume that authentication grants unrestricted access.

2. Identity Types¶

The language should provide dedicated types for security identities.

Proposed types:

• UserIdentity
• ServiceIdentity
• SystemIdentity
• AnonymousIdentity

Rules: - Identity values must have a defined source. - Unverified identity claims must remain distinguishable from authenticated identities. - Identity types must not be interchangeable without explicit conversion. - Identity information must not be trusted merely because it was supplied by a caller. - Identity expiration and revocation must be supported where applicable.

3. Authentication¶

Authentication functions must establish identity through an explicitly defined mechanism.

Supported mechanisms may include: - Password authentication. - Multi-factor authentication. - Cryptographic keys. - Digital certificates. - OAuth and OpenID Connect. - Service-to-service authentication. - Platform-provided identity mechanisms.

Example:

FUNCTION authenticate(
    credentials: UntrustedCredentials
) -> Result<AuthenticatedIdentity, AuthenticationError>

    EFFECTS: NETWORK.CONNECT, NETWORK.RECEIVE
    FAILURES: InvalidCredentials, IdentityProviderUnavailable

END FUNCTION

Rules: - Authentication must return an explicit result. - Failed authentication must not produce an authenticated identity. - Credentials must not be logged or exposed through ordinary diagnostics. - Authentication mechanisms must use approved cryptographic implementations. - Authentication tokens must have documented expiration and validation rules.

4. Authorization¶

Authorization must be checked before protected operations are performed.

Example:

FUNCTION deleteAccount(
    identity: AuthenticatedIdentity,
    account: Account
) -> Result<Unit, AuthorizationError>

    REQUIRES: Authorization.permits(identity, "account.delete")
    EFFECTS: DATABASE.DELETE

END FUNCTION

Rules: - Permissions must be explicit. - Authorization must apply to the specific requested operation and resource. - Access must follow least-privilege principles. - Denied operations must fail explicitly. - Authorization must not be inferred from authentication alone. - Authorization checks must not be silently skipped.

5. Permission Models¶

The standard library should support established authorization models:

• Role-Based Access Control (RBAC).
• Attribute-Based Access Control (ABAC).
• Explicit capability-based authorization.

Rules: - Roles must not automatically grant unrelated permissions. - Permissions must be scoped to defined resources and operations. - Capability transfer must be explicit. - Permission inheritance must be documented. - Revocation behavior must be defined.

6. Authorization and State Changes¶

Authorization must remain valid for the protected operation.

Rules: - A successful check must not automatically authorize unrelated future operations. - Changes to identity, permissions, or resource ownership may invalidate prior authorization. - Sensitive state changes must be protected against time-of-check/time-of-use errors. - Authorization and execution should be performed within a security boundary that prevents unauthorized interference. - The language must not claim that a previous authorization check guarantees future authorization.

7. Secrets and Credentials¶

Sensitive authentication material must use dedicated secret-handling mechanisms.

Rules: - Secrets must not be hardcoded into source code. - Secrets must not appear in ordinary logs or diagnostic output. - Secret access must require explicit permissions. - Secret values must not be freely converted into ordinary strings. - Secret lifetime and cleanup must be documented. - Credential storage must use approved secure mechanisms.

8. Session and Token Management¶

Authentication sessions and tokens must have explicit lifecycle rules.

Rules: - Token expiration must be checked. - Token validation must include the required issuer, audience, signature, and other applicable claims. - Revocation behavior must be documented. - Refresh operations must return explicit results. - Expired or invalid tokens must not be accepted. - Tokens must not be treated as proof of authorization unless the relevant permissions are independently established.

9. Compiler and Runtime Responsibilities¶

The compiler and runtime must: - Distinguish authenticated and unauthenticated identities. - Enforce declared authentication and authorization requirements. - Prevent unauthorized access to protected operations. - Track permission and capability usage. - Protect sensitive values from ordinary logging. - Detect missing authorization checks where requirements declare them. - Report authorization failures explicitly.

10. Verification Limitations¶

The language cannot independently prove that an external identity provider is honest, that credentials have not been compromised, or that an organization's permission policy is appropriate.

Verification reports must distinguish: - Authentication mechanism declared. - Identity successfully authenticated. - Authorization policy evaluated. - Permission granted or denied. - Protected operation attempted. - Protected operation completed.

11. Design Goal¶

An AI agent must be able to determine who or what is requesting an operation, how that identity was established, what permissions apply, and whether the requested operation was authorized.

Identity must never be confused with permission, and permission must never be assumed from identity alone.

Source and related sections¶

Source file: TECHSPEC-30.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.