Verified Human Root Attestation for Agent Delegation Chains and Audit Records

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 January 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. Introduction

Delegation and audit mechanisms for autonomous agents are converging quickly: attenuable token chains, delegation receipts, agent identity attestations, and audit-record architectures are all active areas of specification. These mechanisms share a structural property: authority is rooted in the possession of a cryptographic key, an account at an identity provider, or a workload identity. Attribution therefore terminates at a credential.¶

A large class of deployments — legal instruments, regulated industries, critical infrastructure, government — carries a requirement that credential-level attribution alone does not address. The governing question in these settings is: which accountable natural person authorized this, and can that be proven years later, to a party who was not present, without that party being granted standing access to personal data? Keys are delegated, stolen, shared, and escrowed; accounts are administered; workloads are ephemeral. A credential at the head of a chain does not answer the question.¶

This document defines a small data structure, the Verified Human Root Attestation (VHRA), that closes this gap in a composable way:¶

• A VHRA asserts that a biometric proof-of-human verification of an identified natural person occurred at a specific issuance event, at a stated assurance level, optionally as an M-of-N quorum of distinct persons.¶

• A delegation chain MAY bind a VHRA at its root such that every attenuation hop preserves a resolvable reference to it, and a verifier of any leaf action can validate the human root and fail closed if it is absent, invalid, or revoked.¶

• An audit or interaction record MAY carry a reference to the VHRA under which the recorded action was performed, so that audit resolution reaches a natural person rather than terminating at an agent identifier.¶

The VHRA is intentionally agnostic to how biometric verification is performed. Verification methods, liveness detection techniques, and their quality are the province of certification programs and are out of scope. The structure standardized here is the interface: what an issuer asserts, what travels in the chain, what a record references, and what a verifier is obliged to check.¶

2. Conventions and Definitions

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, as shown here.¶

3. Terminology

Human Principal:

An identified natural person on whose authority a delegation chain is issued or an action is performed.¶

Liveness Event:

A discrete biometric verification of a Human Principal, performed at a specific time, asserting that the person was live and present. The methods by which liveness is established are out of scope.¶

Verified Human Root Attestation (VHRA):

The data structure defined in Section 4, asserting one Liveness Event (or an M-of-N quorum of Liveness Events) bound to a specific issuance event.¶

Issuance Event:

The act of creating a delegation chain, credential, or session for which the VHRA establishes the human root, identified by a unique nonce.¶

Quorum Root:

A VHRA whose assertion covers M-of-N Liveness Events of N distinct Human Principals.¶

Delegation Chain:

Any mechanism by which authority is conveyed from an issuer through zero or more attenuation hops to a leaf credential under which an agent acts. This document is agnostic to the token format.¶

Audit Record:

Any record, per an audit-record data model, describing an agent interaction or action, its delegation context, and its authorization state.¶

4. The Verified Human Root Attestation

A VHRA is a signed structure with the following logical fields. Encodings (CBOR, JSON) are expected to be profiled by the consuming ecosystem; field semantics are normative, serialization is not, in this version.¶

subject:

A reference to the Human Principal's identity credential. This is a reference, not the credential itself and not biometric material.¶

liveness:

Metadata about the Liveness Event(s): the count and class of verification modalities employed (e.g., "multi-modal, fused"), the assurance level asserted by the issuer against a stated assurance framework, and the time of the event. This field carries no biometric samples, templates, or model outputs.¶

issuance_nonce:

The unique identifier of the Issuance Event to which this VHRA is bound. A VHRA MUST be bound to exactly one Issuance Event. This binding is the anti-replay anchor: a VHRA MUST NOT be accepted for any issuance other than the one named by this nonce.¶

freshness:

The validity window within which the Liveness Event must have occurred relative to the Issuance Event, as asserted by the issuer.¶

quorum:

OPTIONAL. Present when the VHRA is a Quorum Root: the values M and N, and, for each constituent Liveness Event, an independently-signed sub-assertion bound to the same issuance_nonce. Constituent sub-assertions MUST be independently produced and signed such that satisfaction of the quorum requires M distinct Human Principals; M qualifying sub-assertions from a single person is a protocol violation.¶

revocation:

A pointer (URI or equivalent) at which the current validity of this VHRA can be checked. Revocation semantics are defined in Section 5.3.¶

issuer, signature:

The attestation issuer's identifier and signature over all fields above.¶

5. Binding a VHRA to a Delegation Chain

6. Referencing a VHRA from Audit Records

An audit-record data model SHOULD provide an OPTIONAL field, suggested name verified_human_root, with the following contents:¶

• a reference to the VHRA under which the recorded action's authority was rooted;¶

• a cryptographic digest of the VHRA as validated at action time; and¶

• the validity status observed at action time.¶

This triple permits a later audit consumer to establish that the recorded action resolved, at the time it was performed, to a then-valid verified human root — and to re-resolve the reference if the underlying attestation is still available — without the record itself carrying any personal data beyond an opaque reference.¶

Records for actions performed under chains with no VHRA simply omit the field. Audit tooling can therefore filter, without heuristics, between human-rooted and credential-rooted actions — which is precisely the distinction that liability-bearing deployments need to make.¶

7. Privacy Considerations

The design constraint of this document is that accountability must not cost surveillance:¶

• No biometric samples, templates, feature vectors, or model outputs appear in the VHRA, the delegation chain, or any audit record.¶

• A verifier receives only: an opaque subject reference, liveness metadata, a digest, and a validity status. Resolution of the subject reference to a legal identity is a governed act, available to authorized oversight parties under the deployment's disclosure rules, and is out of band with respect to this document.¶

• An oversight party can confirm THAT an accountable verified person stands behind an action without learning WHO, unless and until disclosure is authorized. This "standing-access-free" property is deliberate and deployments SHOULD preserve it.¶

• The issuance_nonce binding prevents cross-context correlation of VHRAs: an attestation is meaningful only for its named Issuance Event.¶

8. Security Considerations

Replay:

The issuance_nonce binding (Section 4) is mandatory precisely because a liveness assertion detached from its issuance context is a replayable bearer of trust. Verifiers MUST reject VHRA presentations whose nonce does not match the chain's Issuance Event.¶

Freshness:

A stale Liveness Event weakens the live-and-present claim. Issuers assert a freshness window; verifiers enforce it. Deployments choose windows proportional to risk.¶

Quorum independence:

The value of a Quorum Root depends on constituent sub-assertions being independently produced. Implementations MUST NOT permit a single capture pipeline to emit multiple constituent sub-assertions for one issuance.¶

Downgrade:

An attacker who can strip a VHRA binding converts a human-rooted chain into a credential-rooted one. The non-removability requirement (Section 5.1) exists to make this a signature-breaking operation.¶

Verification quality:

This document standardizes the interface, not the strength, of biometric verification. An attestation is only as strong as its issuer's practices; conformance and certification of issuers is expected to be addressed by external programs and is a natural complement to this specification.¶

9. IANA Considerations

This document has no IANA actions. A future version may register the verified_human_root audit-record field and a VHRA media type, subject to working-group adoption.¶

10. References

Appendix A. Binding to Existing Authorization Ecosystems

This appendix sketches, informatively, how the VHRA composes with current mechanisms; none of these bindings changes the host protocol.¶

GNAP ([RFC9635]):

The VHRA functions as interaction-derived evidence bound to a grant: the grant's issuance is the Issuance Event, and access tokens derived from the grant carry the root reference.¶

OAuth 2.0 Token Exchange ([RFC8693]):

A token-exchange chain preserves the VHRA reference as a claim that MUST survive exchange; the verifier obligations of Section 5.3 apply at resource access.¶

Attenuable token formats (macaroon- and biscuit-class):

The VHRA commitment is the first caveat; attenuation appends caveats but cannot remove it.¶

SPKI-style authorization certificates ([RFC2693]):

The VHRA is carried in the root certificate; delegated certificates reference it.¶

Workload identity ecosystems:

A workload credential remains workload-scoped; where a workload acts under human-rooted delegated authority, the workload's requests carry the chain, and the chain carries the VHRA. Human root and workload identity are complementary, not competing, axes.¶

Acknowledgments

This document responds to the direction of the proposed AUDIT work and to the broader delegation-receipt and agent-identity efforts whose gap it aims to fill.¶

Author's Address