Skip to content

PHASE_7_DECISIONS.md

Latest commit

 

History

History
118 lines (107 loc) · 6.39 KB

PHASE_7_DECISIONS.md

File metadata and controls

118 lines (107 loc) · 6.39 KB
Raw

Phase 7 Decisions — Human Confirmation Architecture

  • Status: Architecture-only; implementation not started
  • Predecessor: PROTOCOL_PHASE_1_6_FINAL

Scope

Phase 7 adds human confirmation and nothing else. It introduces no Swift API, UI, wire format, cryptography, trusted time, persistence, networking, audit, Consumption implementation, Executor, or deployment behavior.

Decisions

  1. Confirmation is immutable Host-controlled evidence of one affirmative act by the exact authenticated subject over one exact confirmation-requiring operation.
  2. The Model cannot create or satisfy confirmation.
  3. Deny remains terminal and cannot be confirmed.
  4. Confirmation does not transform requireConfirmation into allow. The exact original Policy Decision remains bound unchanged.
  5. Confirmation Authority is independently retained by the Host in the same opaque Host authority domain as the Evaluation Input.
  6. Confirmation Authority is a distinct semantic Role Authority and fact class. Authentication, login, Security Context, Intent capture, policy administration, or generic Host trust does not imply it. One component may hold authentication and confirmation roles only by explicit configuration; the roles remain distinct and cannot broaden their common ceiling.
  7. Phase 7 supports only confirmation by the exact bound subject. Third-party, delegated, quorum, role, and administrator approval are outside scope.
  8. The response vocabulary is exactly affirmative and nonAffirmative. Only an explicit authenticated affirmative response to the exact Challenge and Binding can support an Artifact. Silence, timeout, display or dismissal, generic interaction, prior activity, authentication, session continuation, Model output, unrelated state, and defaults are never affirmative.
  9. A complete pre-response Confirmation Challenge Binding precedes the Challenge. It contains only frozen and prospective operation state available before presentation and response collection.
  10. A complete post-response Confirmation Artifact Binding contains the exact Challenge Binding, Confirmation Identity, distinct Confirmation Authority evidence, exact response, confirmedAt, and exclusive Confirmation expiry. It contains no issued Authorization or completed Consumption Binding.
  11. Prospective Authorization identity, scope, lifetime, replay identity, and Consumption identity are selected before and included in confirmation.
  12. Confirmation uses explicit Host-supplied time and finite exclusive expiry. It claims no trusted time.
  13. Challenge validity is evaluated at response collection. A timely affirmative Artifact remains eligible after later Challenge expiry, subject to its own expiry and every other prospective bound. An expired Challenge accepts no new response.
  14. Confirmation validation is pure, deterministic, repeatable, and non-consuming.
  15. A Confirmation Identity is correlation only and proves neither authenticity nor single use.
  16. One Confirmation Artifact Binding binds one exact Challenge Binding and prospective Authorization. Confirmed issuance constructs the complete non-recursive Consumption Binding only after successful confirmation validation. Any changed operation or renewal requires new confirmation.
  17. Phase 7 confirmed issuance adds confirmation checks to every frozen issuance check and removes none.
  18. Both policy triggers—outcome requireConfirmation, and outcome allow with an exact retained requireConfirmation obligation—derive the same Confirmation Requirement and use identical confirmation and issuance semantics. The original Decision remains unchanged; deny and indeterminate states remain ineligible; other obligations remain independently enforced.
  19. The frozen Phase 6 Authorization representation and issuer behavior remain unchanged. Phase 7 uses a distinct versioned semantic extension.
  20. Phase 7 Validation adds independent confirmation expectations while preserving every frozen Validation rule.
  21. Confirmation never substitutes for Authorization, Validation, atomic Consumption, or Execution.
  22. The Host continues to own atomic Consumption and Execution. Without successful atomic Consumption, protected Execution remains blocked.
  23. Structural invalidation is defined; mutable withdrawal, revocation, and current-state services are not.
  24. A nonAffirmative response is terminal for that Challenge. Timeout and invalid states produce no Artifact. Retry requires a new Challenge Identity and authenticated response; unchanged prospective content may be reused in a distinct complete Challenge Binding.
  25. Unknown, absent, unsupported, indeterminate, malformed, mismatched, expired, or unavailable confirmation state fails closed without partial authority.

Deferred implementation-contract decisions

Before implementation begins, a separate approved Phase 7 implementation contract must define:

  • Phase 7 semantic and artifact versions;
  • identifier grammars and finite bounds;
  • separate maximum Challenge validity;
  • separate maximum Confirmation validity;
  • collection, nesting, and aggregate complexity bounds;
  • closed response-vocabulary realization;
  • exact Confirmation Challenge Binding fields;
  • exact Confirmation Artifact Binding fields;
  • exact Phase 7 Authorization-extension fields;
  • exact independent confirmation-validation context;
  • exact Phase 7 Authorization Validation Context additions;
  • controlled construction boundaries and semantic roles;
  • duplicate and deterministic ordering rules;
  • privacy-safe stable reasons and safe-field categories;
  • the exact negative conformance matrix;
  • compatibility and migration behavior;
  • source/API access-control realization without making Swift normative; and
  • a deterministic presentation-field contract before presentation integration.

These are deliberately not selected here because this task defines architecture semantics only and forbids API or implementation design.

Frozen rules reaffirmed

  • Authorization is evidence, not execution.
  • Allow is not Authorization.
  • Validation is pure and non-consuming.
  • Consumption remains mandatory before every protected side effect.
  • Authority is intersection-only and cannot broaden.
  • Complete structural equality outranks identifier or canonical-byte equality.
  • Host owns authentication, Consumption, and Execution.
  • The Model never gains authority.