Non-Collapse Semantics for Authorization, Evidence, and Execution State

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 14 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Security protocols often cross several semantic layers. A sensor or log records an observation; software interprets that observation; a verifier may accept evidence; an authority component may issue permission; and a separate component executes an action. Operational failures occur when one layer is silently substituted for another.¶

observation != evidence != authorization != execution

This document defines a compact model for keeping these layers distinct while still allowing explicit promotion between them.¶

2. Typed State Model

Observation Record:

A measurement, log entry, status report, or externally visible event.¶

Interpretation Record:

A classification or conclusion derived from one or more observations.¶

Evidence Record:

An interpretation or observation accepted under a declared validation procedure for a defined purpose.¶

Authorization Decision:

A decision that a principal or workload may perform a scoped action under stated conditions.¶

Execution Receipt:

A record that an action was attempted, executed, or became externally effective.¶

These types are not interchangeable. A deployment MAY encode them using the same serialization syntax, but it MUST preserve their semantic roles and transition rules.¶

3. Explicit Promotion

A state at layer L_i does not automatically imply a state at L_i+1. Promotion requires an explicit rule P_i with declared inputs, validation criteria, authority, and resulting state.¶

Observation --P0--> Evidence --P1--> Authorization --P2--> Execution

If a required premise is false, the transition MUST fail. If no required premise is false but at least one required premise is unknown, unavailable, stale, or indeterminate, the transition MUST NOT be treated as successful.¶

4. Selection Semantics

A system selecting among authorized actions MUST distinguish an empty authorized set from a successful selection. If the authorized set is empty, the result is INFEASIBLE and no action is selected. If multiple actions are equally preferred and no deterministic or authorized tie-breaking rule exists, the result is TIE_REQUIRES_SELECTION_RULE and no action is selected.¶

"Do nothing" is not implicit authorization. A deployment that permits a no-op or defer action SHOULD model it explicitly.¶

5. Invariant Agreement Across Representations

Two records expressed in different units, coordinate systems, or protocol views can agree only after a declared bridge maps them into a common comparison space. Raw coordinate equality is not required; lawful correspondence is.¶

comparison = (
  source_a, source_b,
  comparison_space,
  projection_a, projection_b,
  metric, tolerance,
  unit_rule, snapshot_rule,
  uncertainty_rule
)

An empty required comparison set, a missing required representation, unaligned snapshots, or invalid uncertainty coverage is INDETERMINATE. A unit or comparison-space mismatch that violates the declared bridge is FAIL. Neither condition is PASS.¶

6. Authorization Examples

• A successful OAuth revocation request is an observation about request handling, not proof that all derived authority is closed.¶
• A valid signature proves integrity/authenticity properties of the signed object; it does not by itself prove freshness, authorization, or policy compliance.¶
• An authorization decision does not prove that the requested side effect actually executed.¶
• An execution receipt does not retroactively authorize an action that lacked valid authority.¶

7. Relationship to Existing IETF Work

[I-D.liu-oauth-authorization-evidence] defines authorization evidence for OAuth access tokens. [I-D.ietf-oauth-transaction-tokens] propagates identity and authorization context through call chains. [I-D.ietf-wimse-aims] distinguishes agent identity, credentials, authentication, authorization, and observability. The non-collapse model in this document is complementary: it focuses on the semantics of transitions among such states.¶

[I-D.watts-oauth-agent-revocation-closure] is a concrete application of this principle: REQUESTED, invalidated, enforced, and CLOSED are distinct states.¶

8. Security Considerations

Collapsing state types can create authorization bypasses and false assurances. A system that treats observation as authorization may allow untrusted telemetry to grant privilege. A system that treats request acknowledgement as execution evidence may claim work completed when it did not. A system that treats unknown required premises as true may fail open. Implementations SHOULD therefore retain typed state, provenance, freshness, and transition authority sufficient to reconstruct why a promotion occurred.¶

9. Privacy Considerations

Evidence and execution records can reveal sensitive identities, user actions, delegation relationships, and operational topology. Implementations SHOULD minimize retained fields and SHOULD avoid turning cross-system evidence identifiers into unnecessary global correlation identifiers.¶

10. IANA Considerations

This document has no IANA actions.¶

Author's Address