Illustrative Codes Are Not a Namespace: Registries for Execution-Finality Consequence Classes, Sink Types, Act Types, Failure Codes, Profiles, and Media Types
draft-das-ef-registries-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-09-29 (Latest revision 2026-09-16) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Before Comparing Meta Muse / Sentinel, Read the Earlier DAS Disclosures: An AI-Assisted Primary-Source Technical Guide — Zenodo
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-ef-registries-01
Individual Submission S. Das
Internet-Draft Independent
Intended status: Informational 16 September 2026
Expires: 20 March 2027
Illustrative Codes Are Not a Namespace: Registries for Execution-
Finality Consequence Classes, Sink Types, Act Types, Failure Codes,
Profiles, and Media Types
draft-das-ef-registries-01
Abstract
The execution-finality family uses a shared vocabulary: Candidate
Act, Execution Handle, Finality Sink, consume, and Finality Receipt
[DAS-HANDLE] [DAS-PROTOCOL]. Each profile currently invents
overlapping labels for the same ideas — FINANCIAL, SETTLEMENT, EF-
005, SINGLE_USE — and then states that the codes are illustrative and
not IANA assignments. Two implementations can therefore emit the
same token string with different meaning, or different strings for
the same deny reason.
Existing IANA registries already name adjacent objects. JWT and CWT
claim names [RFC7519] [RFC8392], OAuth parameters [RFC6749]
[RFC7591], HTTP problem types [RFC9457], media types, RATS EAT
claims, and SCITT statement types [RFC9943] solve identity, token,
and transparency naming. They do not allocate consequence class,
sink type, act type, handle reuse policy, execution-finality failure
code, or finality-profile identifiers.
This document proposes those registries and an initial allocation
drawn from the family drafts. It does not decide which acts should
be authorized. It does not replace OAuth error codes, HTTP status
codes, or application problem types. A registered code is a shared
name for a machine-readable condition; it is not a legal
classification and not evidence that any named product implements the
condition.
Until IANA action occurs, codes in this document and in companion
drafts remain provisional. Implementations MUST treat foreign
namespaces as distinct. Criticism of the registry split, the initial
code list, the registration policy, and the claim that a new
namespace is required at all is explicitly invited.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Das Expires 20 March 2027 [Page 1]
Internet-Draft EF Registries September 2026
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 20 March 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. What This Version (-01) Contains . . . . . . . . . . . . . . 3
1.1. Contents of -01 . . . . . . . . . . . . . . . . . . . . . 3
1.2. Changes from -00 . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Vulnerability: The Same String, Two Meanings . . . . . . 4
2.2. Existing Mechanisms Already Name Adjacent Objects . . . . 5
2.3. Why the Residual Gap Can Remain . . . . . . . . . . . . . 5
2.4. What This Document Introduces . . . . . . . . . . . . . . 5
3. Conventions and Requirements Language . . . . . . . . . . . . 6
4. Direct Question: What Problem Does a Registry Solve? . . . . 6
5. Motivating Scenario: One Agent, Three Sinks, Three
Dialects . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Design Goals and Non-Goals . . . . . . . . . . . . . . . . . 7
7. Existing Registries and the Proposed Delta . . . . . . . . . 7
8. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Namespace Rules . . . . . . . . . . . . . . . . . . . . . . . 8
10. Where Registry Values Appear . . . . . . . . . . . . . . . . 8
11. Consequence Class Registry . . . . . . . . . . . . . . . . . 9
12. Sink Type Registry . . . . . . . . . . . . . . . . . . . . . 11
13. Act Type Registry . . . . . . . . . . . . . . . . . . . . . . 11
Das Expires 20 March 2027 [Page 2]
Internet-Draft EF Registries September 2026
14. Reuse Policy Registry . . . . . . . . . . . . . . . . . . . . 12
15. Decision and Consume-Outcome Registries . . . . . . . . . . . 13
16. Failure Code Registry . . . . . . . . . . . . . . . . . . . . 13
17. Profile Identifier Registry . . . . . . . . . . . . . . . . . 15
18. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 15
19. Optional JWT / CWT Claim Names . . . . . . . . . . . . . . . 16
20. Optional HTTP Authentication Scheme . . . . . . . . . . . . . 16
21. Mapping to Existing Error Channels . . . . . . . . . . . . . 16
22. Formal Consistency Rules . . . . . . . . . . . . . . . . . . 17
23. Hash Function and Formal Tools . . . . . . . . . . . . . . . 18
24. Registration State Machine . . . . . . . . . . . . . . . . . 19
25. Illustrative Pseudocode . . . . . . . . . . . . . . . . . . . 19
25.1. Validate Registry Fields on a CAD . . . . . . . . . . . 19
25.2. Emit a Registered Reason Code . . . . . . . . . . . . . 19
25.3. Map to HTTP Problem Details . . . . . . . . . . . . . . 20
26. Proposed Registration Policy . . . . . . . . . . . . . . . . 20
27. Industrial Relevance and Public-Roadmap Alignment . . . . . . 21
28. Questions to the IETF Community . . . . . . . . . . . . . . . 21
29. Potential IETF Discussion Venues . . . . . . . . . . . . . . 22
29.1. DISPATCH . . . . . . . . . . . . . . . . . . . . . . . . 22
29.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . 22
29.3. HTTPAPI . . . . . . . . . . . . . . . . . . . . . . . . 22
29.4. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 22
29.5. SCITT . . . . . . . . . . . . . . . . . . . . . . . . . 22
29.6. WIMSE . . . . . . . . . . . . . . . . . . . . . . . . . 23
29.7. SAAG . . . . . . . . . . . . . . . . . . . . . . . . . . 23
29.8. No Presumed Home . . . . . . . . . . . . . . . . . . . . 23
30. Relationship to Other Execution-Finality Internet-Drafts . . 23
31. Security Considerations . . . . . . . . . . . . . . . . . . . 23
32. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
33. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
34. Criticism, Corrections, and Review Invited . . . . . . . . . 25
35. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 25
36. Normative References . . . . . . . . . . . . . . . . . . . . 25
37. Informative References . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27
1. What This Version (-01) Contains
This Internet-Draft is draft-das-ef-registries-01. It proposes the
shared namespaces used by [DAS-HANDLE] and [DAS-COMPOSITE]:
consequence class, sink type, act type, reuse policy, decision,
consume outcome, failure codes, profile identifiers, and candidate
media types. It does not request IANA action in this revision.
1.1. Contents of -01
Das Expires 20 March 2027 [Page 3]
Internet-Draft EF Registries September 2026
* Problem of uncoordinated "illustrative" codes and the residual gap
after JWT, OAuth errors, and RFC 9457.
* Initial tables for classes, sinks, act types, reuse policies,
decisions, consume outcomes, EF-nnn codes, and profiles.
* Placeholder warning for urn:ietf:params:ef and the ef URI scheme.
* Unknown public EF-nnn fails closed as EF-080 (intentional forward
compatibility).
* WellTyped identities, hash/algorithm pointer to the handle draft,
and formal-tool note.
* Industrial disclaimer, community questions, and per-WG venue
subsections.
1.2. Changes from -00
* Document name and series info updated to -01.
* PURPOSE / JURISDICTION / REVOCATION codes moved into 060-069 as
EF-060, EF-061, EF-062.
* Added EF-047 PARTIAL_COMMIT; EF-044 remains PATH_INCOMPLETE.
* Decision registry now includes PREPARED, ABORTED, COMPENSATING,
CONTAINED, UNKNOWN.
* Consume outcomes now include RELEASED.
* ENVELOPE identical replay default documented as forbidden.
* Family reference titles aligned; handle and composite cited as
-01.
2. Introduction
2.1. Vulnerability: The Same String, Two Meanings
A sink that returns EF-005 and a second sink that returns
AUTHORITY_ALREADY_USED may intend the same event. A third sink may
use EF-005 for expired handles. A CAD that labels an act
consequence_class=PHYSICAL may mean coil motion in one profile and
printer dispatch in another. Without a shared namespace, verify/
consume receipts cannot be compared across vendors or across drafts
in the same family.
Das Expires 20 March 2027 [Page 4]
Internet-Draft EF Registries September 2026
Sink A receipt: reason_code = EF-005
Sink B receipt: reason_code = EF-005
Observer:
same code
!=
same predicate
Until a registry binds EF-005 to one definition,
the receipt is local dialect, not an interoperable object.
Figure 1: Uncoordinated codes prevent receipt comparison
2.2. Existing Mechanisms Already Name Adjacent Objects
OAuth defines error members such as invalid_grant [RFC6749]. HTTP
Problem Details defines a type URI for API errors [RFC9457]. JWT and
CWT have claim-name registries [RFC7519] [RFC8392]. CoAP and HTTP
have status codes. RATS/EAT and SCITT have their own typed
statements.
Those registries should be reused where the object really is an OAuth
error, an HTTP problem, or a JWT claim. This document exists only
for names that those registries do not currently define: consequence
class, sink type, act type, reuse policy, execution-finality failure
code, finality profile id, and compact media types for CAD / handle /
receipt.
2.3. Why the Residual Gap Can Remain
Companion drafts keep writing "illustrative, not IANA." That
sentence is honest and also the interoperability failure. Profile
catalogues for 6G, enterprise AI, CVID, silicon, and satellites
multiply local enums. A handle implementation cannot declare which
foreign codes it understands.
2.4. What This Document Introduces
* A small set of IANA-facing registries with Expert Review as the
default policy.
* An initial allocation aligned with [DAS-HANDLE] and other family
drafts.
* A rule that unregistered codes MUST use a private prefix or a URI,
not the EF- numeric space.
Das Expires 20 March 2027 [Page 5]
Internet-Draft EF Registries September 2026
* Media type and optional JWT/CWT claim names for the handle
objects.
* An explicit non-goal: this is not a policy ontology of all
possible real-world effects.
3. Conventions and 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.
4. Direct Question: What Problem Does a Registry Solve?
If two Finality Sinks emit receipts for the same denied effect, what
shared identifiers let a relying party know they denied the same
class of failure?
Receipt_A.reason_code == Receipt_B.reason_code
AND
both codes are in the EF Failure Code registry
==>
same registered predicate
Otherwise the equality is coincidental.
5. Motivating Scenario: One Agent, Three Sinks, Three Dialects
An agent issues a payout, a ledger write, and a notification. The
payment sink returns EF-025. The MCP tool sink returns
DESTINATION_MISMATCH. The mail sink returns HTTP 403 with
invalid_scope. A coordinator cannot tell whether all three denied
the same substitution or three different conditions.
Candidate composite C
|
+--> settlement sink : EF-025
+--> tool sink : DESTINATION_MISMATCH
+--> mail sink : invalid_scope
Registry goal:
map each local dialect to one registered
failure code + one consequence class
so the coordinator can fail closed on C.
Figure 2: Composite act, uncoordinated deny codes
Das Expires 20 March 2027 [Page 6]
Internet-Draft EF Registries September 2026
6. Design Goals and Non-Goals
The goal is a compact, extensible namespace for execution-finality
objects so that CAD, Execution Handle, verify, consume, and receipt
fields have one meaning across profiles.
This document does not classify law, medicine, or weapons; does not
assign severity scores that bind operators; does not replace HTTP,
OAuth, or problem+json; does not require every private deployment to
register; and does not freeze the companion architecture drafts.
7. Existing Registries and the Proposed Delta
+=============+===================+===========================+
| Existing | Already names | Does not name |
| namespace | | |
+=============+===================+===========================+
| OAuth | Grant and token- | Sink consume and act- |
| errors | endpoint failures | digest mismatch |
+-------------+-------------------+---------------------------+
| HTTP status | Transport and API | Finality-specific reason |
| / RFC 9457 | problem type | inside 403/409 |
+-------------+-------------------+---------------------------+
| JWT / CWT | iss, aud, exp, | act_digest, sink_id, |
| claims | cnf | reuse_policy as EF fields |
+-------------+-------------------+---------------------------+
| RATS / EAT | Environment | Consequence class of a |
| | claims | later act |
+-------------+-------------------+---------------------------+
| SCITT | Statement / | Whether a receipt is a |
| | receipt types | permit to effectuate |
+-------------+-------------------+---------------------------+
| Media types | Generic JSON/CBOR | CAD, handle, pending, |
| | | receipt types |
+-------------+-------------------+---------------------------+
Table 1: Existing IANA or protocol namespace and residual
naming question
8. Terminology
Terms Candidate Act, Candidate Act Descriptor, Execution Handle,
Finality Sink, Consume, and Finality Receipt are used as in
[DAS-HANDLE].
*Consequence Class:* A registered label for the kind of external
effect a Candidate Act would produce if permitted.
Das Expires 20 March 2027 [Page 7]
Internet-Draft EF Registries September 2026
*Sink Type:* A registered label for the kind of effectuation
boundary.
*Act Type:* A registered label for the kind of proposed operation,
finer than consequence class.
*Failure Code:* A registered identifier for a verify/consume/path
failure predicate.
*Profile Identifier:* A registered name for a named bundle of
required CAD fields, reuse default, and assurance expectations.
9. Namespace Rules
Public compact codes:
EF-nnn failure codes (provisional until IANA)
URI forms in examples:
urn:ietf:params:ef:...
ef:<registry>:<name>
are PLACEHOLDERS. Neither an IETF URN namespace
under RFC 3553 nor an "ef" URI scheme is requested
in this revision. Implementations MUST NOT treat
those strings as registered identifiers.
Private / experimental:
EF-X-* MUST NOT be registered
X- / uns: / urn:uuid: deployment-local
Collision rule:
unregistered use of EF-nnn
is NOT interoperable
and SHOULD be rejected by strict profiles.
Registered names are case-sensitive strings in the compact form
specified for each registry. Profiles MAY also carry the URI form in
receipts.
10. Where Registry Values Appear
Das Expires 20 March 2027 [Page 8]
Internet-Draft EF Registries September 2026
CAD
act_type -> Act Type registry
consequence_class -> Consequence Class registry
finality_sink.type -> Sink Type registry
EH
reuse_policy -> Reuse Policy registry
profile_id -> Profile registry (optional)
Receipt
decision -> Decision registry
consume_outcome -> Consume Outcome registry
reason_code -> Failure Code registry
Figure 3: Registry fields on CAD, handle, and receipt
11. Consequence Class Registry
A consequence class is a coarse effect kind. It is not a risk rating
and not a legal category. Profiles use it to select default reuse
policy and required CAD fields.
Das Expires 20 March 2027 [Page 9]
Internet-Draft EF Registries September 2026
+================+==========================+================+
| Value | Meaning | Typical sink |
+================+==========================+================+
| FINANCIAL | Balance, settlement, or | SETTLEMENT |
| | rail post changes | |
+----------------+--------------------------+----------------+
| PHYSICAL | Motion, energy, or | ACTUATION |
| | process I/O changes | |
+----------------+--------------------------+----------------+
| RF | Transmit, beam, or | RF_TRANSMIT |
| | spectrum enablement | |
+----------------+--------------------------+----------------+
| COMMUNICATIVE | Message send, call | EGRESS or |
| | setup, or reachability | REACHABILITY |
+----------------+--------------------------+----------------+
| DISCLOSURE | Release of held data or | RELEASE or |
| | model information | EGRESS |
+----------------+--------------------------+----------------+
| RENDER | Presentation to a | RENDER |
| | display or media sink | |
+----------------+--------------------------+----------------+
| CONTROL_PLANE | Live infra mutation | CONTROL_PLANE |
| | (DNS, BGP, cluster, IAM) | |
+----------------+--------------------------+----------------+
| IDENTITY | Credential issuance or | IDENTITY_ISSUE |
| | privilege grant | |
+----------------+--------------------------+----------------+
| MEMORY_WRITE | Durable agent memory or | MEMORY |
| | corpus write | |
+----------------+--------------------------+----------------+
| MODEL_RELEASE | Weight, adapter, or SMI | RELEASE |
| | release | |
+----------------+--------------------------+----------------+
| CLINICAL | Care-delivery order or | ACTUATION or |
| | device setpoint | CLINICAL |
+----------------+--------------------------+----------------+
| ADMINISTRATIVE | Recorded official or | ADMIN |
| | eligibility effect | |
+----------------+--------------------------+----------------+
| ERASURE | Required delete, hold, | DATA_LIFECYCLE |
| | or export effect | |
+----------------+--------------------------+----------------+
| COMPOSITE | Two or more classes that | COMPOSITE |
| | must close together | |
+----------------+--------------------------+----------------+
Table 2: Initial consequence classes
Das Expires 20 March 2027 [Page 10]
Internet-Draft EF Registries September 2026
CLINICAL is a technical effect class for care-delivery sinks. It is
not a medical-device approval and not a clinical-safety standard.
12. Sink Type Registry
+================+===========================================+
| Value | Boundary that first makes the effect real |
+================+===========================================+
| SETTLEMENT | Payment or ledger post |
+----------------+-------------------------------------------+
| TOOL_DISPATCH | Agent tool / MCP / function invoke |
+----------------+-------------------------------------------+
| ACTUATION | ICS, robot, vehicle, or lab effector |
+----------------+-------------------------------------------+
| RF_TRANSMIT | Radio or optical transmit enable |
+----------------+-------------------------------------------+
| EGRESS | Organization or device outbound release |
+----------------+-------------------------------------------+
| RELEASE | Model, secret, or dataset release |
+----------------+-------------------------------------------+
| RENDER | Compositor, display, or media decoder |
+----------------+-------------------------------------------+
| CONTROL_PLANE | Orchestrator, DNS, routing, or IAM commit |
+----------------+-------------------------------------------+
| IDENTITY_ISSUE | Issuer of a usable credential |
+----------------+-------------------------------------------+
| MEMORY | Durable memory or RAG write |
+----------------+-------------------------------------------+
| REACHABILITY | Create or extend a contact path |
+----------------+-------------------------------------------+
| ADMIN | Authoritative administrative record |
+----------------+-------------------------------------------+
| DATA_LIFECYCLE | Erase, hold, or mandated export |
+----------------+-------------------------------------------+
| COMPOSITE | Coordinator of N child sinks |
+----------------+-------------------------------------------+
Table 3: Initial sink types
13. Act Type Registry
Act types are optional finer labels. The initial set is small on
purpose. Profiles SHOULD prefer consequence class plus operation
fields when an act type would only duplicate a tool name.
Das Expires 20 March 2027 [Page 11]
Internet-Draft EF Registries September 2026
+==================+========================================+
| Value | Notes |
+==================+========================================+
| PAYMENT_POST | Settlement instruction |
+------------------+----------------------------------------+
| TOOL_CALL | Generic tool/function invoke |
+------------------+----------------------------------------+
| SETPOINT_WRITE | Process or device setpoint |
+------------------+----------------------------------------+
| RF_ENABLE | Enable a transmit path |
+------------------+----------------------------------------+
| MESSAGE_SEND | Outbound message |
+------------------+----------------------------------------+
| DATA_EGRESS | Copy or disclose held data |
+------------------+----------------------------------------+
| OUTPUT_RELEASE | Model or inference output release |
+------------------+----------------------------------------+
| WEIGHT_LOAD | Load or hot-swap model weights |
+------------------+----------------------------------------+
| MEMORY_COMMIT | Durable memory write |
+------------------+----------------------------------------+
| PLAN_APPLY | Control-plane apply of a prepared plan |
+------------------+----------------------------------------+
| CREDENTIAL_ISSUE | Issue a usable token or cert |
+------------------+----------------------------------------+
| RENDER_PRESENT | Present media to a surface |
+------------------+----------------------------------------+
| ERASE_COMMIT | Commit a delete or hold |
+------------------+----------------------------------------+
Table 4: Initial act types
14. Reuse Policy Registry
+============+======================================================+
| Value | Rule |
+============+======================================================+
| SINGLE_USE | First successful consume wins |
+------------+------------------------------------------------------+
| COUNTED | Consume until max_uses |
+------------+------------------------------------------------------+
| ENVELOPE | Repeat only inside declared bounds; |
| | identical-digest replay forbidden |
| | unless allow_identical_replay |
+------------+------------------------------------------------------+
Table 5: Initial reuse policies
Das Expires 20 March 2027 [Page 12]
Internet-Draft EF Registries September 2026
High-consequence classes FINANCIAL, PHYSICAL, RF, MODEL_RELEASE, and
CLINICAL SHOULD default to SINGLE_USE unless a profile documents why
not.
15. Decision and Consume-Outcome Registries
Sink-commit decisions used by [DAS-HANDLE]: EFFECTUATED, REJECTED.
Coordinator and composite decisions used by [DAS-COMPOSITE]:
NON_EFFECTIVE, PREPARED, ABORTED, COMPENSATING, CONTAINED, UNKNOWN.
Consume outcomes: CONSUMED, RESERVED, RELEASED (reservation dropped
on abort, no post), UNCHANGED, FAILED.
16. Failure Code Registry
Codes are compact EF-nnn identifiers. Ranges are reserved to keep
related failures adjacent.
002-019 authority / handle
020-039 act correspondence
040-059 sink / generation / path
060-069 policy / purpose / jurisdiction
070-079 escalation / human gate
080-089 fail-closed / availability of TCB
090-099 reserved
100-199 specified by later profiles
900-999 reserved for private experiments
(MUST NOT be registered)
+========+===========================+=============================+
| Code | Name | Predicate |
+========+===========================+=============================+
| EF-002 | NO_FINALITY_AUTHORITY | No current handle or |
| | | equivalent authority |
+--------+---------------------------+-----------------------------+
| EF-003 | HANDLE_INTEGRITY_FAILURE | Handle signature or MAC |
| | | fails |
+--------+---------------------------+-----------------------------+
| EF-004 | HANDLE_EXPIRED | Handle or CAD past |
| | | expires_at |
+--------+---------------------------+-----------------------------+
| EF-005 | AUTHORITY_ALREADY_USED | Reuse policy exhausted |
+--------+---------------------------+-----------------------------+
| EF-006 | REPLAY_DETECTED | Same act presented against |
| | | consumed state |
+--------+---------------------------+-----------------------------+
| EF-012 | SCOPE_MISMATCH | Key-binding, workload, or |
Das Expires 20 March 2027 [Page 13]
Internet-Draft EF Registries September 2026
| | | scope proof fails |
+--------+---------------------------+-----------------------------+
| EF-020 | DESTINATION_MISMATCH | Live destination not bound |
| | | destination |
+--------+---------------------------+-----------------------------+
| EF-023 | ACT_DIGEST_MISMATCH | Reconstructed digest != |
| | | handle digest |
+--------+---------------------------+-----------------------------+
| EF-024 | AMOUNT_MISMATCH | Financial amount field |
| | | diverged |
+--------+---------------------------+-----------------------------+
| EF-025 | BENEFICIARY_MISMATCH | Payee / recipient diverged |
+--------+---------------------------+-----------------------------+
| EF-026 | RAIL_MISMATCH | Settlement rail diverged |
+--------+---------------------------+-----------------------------+
| EF-030 | MODE_FORBIDDEN | Device or process mode |
| | | forbids the write |
+--------+---------------------------+-----------------------------+
| EF-031 | INTERLOCK | Safety interlock open |
+--------+---------------------------+-----------------------------+
| EF-033 | VALUE_ENVELOPE | Setpoint or argument |
| | | outside envelope |
+--------+---------------------------+-----------------------------+
| EF-040 | SINK_MISMATCH | Presented at a sink other |
| | | than bound sink |
+--------+---------------------------+-----------------------------+
| EF-041 | GENERATION_STALE | Policy or context |
| | | generation moved |
+--------+---------------------------+-----------------------------+
| EF-042 | REUSE_POLICY_VIOLATION | Reuse rule not satisfied |
+--------+---------------------------+-----------------------------+
| EF-043 | ENVELOPE_EXCEEDED | Live CAD left the envelope |
+--------+---------------------------+-----------------------------+
| EF-044 | PATH_INCOMPLETE | Alternate path can produce |
| | | K |
+--------+---------------------------+-----------------------------+
| EF-047 | PARTIAL_COMMIT | Required child posted while |
| | | composite did not close |
+--------+---------------------------+-----------------------------+
| EF-060 | PURPOSE_MISMATCH | Live purpose not the |
| | | authorized purpose |
+--------+---------------------------+-----------------------------+
| EF-061 | JURISDICTION_MISMATCH | Current JEC does not |
| | | satisfy J_req |
+--------+---------------------------+-----------------------------+
| EF-062 | REVOCATION_ACTIVE | Handle or basis revoked |
| | | before commit |
+--------+---------------------------+-----------------------------+
Das Expires 20 March 2027 [Page 14]
Internet-Draft EF Registries September 2026
| EF-070 | ESCALATION_REQUIRED | Profile requires a further |
| | | gate |
+--------+---------------------------+-----------------------------+
| EF-080 | FAIL_CLOSED | Required check unavailable; |
| | | no effect |
+--------+---------------------------+-----------------------------+
| EF-081 | CONSUME_STATE_UNAVAILABLE | Consume store cannot be |
| | | used safely |
+--------+---------------------------+-----------------------------+
Table 6: Initial failure codes
17. Profile Identifier Registry
A profile identifier names a bundle, not a vendor. Initial values
are architecture bundles from the family. Domain catalogues SHOULD
reuse these rather than mint a new profile per industry press
release.
+========================+=======================================+
| Value | Bundle |
+========================+=======================================+
| ef-handle-strict | Reconstruct + sink bind + SINGLE_USE |
| | default + fail closed |
+------------------------+---------------------------------------+
| ef-handle-envelope | Strict verify with documented |
| | envelope reuse |
+------------------------+---------------------------------------+
| ef-handle-mitigation | Handle present but path coverage |
| | incomplete; must not claim prevention |
+------------------------+---------------------------------------+
| ef-jurisdiction-strict | Handle plus current JEC dimensions |
+------------------------+---------------------------------------+
| ef-purpose-strict | Handle plus purpose binding |
+------------------------+---------------------------------------+
| ef-path-complete | Handle plus declared complete path |
| | inventory |
+------------------------+---------------------------------------+
Table 7: Initial profile identifiers
18. Media Types
This document requests, if the community agrees to proceed,
registration of:
Das Expires 20 March 2027 [Page 15]
Internet-Draft EF Registries September 2026
application/ef-cad+json
application/ef-handle+json
application/ef-pending+json
application/ef-receipt+json
application/ef-cad+cbor
application/ef-handle+cbor
application/ef-receipt+cbor
Until registration, implementations MAY use these strings only in
private deployments and SHOULD include a profile_id.
19. Optional JWT / CWT Claim Names
If a profile encodes an Execution Handle as JWT or CWT, the following
claim names are proposed. They MUST NOT collide with registered JWT/
CWT claims. This document does not itself complete that IANA
request; it records the intended names for review.
ef_act_digest
ef_sink_id
ef_reuse_policy
ef_profile_id
ef_generations
ef_candidate_act_id
Standard iss, exp, nbf, jti, and cnf remain the existing registries'
objects. This draft does not redefine them.
20. Optional HTTP Authentication Scheme
[DAS-HANDLE] illustrates Authorization: EFHandle .... That scheme
name is provisional. A later revision may request an HTTP
authentication scheme registration. This -00 does not.
21. Mapping to Existing Error Channels
A sink that speaks HTTP SHOULD still use an appropriate status code
(typically 403 or 409) and MAY include an RFC 9457 problem document
whose type URI is the URI form of the EF failure code. OAuth token
endpoints SHOULD keep OAuth errors for token issuance and use EF
codes only at the effectuation sink.
Das Expires 20 March 2027 [Page 16]
Internet-Draft EF Registries September 2026
HTTP 403
Content-Type: application/problem+json
{
"type": "urn:ietf:params:ef:failure:EF-023",
"title": "ACT_DIGEST_MISMATCH",
"status": 403,
"ef_handle_id": "...",
"ef_sink_id": "core-post-eu-1"
}
22. Formal Consistency Rules
Let R_class, R_sink, R_act, R_reuse, R_dec, R_out, R_fail, R_prof be
the eight provisional tables. The identities below are the same
membership tests as the validation pseudocode.
WellTyped(CAD) iff
CAD.consequence_class in R_class
and CAD.sink_type in R_sink
and (CAD.act_type = bot or CAD.act_type in R_act)
UnknownPublic(code) iff
code matches EF-nnn, nnn in [002,899]
and code notin R_fail
Strict: UnknownPublic(code) => reason = EF-080
and not Effect
Das Expires 20 March 2027 [Page 17]
Internet-Draft EF Registries September 2026
WellTyped(CAD) :=
CAD.consequence_class in ConsequenceClassRegistry
AND CAD.finality_sink.sink_type in SinkTypeRegistry
AND (CAD.act_type absent
OR CAD.act_type in ActTypeRegistry)
WellTyped(EH) :=
EH.reuse_policy in ReusePolicyRegistry
AND (EH.profile_id absent
OR EH.profile_id in ProfileRegistry)
WellTyped(Receipt) :=
Receipt.decision in DecisionRegistry
AND Receipt.consume_outcome in ConsumeOutcomeRegistry
AND (Receipt.reason_code absent
OR Receipt.reason_code in FailureCodeRegistry)
UnknownPublicCode :=
compact form looks like EF-nnn
AND code not registered
AND not in 900-999 private range
Strict profile:
UnknownPublicCode ==> treat as EF-080 FAIL_CLOSED
rather than as a vendor extension.
This fail-closed rule is intentional forward
compatibility: a strict sink that has not yet
learned a later-registered public EF-nnn MUST
refuse rather than guess. Operators who need
to accept a newly registered code MUST update
the local table. Mitigation profiles MAY
log-and-continue; they MUST NOT call that
behavior the strict profile.
23. Hash Function and Formal Tools
This document names codes; it does not define d(C). The Act Digest
hash, canonicalization, SHA-256 default, and collision-resistance
argument live in [DAS-HANDLE]. A receipt that carries a digest MUST
also carry the algorithm name used to produce it.
Formal verification tools are not required to use these tables. A
TLA+ or Alloy model of a sink SHOULD treat WellTyped and
UnknownPublic => EF-080 as invariants of the strict profile.
Registry membership is not a security proof; it is a precondition the
handle and composite models assume when they mention EF-nnn.
Das Expires 20 March 2027 [Page 18]
Internet-Draft EF Registries September 2026
24. Registration State Machine
+------------------+
| PRIVATE / EF-X-* |
+--------+---------+
|
specification + review
v
+------------------+
| PROVISIONAL |
| (this draft) |
+--------+---------+
|
IANA expert review
v
+------------------+
| REGISTERED |
+--------+---------+
|
breaking semantic change
v
+------------------+
| DEPRECATED + |
| successor code |
+------------------+
A registered code MUST NOT silently change predicate.
Figure 4: From private code to registered code
25. Illustrative Pseudocode
25.1. Validate Registry Fields on a CAD
function validate_cad_registries(cad, tables):
if cad.consequence_class not in tables.consequence:
return FAIL("unregistered consequence_class")
if cad.finality_sink.sink_type not in tables.sink:
return FAIL("unregistered sink_type")
if cad.act_type and cad.act_type not in tables.act:
return FAIL("unregistered act_type")
return PASS
25.2. Emit a Registered Reason Code
Das Expires 20 March 2027 [Page 19]
Internet-Draft EF Registries September 2026
function reason(code, tables):
if code in tables.failure:
return {
compact: code,
name: tables.failure[code].name,
uri: "urn:ietf:params:ef:failure:" + code
}
if matches_ef_numeric(code) and not private_range(code):
return fail_closed("EF-080",
detail="unknown public failure code")
return {
compact: code,
name: "PRIVATE",
uri: null
}
25.3. Map to HTTP Problem Details
function to_problem(receipt):
r = reason(receipt.reason_code, tables)
status = 409 if r.compact == "EF-005" else 403
return {
type: r.uri,
title: r.name,
status: status,
ef_decision: receipt.decision,
ef_consume_outcome: receipt.consume_outcome
}
26. Proposed Registration Policy
Unless the community directs otherwise, the proposed policy for all
EF registries in this document is Expert Review [RFC8126]. Media
types follow the normal media-type process.
Experts SHOULD reject: duplicate predicates under a new name; codes
that encode a vendor product; codes that assert a legal conclusion;
and changes that alter the predicate of an already registered value.
New semantics get a new code. Old codes may be marked Deprecated.
Das Expires 20 March 2027 [Page 20]
Internet-Draft EF Registries September 2026
27. Industrial Relevance and Public-Roadmap Alignment
Agent platforms, clouds, PSPs, and silicon vendors already ship local
enums for deny reasons and tool categories. A public registry is
useful only if two of those stacks need to read each other's
receipts. This section does not claim that any named company lacks a
namespace or should adopt these codes. Named products are not
described as implementers of this draft.
Complementary reading: MCP tool names are tool identifiers, not
consequence classes. Copilot connector errors are product errors,
not EF failure codes. OAuth invalid_scope remains an OAuth error.
NVIDIA attestation result types remain RATS/EAT objects. A rail
decline code remains a rail code unless a profile explicitly maps it
to an EF code at the SETTLEMENT sink.
MCP / Copilot tool name != consequence class
OAuth invalid_scope != EF-023
PSP / rail decline != EF failure code (unless mapped)
Attestation result type != consume outcome
Named organizations are not asserted to have reviewed, implemented,
or endorsed this registry. Corrections of mappings and requests to
remove a name are invited. Silence is not agreement.
28. Questions to the IETF Community
Criticism, including the conclusion that no new registry is needed,
is a successful review outcome.
1. Is a new EF namespace justified, or should failure codes live
only as RFC 9457 type URIs under a vendor or draft tree?
2. Is Expert Review the right policy, or Specification Required, or
First Come First Served for some tables?
3. Should consequence class and sink type be one table?
4. Is CLINICAL an acceptable technical class, or is it too close to
a regulated domain name?
5. Should COMPOSITE be a class, a sink type, both, or deferred to a
later composite-finality draft?
6. Are the initial EF-nnn assignments stable enough to freeze, or
should -00 keep them all Provisional?
Das Expires 20 March 2027 [Page 21]
Internet-Draft EF Registries September 2026
7. Should JWT/CWT claim names be requested now or only after the
handle encoding is chosen?
8. Should an HTTP authentication scheme be requested, or is that
premature?
9. How should private deployments avoid colliding with later public
allocations?
10. Which existing IANA registry is the closest overlap this draft
underestimates?
11. Should this document be merged into draft-das-execution-handle
instead of standing alone?
12. Which venue should own any eventual IANA request: dispatch
first, then SEC or ART?
29. Potential IETF Discussion Venues
This document does not claim that any named group should adopt the
work. Overlap review should come before an IANA request.
29.1. DISPATCH
The registries cut across OAuth, HTTP, RATS, and SCITT. DISPATCH is
the natural first discussion venue if no WG claims the namespace.
29.2. OAuth
Relevant if EF codes or handle claims are profiled onto tokens.
OAuth should not be asked to own consequence classes for actuation or
RF.
29.3. HTTPAPI
Relevant to problem+json mapping and any later authentication-scheme
request. Not a home for sink-type semantics.
29.4. RATS
Relevant only to keep EAT/attestation claim names from colliding with
proposed ef_* claims. RATS should not own FINANCIAL vs PHYSICAL.
29.5. SCITT
Relevant if Finality Receipts are SCITT statements and need a
statement type. SCITT should not own consume-state failure codes.
Das Expires 20 March 2027 [Page 22]
Internet-Draft EF Registries September 2026
29.6. WIMSE
Relevant to workload identifiers inside CAD.actor, not to the failure
namespace itself.
29.7. SAAG
Useful for whether a new security-area namespace is justified. SAAG
does not adopt documents.
29.8. No Presumed Home
An individual -00 that requests IANA too early will fail. This
version specifies the tables and policy so they can be rejected
cleanly.
30. Relationship to Other Execution-Finality Internet-Drafts
[DAS-HANDLE] defines the objects that carry these fields. This
document names the fields' allowed values. Domain drafts SHOULD
reference these registries instead of minting parallel enums.
DAS-PROTOCOL architecture: computation is not authority
DAS-HANDLE wire objects that carry the fields
this document allowed values
DAS-COMPOSITE uses COMPOSITE class/type,
EF-044 PATH_INCOMPLETE,
EF-047 PARTIAL_COMMIT
Predicate drafts that SHOULD reuse codes, not fork them:
DAS-STATE, DAS-REVOCATION, DAS-PATH,
DAS-JURISDICTION, DAS-PURPOSE
Domain drafts that SHOULD cite this registry:
DAS-AGENTIC / DAS-TOOL, payment, OT/actuation,
6G/NTN, enterprise-AI, silicon, CVID profiles
See also [DAS-PROTOCOL], [DAS-COMPOSITE], [DAS-JURISDICTION],
[DAS-PATH], [DAS-STATE], [DAS-REVOCATION], [DAS-PURPOSE], and
[DAS-AGENTIC].
31. Security Considerations
A registry does not enforce finality. It only makes failures
comparable. Security-relevant risks of the namespace itself include:
* Colliding public codes with private meanings (mitigate with the
unknown-public-code fail-closed rule).
Das Expires 20 March 2027 [Page 23]
Internet-Draft EF Registries September 2026
* Using a coarse class to hide a finer substitution (amount mismatch
reported only as SCOPE_MISMATCH).
* Treating a registered profile_id as proof that path coverage
exists.
* Stable reason codes that leak destination or act class in
receipts.
32. Privacy Considerations
Consequence class, act type, and failure code can reveal that a
financial, clinical, or disclosure act was attempted. Receipts
SHOULD omit unused fields and MAY return a coarse code to untrusted
callers while logging the registered fine code locally.
33. IANA Considerations
This version does not request IANA action. It defines candidate
tables and a proposed Expert Review policy so that a later revision,
if the community agrees, can request:
* Execution-Finality Consequence Classes
* Execution-Finality Sink Types
* Execution-Finality Act Types
* Execution-Finality Reuse Policies
* Execution-Finality Decisions
* Execution-Finality Consume Outcomes
* Execution-Finality Failure Codes
* Execution-Finality Profile Identifiers
* media types listed in Section 18
JWT/CWT claim names and an HTTP authentication scheme are explicitly
not requested in this revision.
Das Expires 20 March 2027 [Page 24]
Internet-Draft EF Registries September 2026
34. Criticism, Corrections, and Review Invited
The most useful criticism is that an existing IANA registry already
covers one or more of these tables. That evidence should delete the
overlapping table, not be ignored. Equally useful is a demonstration
that keeping "illustrative codes" in each domain draft is preferable
to a shared namespace at this stage.
35. Conclusion
Execution-finality objects are not interoperable while every profile
assigns private meaning to EF-005 and FINANCIAL. This draft proposes
a namespace, an initial allocation, and a conservative IANA posture:
specify the tables now, request registrations only after the
community accepts that a new namespace is required.
ILLUSTRATIVE CODE
!=
SHARED PREDICATE
Same string
!=
same meaning
Register the predicate
OR
keep the dialect private
and do not pretend it is IANA.
36. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8126] IETF, "Guidelines for Writing an IANA Considerations
Section in RFCs", BCP 26, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
37. Informative References
[DAS-AGENTIC]
Das, S., "Tool Selection Is Not Execution: Finality for
Agentic Tool Dispatch in High-Risk AI Systems", Work in
Das Expires 20 March 2027 [Page 25]
Internet-Draft EF Registries September 2026
Progress, Internet-Draft, draft-das-agentic-execution-
finality, September 2026,
<https://datatracker.ietf.org/doc/draft-das-agentic-
execution-finality/>.
[DAS-COMPOSITE]
Das, S., "Partial Commit Is Not Finality: Composite
Candidate Acts Across Multiple Finality Sinks", Work in
Progress, Internet-Draft, draft-das-composite-execution-
finality-01, September 2026,
<https://datatracker.ietf.org/doc/html/draft-das-
composite-execution-finality-01>.
[DAS-HANDLE]
Das, S., "Possession Is Not Authority: Execution Handle,
Sink Verification, Atomic Consumption, and Finality
Receipt", Work in Progress, Internet-Draft, draft-das-
execution-handle-01, September 2026,
<https://datatracker.ietf.org/doc/html/draft-das-
execution-handle-01>.
[DAS-JURISDICTION]
Das, S., "Authorized Here, Not Authorized There:
Jurisdiction-Bound Execution Finality for Cross-Border and
Sovereign Systems", Work in Progress, Internet-Draft,
draft-das-jurisdiction-bound-execution-finality-00,
September 2026, <https://datatracker.ietf.org/doc/html/
draft-das-jurisdiction-bound-execution-finality-00>.
[DAS-PATH] Das, S., "When the Gate Can Be Bypassed: Consequence-Path
Completeness for Execution Finality", Work in Progress,
Internet-Draft, draft-das-consequence-path-completeness,
September 2026, <https://datatracker.ietf.org/doc/draft-
das-consequence-path-completeness/>.
[DAS-PROTOCOL]
Das, S., "The Missing Protocol Layer for the Agentic
Internet: Computation Is Not Authority", Work in Progress,
Internet-Draft, draft-das-execution-finality-protocol-
layer-01, September 2026,
<https://datatracker.ietf.org/doc/draft-das-execution-
finality-protocol-layer/>.
Das Expires 20 March 2027 [Page 26]
Internet-Draft EF Registries September 2026
[DAS-PURPOSE]
Das, S., "Data-Purpose Laundering Prevention: Execution-
Finality for Preventing Cross-Domain Data Reuse", Work in
Progress, Internet-Draft, draft-das-purpose-execution-
finality, September 2026,
<https://datatracker.ietf.org/doc/draft-das-purpose-
execution-finality/>.
[DAS-REVOCATION]
Das, S., "Revoked but Still Executable: Closing the
Authorization-to-Effect Gap with Finality-Bound
Revocation", Work in Progress, Internet-Draft, draft-das-
finality-bound-revocation-00, September 2026,
<https://datatracker.ietf.org/doc/html/draft-das-finality-
bound-revocation-00>.
[DAS-STATE]
Das, S., "When Valid Authorization Becomes Stale: State
and Policy Continuity at the Execution-Finality Boundary",
Work in Progress, Internet-Draft, draft-das-state-policy-
continuity-finality-00, September 2026,
<https://datatracker.ietf.org/doc/html/draft-das-state-
policy-continuity-finality-00>.
[RFC6749] IETF, "The OAuth 2.0 Authorization Framework", RFC 6749,
October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.
[RFC7519] IETF, "JSON Web Token (JWT)", RFC 7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7591] IETF, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, July 2015,
<https://www.rfc-editor.org/rfc/rfc7591>.
[RFC8392] IETF, "CBOR Web Token (CWT)", RFC 8392, May 2018,
<https://www.rfc-editor.org/rfc/rfc8392>.
[RFC9457] IETF, "Problem Details for HTTP APIs", RFC 9457, July
2023, <https://www.rfc-editor.org/rfc/rfc9457>.
[RFC9943] IETF, "An Architecture for Trustworthy and Transparent
Digital Supply Chains", RFC 9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
Author's Address
Das Expires 20 March 2027 [Page 27]
Internet-Draft EF Registries September 2026
Sangam Das
Independent
Balasore
Odisha
India
Phone: +91-9861363532
Email: info@sangamdas.com
Das Expires 20 March 2027 [Page 28]