Illustrative Codes Are Not a Namespace: Registries for Execution-Finality Consequence Classes, Sink Types, Act Types, Failure Codes, Profiles, and Media Types

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

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.¶

2. Introduction

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.

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.

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

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.¶

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

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

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.¶

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

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.¶

14. Reuse Policy Registry

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)

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.¶

18. Media Types

This document requests, if the community agrees to proceed, registration of:¶

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.¶

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

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.¶

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.

25. Illustrative Pseudocode

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

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
    }

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.¶

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?¶
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.¶

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).¶
• 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.¶

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.

Author's Address