GRACE: Evidence-Bound Grid Curtailment Admission, Observation, and Single-Use Settlement

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 22 February 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

A curtailment instruction can cross several administrative and technical boundaries before it changes electrical load. Authentication of the dispatcher alone does not answer whether the exact event fit a customer-approved participation envelope, whether the required people approved it, whether the executor admitted it only once, or whether later measurement refers to the same action.¶

GRACE keeps those questions separate. It defines an exact action, a bounded envelope, pre-dispatch authorization and admission checks, separately authenticated execution and measurement claims, outcome reconciliation, and single-use settlement admission. Each relying party selects and pins its own issuers, keys, policies, adapters, clocks, and state stores.¶

The profile does not define a demand-response tariff, a baseline methodology, a physical meter, a scheduler, or a payment rail. Those systems remain authoritative for their own claims. GRACE binds their signed inputs to one action and records the result of deterministic verification.¶

2. Terminology and Roles

Participation Envelope

A customer-approved, finite set of power, energy, count, duration, notice, and time-window bounds. The current profile identifier is EP-FLEX-ENVELOPE-v2.¶

Curtailment Action

The closed EP-GRACE-CURTAILMENT-ACTION-v1 object that identifies one requested power-reduction event.¶

Admission

The executor-side decision that the exact action may enter effect custody once. Admission is not evidence that the effect occurred.¶

Actuator

The deployment-pinned adapter that attempts the physical or scheduler operation and signs an acknowledgment.¶

Meter

A separately pinned observation source. A meter statement is a signed source claim, not proof of physical truth or calibration.¶

Settlement Effect

A deployment-supplied downstream operation invoked only after the required evidence reconciles. GRACE controls at-most-one invocation attempt for one entitlement key. It does not define or prove payment.¶

3. Trust and Deployment Inputs

A conforming deployment MUST independently configure the accepted action and envelope versions, approver roster and threshold, WebAuthn relying-party identifier and origins, actuator and meter keys, source roles and control-domain identifiers, validity and freshness policy, Action State signing key, execution store, settlement store, and settlement adapter. Presenter-supplied trust anchors or policy values MUST NOT influence acceptance.¶

Every protected effect path for which a deployment claims GRACE enforcement MUST pass through the same admission boundary. An implementation that can be bypassed may still emit evidence, but it MUST NOT claim complete enforcement.¶

4. Curtailment Action

The action MUST be a closed JSON object [RFC8259] that can be serialized with JCS [RFC8785]. Unknown, duplicated, missing, or non-canonicalizable members are a refusal. Its required members are:¶

{
  "@version": "EP-GRACE-CURTAILMENT-ACTION-v1",
  "action_id": "grace:event:...",
  "action_type": "grid.curtailment",
  "effect_class": "power_reduction",
  "facility": "facility:...",
  "target_delta_kw": "18000",
  "window": {
    "not_before": "2026-07-15T20:15:00.000Z",
    "not_after": "2026-07-15T21:45:00.000Z"
  },
  "issued_at": "2026-07-15T20:00:00.000Z",
  "expires_at": "2026-07-15T21:45:00.000Z",
  "baseline_method_hash": "sha256:...",
  "control_mode": "human_on_the_loop",
  "envelope_id": "grace:envelope:...",
  "requested_by": "ep:agent:grid-coordinator"
}

target_delta_kw MUST be a positive decimal string with at most three fractional digits. Timestamps MUST be UTC RFC 3339 timestamps with millisecond precision. issued_at MUST precede window.not_before. expires_at MUST equal window.not_after. control_mode is either human_on_the_loop or human_in_the_loop. The baseline-method digest commits to the program-selected method; it does not validate that method.¶

The verifier MUST derive the action digest and CAID [EP-CAID] from the exact controlled-action projection. A supplied identifier MUST NOT replace that derivation.¶

5. Participation Envelope and Containment

The action names one EP-FLEX-ENVELOPE-v2 envelope. The relying party MUST obtain that envelope from its pinned authority and MUST verify that it applies to the facility, program, and evaluation time. The bounds object contains positive max_event_mw, max_period_mwh, max_events, max_event_hours, min_notice_minutes, and a participation window.¶

Before dispatch, the executor MUST compare power with power, energy with energy, count with count, and duration with duration. The action's MW cannot exceed max_event_mw. Its MW multiplied by window duration cannot exceed the remaining period MWh budget. One more event and its duration must fit the remaining event and event-hour budgets. Its notice and window must fit the envelope.¶

A required bound or present spent-accounting value that is missing, negative, or unparseable is a refusal. An omitted spent value asserts zero prior settled usage; deployments that cannot make that assertion MUST return indeterminate rather than use zero.¶

6. Human Authorization

The relying party selects an ordered approver roster and a threshold using the action-bound authorization evidence in [EP-RECEIPTS]. Each accepted approval MUST be a Class-A WebAuthn [WEBAUTHN] signoff over a context that binds the controlled action digest, presentation digest, policy digest, initiator, approver, roster index, threshold, validity window, relying-party profile, app, platform, credential, and device key.¶

The verifier MUST require user verification, the pinned relying-party identifier and origin, distinct approvers, distinct device and credential identifiers, initiator exclusion, the exact roster index, and the selected threshold. The quorum semantics are those of [EP-QUORUM]. A valid signature that does not match the relying party's current roster, policy, action, presentation, or ceremony window is a refusal.¶

7. Executor Admission and Refusal Semantics

The executor applies the Action Evidence Boundary [EP-AEB] in this order:¶

1. Validate the closed action and require it to be active.¶
2. Derive and verify action-to-envelope containment.¶
3. Derive the expected outcome policy and require its digest to be inside the human-approved policy bytes.¶
4. Verify the human authorization against the pinned profile.¶
5. Require the pinned actuator, meter, Action State signer, execution store, settlement store, and settlement adapter.¶
6. Atomically reserve the exact execution idempotency key before invoking the actuator.¶

The execution idempotency key MUST bind the action identifier and action digest. The shared store MUST be durable, atomic, and ownership-fenced. Concurrent reservation failure is refuse_replay. Storage unavailability is a refusal before invocation.¶

If invocation begins and the result is lost, malformed, or raises an exception, the executor MUST return execution_indeterminate, preserve or burn the reservation, set retry_safe to false, and MUST NOT blindly invoke the effect again. Authenticated reconciliation is required.¶

Pre-invocation failures use a mechanism-named refusal such as refuse_action, refuse_action_not_active, refuse_outside_envelope, refuse_outcome_policy, refuse_authorization, or refuse_adapter_unavailable. Post-invocation evidence failures use effect_unconfirmed and are not retry authorization.¶

8. Dispatch Acknowledgment

The dispatch request binds the complete action, action digest, envelope digest, human-authorization digest, idempotency key, and operator. The actuator acknowledgment MUST bind the event identifier, action digest, dispatch-request digest, idempotency key, actuator identity, status, and dispatch time, and MUST verify under the pinned actuator key.¶

An accepted acknowledgment is the actuator's authenticated claim that it dispatched the request. It is not independent measurement and does not establish that electrical load changed.¶

9. Meter Statement and Compliance Computation

The meter statement MUST bind the meter identifier, event identifier, action digest, exact action window, unit, baseline MW, ordered sequence of timestamped load intervals, measurement class, observation time, and signer key identifier. It MUST verify under a separately pinned meter key.¶

The meter statement MUST NOT contain baseline_method_hash. Program and tariff rules remain in the authorized action and relying-party policy. This separates a signed measurement-source claim from the rule used to interpret it.¶

The reference computation subtracts average interval load from the signed baseline MW, divides the delivered MW by ordered MW, and marks the event compliant at a profile-selected threshold. A deployment MUST pin the computation and threshold it uses. The result states what follows from the accepted inputs. It does not prove the baseline was economically correct, the readings were physically true, or the event qualifies under a tariff.¶

10. Outcome Binding

The action's human-approved policy binds source-routed predictions for an executor observation and an independent-observer meter observation. Each Outcome Observation [EP-OUTCOME] MUST bind the authorization record, action digest, CAID, consumption nonce, operation identifier, facility, observation window, source role, source class, and observed effect.¶

The relying party MUST pin source keys, roles, classes, control domains, status and validity, distinctness requirements, observation windows, and maximum attestation delay. A declared control domain is relying-party policy input, not proof of organizational independence.¶

Settlement admission requires a reconciled outcome with the profile-selected in-bounds result. Missing, stale, invalid, wrong-window, same-domain, or otherwise insufficient observations produce effect_unconfirmed. They MUST NOT be converted to success, failure, or retry authorization.¶

11. Action State Signed Statement

After outcome reconciliation, the profile emits a COSE_Sign1 [RFC9052] Action State Signed Statement using [ACTION-STATE] format version 2 and media type application/agent-action-capsule+json. The statement binds the action, operator, developer, authorization digest, dispatch-request digest, meter digest, constraints evaluated, disposition, and confirmed effect.¶

The capsule identifier is derived from canonical capsule bytes. The JSON wrapper, COSE payload, protected headers, key identifier, and statement digest MUST cross-check. The current reference output is an unregistered_signed_statement. It is not a SCITT transparency-service registration or proof of ledger inclusion.¶

12. Single-Use Settlement Admission

The one-time entitlement key is the injective serialization of [envelope_id, event_id, meter_payload_digest] under profile EP-GRACE-SETTLE-v1. Every member is required. The meter digest MUST be a lowercase SHA-256 digest of the accepted signed meter body.¶

Only a compliant computation and an in-bounds reconciled outcome may reach the settlement adapter. The settlement store MUST reserve the entitlement atomically before invocation. A duplicate is settlement_already_consumed. If invocation begins and its result is unknown, the implementation MUST commit or preserve the reservation and MUST NOT issue another settlement attempt under the same entitlement.¶

This is at-most-one admission to the configured settlement effect in one authoritative state domain. It is not exactly-once physical payment, global double-spend prevention across independent authorities, tariff eligibility, or evidence that funds moved.¶

13. Proof-of-Curtailment Bundle

The EP-GRACE-PROOF-OF-CURTAILMENT-v1 bundle is a signed, offline-verifiable summary. It binds the action and action digest, envelope digest, baseline-method digest, authorization digest, dispatch-request digest, actuator-acknowledgment digest, meter-payload digest, Outcome Binding result digest and outcome, deterministic compliance result, Action State statement digest, and settlement admission result.¶

Bundle verification establishes integrity and binding relative to the verifier's pinned trust and policy inputs. It does not independently establish any source claim as real-world truth.¶

14. Artifact Signature Profiles

The baseline profile signs canonical artifact bytes with Ed25519. The optional EP-GRACE-ARTIFACT-SIGNATURE-v2 profile uses a fixed required algorithm list, in order: Ed25519 and ML-DSA-65 [FIPS204]. Its signing bytes commit to the complete artifact and the required algorithm list.¶

A v2 verifier MUST require exactly one signature under each independently pinned key and MUST accept only when both signatures verify. Missing algorithms, reordered or narrowed requirements, key substitution, malformed signatures, or an unavailable ML-DSA verifier are refusals. A v1 verifier MUST NOT silently accept a v2 artifact.¶

Hybrid signing provides cryptographic migration evidence. It does not make a software-held key hardware-backed, FIPS validated, deployed, or operationally independent. A deployment claiming the hybrid profile MUST identify and protect both actual signing keys.¶

15. Privacy Considerations

Curtailment records can reveal facility identity, capacity, operating schedules, energy consumption, human approvers, device identifiers, and commercial program terms. Implementations SHOULD minimize portable fields, disclose raw intervals only to parties that require them, use digests when independent recomputation is not required, and apply retention and access policies appropriate to critical-infrastructure data.¶

Selective disclosure or encryption cannot repair an overbroad signed source object. Deployments SHOULD separate public verification material from restricted operational evidence and preserve enough binding information to detect substitution.¶

16. Security Considerations

The principal attacks are action substitution, envelope overflow, stale approval, initiator self-approval, duplicate approvers, dispatch replay, lost acknowledgment, actuator-key substitution, meter-key substitution, market-rule smuggling into meter data, observation-source collapse, wrapper substitution, signature-leg stripping, and duplicate settlement admission. The preceding sections require fail-closed checks for each.¶

Key compromise remains a trust-root failure. Historical signatures can establish what a key signed; they do not prove who controlled the key or that the signed claim was true. A separately keyed meter under the same operator's control may improve fault isolation but does not create organizational independence.¶

GRACE cannot prove that the selected baseline is fair, a meter is calibrated or untampered, a scheduler has no bypass, a declared control domain is honest, a payment rail moved funds, or an authority's upstream population is complete. Deployment claims MUST state those acceptance roots.¶

17. Implementation Status

This section records implementation evidence and may be removed before publication as an RFC.¶

The public EMILIA repository [GRACE-IMPLEMENTATION] contains a TypeScript reference circuit for exact action construction, two distinct Class-A approvals, bounded admission, a COSA-labeled simulated actuator, a separately keyed simulated meter, Outcome Binding, an Action State Signed Statement, and one-time settlement admission. The adapters are marked simulation: true. The circuit is not evidence of a physical grid event, production COSA integration, utility adoption, meter truth, or an actual payment.¶

At the repository revision identified in the companion validation record, 80 targeted tests pass across four files. They cover the curtailment and mobile-grid state machines, production route boundary, and an 11-case Ed25519 plus ML-DSA-65 hostile signature matrix. Six declared vertical vectors [GRACE-VECTORS] cover the accepted path and refusals for missing independent outcome signature, self-approval, inactive action, replay, and meter-rule smuggling. These are same-team reference results, not an independent implementation or interoperability claim.¶

18. IANA Considerations

This document has no IANA actions. The grid.curtailment and EP-GRACE-* identifiers are profile-local strings and are not entries in an IANA registry.¶

Authors' Addresses