Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-Custody for Agentic AI Systems

1.1. What HDP Is Not

HDP is not an authorization protocol, and an HDP token is not a capability, an access token, or a credential that entitles its holder to anything. Presenting a valid HDP token to a service does not authorize the presenter to perform the requested action. That decision belongs to the service's own access control mechanism, whether that is OAuth 2.0 (Section 12.2), a capability system such as UCAN or ZCAP-LD (Section 12.4, Section 12.5), or something else. HDP is designed to travel alongside such mechanisms, not to replace them (Section 10.1).¶

Several parts of this document can be misread as authorization if this distinction is not kept in view. The scope object (Section 3.3) records what the human declared, in fields named authorized_tools and authorized_resources among others; it is a signed record of the authorization event, not a grant. The verification pipeline (Section 5) establishes that a token is authentic and intact, not that its presenter may act. The HTTP transport (Section 8) shows a token accompanying a request because the task travels in the request, not because the token authorizes it.¶

The primary reader of an HDP token is therefore not the service receiving a request but whoever examines the record afterwards: post-incident reconstruction of which agent did what, under whose authorization, and in what order; compliance evidence that a human authorized a class of action; and human oversight, where an approver inspects the chain a task has accumulated before permitting it to continue. A token is carried at invocation and read at audit.¶

1.2. Motivation

The need for agentic delegation provenance is not hypothetical. Production deployments of AI orchestration systems (LangChain, AutoGPT, CrewAI, and similar frameworks) today pass natural language task descriptions between agents with no cryptographic binding to the original human authorization. The operational risk compounds as models become more capable and agents are granted access to higher- consequence tools.¶

A provenance token that travels alongside the task (tamper-evident, offline-verifiable, and scoped to what the human actually approved) provides the foundation for auditable, accountable agentic systems.¶

1.3. Design Goals

HDP is designed with the following goals in order of priority:¶

1. Offline verifiability. Verification MUST require only a public key, a session ID, and state held locally by the verifier. No network call, registry lookup, or third-party endpoint is required.¶
2. Self-sovereignty. Any organization MUST be able to issue and verify HDP tokens without registering with a central authority or anchoring to a third-party key.¶
3. Tamper evidence. Any modification to a token's recorded content (its header, principal, scope, or any recorded hop) MUST be detectable by the verification pipeline. Completeness of the chain (that no trailing hop has been omitted) is a separate property; see Section 10.4.¶
4. Minimal footprint. The protocol MUST be implementable in any language with Ed25519 and JSON support. No mandatory infrastructure beyond key management is required.¶
5. Privacy by design. Principal identity fields MUST be separable from the audit-relevant parts of the token, so tokens can be transmitted to agents without exposing PII.¶

1.4. Relationship to IPP (draft-haberkamp-ipp-01)

The Intent Provenance Protocol [I-D.haberkamp-ipp] addresses the same problem space. HDP and IPP share the use of Ed25519 signatures and append-only provenance chains but make different architectural trade-offs, which are detailed in Section 12. The two protocols are not interoperable. HDP is offered as a distinct design point, not a revision of IPP.¶

The full HDP protocol specification is available at [HDP-SPEC]. A TypeScript reference implementation is available at [HDP-IMPL].¶

1.5. Generality of the Chain-of-Custody Mechanism

The core of HDP is an append-only, cryptographically chained record: each hop extends a signed entry that covers all prior state, gaps in the hop sequence are tamper-evident, and any party can verify the entire chain offline using only a public key. This chain-of-custody mechanism is independent of what the chain carries.¶

This document profiles that mechanism for one application: human-authorized agentic delegation. In this profile the carried payload is the scope object (Section 3.3) and each hop record describes an agent delegation action. The same mechanism could carry other payloads, for example data provenance, consent delegation, or physical-world command chains, each as a distinct profile. Such profiles are out of scope for this document; HDP v0.1 defines only the agentic-delegation profile. Where practical, the signing (Section 4.1, Section 4.2) and verification (Section 5) procedures are described in a payload-agnostic way so that future profiles can reuse them unchanged.¶

3.1. Header

The header object carries token lifecycle and session binding fields.¶

{
  "token_id"        : "550e8400-e29b-41d4-a716-446655440000",
  "issued_at"       : 1711483200000,
  "expires_at"      : 1711569600000,
  "session_id"      : "sess-20260326-abc123",
  "version"         : "0.1",
  "parent_token_id" : "..."
}

token_id:

REQUIRED. A version 4 UUID [RFC9562]. Unique identifier for this token.¶

issued_at:

REQUIRED. Unix milliseconds. Time of issuance.¶

expires_at:

REQUIRED. Unix milliseconds. MUST be greater than issued_at. A token MUST NOT be accepted for live use at or after this time. Expiry does not prevent historical integrity verification (Section 5.1). HDP defines no default lifetime; the value is an issuer choice, and Section 10.5 discusses how to make it.¶

session_id:

REQUIRED. Opaque string. Established out-of-band between issuer and agent framework before token issuance. Provides replay defense: a token is only valid within the session for which it was issued.¶

version:

REQUIRED. MUST equal the value of the top-level hdp field.¶

parent_token_id:

OPTIONAL. If present, identifies the token this token supersedes in a re-authorization chain. See Section 6.¶

3.2. Principal

The principal object identifies the authorizing human. It MUST contain id and id_type. All other fields are OPTIONAL.¶

{
  "id"             : "usr_alice_opaque",
  "id_type"        : "opaque",
  "display_name"   : "Alice Chen",
  "poh_credential" : "...",
  "metadata"       : {}
}

The id_type field MUST be one of the following defined values, or a custom string prefixed with x-:¶

• opaque: Application-defined identifier. No resolution semantics are implied.¶
• email: An email address as defined in [RFC5321].¶
• uuid: A UUID as defined in [RFC9562].¶
• did: W3C Decentralized Identifier [W3C.DID]. DID resolution is application- defined and not required by this protocol.¶
• poh: A Proof-of-Humanity credential identifier. Verification semantics are application-defined; see Section 9.3.¶

HDP does not mandate any specific identity model. The did id_type is available for deployments with existing DID infrastructure; it is not required.¶

3.3. Scope

The scope object records what the human authorized. It is signed as part of the root signature and MUST NOT be modified after issuance.¶

The scope object is a record, not a grant. Its fields describe the authorization the human gave at issuance so that the record can later be compared with what agents declared they did. Nothing in this object confers authority on an agent that holds the token (Section 1.1).¶

{
  "intent"               : "Analyze Q1 sales data and report.",
  "authorized_tools"     : ["database_read", "file_write"],
  "authorized_resources" : ["db://sales/q1-2026", "file://reports/"],
  "data_classification"  : "confidential",
  "network_egress"       : false,
  "persistence"          : true,
  "max_hops"             : 3
}

The values above are illustrative. In particular, the max_hops value shown is an issuer choice for this example, not a protocol limit.¶

intent:

REQUIRED. Natural language description of the authorized task. Free-form string. This is the authorization statement, and SHOULD be written to be both human- and agent-readable.¶

authorized_tools:

OPTIONAL. Array of tool identifiers the principal declared as authorized. The field records the declaration; it does not grant access to the tools named, and enforcement, if any, is application-defined.¶

authorized_resources:

OPTIONAL. Array of resource identifiers (URIs, paths, etc.) the principal declared as authorized. As with authorized_tools, this records the declaration and grants nothing.¶

data_classification:

REQUIRED. One of: public, internal, confidential, restricted. Expresses the sensitivity level of data the agent is authorized to access.¶

network_egress:

REQUIRED. Boolean. Whether the agent is authorized to make outbound network requests.¶

persistence:

REQUIRED. Boolean. Whether the agent is authorized to write persistent state.¶

max_hops:

OPTIONAL. Positive integer, chosen by the issuer, expressing the delegation budget the human authorized for this token. An issuer MAY choose any value within the representation bounds in Section 3, Paragraph 3. HDP defines no fixed operational budget. Verification MUST reject tokens whose chain length exceeds this value. If max_hops is absent, HDP places no limit on chain length, and delegation depth is governed by application policy (see Section 4.3). Issuers SHOULD omit this field unless the delegation budget is itself part of what the human declared; Section 10.7 explains why.¶

HDP does not mandate a central taxonomy for intent, authorized_tools, or authorized_resources. These are self-described by the issuer. Semantic validation of agent actions against declared scope is an application-layer concern.¶

The authorized_tools and authorized_resources arrays are independent lists. HDP v0.1 defines no binding between a tool and the resources it may be used on: the example above lists two tools and two resources, and nothing in it states which tool the principal authorized against which resource. Applications MUST NOT infer a per-tool resource binding from a v0.1 scope. Issuers that need the binding recorded SHOULD state it in intent, and SHOULD list a resource for every tool that acts on one, as Appendix A does. A structured per-resource permission map is planned for a future version; it is a wire-format change and is not part of v0.1.¶

3.4. Chain

The chain array is append-only. Each element records a single delegation event (hop). The array is empty at issuance and grows as the token passes through agents. Agents MUST NOT remove or modify existing entries.¶

{
  "seq"               : 1,
  "agent_id"          : "orchestrator-v2",
  "agent_type"        : "orchestrator",
  "agent_fingerprint" : "sha256:abc123...",
  "timestamp"         : 1711483260000,
  "action_summary"    : "Decompose task; delegate to sub-agents.",
  "parent_hop"        : 0,
  "hop_signature"     : "<base64url-encoded Ed25519 signature>"
}

seq:

REQUIRED. Positive integer. Sequential index, starting at 1. MUST be exactly one greater than the previous hop's seq. Gaps in sequence are a protocol violation.¶

agent_id:

REQUIRED. Identifier of the agent adding this hop. The identifier need not be globally meaningful; it is sufficient that the delegator which assigned it can interpret it (Section 9.1).¶

agent_type:

REQUIRED. One of: orchestrator, sub-agent, tool-executor, custom.¶

agent_fingerprint:

OPTIONAL. Model or binary fingerprint for the acting agent.¶

timestamp:

REQUIRED. Unix milliseconds. Time of hop extension, as declared by the agent extending the chain. Hop timestamps are declared values: the hop signature proves who attested the value, not that it is accurate. MUST be greater than or equal to the previous hop's timestamp (Rule 5 of Section 4.3).¶

action_summary:

REQUIRED. Description of an action declared by the agent, written to be both human- and agent-readable. The description MUST distinguish an intended action from an attempted, blocked, or observed action whenever that distinction affects its interpretation. Out-of-scope attempts and observed violations MAY be recorded, with the deviation stated explicitly; their inclusion does not imply principal approval. This remains a signed declaration, not proof that an action occurred (Section 10.1).¶

parent_hop:

REQUIRED. Non-negative integer. Index of the hop that triggered this delegation, where 0 indicates the root (human) authorization.¶

hop_signature:

REQUIRED. Base64url-encoded (no padding) Ed25519 signature. See Section 4.2. Absence is a protocol violation per Rule 6 of Section 4.3.¶

3.5. Signature

The signature object carries the root signature computed by the issuer.¶

{
  "kid"   : "alice-signing-key-v1",
  "alg"   : "Ed25519",
  "value" : "<base64url Ed25519 signature over canonical JSON>"
}

The alg field MUST be Ed25519 for HDP v0.1. The kid field SHOULD be used by verifiers to identify the correct public key when multiple keys are in circulation.¶

4.1. Root Signature

The root signature is computed by the issuer at token creation time. It covers the token's header, principal, and scope, the fields that constitute the human authorization event.¶

The signing procedure is:¶

1. Construct the unsigned token object containing the hdp, header, principal, scope, and chain (empty array at issuance) fields.¶
2. Serialize the object to canonical JSON using RFC 8785 [RFC8785] (JSON Canonicalization Scheme). This ensures deterministic byte representation across implementations and platforms.¶
3. Compute the Ed25519 [RFC8032] signature over the canonical JSON bytes using the issuer's private key.¶
4. Encode the signature bytes as base64url [RFC4648] (no padding).¶
5. Attach the signature object (kid, alg, value) to the token.¶

The signature field itself MUST NOT be included in the canonical JSON payload before signing. Because the root signature is computed while chain is empty, the signed payload is deterministically recoverable from a populated token by removing the signature field, resetting chain to an empty array, and re-serializing with RFC 8785. The root signature therefore covers hdp, header, principal, and scope; the chain is protected by the hop signatures (Section 4.2) rather than by the root signature.¶

4.2. Hop Signature

Each hop MUST carry a hop_signature. This signature binds the new hop record to the entire accumulated delegation history and to the root signature, making retroactive chain modification detectable.¶

The hop signing procedure is:¶

1. Construct the new hop record (all fields except hop_signature).¶
2. Build the signing payload as a JSON array: [hop_1, hop_2, ..., hop_(n-1), new_hop_unsigned] where hop_1 through hop_(n-1) are the previously signed hops (WITH their hop_signature fields) and new_hop_unsigned is the new hop record WITHOUT its hop_signature.¶
3. Prepend the root signature value (base64url string) to the array as its first element: [root_sig_value, hop_1, ..., new_hop_unsigned]. This chains the hop signature to the root.¶
4. Serialize the array to canonical JSON per RFC 8785.¶
5. Compute the Ed25519 signature over the canonical JSON bytes using the issuer's private key.¶
6. Encode as base64url and attach as the hop_signature field on the new hop record.¶
7. Append the signed hop to the token's chain array.¶

The asymmetry between previously-signed hops (WITH hop_signature) and the new hop (WITHOUT hop_signature) in step 2 is intentional and critical. The verifier MUST reconstruct this exact payload structure when verifying each hop. See Section 5.¶

In HDP v0.1, all signatures (the root signature and every hop signature) are produced by the issuer using a single key. An extending agent that is not the issuer submits its hop to the issuer, which signs it and returns the extended token. Two consequences follow, and implementers should weigh both.¶

First, a v0.1 hop signature attests that the issuer recorded a delegation claim naming the agent in agent_id. It does not attest that the named agent consented to, or knew of, the hop, because the agent signed nothing. The chain is a record of what the issuer recorded, not of what each agent agreed to. Deployments in which that distinction matters need per-agent signing.¶

Second, the single-key design is practical only where the issuer is reachable whenever any agent wishes to extend the chain. This adds a round trip to every delegation, and it makes delegation across trust domains awkward, since an issuer in one domain must sign on behalf of agents in another. Only verification is offline; extension is not.¶

The single-key design does not, however, gain anything for offline verification that per-agent signing would lose. If each hop carried the public key of the agent appending it, signed into the chain by that agent's delegator, a verifier would authenticate every key after the first from the chain itself and would still resolve exactly one key out of band: the issuer's. Per-agent hop signing on that pattern is the planned extension for a future version. It is not part of v0.1, and v0.1 tokens carry no per-agent keys.¶

4.3. Chain Integrity Rules

The following rules govern chain construction and MUST be enforced by both extenders and verifiers:¶

1. Hop seq values MUST start at 1 and increment by exactly 1. No gaps are permitted.¶
2. Existing hop records MUST NOT be modified or removed.¶
3. A hop's parent_hop MUST reference a valid prior hop index (0 for the root human authorization, or the seq value of a prior hop).¶
4. If scope.max_hops is set, the chain length MUST NOT exceed it. A token with a full chain MUST NOT be extended.¶
5. Each hop's timestamp MUST be greater than or equal to the timestamp of the hop before it. A verifier MUST reject a chain in which a hop's timestamp is less than its predecessor's (Step 4 of Section 5). Because the issuer signs every hop in v0.1, all hop timestamps pass through one clock domain, which is what makes this rule enforceable.¶
6. The hop_signature field MUST be present on every hop. A hop without a hop_signature is a protocol violation and MUST cause verification to fail.¶

5.1. Historical Audit Verification

An auditor MUST be able to examine an expired or revoked token without treating it as acceptable for a new request. Audit tooling MUST report the following results separately. These are verification results, not new fields in an HDP token:¶

Record integrity:

Whether the record conforms to the format and its root and hop signatures verify. Apply the input validation in Section 3 and Steps 1, 3, 4, 5, and 6 of Section 5, using a trusted archived issuer key. Failure of one of these checks MUST NOT be reported as valid integrity. Expiry and revocation do not invalidate the signature mathematics; they are reported separately. If the key or supported verification algorithm is unavailable, integrity is unverified rather than valid.¶

Current acceptance:

Whether the live acceptance pipeline succeeds now. It MAY be reported as not evaluated when no current request or session exists. Successful integrity verification MUST NOT be used as a substitute for live acceptance.¶

Historical acceptance:

Whether evidence establishes acceptance conditions at a particular verifier and time. The auditor MUST identify that verifier and evaluation time, check the recorded session context using Step 7, check that the time is within the token's signed issuance and expiry interval, and evaluate the revocation state and any additional acceptance policy applicable there at that time. A positive result MUST require valid record integrity and authenticated evidence bound to the token and evaluation context. Missing evidence MUST produce an indeterminate result, not a claim that the token was historically accepted.¶

Historical evidence SHOULD include an authenticated receipt or integrity-protected verifier log binding the complete token digest (Section 8.2), the observed request or event, session identifier, verifier identity, time, decision, and relevant revocation and policy state. Any required Proof-of-Humanity result belongs in that evidence; a credential check performed today is not evidence of its status then. A declared hop timestamp alone is not trusted time evidence, and an empty current revocation set does not establish past status. These records are application-layer artifacts whose encoding is outside HDP v0.1. They can be retained and checked offline.¶

Historical acceptance describes the identified verifier's decision and available state; it does not establish global revocation freshness, that an action occurred, or that the human authorized that particular action. Applications requiring historical audit SHOULD retain the tokens, trusted public keys, session context, and evidence for their audit retention period, even after the tokens expire. Key-compromise information and applicable policy MUST qualify any conclusions drawn from a mathematically valid signature.¶

8.1. HTTP Header: HDP-Token

HDP tokens MAY be transmitted in HTTP requests and responses using the HDP-Token header. The header value is the base64url encoding (RFC 4648, no padding) of the UTF-8 JSON serialization of the complete token object.¶

POST /api/task HTTP/1.1
Host: agent.example.com
HDP-Token: eyJoZHAiOiIwLjEiLCJoZWFkZXIiOnsi...
Content-Type: application/json

Implementations MUST NOT include tokens in URL query parameters, as this exposes sensitive data in server logs and browser history.¶

A token accompanies a request because the task it records travels in that request. Its presence does not authorize the request (Section 1.1). The receiving service decides whether to act by its own means and MAY use the verified token as an input to that decision.¶

HTTP header values are routinely written to access logs, proxy logs, and error reports, and the HDP-Token value contains the principal object and the full chain. Deployments SHOULD configure logging to treat HDP-Token as sensitive, as they would an Authorization header.¶

8.2. Token by Reference: HDP-Token-Ref

When token size is a concern (e.g., large chains), the token MAY be stored server-side and referenced using the HDP-Token-Ref header. The reference is either the token's token_id, or a content-addressed reference: the string sha256: followed by the base64url encoding (no padding) of the SHA-256 digest [RFC6234] of the token's canonical JSON serialization per RFC 8785.¶

A recipient resolving a content-addressed reference MUST validate the resolved token's input representation, serialize the complete token (including signature and all hop signatures) with RFC 8785, encode the result as UTF-8, compute SHA-256, and compare the digest with the reference. The digest in the reference MUST be exactly 32 bytes encoded as canonical unpadded base64url; malformed encodings or a digest mismatch MUST cause rejection. The comparison commits to canonical JSON, not to whitespace or member ordering in the stored serialization. For a UUID reference, the resolved header.token_id MUST identify the same UUID; equality is determined by the UUID's 128-bit value, not hexadecimal letter case. The recipient MUST reject a mismatch. Successful reference resolution MUST be followed by live acceptance or historical audit verification as appropriate; a valid signature alone does not establish that the requested reference was resolved correctly.¶

POST /api/task HTTP/1.1
Host: agent.example.com
HDP-Token-Ref: 550e8400-e29b-41d4-a716-446655440000

Implementations using token-by-reference MUST secure the token store and use transport-layer security (TLS) for all reference resolution. The store MUST be write-once per reference: once a reference resolves to a token, it MUST NOT later resolve to a different one. Here, sameness means an identical complete canonical JSON token, not an identical token_id alone. A UUID reference therefore identifies one immutable snapshot, optionally the final record. It MUST NOT be used as a mutable pointer to the latest chain. Because extension preserves token_id, subsequent snapshots MUST use new content-addressed references when transported by reference; the previous UUID mapping remains unchanged.¶

The write-once requirement exists because a reference by token_id is a substitution point. A different but validly signed token stored under the same token_id passes every step of the verification pipeline and presents the wrong provenance. Session binding narrows the set of tokens that could be substituted but does not eliminate it. A content-addressed reference removes the substitution point, when the recipient performs the required digest check, and SHOULD be preferred where the resolving party does not control the store. A content-addressed reference changes each time the chain is extended, which is the intended behaviour: each extension is a different record.¶

8.3. Key Distribution: Well-Known Endpoint

Issuers that wish to publish their Ed25519 public keys for automated discovery SHOULD serve a JSON document at /.well-known/hdp-keys.json with the following structure:¶

{
  "keys": [
    {
      "kid" : "alice-signing-key-v1",
      "alg" : "Ed25519",
      "pub" : "<base64url-encoded 32-byte Ed25519 public key>"
    }
  ]
}

This endpoint is a discovery convenience only. It is not part of verification, which takes the issuer's public key as an input and remains fully offline (Section 10.11). A verifier that has obtained the key by other means has no reason to consult it.¶

This format is intentionally minimal. Implementations MAY extend it with additional metadata. The alg field MUST be "Ed25519" for HDP v0.1 keys. Consumers MUST reject entries with unrecognized alg values. Consumers MUST validate that the decoded public key is exactly 32 bytes.¶

9.1. Minimum-Disclosure Principal Fields

The principal object may contain PII (email address, display name). Issuers SHOULD apply the principle of minimum disclosure when constructing tokens that will traverse multiple agents. Specifically:¶

• Use id_type: "opaque" with an application-internal identifier rather than embedding the user's email address in tokens that will be sent to third-party agents.¶
• Omit display_name when the receiving agent does not require a human-readable identity.¶

The token structure separates the identity fields (principal) from the audit-relevant fields (header, scope, chain). Implementations MAY strip the principal object when forwarding tokens to agents that do not require principal identity, while preserving the integrity of the signature chain. Note that stripping principal invalidates the root signature; stripped tokens MUST be clearly marked as audit-only records and MUST NOT be presented for signature verification.¶

The same principle applies to the agent_id field in hop records (Section 3.4). An agent_id need not be meaningful to anyone but the delegator that assigned it. This is sufficient because accountability in a delegation chain is recursive: a delegator is responsible for how its direct delegate uses the delegation, even when the use occurred further down the chain, and that delegate is in turn responsible for its own direct delegate. A verifier or auditor therefore never needs to resolve an agent_id globally. It needs the delegator at each step to be able to identify the party it delegated to, and the agent_id and its action_summary are bound into the signed chain for exactly that purpose.¶

Which identifier to use is context dependent, and HDP does not prescribe one. Non-exhaustively: a widely known identifier, such as an enterprise employee or service number, suits deployments where correlation is not a concern; an identifier meaningful only to the delegator suits deployments where an observer must be prevented from correlating requests across chains; a DID ([W3C.DID]) suits deployments where a trusted authority exists to assert claims about it. An issuer or extending agent MAY use a fresh identifier for every delegation.¶

HDP v0.1 offers no field-level confidentiality: a token is either presented whole for verification or stripped and marked audit-only, as above. Encrypting principal fields is not specified, because the keys in circulation are Ed25519 signing keys rather than encryption keys and because the set of verifiers is deliberately open, so there is no defined party to encrypt to. Selective disclosure of principal fields and of individual hops, which would allow a token to be verified with parts withheld, is planned for a future version.¶

9.2. Data Retention and the Right to Erasure

HDP tokens may constitute personal data under applicable privacy regulations (e.g., GDPR Article 4(1)) when the principal.id or principal.display_name fields contain directly or indirectly identifying information.¶

Implementations SHOULD:¶

• Store tokens with explicit retention periods derived from header.expires_at.¶
• Provide deletion mechanisms that remove stored tokens upon erasure requests.¶
• Use opaque identifiers in principal.id where possible, maintaining a separate mapping that can be destroyed independently of the token audit log.¶

Encrypting stored tokens does not by itself discharge an erasure obligation, since the ciphertext remains personal data for as long as the key exists. Destroying the key (crypto-shredding) is a recognised technique for rendering retained tokens unreadable and MAY be used together with the mapping-destruction approach above.¶

9.3. Proof of Humanity

The optional principal.poh_credential field MAY carry a credential attesting that the principal is a human (e.g., a Worldcoin World ID proof, a CAPTCHA session token, or a biometric attestation identifier). The HDP protocol does not define the semantics of this field; verification is entirely application-defined.¶

When a PoH verifier is configured, the verification pipeline MUST validate the credential as the final step (after session binding) and MUST reject the token if validation fails. The verifier callback SHOULD be idempotent and SHOULD NOT have side effects. Section 5 explains why the callback is ordered last.¶

10.1. Threat Model

HDP is designed to provide provenance and tamper evidence, not runtime enforcement. An agent that exceeds its declared scope is still a bad actor; HDP creates an evidence trail, not a capability boundary. Applications requiring runtime enforcement MUST implement it at the application layer using the HDP token as audit input. HDP is not an authorization protocol (Section 1.1); the properties discussed below are properties of the record: who could have produced it, whether it has been altered, and what it does and does not establish.¶

10.2. Token Forgery

A forged token (one whose header, principal, or scope fields do not match the original issuance) will fail Step 3 of the verification pipeline (root signature check). The security of this step relies on the unforgeability of Ed25519 signatures and the collision resistance of SHA-512 (used internally by Ed25519). An attacker who does not possess the issuer's private key cannot produce a valid root signature for a modified token.¶

10.3. Chain Tampering

Modification, reordering, or removal of any non-trailing hop is detectable: it either breaks the hop sequence check (Step 4) or invalidates the hop signatures of all subsequent hops (Step 5), because each hop signature covers all previous hops and the root signature. Insertion of a fabricated hop will similarly fail unless the attacker possesses the issuer's private key. Removal of one or more trailing hops is a distinct case that these checks do not detect; see Section 10.4.¶

10.4. Chain Truncation and Completeness

Each hop signature covers only the hops that precede it and the root signature. Consequently, deleting one or more hops from the end of the chain, or presenting an earlier and shorter copy of a token, yields a token that still passes every step of the verification pipeline. HDP therefore provides tamper evidence for the hops that are present, but does not by itself prove that the chain is complete.¶

Relatedly, a non-cooperating or compromised agent can decline to append a hop for an action it takes; HDP records declared delegation actions and cannot compel an agent to record one. HDP is an evidence trail, not an enforcement mechanism (Section 10.1).¶

A verifier that can authenticate the presenter (for example, because the transport identifies the calling agent) SHOULD require that the final hop's agent_id correspond to that presenter. This is cheap and closes one truncation case: a third party holding a shorter, earlier copy of the token cannot present it, because the final hop of that copy names someone else. Capability systems impose the same requirement; UCAN Invocation requires the delegation chain to end at the invoker, and a ZCAP-LD invocation proof is rooted in the invoker's key.¶

The presenter check does not make the chain complete. In a capability chain, truncation gains an attacker nothing beyond what the presenter check catches, because authority only narrows toward the tail: a truncated prefix is usable only by the delegatee of its last remaining hop, who holds that authority legitimately. HDP hops record actions, not grants, and there is no attenuation; a truncated chain carries the full original scope. The case HDP must consider is an intermediate agent that deletes the hops appended after its own, in order to hide what its sub-agents did. After truncation that agent genuinely is the presenter, and the presenter check passes.¶

Concurrent extensions from the same prefix can produce two valid branches with the same token_id, hop count, and final agent_id, but different recorded actions. A hop count or presenter check cannot distinguish them. The signature pipeline verifies the supplied branch; it does not discover other branches or select a uniquely final one.¶

Deployments that require one linear record per token MUST serialize extensions at the issuer. The issuer MUST atomically check that the submitted prefix matches its accepted chain head and advance that head when committing an extension. A stale prefix MUST be rejected for reconciliation against the current head. An already signed hop cannot simply be transplanted onto another branch; extending the reconciled prefix requires a new signature. Retries SHOULD return an already committed result when the application identifies the same extension request. Deployments that intentionally allow branching MUST retain and identify the branches separately and define how their audit process accounts for them. HDP v0.1 defines no branch merge operation. Issuer serialization is state used for construction, not a network dependency of verification.¶

Applications requiring evidence of a particular observed or final record SHOULD retain an authenticated receipt or settlement record binding the token_id, session_id, complete token digest as defined in Section 8.2, observation time, and observing party. It MUST distinguish an observed snapshot from a claimed final record. A verifier relying on that receipt MUST validate its authenticity and compare the token digest. A hop count MAY be included for diagnostics but MUST NOT be treated as a substitute for the digest. The receipt establishes which branch was observed or finalized under the application's policy; it does not prove that no unrecorded action or undisclosed branch exists. Off-record delegation remains a separate limitation (Section 10.7). These receipts are application-layer artifacts, not new token fields.¶

10.5. Replay Attack Defense

HDP provides two orthogonal replay defenses:¶

1. Expiry. Every token carries an expires_at. An expired token is rejected at Step 2 regardless of network conditions.¶
2. Session binding. The token carries the session_id established out-of-band between issuer and verifier. A token is valid only within the session for which it was issued. Even a non-expired token cannot be replayed across sessions.¶

Together, these defenses ensure that a stolen token is useful to an attacker only within the original session and only until it expires or is revoked (Section 10.6).¶

HDP specifies no default lifetime, deliberately. Expiry alone forces a choice between tokens that lapse just before they are needed and tokens that outlive a detected compromise, and the tendency in deployed systems is for lifetimes to lengthen over time as the first kind of failure accumulates operational friction. Issuers SHOULD choose the shortest lifetime the task permits, and SHOULD rely on revocation rather than on long lifetimes to avoid disruption, since revocation is what bounds the exposure of a compromised token regardless of the lifetime it was issued with.¶

Session binding says nothing about replay of the same token within its session. Whether a presenter may present one token for two requests is an application-layer question on which HDP takes no position. Applications for which it matters SHOULD record the requests each token has accompanied, for example by retaining a hash of each request until the token expires, and reject repeats.¶

Because session_id anchors the session-binding defense, it SHOULD be unguessable: issuers SHOULD generate session_id values with at least 128 bits of entropy from a cryptographically secure random source. A predictable session_id weakens replay protection.¶

10.6. Revocation

A verifier MUST support being instructed to stop honouring a token. The instruction identifies the token by header.token_id; the verifier records that identifier in local revocation state and thereafter rejects the token at Step 2 of the live acceptance pipeline (Section 5). Revocation MUST NOT prevent separate historical integrity verification (Section 5.1). No central registry, no publication mechanism, and no network access at verification time are involved. The revocation state is held by the verifier, as the session_id already is, and verification remains fully offline (Section 10.11).¶

HDP does not specify who may revoke, how the instruction reaches the verifier, or the retention period for revocation evidence; these are verifier policy. Retaining an entry until the corresponding token's expires_at is sufficient for live rejection, since the token is rejected on expiry thereafter. Historical audit may require longer retention of revocation events and effective times, as described in Section 5.1. The range of reasonable policies is illustrated by existing capability systems: UCAN allows a delegator to revoke and makes the right to revoke itself delegable, and ZCAP-LD allows any delegator in a chain to revoke what it delegated.¶

Some designs obtain bounded revocation freshness differently, by requiring the verifier to fetch a short-lived status assertion from the issuer before honouring a token. HDP does not, because that makes every verification depend on the issuer being reachable. The trade is deliberate: HDP keeps verification offline and leaves the freshness of revocation state to whoever populates it.¶

Revocation is per token, not per hop. There is no mechanism to revoke authorization for a single delegate in the middle of an otherwise valid chain while leaving the token valid; the token is revoked and, if the task is to continue, re-authorized (Section 6). Deployments that require per-delegate revocation SHOULD layer a capability system that supports cascade revocation at the application layer. Retaining accountability for each delegate (for example through distinct per-hop identifiers, Section 9.1) is what makes such application-layer revocation actionable.¶

A consequence of any revocation mechanism is that proof an action was authorized is not, by itself, proof that the authorization was still current when the action was taken. An auditor reading a token after the fact cannot tell from the token whether it had been revoked at a verifier; that information lives in the verifier's state and SHOULD be retained alongside stored tokens where audit requires it.¶

10.7. Delegation Budgets and Off-Record Delegation

The scope.max_hops field (Section 3.3) creates an incentive that works against the purpose of this protocol, and issuers need to understand it before setting the field. When an application gates actions on a valid chain and the hop budget is exhausted, an agent that still needs to delegate has two options: seek re-authorization (Section 6), or delegate without appending a hop. The second is off-record delegation. It produces a chain that verifies, an action that occurred, and no record connecting them, which is the worst outcome a provenance protocol can produce. A limit meant to constrain delegation instead constrains the recording of it.¶

The usual motivation for limiting delegation depth is to bound the cost of verifying, storing, or reasoning about long chains. That is a verifier concern and belongs at the verifier: a verifier MAY reject or flag chains longer than a locally configured limit, as a heuristic it controls and can adjust without reissuing tokens. Placing the limit in the token binds every verifier to a number chosen at issuance and hands the incentive above to every agent that carries the token.¶

Accordingly, issuers SHOULD omit max_hops unless the delegation budget is itself part of what the human declared and recording it has evidentiary value. Where the field is set, applications SHOULD make re-authorization readily available to agents that exhaust it, so that the honest path is not more costly than the off-record one. The field is retained in v0.1 because it is optional and because, where a human did declare a budget, the declaration is provenance.¶

10.8. Attribution Across Concurrent Tokens

An agent may hold more than one valid HDP token whose scope covers the same resource: for example, one issued for Alice authorizing a read of a dataset and one issued for Carol authorizing an update to it. Applications MUST bind an action or attempted action to the task and token that actually triggered it, and agents MUST record it under that context. They MUST NOT select a different token merely because its scope would make the action appear authorized. A deviation from the triggering token's scope SHOULD be recorded under that token, explicitly identified as an attempted, blocked, or observed violation in action_summary. Recording the deviation does not amend scope or assert that the principal approved it. If the triggering context is unknown, the application MUST preserve that uncertainty in its audit record rather than assign an unrelated principal.¶

HDP cannot detect a violation of this rule. A hop appended to the wrong token verifies at every step of the pipeline, because the pipeline establishes that the hop was recorded, not that it was recorded in the right place. The consequence is borne at audit: an update performed in Carol's task but recorded under Alice's token misattributes the triggering context and leaves Carol's token silent. Conversely, an update that actually occurred in Alice's read-only task belongs in Alice's task record as a violation; it MUST NOT be moved to Carol's token to make it appear permitted. A signed record alone cannot prove correct task attribution, and inclusion of an action MUST NOT be interpreted as proof that the principal approved it.¶

Where more than one task could legitimately initiate an action, selecting the initiating task is application policy. Applications SHOULD define and record that choice before execution, together with a request or event identifier. Once selected, the triggering context governs provenance even if the action deviates from its scope. Multi-principal delegation (Section 7) does not address this case: it covers tokens linked by parent_token_id that share a session_id, and the tokens here are unrelated. The neighbouring question of how a service decides which of several grants applies to a request is an authorization-layer question and is outside HDP (Section 1.1).¶

10.9. Prompt Injection

Prompt injection attacks attempt to cause an agent to act as if it received instructions from a legitimate principal, when in fact the instructions originate from adversarial content in the agent's environment (e.g., a malicious web page or document). HDP mitigates but does not fully prevent this attack.¶

Applications SHOULD detect and block actions that contradict the human's declared scope using their own enforcement mechanisms. The semantic comparison is application-defined. Blocking an action MUST NOT require suppressing its evidence: an HDP-aware agent SHOULD record the attempted action, the detected scope deviation, and whether it was blocked in action_summary under the triggering task's token. If a violation is observed after execution, it SHOULD likewise be recorded as an observed violation, without claiming that the principal approved it or that the signature proves execution. The hop timestamp remains the extension time, not a backdated event time. If the token cannot be extended, for example because its hop budget is exhausted, the application SHOULD retain an integrity-protected incident record linked to the token digest and triggering request. HDP v0.1 adds no status field for this purpose; the distinction is explicit in the declaration.¶

The mitigation HDP provides is evidentiary: an HDP-aware agent records each delegation action it takes as a signed hop, so an action carried out under a legitimately issued token leaves an auditable record, supporting post-hoc detection of prompt injection. This mitigation depends on agents actually recording their actions; an agent that omits a hop is discussed in Section 10.4.¶

10.10. Key Management

The security of all HDP guarantees depends on the confidentiality of the issuer's Ed25519 private key. Implementations MUST:¶

• Store private keys in a secrets manager, HSM, or equivalent secure enclave. Private keys MUST NOT be stored in source code, configuration files, or environment variables in production.¶
• Use distinct key pairs per environment (development, staging, production).¶
• Support key rotation by issuing new tokens with a new kid while maintaining the old public key in the verifier's registry until all tokens signed with it have expired. Applications requiring historical audit SHOULD retain trusted public keys and relevant compromise history for the audit retention period (Section 5.1). This does not require retaining retired private keys.¶

10.11. Offline Verification Guarantee

HDP makes a strong architectural guarantee: a correct implementation of the 7-step verification pipeline requires no network calls, no registry lookups, and no third-party contact. The complete trust state required for verification is:¶

• The issuer's Ed25519 public key (32 bytes).¶
• The current session identifier (string).¶
• The current time (for expiry checking).¶
• The verifier's own revocation state: a set of token_id values, possibly empty (Section 10.6).¶

This guarantee is a property of the verification procedure, not of the single-key signing model of v0.1. Per-agent hop signing on the pattern described in Section 4.2 would preserve it, since the verifier would still resolve only the issuer's key out of band.¶

This guarantee enables HDP verification in air-gapped environments, edge deployments with intermittent connectivity, and latency-sensitive contexts where a network round-trip before every action is unacceptable.¶

11.1. HTTP Header Field Registration

This document requests registration of the following HTTP header fields in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at <https://www.iana.org/assignments/http-fields/>.¶

Header Field Name:

HDP-Token¶

Status:

provisional¶

Reference:

This document, Section 8.1¶

Comments:

Carries a base64url-encoded HDP token for agentic delegation provenance.¶

Header Field Name:

HDP-Token-Ref¶

Status:

provisional¶

Reference:

This document, Section 8.2¶

Comments:

Carries a UUID token_id identifying an immutable token snapshot, or a sha256 content-addressed reference to a complete HDP token.¶

11.2. Media Type Registration

This document requests registration of the application/hdp-token+json media type in the "Media Types" registry, following the procedures of [RFC6838].¶

Type name:

application¶

Subtype name:

hdp-token+json¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary; the token is a UTF-8 JSON object [RFC8259].¶

Security considerations:

See Section 10 of this document.¶

Interoperability considerations:

The token uses the "+json" structured syntax suffix [RFC6839]; generic JSON processors can parse it. HDP-specific semantics are defined in this document.¶

Published specification:

This document.¶

Applications that use this media type:

Agentic AI frameworks and services that exchange HDP delegation-provenance tokens.¶

Fragment identifier considerations:

N/A¶

Additional information:

Deprecated alias names: none. Magic number(s): none. File extension(s): none. Macintosh file type code(s): none.¶

Person & email address to contact for further information:

Asiri Dalugoda <protocol@helixar.ai>¶

Intended usage:

COMMON¶

Restrictions on usage:

None¶

Author:

Asiri Dalugoda¶

Change controller:

IETF¶

11.3. Well-Known URI Registration

This document requests registration of the following entry in the "Well-Known URIs" registry, per [RFC8615].¶

URI suffix:

hdp-keys.json¶

Change controller:

IETF¶

Specification document:

This document, Section 8.3¶

Status:

provisional¶

Related information:

Serves a JSON document listing an issuer's Ed25519 public keys for HDP token verification.¶

12.1. IPP (draft-haberkamp-ipp-01)

The Intent Provenance Protocol [I-D.haberkamp-ipp] and HDP address the same root problem with different architectural trade-offs. The key differences are:¶

1. Revocation model. IPP -01 Section 8 describes its revocation registry as a distributed service at an endpoint specified by the token. IPP requires agents to poll at the configured interval, with a recommended default of 5,000 milliseconds; for high-stakes actions IPP recommends an additional check immediately before acting. When the registry is unreachable, IPP permits action only if the token supplies offline_grace_period_ms and the offline duration remains within that period. Otherwise IPP prohibits proceeding. HDP instead consults verifier-local revocation state at verification time (Section 10.6). HDP does not require polling, but it also provides no protocol-defined bound on the freshness of that local state.¶
2. Trust anchor. IPP tokens contain a genesis object (the Genesis Seal), a cryptographic artifact linking every token to the specification author's public key at https://ipp.khsovereign.com/keys/founding_public.pem. Self-hosted IPP deployments are cryptographically bound to this third-party key. HDP tokens carry no genesis seal and no spec-level attribution; any organization can issue and verify HDP tokens without anchoring to a third party.¶
3. Identity model. IPP mandates W3C DID Core-conformant principal identifiers. HDP supports id_type: "opaque" as a first-class option, making DID infrastructure optional rather than required.¶

These are design choices, not defects. Deployments with reliable connectivity to a revocation service, existing DID infrastructure, and a requirement for revocation across token ancestry may prefer IPP. Deployments that prioritize offline operability, self-sovereignty, and minimal infrastructure may prefer HDP.¶

12.2. OAuth 2.0 Token Exchange (RFC 8693)

OAuth 2.0 Token Exchange [RFC8693] defines a mechanism for exchanging one security token for another, including delegation and impersonation use cases. HDP and RFC 8693 are complementary rather than competing: RFC 8693 governs access token issuance and delegation in an OAuth 2.0 authorization server context, while HDP governs the provenance record that travels with an agentic task regardless of the authentication mechanism used.¶

HDP tokens do not replace OAuth access tokens. An agent framework MAY use OAuth 2.0 for resource authorization and HDP for delegation provenance simultaneously.¶

12.3. JSON Web Token (RFC 7519)

JSON Web Token [RFC7519] provides a general-purpose signed claims format. HDP differs from JWT in three respects:¶

• HDP tokens carry an append-only, per-hop-signed delegation chain (chain) that has no equivalent in the JWT standard claims set.¶
• HDP uses RFC 8785 canonical JSON for signing payloads, rather than the base64url-encoded header.payload convention used by JWS [RFC7515]. This allows direct JSON manipulation without base64 decoding.¶
• HDP's verification pipeline is domain-specific to agentic delegation (session binding, hop verification, max_hops) rather than general-purpose.¶

12.4. UCAN (User Controlled Authorization Networks)

UCAN [UCAN] defines a capability-based authorization token system with chained delegation. HDP and UCAN share the concept of delegation chains but differ significantly in scope: UCAN is a general capability authorization system, while HDP is specifically a provenance record for human-authorized agentic tasks. HDP makes no claims about capability enforcement; UCAN tokens carry executable capabilities that are enforced by receiving systems.¶

A UCAN delegation records the authorization provenance of a capability: who delegated what to whom. UCAN's separate Invocation and Receipt objects can record individual invocations and their results; HDP instead keeps the execution record inline in the delegation chain itself, as the signed action_summary declared at each hop, so that the human authorization and the subsequent declared actions travel together in a single offline-verifiable record. In this sense HDP complements capability systems rather than competing with them: a deployment MAY use UCAN (or ZCAP-LD, below) for capability delegation and HDP alongside it for the tamper-evident execution record.¶

12.5. ZCAP-LD (Authorization Capabilities for Linked Data)

ZCAP-LD [W3C.ZCAP-LD] expresses delegated authorization capabilities as Linked Data, with invocation and delegation rooted in a controller's key. As with UCAN, a ZCAP-LD delegation chain captures the authorization provenance of a capability but not a record of the delegate's subsequent actions. HDP neither defines nor enforces capabilities; it records the human authorization event and the subsequent execution history. Deployments that already use ZCAP-LD MAY use HDP alongside it to supply the execution audit trail ZCAP-LD does not itself provide.¶

12.6. ODRL and the Verifiable Credentials Data Model

The Open Digital Rights Language (ODRL) [W3C.ODRL] is a W3C Recommendation for expressing permissions, prohibitions, and constraints. Several fields in HDP's scope object (Section 3.3) overlap with concepts ODRL already defines: authorized_tools and authorized_resources correspond to ODRL actions and targets, network_egress and persistence map to ODRL permissions or prohibitions, and quantitative limits such as max_hops map to ODRL constraints.¶

HDP v0.1 deliberately retains a small, self-contained scope object rather than embedding an ODRL policy. The trade-off is explicit: the minimal object keeps tokens compact and implementable with only JSON and Ed25519, at the cost of the vocabulary reuse, policy composability, and tooling interoperability that ODRL provides. Deployments that already reason over ODRL policies will require a separate mapping to interpret HDP scopes.¶

A further limitation of the v0.1 scope object is that it is fixed at issuance. HDP has no attenuation: a delegate cannot narrow the scope at its own hop, because hops record actions rather than grants and a hop record has no field in which a narrower scope could be expressed. A delegate that wishes to pass on less than it received must obtain a new token from the issuer with a narrower scope. Per-hop caveats, which only the verifier and any attenuating agent would need to interpret, are planned for a future version.¶

Because the chain-of-custody mechanism is payload-agnostic (Section 1.5), a future HDP profile MAY carry an ODRL policy as its payload in place of the native scope object. Such a profile would gain a natural binding to the Verifiable Credentials Data Model 2.0 [W3C.VC-DATA-MODEL-2.0], whose termsOfUse property can carry ODRL policies. This binding is identified as future work and is not specified in this document.¶