Web Authorization Protocol D. O. Watts Internet-Draft GoodShyt Group Inc. Intended status: Informational 11 October 2026 Expires: 14 April 2027 Non-Collapse Semantics for Authorization, Evidence, and Execution State draft-watts-authorization-noncollapse-semantics-00 Abstract Distributed authorization systems frequently combine observations, policy evaluations, evidence records, authorization decisions, and execution receipts. Treating these different objects as interchangeable can create fail-open behavior, stale-authority bugs, and false claims of completion. This document defines non-collapse semantics: explicit typed transitions between observation, evidence, authorization, and execution state; fail-closed treatment of missing or indeterminate premises; and comparison rules for determining when heterogeneous representations agree on a declared invariant. The document is informational and defines no new wire protocol. 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. Watts Expires 14 April 2027 [Page 1] Internet-Draft Authorization Non-Collapse Semantics October 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Typed State Model . . . . . . . . . . . . . . . . . . . . . . 3 3. Explicit Promotion . . . . . . . . . . . . . . . . . . . . . 3 4. Selection Semantics . . . . . . . . . . . . . . . . . . . . . 4 5. Invariant Agreement Across Representations . . . . . . . . . 4 5.1. Relation Types . . . . . . . . . . . . . . . . . . . . . 4 6. Authorization Examples . . . . . . . . . . . . . . . . . . . 5 7. Relationship to Existing IETF Work . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 11.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 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 Figure 1 This document defines a compact model for keeping these layers distinct while still allowing explicit promotion between them. Watts Expires 14 April 2027 [Page 2] Internet-Draft Authorization Non-Collapse Semantics October 2026 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. 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 Figure 2 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. Watts Expires 14 April 2027 [Page 3] Internet-Draft Authorization Non-Collapse Semantics October 2026 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. 5.1. Relation Types * STRICT_INVARIANT: the compared value is unchanged under the declared transformation. * COVARIANT: the value changes according to a declared transformation law. * QUOTIENT_EQUIVALENT: different representatives map to the same declared equivalence class. * TOLERANCE_EQUIVALENT: values agree only within a declared metric and tolerance. Watts Expires 14 April 2027 [Page 4] Internet-Draft Authorization Non-Collapse Semantics October 2026 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. Watts Expires 14 April 2027 [Page 5] Internet-Draft Authorization Non-Collapse Semantics October 2026 10. IANA Considerations This document has no IANA actions. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [I-D.liu-oauth-authorization-evidence] Liu, D., Zhu, H., Krishnan, S., and A. Parecki, "Authorization Evidence and Audit Trail for OAuth 2.0 Access Tokens", Work in Progress, Internet-Draft, draft- liu-oauth-authorization-evidence-01, June 2026, . [I-D.ietf-oauth-transaction-tokens] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-11, July 2026, . [I-D.ietf-wimse-aims] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf- wimse-aims-00, September 2026, . [I-D.watts-oauth-agent-revocation-closure] Watts, D., "Revocation Closure for Agentic Authorization Systems", Work in Progress, Internet-Draft, draft-watts- oauth-agent-revocation-closure-00, September 2026, . Watts Expires 14 April 2027 [Page 6] Internet-Draft Authorization Non-Collapse Semantics October 2026 Author's Address Deonté O’dell Watts GoodShyt Group Inc. San Francisco, CA United States of America Email: deonte@goodshyt.fun URI: https://orcid.org/0009-0005-8586-3650 Watts Expires 14 April 2027 [Page 7]