NHE Constrained Bootstrap: A Self-Describing Capability and Constraint Declaration Protocol for Autonomous Agents
draft-ruvalcaba-nhe-bootstrap-00

Individual Submission                                     C.X. Ruvalcaba
Internet-Draft                                                Saluca LLC
Intended status: Standards Track                          11 August 2026
Expires: 12 February 2027

 NHE Constrained Bootstrap: A Self-Describing Capability and Constraint
               Declaration Protocol for Autonomous Agents
                    draft-ruvalcaba-nhe-bootstrap-00

Abstract

   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.

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 12 February 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Ruvalcaba               Expires 12 February 2027                [Page 1]
Internet-Draft                NHE Bootstrap                  August 2026

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Relationship to the NHE Architecture  . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  The Capability Manifest . . . . . . . . . . . . . . . . . . .   3
   5.  Capability Tiers and the Permission Matrix  . . . . . . . . .   4
   6.  The Bootstrap Handshake . . . . . . . . . . . . . . . . . . .   4
   7.  Dispatch Gating and Capability Assurance  . . . . . . . . . .   5
   8.  Wire Format (to be specified in -01)  . . . . . . . . . . . .   5
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   11. Normative References  . . . . . . . . . . . . . . . . . . . .   6
   12. Informative References  . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   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.

2.  Relationship to the NHE Architecture

   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

Ruvalcaba               Expires 12 February 2027                [Page 2]
Internet-Draft                NHE Bootstrap                  August 2026

   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.

3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "MAY", and
   "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119]
   [RFC8174].

   Capability manifest:  A self-describing declaration of an entity's
      resources and capabilities, produced by introspection and signed
      by the entity.

   Capability tier:  A class assigned by the coordinator from the
      manifest via quantitative thresholds.

   Permission matrix:  The set of task types and subtypes a tier is
      authorized to perform.

   Constraint manifest:  The capability manifest together with the tier-
      derived permission matrix; the entity's full authorization
      envelope.

   Coordinator:  The party that classifies manifests, registers
      entities, and gates task dispatch.

4.  The Capability Manifest

   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.

Ruvalcaba               Expires 12 February 2027                [Page 3]
Internet-Draft                NHE Bootstrap                  August 2026

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

5.  Capability Tiers and the Permission Matrix

   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.

6.  The Bootstrap Handshake

   The bootstrap is a fixed, non-recursive sequence:

   1.  The entity introspects and builds its capability manifest.

   2.  The entity registers with the coordinator over a mutually
       authenticated transport.

   3.  The coordinator derives a per-entity key --- for example by an
       HKDF [RFC5869] from the entity's identity-bound identifier,
       giving certificate-less identity without PKI provisioning --- and
       returns it once, over the mutually authenticated channel (a
       trust-on-first-use root), together with a scoped namespace and a
       poll interval calibrated to the entity's tier.

   4.  The entity re-signs its manifest with the derived (or its own
       asymmetric) key and returns it.

   5.  The coordinator verifies the re-signed manifest by independently
       re-deriving the key (or checking the registered public key) and
       recomputing the signature.

   6.  The coordinator registers the entity with its verified manifest,
       computed tier, and key identifier.

Ruvalcaba               Expires 12 February 2027                [Page 4]
Internet-Draft                NHE Bootstrap                  August 2026

   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.

7.  Dispatch Gating and Capability Assurance

   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.

8.  Wire Format (to be specified in -01)

   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.

9.  Security Considerations

   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

Ruvalcaba               Expires 12 February 2027                [Page 5]
Internet-Draft                NHE Bootstrap                  August 2026

   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.

10.  IANA Considerations

   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.

11.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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

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

12.  Informative References

   [I-D.ruvalcaba-nhe-arch]
              Ruvalcaba, C.X., "An Architecture for Non-Human Entities
              (NHE)", Work in Progress, Internet-Draft, draft-ruvalcaba-
              nhe-arch-00, August 2026,
              <https://datatracker.ietf.org/doc/html/draft-ruvalcaba-
              nhe-arch-00>.

   [I-D.ruvalcaba-nhe-authz]
              Ruvalcaba, C.X., "NHE Backchannel Authorization", Work in
              Progress, Internet-Draft, draft-ruvalcaba-nhe-authz-00,
              August 2026, <https://datatracker.ietf.org/doc/html/draft-
              ruvalcaba-nhe-authz-00>.

   [I-D.ruvalcaba-nhe-identity]
              Ruvalcaba, C.X., "NHE Identity", Work in Progress,
              Internet-Draft, draft-ruvalcaba-nhe-identity-00, August
              2026, <https://datatracker.ietf.org/doc/html/draft-
              ruvalcaba-nhe-identity-00>.

Ruvalcaba               Expires 12 February 2027                [Page 6]
Internet-Draft                NHE Bootstrap                  August 2026

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

Author's Address

   Cristian Xavier Ruvalcaba
   Saluca LLC
   Email: cristian@saluca.com

Ruvalcaba               Expires 12 February 2027                [Page 7]