]> Violet Shores Pty Ltd

rob@violetshores.com

Security agent identity delegation audit biometric attestation provenance Autonomous software agents increasingly act under delegated authority, and emerging audit-record data models capture what an agent did, under which delegation, with which authorization state. In current practice the head of every such chain, and the identity axis of every such record, is a key, an account, or a workload identity. No standardized element establishes that an identified natural person, verified as live and present, stands at the head of the chain or behind the recorded action. This document defines the Verified Human Root Attestation (VHRA): a compact, privacy-preserving data structure asserting that a biometric proof-of-human verification of an identified natural person (or an M-of-N quorum of such persons) occurred at a specific issuance event. It further defines how a delegation chain binds a VHRA at its root such that the binding survives attenuation, and how audit and interaction records reference a VHRA so that any recorded agent action can be resolved to an accountable natural person without the verifier receiving any biometric material. This document is offered as input to the proposed AUDIT working group's data model work. It deliberately does not standardize biometric verification methods; it standardizes only the attestation structure, its bindings, and verifier obligations.

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.

Relationship to the proposed AUDIT work The proposed AUDIT working group contemplates data models for interaction records, agent identity, delegation context, authorization state over time, and action provenance. Each of those elements is strengthened by, and none currently provides, an optional verified-human-root binding. This document proposes that the audit-record data model include an OPTIONAL field carrying a VHRA reference (Section 6), so that deployments with accountability requirements can resolve records to natural persons while deployments without such requirements omit the field entirely.

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 when, and only when, they appear in all capitals, as shown here.

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.

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

issuer, signature:

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

Binding a VHRA to a Delegation Chain This section is written for the general case of an attenuated chain. A chain with no attenuation hops is in scope and is a distinct case: in it the chain itself performs no checking, and the whole of verification rests on the standing of a single event. Readers SHOULD read Section 5.1 before assuming that the hop-by-hop machinery in Sections 5.2 through 5.4 is where verification happens.

Chains of length zero A credential issued directly by the Human Principal, with no attenuation hop between the Issuance Event and the credential presented to a verifier, is a delegation chain of length zero. A consent grant signed by the subject's own key is the canonical example. At length zero: Binding is the Issuance Event's binding of the signing key to a verified natural person, and nothing else. There is no root position distinct from the credential itself; the VHRA (or the commitment to it) is carried by the credential directly. Section 5.2 applies trivially. There is nothing to attenuate, so Section 5.3 imposes no obligation, and the chain contributes no verification of its own. A verifier MUST NOT infer any assurance from the absence of hops. The relying party's entire verification is the resolution of that one Issuance Event's standing at the time of the act: the VHRA resolves, validates, is fresh, satisfies any quorum, and is not revoked (Section 5.4, steps 1 through 5, applied to the single event). Continuation and revocation semantics (Section 5.5) apply to it unchanged and carry the full verification burden. A profile that carries a subject-signed consent grant and requires that the signing key be bound to a credentialed unique human is satisfied at length zero by the Issuance Event alone.

Root placement A delegation chain that claims a verified human root MUST bind the VHRA (or a cryptographic commitment to it) in a root position with the following properties: It is covered by the signature of the root credential and, transitively, by every signature in the chain, such that its removal or alteration invalidates the chain. It is non-removable: no attenuation hop can produce a valid derivative credential that omits the binding.

Preservation across attenuation Each attenuation hop, whatever else it narrows, MUST preserve a resolvable cryptographic reference to the root VHRA. A verifier presented with any leaf credential of the chain MUST be able to resolve the reference and validate the VHRA without cooperation from intermediate hops.

Verifier obligations A verifier of an action requested under a chain that claims a verified human root MUST, in addition to whatever chain validation the token format requires: resolve the root VHRA reference; validate the VHRA signature and its binding to the chain's Issuance Event via issuance_nonce; check freshness and, where present, quorum satisfaction; check current validity via the revocation pointer; and reject the action if the VHRA is absent, unresolvable, invalid, stale, quorum-deficient, or revoked (fail closed). A verifier MUST NOT treat the absence of a VHRA as equivalent to a present but unverifiable VHRA: a chain that claims a human root and cannot prove it is invalid, whereas a chain that never claimed one is simply outside this document's scope.

Revocation Revocation of a VHRA by or on behalf of the Human Principal invalidates the chain rooted in it. Post-revocation, verification per Section 5.4 fails, and all leaf authority derived from the chain is extinguished at the identity layer, independent of the revocation state of any individual key in the chain.

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.

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.

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.

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.

&RFC2119; &RFC8174; &RFC9635; &RFC8693; &RFC2693;

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 ():

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 ():

A token-exchange chain preserves the VHRA reference as a claim that MUST survive exchange; the verifier obligations of Section 5.4 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 ():

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.

Changes from -00 Added Section 5.1, chains of length zero, and a lead-in note to Section 5 directing readers to it. Renumbered the remaining subsections of Section 5 and updated internal cross-references, including two in -00 that pointed to the wrong subsection (Sections 4 and 10 referenced revocation and verifier obligations by the wrong numbers). No change to the VHRA structure, processing rules, or IANA considerations.

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. Blake Morrison identified that -00 was written only for the attenuated case and that, at length zero, continuation and revocation carry the whole verification burden; Section 5.1 is the result.