Skip to content

PHASE_7_ARCHITECTURE.md

Latest commit

 

History

History
533 lines (428 loc) · 25.5 KB

PHASE_7_ARCHITECTURE.md

File metadata and controls

533 lines (428 loc) · 25.5 KB
Raw

Phase 7 Architecture Contract — Human Confirmation

  • Status: Architecture contract; implementation not started
  • Baseline: RC0_FINAL_1
  • Frozen predecessor specification: PROTOCOL_PHASE_1_6_FINAL
  • Scope: Human confirmation semantics only

1. Purpose

Phase 7 adds a deterministic way for an authenticated human to confirm one already evaluated operation. Confirmation is additional Host-controlled evidence. It is not policy, Intent, Authorization, Consumption, or Execution.

This contract extends the frozen Phase 1–6 protocol. It does not amend or reinterpret any Phase 1–6 rule. In particular:

  • a Model cannot confirm;
  • a Policy Decision with outcome deny remains terminal;
  • requireConfirmation does not become allow;
  • an allow Decision remains insufficient to create Authorization;
  • Authorization remains controlled structural evidence;
  • Validation remains deterministic, pure, repeatable, and non-consuming;
  • successful atomic Consumption remains mandatory before a protected side effect; and
  • Execution remains Host-owned and outside SecureToolKit.

Phase 7 defines no API, user interface, wire representation, cryptography, trusted clock, storage, networking, audit persistence, Consumption facility, or Executor.

2. Terms

Confirmation Requirement: The immutable fact that the exact Policy Decision requires human confirmation before Authorization issuance can become eligible. It arises from either a requireConfirmation outcome or an exact retained requireConfirmation obligation. It grants no authority.

Confirmation Challenge Binding: The complete immutable pre-response binding of one Confirmation Requirement and every prospective operation value available before Host presentation and response collection. It contains no response or post-response state.

Confirmation Challenge: A controlled, immutable, safe-presentation source that contains one exact Confirmation Challenge Binding. It is an input to Host presentation, not a user interface and not authority.

Confirmation Authority: Host-controlled authority to attest that the exact authenticated subject made an affirmative confirmation for the exact Confirmation Challenge. It cannot be supplied by a Model, inferred from text, recovered from an artifact, or used to broaden scope.

Confirmation Artifact: Controlled, immutable evidence that the exact authenticated subject affirmatively confirmed one exact Confirmation Challenge within its explicit validity interval. It is necessary evidence for confirmed issuance but is not Authorization or permission to execute.

Confirmation Artifact Binding: The complete immutable post-response binding that contains the exact Confirmation Challenge Binding plus the exact Confirmation Identity, Confirmation Authority evidence, closed response value, confirmation time, and exclusive Confirmation expiry. It contains no issued Authorization or completed Authorization Consumption Binding.

Confirmation Identity: An exact Host-supplied correlation identity bound to one Confirmation Artifact. Equality is descriptive only. It does not prove authenticity, randomness, uniqueness, freshness, reservation, or single use.

Challenge Identity: An exact Host-supplied correlation identity for one Confirmation Challenge. It has the same non-authoritative properties as a Confirmation Identity.

Prospective Authorization Binding: The complete immutable set of values selected before confirmation that is sufficient to construct exactly one Phase 7 Authorization after an affirmative Confirmation Artifact exists. It includes all frozen issuance inputs and all prospective Authorization, replay, and Consumption parameters, but not the not-yet-created Confirmation Artifact or a recursively completed Authorization Consumption Binding.

Confirmed Issuance Eligibility: A transient deterministic result stating that the exact Confirmation Requirement is satisfied for one exact prospective Authorization. It is not a new Policy outcome, Authorization, or execution authority.

Confirmation Response: Exactly one closed value: affirmative or nonAffirmative. Only an explicit authenticated affirmative response to the exact Challenge Identity and complete Confirmation Challenge Binding can support a Confirmation Artifact.

3. Trust boundary

The Model may propose an operation and may cause policy to deny or require confirmation. It cannot create a Confirmation Requirement, Challenge, Confirmation Artifact, affirmative response, Confirmation Authority, or Confirmed Issuance Eligibility.

The human supplies an affirmative or non-affirmative choice through an authenticated Host path. The Host owns authentication and presentation and collection mechanisms. SecureToolKit's future Phase 7 core may validate exact structure and produce controlled evidence, but it does not authenticate a person or present a prompt.

For this phase, the confirmer MUST be the exact subject already bound through Security Context, User Intent, Evaluation Input, and Policy Decision. Approval by a different person, group, role, quorum, delegation workflow, or administrator is outside Phase 7.

Confirmation Authority MUST be retained independently by the Host and confined to the same opaque Host authority domain as the Evaluation Input. Descriptive identity equality cannot replace possession of the genuine Host-controlled authority. A parallel or reconstructed authority domain MUST reject.

Confirmation Authority is a distinct semantic Role Authority and fact class. It is not implied by Authentication Authority, successful login, possession of Security Context, Intent capture, policy administration, or generic Host trust. A Host profile MAY assign authentication and confirmation roles to one component only through explicit configuration. Even then, the roles and fact classes remain distinct, authentication alone produces no confirmation evidence, and Confirmation Authority cannot broaden the common entitlement ceiling.

Affirmation MUST NOT be inferred from silence, timeout, Challenge display or dismissal, a generic click or navigation, prior confirmation, prior activity, successful authentication, session continuation, Model output, unrelated Host state, or a default selection.

4. When confirmation is required

Confirmation is required when the exact Policy Decision:

  1. has outcome requireConfirmation; or
  2. has outcome allow and retains a requireConfirmation obligation.

Both paths derive the same Confirmation Requirement and use the same Challenge, Artifact, validation, and confirmed-issuance semantics. The two paths do not create different kinds or degrees of authority.

A deny outcome is never confirmable. Confirmation cannot override deny precedence, indeterminate evidence, missing policy, unsupported obligations, or any other failure.

The Policy Decision remains unchanged after confirmation. In particular, Phase 7 MUST NOT replace, relabel, or copy a requireConfirmation Decision as an allow Decision. Confirmed Issuance Eligibility records satisfaction of a separate precondition while retaining the exact original Decision.

An operation for which policy requires no confirmation does not acquire a Confirmation Artifact. Phase 7 does not make confirmation an alternate authority path for ordinary allow Decisions.

Every non-confirmation obligation remains independently enforced. An unsupported obligation remains fail closed and cannot be satisfied by confirmation.

5. Confirmation lifecycle

The exact construction order is linear and fail closed:

1. frozen Evaluation Input exists
2. exact original Policy Decision exists
3. Confirmation Requirement is derived
4. Prospective Authorization Binding is selected
5. Confirmation Challenge Binding is constructed
6. Confirmation Challenge is constructed
7. Host presents and collects an explicit response
8. Confirmation Authority constructs the affirmative Artifact Binding and Artifact
9. pure confirmation validation produces Confirmed Issuance Eligibility
10. confirmed issuer repeats every frozen issuance check
11. Phase 7 Authorization is constructed
12. final Phase 7 Authorization Consumption Binding is constructed
13. pure Phase 7 Authorization Validation independently reconstructs it
14. future Host atomic Consumption occurs
15. Host Execution may occur only after successful Consumption

An absent, unknown, malformed, indeterminate, unsupported, or timed-out response produces no Artifact. A nonAffirmative response is terminal for that Challenge and produces no affirmative Confirmation Artifact. Whether a future Host retains separate non-affirmative evidence is outside this architecture. There is no transition from any such state to Authorization.

A retry requires a new Challenge Identity, a distinct complete Confirmation Challenge Binding, and a new authenticated response. The new Challenge MAY reuse unchanged prospective operation content. Changed operation content always requires a new Challenge and affirmative human act.

Challenge creation, confirmation validation, and confirmed issuance perform no Consumption or Execution.

6. Complete non-circular bindings

6.1 Confirmation Challenge Binding

The complete pre-response Confirmation Challenge Binding MUST contain exact equality for:

  • Phase 7 semantic version and Challenge Identity;
  • exact Confirmation Requirement;
  • exact Host authority domain;
  • exact subject, tenant, session state, and optional delegation;
  • complete Security Context and User Intent;
  • complete Evaluation Input and explicit evaluation time;
  • complete Canonical Request and all transitive Tool, Tool Definition, Registry Snapshot, Schema, typed argument, canonicalization, Resource, Proposal Assessment, Provenance, and Influence state;
  • complete Policy Snapshot, unchanged original Policy Decision, reasons, and every retained obligation;
  • exact constrained and prospective effective Capability and Resource scope;
  • prospective Authorization identity, representation version, and renewal generation;
  • prospective issuance, expiry, maximum lifetime, and freshness state;
  • prospective replay and Consumption identities;
  • atomicSingleUseRequired;
  • inclusive Challenge issuance and exclusive Challenge expiry;
  • the closed response choices affirmative and nonAffirmative; and
  • any privacy-safe controlled presentation facts accepted by a future implementation contract.

The prospective operation values are owned through one exact Prospective Authorization Binding. The list above states its required transitive coverage; it does not create independently mutable duplicate fields. Any deliberately repeated comparison field MUST equal its controlling complete value exactly.

It MUST NOT contain Confirmation Identity, response-produced Confirmation Authority evidence, a response, confirmedAt, Confirmation expiry, Confirmation Artifact or eligibility, issued Authorization, or a completed Authorization Consumption Binding.

6.2 Confirmation Artifact Binding

The complete post-response Confirmation Artifact Binding MUST contain:

  • the exact complete Confirmation Challenge Binding;
  • Confirmation Identity;
  • exact Confirmation Authority evidence in the same Host domain;
  • exact closed response value;
  • inclusive confirmedAt time;
  • exclusive confirmationExpiresAt; and
  • any response-specific controlled evidence required by a future implementation contract.

An affirmative Confirmation Artifact MUST contain the exact affirmative token. The Artifact Binding MUST NOT contain an issued Authorization or completed Authorization Consumption Binding.

6.3 Final Phase 7 Authorization Consumption Binding

Only confirmed issuance, after successful confirmation validation, constructs the final Phase 7 Authorization Consumption Binding. It contains:

  • the complete frozen Phase 1–6 Authorization binding;
  • exact Confirmation Requirement;
  • exact complete Confirmation Challenge Binding;
  • exact complete affirmative Confirmation Artifact Binding;
  • exact continuity between prospective and issued Authorization state;
  • replay and Consumption identities and atomicSingleUseRequired; and
  • every other security-relevant confirmation value.

Complete typed structural equality applies throughout. Canonicalization-v1 bytes, identifiers, display content, or semantic equivalence cannot replace it. No Challenge value depends on post-response state; no Artifact depends on issued Authorization; and no pre-issuance value contains the completed Consumption Binding. The final binding contains the Artifact Binding, which does not contain the final binding, so no value directly or transitively contains itself.

7. Safe presentation boundary

The Confirmation Challenge Binding is the sole controlled source from which a Host may derive a human-facing description. Display output is non-authoritative, and presentation conformance is outside this architecture contract.

Display labels, summaries, localization, formatting, truncation, and ordering are non-authoritative and cannot replace complete structural binding. Model-supplied labels cannot become trusted presentation facts.

A future implementation contract MUST define a deterministic set of controlled presentation fields and minimum presentation-evidence requirements before any UI or Host presentation integration is implemented. This architecture selects no actual presentation fields.

The Confirmation Artifact MUST NOT retain raw prompts, documents, tool output, credentials, secrets, or raw argument values merely to prove confirmation. Privacy-safe typed summaries and exact structural references may be retained, but equality MUST be established from controlled typed values rather than display text.

Approval UX, accessibility rules, dialog layout, risk wording, and localization are explicitly outside this contract.

8. Freshness and time

All Phase 7 time values are explicit Host inputs using the frozen explicit-time representation. Phase 7 reads no ambient clock and claims no trusted time.

The following ordering MUST hold:

evaluationTime <= challengeIssuedAt <= confirmedAt <= authorizationIssuedAt
authorizationIssuedAt < authorizationExpiresAt
confirmedAt < confirmationExpiresAt
authorizationExpiresAt <= confirmationExpiresAt

The Challenge MUST also have a finite exclusive expiry. Challenge validity is evaluated at response collection: confirmation MUST occur at or after Challenge issuance and strictly before Challenge expiry. A Confirmation Artifact is valid at a supplied explicit time only at or after confirmedAt and before confirmationExpiresAt.

Once a valid affirmative Confirmation Artifact exists, later Challenge expiry does not by itself invalidate the Artifact or confirmed issuance. Confirmation validation verifies that confirmedAt was within the Challenge interval; it does not require the Challenge to remain live at later issuance or Authorization Validation. Confirmation expiry and Authorization expiry remain active at their respective later validation times. An expired Challenge accepts no new response and produces no new Artifact. Mutation of its Binding always invalidates the Artifact.

The Challenge and Confirmation intervals MUST NOT outlive any already bound Intent, Security Context, or applicable Host attestation. The prospective Authorization MUST NOT outlive the Confirmation interval. Existing maximum-evaluation-age and Authorization lifetime rules remain independently active and are rechecked without modification.

No new universal numeric duration is selected by this architecture contract. A future Phase 7 implementation contract MUST define a finite deterministic Protocol maximum before implementation. Until that bound is accepted, Phase 7 is not implementation-ready.

9. Invalidation

Confirmation validation MUST reject the complete result when any of the following occurs:

  • missing, unknown, unsupported, malformed, duplicated, or excessive content;
  • nonAffirmative, absent, unknown, malformed, indeterminate, unsupported, inferred, timed-out, or Model-originated response;
  • wrong subject, tenant, session, delegation, Confirmation Authority, or Host authority domain;
  • Challenge or Confirmation identity mismatch;
  • Challenge or Confirmation outside its explicit validity interval;
  • invalid time ordering or arithmetic;
  • mutation or substitution of any bound request, Tool, Tool Definition, Schema, Registry Snapshot, Proposal Assessment, subject, tenant, session, delegation, Intent, Security Context, Provenance, Influence, Policy Snapshot, Policy Decision, reason, obligation, Challenge content, or Artifact content;
  • Policy re-evaluation no longer producing the exact confirmation-requiring Decision;
  • Capability or Resource broadening, narrowing, substitution, or failure of exact recomputation;
  • prospective Authorization identity, representation version, renewal generation, issuance, expiry, maximum lifetime, freshness, replay identity, or Consumption identity mismatch; or
  • unavailable required confirmation validation.

Invalidation is structural and deterministic. Phase 7 defines no mutable withdrawal, revocation service, current-state lookup, or persistence. A Host may always refuse to proceed, but it cannot represent that operational refusal as a protocol revocation claim.

10. Replay and single-use semantics

A Confirmation Identity is correlation only. Validation of a Confirmation Artifact is pure and repeatable and MUST NOT mark it used.

One Confirmation Artifact Binding is bound to one exact Confirmation Challenge Binding and its Prospective Authorization Binding. It MUST NOT satisfy a different Authorization, a renewal, a changed request, or a second logical operation. Confirmed issuance includes the Artifact Binding when it constructs the complete Authorization Consumption Binding.

Repeated construction of structurally identical Authorization evidence does not create additional execution authority. The complete binding, including the Confirmation Artifact and its identities, MUST be included in the future atomic Consumption comparison. Only successful Host-owned atomic Consumption can enforce the single protected side effect under concurrency or restart.

Phase 7 introduces no replay database, reservation, used flag, uniqueness registry, or atomic transition. Without a conforming Consumption facility, protected Execution remains blocked exactly as required by the frozen protocol.

11. Relationship to Authorization

Confirmation is necessary but never sufficient for Authorization issuance. Phase 7 confirmed issuance MUST still perform every frozen issuance check:

  • exact Host boundary and authority;
  • exact Registry, Tool Definition, Schema, request, Proposal Assessment, Intent, context, Provenance, and Influence continuity;
  • exact Policy Snapshot and deterministic policy re-evaluation;
  • unchanged Decision equality and deny precedence;
  • exact intersection-only Capability and Resource recomputation;
  • satisfaction of every non-confirmation obligation;
  • exact lifetime and freshness checks; and
  • complete replay and Consumption Binding construction.

Confirmed issuance first rechecks confirmation eligibility and every frozen issuance requirement. It then constructs the Phase 7 Authorization and only then constructs the final non-circular Authorization Consumption Binding from the complete frozen binding and exact confirmation bindings. It removes no frozen check.

The Phase 6 Authorization representation and issuer semantics remain frozen. Phase 7 requires a distinct versioned semantic extension that retains the complete Phase 1–6 Authorization binding plus the complete Confirmation Challenge and Artifact Bindings. The concrete language type, initializer, API name, and any portable format are outside this architecture contract.

12. Relationship to Validation

Pure confirmation validation occurs before confirmed issuance. It MUST validate the complete Challenge and Artifact Bindings, exact response, authority/domain/ subject continuity, Challenge validity at confirmedAt, Confirmation validity at the supplied validation time, complete Prospective Authorization continuity, and every pre-issuance scope, time, policy, and identity field. It MUST NOT compare a completed final Authorization Consumption Binding because that value does not yet exist. Success produces only Confirmed Issuance Eligibility.

Later Phase 7 Authorization Validation remains pure, deterministic, repeatable, and non-consuming. In addition to every frozen independent expectation, the Host MUST supply independently retained expected Confirmation identities, authority domain, exact Challenge and Artifact Bindings, and explicit validation time.

Validation MUST NOT populate expectations from the Authorization or Confirmation Artifact under validation. It MUST re-evaluate policy, confirm the same confirmation requirement, compare the complete confirmation bindings, recheck time ordering and validity, and reconstruct the complete Authorization Consumption Binding including confirmation.

Successful Validation means only that the versioned Authorization and bound confirmation evidence exactly matched independent expectations at the supplied explicit time. It does not prove human identity independently of the Host, consume confirmation, consume Authorization, prevent replay, or permit Execution.

13. Relationship to Consumption and Execution

The Host remains the owner of Consumption and Execution. Phase 7 does not add a Consumption transition or Executor.

The future complete atomic Consumption key/value MUST distinguish every security-relevant Confirmation field in addition to the frozen Authorization Consumption Binding. Missing, mismatched, duplicate, failed, unavailable, or indeterminate Consumption blocks every protected side effect.

The only permitted sequence to a protected side effect is:

exact confirmation-requiring Decision
  + valid exact Confirmation Artifact
  + valid Phase 7 Authorization
  + successful pure Validation
  + successful Host atomic Consumption of the complete binding
  -> Host Execution of the exact validated request

No intermediate value is executable authority.

14. Determinism and failure model

Every Phase 7 core decision MUST be a deterministic function of explicit, immutable inputs. Unknown fields and unknown enum values fail closed. Missing Confirmation Authority, Requirement, Challenge, Artifact, binding, independent expectation, or explicit time rejects.

Failures MUST expose only stable privacy-safe reasons and closed field categories. They MUST NOT echo raw prompts, documents, tool output, raw argument values, credentials, secrets, rejected free-form values, or evidence payloads.

No failure may return partial confirmation, partial Authorization eligibility, or broadened authority. A denial or confirmation failure is explainable but not repairable through inferred defaults.

15. Required Phase 7 security properties

Any future implementation and conformance suite MUST demonstrate at least:

  1. Model-supplied or artifact-derived confirmation rejects.
  2. A deny Decision cannot be confirmed.
  3. Confirmation does not mutate requireConfirmation into allow.
  4. Wrong subject, Host domain, or Confirmation Authority rejects.
  5. Same-ID/different-content Challenge or Artifact substitution rejects.
  6. Mutation of any request, policy, Decision, scope, lifetime, replay, or Consumption field rejects.
  7. Capability or Resource broadening and narrowing both reject exact issuance.
  8. Challenge and Confirmation time boundaries are enforced deterministically.
  9. Existing evaluation-age, issuance-inclusive, and expiry-exclusive rules remain unchanged.
  10. Repeated confirmation validation returns the same result and does not consume.
  11. One Confirmation Artifact cannot bind a different Authorization or renewal.
  12. Successful confirmation alone cannot reach Execution.
  13. Missing or failed atomic Consumption blocks Execution.
  14. Privacy-safe failures reveal no prohibited raw content.
  15. Silence, timeout, authentication, default selection, and unrelated Host activity cannot create an affirmative Artifact.
  16. A timely Artifact remains usable after Challenge expiry while its own and every prospective validity constraint remain satisfied.

16. Explicit exclusions and readiness

This contract does not define:

  • confirmation APIs or Swift types;
  • presentation, collection, dialogs, or approval UX;
  • cryptographic authenticity or signatures;
  • trusted time or rollback resistance;
  • persistence, replay storage, or atomic Consumption;
  • revocation or withdrawal infrastructure;
  • audit events or audit persistence;
  • networking or wire formats;
  • an Executor or deployment profile; or
  • third-party, delegated, quorum, or multi-party approval.

Phase 7 implementation MUST NOT begin until a separate implementation contract accepts:

  • Phase 7 semantic and artifact versions;
  • identifier grammars and finite bounds;
  • separate maximum Challenge and Confirmation validity;
  • collection, nesting, and aggregate complexity bounds;
  • realization of the closed response vocabulary;
  • exact Challenge Binding, Artifact Binding, and Authorization-extension fields;
  • exact independent confirmation-validation context and 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 complete 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.

That future work may realize this architecture but cannot weaken the frozen Phase 1–6 semantics or add any excluded facility implicitly. No numeric value or API shape is selected here.