Outcome Binding for Authorized Actions and Independently Observed Effects
draft-schrock-ep-outcome-binding-00

Network Working Group                                         I. Schrock
Internet-Draft                                     EMILIA Protocol, Inc.
Intended status: Experimental                               28 July 2026
Expires: 29 January 2027

   Outcome Binding for Authorized Actions and Independently Observed
                                Effects
                  draft-schrock-ep-outcome-binding-00

Abstract

   Authorization proves what action was permitted; it does not prove
   what happened after execution.  An executor-signed result improves
   attribution but remains a claim by the party that acted.  This
   document specifies a source-routed Outcome Binding profile.  Signed
   predicted effects identify the source role and source class required
   to evaluate each predicate.  Executors, systems of record, and
   independent observers sign closed observation objects bound to the
   same authorization, action digest, Canonical Action Identifier,
   consumption nonce, operation, facility, and observation window.  A
   deterministic verifier separates evidence availability from
   comparison: missing or unauthenticated required sources yield an
   indeterminate lifecycle state; authentic observations yield the
   closed comparison result in_bounds, divergent, or incomparable.  The
   profile improves consequence reconciliation without claiming physical
   truth, sensor correctness, or legal finality.

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 29 January 2027.

Schrock                  Expires 29 January 2027                [Page 1]
Internet-Draft               Outcome Binding                   July 2026

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terms and State Separation  . . . . . . . . . . . . . . . . .   3
   3.  Source-Routed Predicted Effects . . . . . . . . . . . . . . .   3
   4.  Outcome Observation . . . . . . . . . . . . . . . . . . . . .   4
   5.  Relying-Party Source Policy . . . . . . . . . . . . . . . . .   6
   6.  Verification and Reconciliation . . . . . . . . . . . . . . .   6
   7.  Industrial Curtailment Profile  . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   8
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   11. Implementation Status . . . . . . . . . . . . . . . . . . . .   8
   12. Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   A valid authorization, an accepted dispatch, and an observed effect
   are different facts.  Treating a controller acknowledgment as proof
   of a physical outcome permits the actor that caused an effect to be
   its only witness.  Treating absent evidence as an unfavorable
   measurement similarly collapses uncertainty into a false result.

   This profile keeps those axes separate.  It extends the original
   executor-attestation comparison with independently pinned source
   roles, exact cross-source bindings, and an explicit indeterminate
   lifecycle.  Existing EP-OUTCOME-ATTESTATION-v1 objects remain valid
   and default to the executor source role.

Schrock                  Expires 29 January 2027                [Page 2]
Internet-Draft               Outcome Binding                   July 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, as shown here.

2.  Terms and State Separation

   Executor  The party that attempts the authorized effect.

   System of record  A source authoritative for a bounded digital state,
      but not necessarily independent of the executor.

   Independent observer  A separately pinned source whose canonical
      public key identity and relying-party-declared control domain
      differ from every source that performed or controlled the action,
      such as a revenue meter, telemetry provider, or external
      measurement service.  A declaration is policy input; it is not
      cryptographic proof of organizational or physical independence.

   Indeterminate  The lifecycle state used when required evidence is
      missing, unauthenticated, unpinned, or not exactly bound.  It is
      not a comparison outcome and MUST NOT authorize blind retry.

   Incomparable  A comparison result reached only after authentic, bound
      evidence exists but cannot be evaluated under the closed predicate
      language.

3.  Source-Routed Predicted Effects

   predicted_effects is a non-empty array covered by the authorization
   signature or an explicitly identified additive relying-party policy.
   Its digest is SHA-256 over JCS [RFC8785] bytes.  Every entry has
   effect_type, literal target, and a closed predicate.  An entry MAY
   also have required_source_role and required_source_class.  The role
   is one of executor, system_of_record, or independent_observer.  When
   omitted, the role defaults to executor for compatibility with EP-
   OUTCOME-ATTESTATION-v1.

Schrock                  Expires 29 January 2027                [Page 3]
Internet-Draft               Outcome Binding                   July 2026

   [
     { "effect_type": "controller_status",
       "target": "facility:plant-7",
       "required_source_role": "executor",
       "required_source_class": "cosa.actuator",
       "predicate": { "op": "eq", "value": "dispatched" } },
     { "effect_type": "delivered_mw",
       "target": "facility:plant-7",
       "required_source_role": "independent_observer",
       "required_source_class": "revenue_meter",
       "predicate": { "op": "gte", "value": "5.000" } }
   ]

   The closed predicate set is eq, lte, gte, range, set_eq, count_lte,
   and absent.  Comparison values are strings.  Targets are literal;
   wildcard semantics are not defined.  Unknown members, unknown
   operations, and numeric comparison operands MUST be refused.

4.  Outcome Observation

   EP-OUTCOME-OBSERVATION-v1 is a closed I-JSON [RFC7493] object signed
   with Ed25519 [RFC8032] under the domain string "EP-OUTCOME-
   OBSERVATION-v1" followed by a zero octet.  The signed body is:

Schrock                  Expires 29 January 2027                [Page 4]
Internet-Draft               Outcome Binding                   July 2026

   {
     "@version": "EP-OUTCOME-OBSERVATION-v1",
     "receipt_id": "ep:receipt:...",
     "receipt_digest": "sha256:...",
     "action_hash": "sha256:...",
     "action_caid": "caid:...",
     "consumption_nonce": "nonce:...",
     "operation_id": "operation:...",
     "source": {
       "role": "independent_observer",
       "source_id": "meter:plant-7",
       "source_class": "revenue_meter",
       "facility_id": "facility:plant-7"
     },
     "observed_from": "2026-07-28T17:00:00Z",
     "observed_until": "2026-07-28T17:05:00Z",
     "attested_at": "2026-07-28T17:05:01Z",
     "observed_effects": [
       { "effect_type": "delivered_mw",
         "target": "facility:plant-7", "value": "5.200" }
     ],
     "observed_effects_digest": "sha256:...",
     "proof": {
       "algorithm": "Ed25519",
       "key_id": "ep:outcome-source-key:sha256:...",
       "public_key": "...",
       "signature_b64u": "..."
     }
   }

   The verifier MUST pin source_id, public key, role, source_class,
   control_domain_id, status, valid_from, valid_to, and any required
   facility.  A compromised source pin MUST also carry compromised_at.
   The verifier MUST parse the pinned and presented keys as Ed25519
   SubjectPublicKeyInfo, compare their canonical DER encodings, and
   derive key identity from those bytes rather than from caller-provided
   key text or key_id.  It MUST verify observed_from is not after
   observed_until, observed_until is not after attested_at, and
   attested_at is not in the verifier's future.  A valid signature
   without an accepted, current pin is verified but not accepted.

Schrock                  Expires 29 January 2027                [Page 5]
Internet-Draft               Outcome Binding                   July 2026

5.  Relying-Party Source Policy

   The relying party supplies source requirements independently of the
   observation presenter.  A requirement selects a role and optional
   source class, sets min_distinct_sources, and selects one or both
   distinctness dimensions: key or control_domain.  It MAY further
   restrict accepted source identifiers. min_distinct_sources MUST be
   between 1 and 16.

   { "role": "independent_observer",
     "source_class": "revenue_meter",
     "min_distinct_sources": 2,
     "distinct_by": ["key", "control_domain"] }

   An independent_observer observation MUST use a canonical key identity
   and control_domain_id distinct from every accepted non-independent
   source, even when min_distinct_sources is one.  Re-encoding the same
   Ed25519 key MUST NOT create a distinct source.  Different keys under
   the same declared control domain MUST NOT satisfy independence or a
   control-domain quorum.

   The relying party MAY also supply an observation-window requirement
   by role and optional source class. relation is exact, within, or
   covers and compares observed_from and observed_until with the
   required not_before and not_after. max_attestation_delay_ms limits
   the interval from observed_until to attested_at and MUST NOT exceed
   86400000.  A presenter MUST NOT widen, replace, or select these
   requirements.

6.  Verification and Reconciliation

   1.  Verify the authorization under its native rules and recompute the
       predicted-effects commitment.

   2.  Verify every observation signature against the canonical Ed25519
       key in its source pin.  Refuse a source whose pin is malformed,
       compromised at or before attested_at, not yet valid, or expired
       at attested_at.  A retired key MAY verify a historical
       observation only when attested_at remains inside its pinned
       validity interval.

   3.  Require exact equality of receipt identifier and digest, action
       digest, optional CAID, consumption nonce, operation identifier,
       required facility, and source metadata.

   4.  Enforce independent-observer canonical-key and declared-control-
       domain separation from every accepted non-independent source.

Schrock                  Expires 29 January 2027                [Page 6]
Internet-Draft               Outcome Binding                   July 2026

   5.  Enforce every relying-party source quorum and observation-window
       requirement.  Missing, non-current, non-distinct, late, or
       window-mismatched evidence returns lifecycle_state=indeterminate
       and outcome=null.

   6.  Group predictions by required source role and class.  If any
       group lacks an accepted observation, return
       lifecycle_state=indeterminate and outcome=null.

   7.  Evaluate each group against only the matching accepted
       observations.  Aggregate with precedence divergent, then
       incomparable, then in_bounds.

   A reconciled in_bounds result MAY satisfy an additive reliance
   policy.  A divergent result MUST NOT be rewritten as success.  An
   incomparable result MUST NOT be treated as missing evidence.  An
   indeterminate state MUST enter authenticated reconciliation; it MUST
   NOT trigger blind replay of a potentially completed consequence.

7.  Industrial Curtailment Profile

   A grid-curtailment deployment SHOULD require at least two sources: an
   executor-class controller acknowledgment and an independent meter-
   class observation.  The controller statement establishes accepted
   dispatch, not delivered power.  The meter statement establishes what
   the pinned meter claimed over the bound interval, not market
   eligibility or tariff rules.  Baseline and settlement policy remain
   relying-party policy.

   Settlement MUST be downstream of reconciliation.  A controller pass
   with a divergent meter result is a reconciled divergence and MUST NOT
   settle.  An unavailable meter is indeterminate and MUST NOT settle or
   cause a blind redispatch.  Action State or another external evidence
   capsule MAY carry the result digest; such a carrier is not required
   for core verification.

8.  Security Considerations

   Independent means separately pinned with a distinct canonical key and
   a distinct relying-party-declared control domain.  A second key
   controlled by the executor is not independent, and control_domain_id
   alone does not prove otherwise.  Multiple sources can collude or
   share faulty inputs.  Sensors can be biased, replayed, or installed
   at the wrong boundary.  This profile proves signed claims and exact
   joins, not physical truth.  Deployments need calibration, key
   governance, custody, authenticated time, anti-replay state, and
   dispute procedures appropriate to the consequence.

Schrock                  Expires 29 January 2027                [Page 7]
Internet-Draft               Outcome Binding                   July 2026

   Source substitution, facility substitution, action substitution, CAID
   substitution, operation substitution, and window substitution MUST
   fail closed.  Result digests MUST cover lifecycle state, comparison
   outcome, checks, errors, input commitments, and source evaluations.

9.  Privacy Considerations

   Observations can expose facilities, operations, timing, and sensitive
   effects.  Implementations SHOULD minimize identifiers, keep raw
   telemetry outside portable artifacts, and disclose only commitments
   and bounded values necessary for the relying purpose.

10.  IANA Considerations

   This document has no IANA actions.

11.  Implementation Status

   An Apache-2.0 TypeScript reference implementation includes legacy
   executor-attestation compatibility, source-routed predictions, signed
   multi-source observations, exact binding checks, deterministic result
   digests, eight real-cryptography source-policy vectors, five hostile
   independence/freshness/window/quorum cases, eleven bounded
   obligations with deliberately weakened counterexamples, Model-to-
   Matter composition, and a synthetic GRACE controller-plus-meter
   settlement path.  The bounded model and implementation are same-team
   artifacts, not an unbounded proof or independent implementation.  The
   GRACE path is a reference simulation and is not evidence of a
   physical deployment, utility acceptance, meter certification, or
   partner endorsement.

12.  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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7493]  Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
              DOI 10.17487/RFC7493, March 2015,
              <https://www.rfc-editor.org/info/rfc7493>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

Schrock                  Expires 29 January 2027                [Page 8]
Internet-Draft               Outcome Binding                   July 2026

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.

Author's Address

   Iman Schrock
   EMILIA Protocol, Inc.
   United States of America
   Email: team@emiliaprotocol.ai

Schrock                  Expires 29 January 2027                [Page 9]