| Internet-Draft | NHE Bootstrap | August 2026 |
| Ruvalcaba | Expires 12 February 2027 | [Page] |
This document specifies how a Non-Human Entity (NHE) declares, at bootstrap, what it is capable of and is thereby bounded in what it is permitted to do. An entity produces a signed, self-describing capability manifest through automated introspection; a coordinator classifies the manifest into a capability tier that maps to a permission matrix --- the set of task types the entity is authorized to perform --- and every subsequent task dispatch is gated against that envelope. The result is a verifiable, self-describing constraint on an entity established at the moment it joins, realizing the bounded-authority invariant of the NHE architecture at boot time. The manifest and handshake data model is specified here; the wire encoding is deferred to the next revision.¶
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 12 February 2027.¶
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.¶
An autonomous entity should not be trusted to do whatever it asks to do; it should be bounded to what it is actually capable of and authorized for, and that bound should be established verifiably when it joins, not assumed. This document specifies a bootstrap in which an entity describes itself --- its resources, its capabilities, the actions it can perform --- in a signed manifest, is classified into a permission envelope on that basis, and is thereafter gated so that a task exceeding its declared and authorized capability is never dispatched to it. The motivating case is an entity that can drive physical actuation: dispatching an actuator task to an entity not tier-authorized for it is a safety failure, not merely a routing error.¶
This document specifies part of the Governance interface of [I-D.ruvalcaba-nhe-arch] and is the boot-time realization of that model's bounded-authority invariant: authority is conferred by classification of a verifiable self-description into a permission envelope, and is exercised only within it. The entity is named by its NHE identity [I-D.ruvalcaba-nhe-identity], and the key that signs its manifest is bound to that identity, so a capability assertion is tied to the entity making it. This protocol governs what an entity may ever do; the companion backchannel-authorization protocol [I-D.ruvalcaba-nhe-authz] governs whether a specific action is permitted at the time it is attempted.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174].¶
An entity produces its capability manifest by automated introspection. The manifest declares at least: a stable entity identifier bound to the entity's identity, an enumeration of computational resources, an enumeration of the classes of action the entity can perform (including any that affect the physical world), an enumeration of locally available inference capabilities with measured throughput, and network characteristics. The specific fields are extensible; the requirement is that the manifest be a complete, honest self-description sufficient for classification.¶
The manifest is signed over its canonical serialization --- JSON Canonicalization Scheme [RFC8785], with the signature and signature-method fields excluded from the signed content --- so any verifier recomputes byte-identical signed input. The signature MAY be a symmetric MAC under a coordinator-derived per-entity key (integrity relative to a key-holder) or, where non-repudiation is required, an asymmetric signature under an entity-generated key whose public half is registered (Section 6).¶
The coordinator classifies a manifest into a capability tier by applying quantitative thresholds to the declared resources and capabilities. Each tier maps to a permission matrix: the task types and subtypes an entity in that tier is authorized to perform. The pairing of the capability manifest with the tier-derived permission matrix is the entity's constraint manifest --- its authorization envelope. Classification is the point at which a self-description becomes a bounded authority.¶
The bootstrap is a fixed, non-recursive sequence:¶
Because the per-entity key is derived from the same identity-bound identifier that the signed manifest asserts, the capability assertion is cryptographically knotted to the entity's derived identity: a manifest cannot be presented under one identity but signed as another.¶
For each proposed task dispatch, the coordinator MUST verify that the task type and subtype are permitted by the target entity's permission matrix, that the capabilities the task requires are declared present in the target's manifest, and that the target is active. A task is enqueued only if all hold; otherwise it is rerouted to an entity whose tier and manifest permit it, or denied. This is what prevents capability-exceeding dispatch.¶
Because a self-description is self-reported and therefore potentially false, the coordinator SHOULD perform capability assurance under trust-on-first-use: it dispatches a test task exercising a claimed capability and compares the result to an expected oracle, demoting or quarantining an entity whose claimed capability does not check out. Self-report establishes the envelope; spot-check and identity binding keep it honest.¶
The manifest content model, its canonical serialization and signature, the tier-and-permission-matrix model, the six-step handshake, and the dispatch gating rule are fixed by this revision. The concrete encodings of the manifest and the handshake messages are deferred to the next revision.¶
A capability manifest is self-reported, so its declarations authenticate an entity only as strongly as the key that signs it and the assurance that backs it. A symmetric-MAC manifest provides integrity relative to a key-holder but not non-repudiation, and an identifier derived from semi-public attributes does not by itself authenticate hardware; deployments needing non-repudiation or hardware assurance MUST use the asymmetric-key variant bound to identity [I-D.ruvalcaba-nhe-identity] and/or the hardware-rooted attestation profile referenced there, plus spot-check capability assurance (Section 7). The derived per-entity key is returned once over the mutually authenticated channel; that channel is the trust-on-first-use root and MUST be strongly authenticated. Canonicalization [RFC8785] MUST be identical at signing and verification, or valid manifests will be rejected or, worse, a binding gap will open. Dispatch gating is a safety control, not only an authorization one: for actions affecting the physical world, a gating bypass can cause physical harm, so gating MUST fail closed --- an unclassifiable or unverifiable entity receives no permissions.¶
A future revision will request registries for capability-manifest field identifiers and for task-type/subtype identifiers used in permission matrices, under a Specification Required policy [RFC8126]. No IANA action is requested by this skeleton revision.¶