NHE Identity: A Verifiable Key-Committed Identity and Genesis-Attestation Format for Autonomous Agents

Introduction Every other interface of the NHE reference architecture is scoped to identity: continuity, memory, inter-entity messaging, audit, and authority are all bound to "which entity." An identity that is only a name is forgeable and therefore useless as that anchor. This document specifies identity as a verifiable commitment: an entity is identified by control of an identity key, and that key is bound by an append-only, independently verifiable hash chain to the entity's genesis and to the succession of configurations it has held. The construction is deliberately simple and self-contained: a relying party --- a peer entity, an operator, or any verifier --- can confirm an identity from the chain alone plus a signature, with no registration authority in the base case. An optional profile adds hardware-rooted genesis attestation for deployments that require it.

Relationship to the NHE Architecture This document specifies the Identity interface of and inherits its scope framing. An NHE identity is a functional construct --- a key commitment and a configuration lineage --- and asserts nothing about the entity being alive, sentient, or a person. The identity mechanism is precisely what makes the architecture's invariants enforceable: inspectability, because the chain is an independently verifiable audit of identity and configuration lineage; operator control, because identity keys and chain progression are subject to operator-held revocation (); and bounded authority, because authority grants elsewhere in the suite name this identity as their subject.

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

Identity key:: The long-term key pair whose control defines the entity. May be a hybrid of a classical and a post-quantum signature key ().
Identity key hash:: A cryptographic digest of the identity public key; the stable identifier for the entity.
Configuration profile:: The structured description of the entity's capabilities and constraints at a point in time; committed to the chain by its digest, not by value.
Identity chain:: The append-only hash chain of identity records binding the identity key to its genesis and configuration lineage.
Genesis record:: The first record of an identity chain.
Relying party:: Any party that verifies an entity's identity --- a peer, an operator, or a third-party verifier.

Identity Chain Model An identity is a chain of records. Each record commits, in order, to the identity key hash, the current configuration profile digest, a pointer to the preceding record, a timestamp, and a signature by the identity key.

Record Structure An identity record is the ordered tuple: The canonical serialization of a record, used both for the prior_record_hash computation and for transport, is the canonical form of the ordered tuple {identity_key_hash, profile_hash, prior_record_hash, timestamp, signature}, with binary fields encoded as lowercase hexadecimal and object members in the fixed order shown. Canonicalization MUST be deterministic so that any verifier recomputes byte-identical input.

Genesis and Linkage The prior_record_hash of the genesis record is a sentinel of 32 zero octets (0x00 repeated 32 times). For every non-genesis record, the prior_record_hash MUST equal the SHA3-256 digest of the canonical serialization of its immediate predecessor for the same identity key hash. The chain has the no-fork property: at most one record exists for each (identity_key_hash, prior_record_hash) pair, so no two records may claim the same predecessor. A configuration change is recorded by appending a new record with a new profile_hash; the identity key is continuous across the change, which is how an entity's configuration lineage is bound to a single identity.

Verification A relying party verifies an identity chain by, for each record in insertion order: (a) verifying the record signature against the identity public key; (b) for each non-genesis record, recomputing the SHA3-256 digest of the canonical serialization of its immediate predecessor and confirming it equals the record's prior_record_hash; and (c) confirming the no-fork property. Signature verification and per-record hash recomputation are each O(1); full-chain verification is O(n) in chain length. A relying party that only needs the current identity MAY verify from a trusted checkpoint rather than from genesis.

Proof of Control Presenting a chain proves the chain is well-formed; it does not prove the presenter controls the identity key. To prove control, a verifier issues a challenge comprising a fresh nonce and a freshness counter, and the entity returns a signature by its identity key over the challenge together with its current record's prior_record_hash. The verifier accepts only if the signature verifies against the identity public key committed in the presented chain and the freshness counter has not been seen before. This binds the live proof to the specific identity and defeats replay.

Capability Attestation (Optional) An entity MAY prove that a specific capability is present in its configuration profile without revealing the remainder of the profile, by producing a proof that is verifiable against the identity public key and that attests to the presence of the named capability in the profile committed by profile_hash. This lets a relying party confirm "this entity is authorized for capability X" without learning the entity's full configuration. The proof system is negotiable; the requirement is only that the proof be verifiable against the committed identity and profile digest.

Hardware-Rooted Genesis-Attestation Profile (Optional) Deployments that require identity rooted in hardware MAY use this profile. At provisioning, a genesis hash is computed as a digest over a canonical, fixed-order, length-prefixed serialization of the entity's provisioning inputs (its initial configuration commitments), and a genesis record containing the genesis hash and a manufacturer signature over it is published to a content-addressable registry. The device holds a device-root-bound identity private key inside a secure boundary; only the corresponding public key is exported. Attestation proceeds as a challenge/response: the verifier sends a nonce and freshness counter; the device signs an attestation tuple (the challenge, a device serial, and a commitment to its current configuration-version counter) with the device-rooted key; the verifier fetches the genesis record from the registry keyed by a digest of the device serial and verifies a signature chain from a manufacturer certificate, through the device public key, to the attestation tuple, and that the committed configuration version is consistent with the authorized version. Keys used for confidentiality MUST be derived from a high-entropy device root secret; published identity values (the genesis hash, serial) MUST appear only as non-secret domain-separation inputs, never as keying material.

Cryptographic Agility Identity signatures SHOULD be hybrid: a classical signature (for example Ed25519 ) composed with a post-quantum signature (for example ML-DSA), so that identity survives the compromise of either primitive alone. The chain-linkage hash in this document is SHA3-256. The set of permitted signature suites and hash functions is registry-controlled () so the format can migrate without a new protocol version; a verifier MUST reject records using a suite it does not implement.

Revocation and Operator Control An operator MUST be able to revoke an identity or a key. Revocation is itself expressible as a chain event (a terminal record marking the identity or a key as revoked, signed under operator-held authority) and/or as a registry status in the hardware-rooted profile. A relying party MUST treat a revoked identity as invalid regardless of otherwise well-formed chain and proof of control. This is the mechanism by which the architecture's operator-control invariant is realized at the identity layer: a continuous identity is never continuous against its operator.

Wire Format (to be specified in -01) The data model above --- record tuple, genesis sentinel, linkage rule, no-fork property, and verification procedure --- is fixed by this revision. The concrete encoding of records and messages on the wire (field encodings, the challenge/response and attestation message layouts, and the registry interaction for the hardware-rooted profile) is deferred to the next revision, following the compact-binary approach of HCTP .

Security Considerations Identity is the root of all scoping in the NHE suite; compromise of an identity key compromises the guarantees of every interface bound to that identity. Identity key protection is therefore the highest-value control, and the hybrid-signature requirement () exists to keep the root secure across cryptographic transitions. The chain provides tamper-evidence and lineage, not confidentiality: it reveals the sequence and timing of configuration changes and the profile digests. Where that metadata is sensitive it MUST be protected by the transport. The no-fork check is essential --- without it an entity could maintain divergent identities from a shared predecessor; verifiers MUST enforce it. Proof of control MUST use unpredictable nonces and monotonic freshness to defeat replay. In the hardware-rooted profile, deriving any confidentiality key from published or low-entropy identity values is cryptographically broken and MUST NOT be done; keys come from the device root secret, with published values used only as domain separation. Finally, revocation () is a security-critical path: a verifier that cannot learn revocation status MUST treat the identity as untrusted for high-value actions rather than assume validity.

IANA Considerations A future revision will request two registries: "NHE Identity Signature Suites" (classical, post-quantum, and hybrid combinations) and "NHE Identity Hash Functions" (chain-linkage digests), each under a Specification Required policy . No IANA action is requested by this skeleton revision.