Skip to content

authz: bind AuthorizationDecision issuance to governed evaluation #169

Description

@seonghobae

Problem

Fresh review of PR #65 after the policy/request constructor-provenance repair found a separate authority-minting gap in the final authorization evidence. AuthorizationDecision remained publicly constructible with allowed=True and otherwise valid fields. Its constructor validated and registered that object in the same issuance registry used by evaluator-produced decisions, while downstream People persistence treats an exact AuthorizationDecision as authorization evidence. A consumer could therefore mint a structurally immutable allow result without running evaluate_purpose_bound_access.

This is distinct from #168. #168 protects policy/request objects from post-construction mutation, reinitialization side effects and constructor-hook bypass; this issue binds the final decision issuance itself to the canonical policy evaluator.

Test-first repair in #65

  • RED 269b52141969c699646cdacdfe9d2ed93630e04e proves direct construction of a semantically valid allow decision must fail while public purpose-bound evaluation must still issue a valid allow result.
  • Production fix ffdf141e2336e0fdba320e620fadb19d39b1a313 adds a module-owned decision issuance lifecycle. AuthorizationDecision.__init__ refuses first issuance unless _decision(...) allocated that exact object inside purpose-bound evaluation. The temporary issuance state is cleared in finally; already-issued decisions remain non-reinitializable; low-level unissued objects remain unreadable.
  • Successor package and People test commits remove direct authority construction from valid/deny/wrong-target fixtures. Tests obtain real authorization evidence through evaluate_purpose_bound_access, while malformed decision-shape branches are covered through the pure internal snapshot validator without minting authority.
  • 2351bd0c2b7ac9634bfd9e47601c8fbbb73402d8 doctors docs/TRACEABILITY.md to record evaluator-only decision issuance.
  • b75fb41243ec71076fb2dcbd360ab55150398515 reseals the deterministic foundation manifest to the updated TRACEABILITY SHA-256/byte/line tuple rather than weakening repository validation.

Acceptance

Keep this issue open. Current canonical #65 head is b75fb41243ec71076fb2dcbd360ab55150398515 on protected develop@ef1b143368cb6249c9520ca8cae10ebe844a5aa1. Require fresh terminal exact-head Keyverse package, People API, security/repository-integrity evidence at the repository's owned 100% statement/branch contract and independent current-head review before ordinary protected integration. Predecessor workflow/review evidence does not transfer across these issuance-provenance commits.

Do not copy this source into #163/#165 or treat the mutable #65 branch as a released dependency. #65 remains the canonical authorization owner; descendants adopt only protected truth through non-force integration.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions