Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-Custody for Agentic AI Systems
draft-helixar-hdp-agentic-delegation-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Asiri Dalugoda | ||
| Last updated | 2026-08-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-helixar-hdp-agentic-delegation-01
Network Working Group A. Dalugoda
Internet-Draft Helixar Limited
Intended status: Informational 3 August 2026
Expires: 4 February 2027
Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-
Custody for Agentic AI Systems
draft-helixar-hdp-agentic-delegation-01
Abstract
Agentic AI systems operate on behalf of human principals, often
delegating tasks through multi-step chains of AI agents. There is
currently no standard mechanism to record who authorized an agent to
act, under what scope, and through what chain of delegation, in a way
that can be verified offline, without a central registry, and without
third-party trust anchors.
This document specifies the Human Delegation Provenance Protocol
(HDP) version 0.1, a lightweight token-based protocol that captures,
structures, cryptographically signs, and verifies human delegation
context in agentic AI systems. An HDP token binds a human
authorization event to a session, records each agent's delegation
action as a signed hop in an append-only chain, and enables any
participant to verify the full provenance record using only the
issuer's Ed25519 public key and the current session identifier.
Verification is fully offline. No registry lookup, no network call,
and no third-party trust anchor is required.
HDP's distinguishing contribution is a signed, tamper-evident record
of each agent's declared action at each hop, an execution audit trail
that complements, rather than replaces, capability-based delegation
formats such as UCAN and ZCAP-LD. The underlying append-only,
offline-verifiable chain-of-custody mechanism is payload-agnostic;
human-authorized agentic delegation is the reference profile
specified in this document.
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/.
Dalugoda Expires 4 February 2027 [Page 1]
Internet-Draft HDP Agentic Delegation August 2026
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 4 February 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Relationship to IPP (draft-haberkamp-ipp-01) . . . . . . 5
1.4. Generality of the Chain-of-Custody Mechanism . . . . . . 5
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. Token Structure . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Principal . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Chain . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Cryptographic Signing . . . . . . . . . . . . . . . . . . . . 10
4.1. Root Signature . . . . . . . . . . . . . . . . . . . . . 10
4.2. Hop Signature . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Chain Integrity Rules . . . . . . . . . . . . . . . . . . 12
5. Verification Pipeline . . . . . . . . . . . . . . . . . . . . 12
6. Re-Authorization . . . . . . . . . . . . . . . . . . . . . . 14
7. Multi-Principal Delegation . . . . . . . . . . . . . . . . . 14
8. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. HTTP Header: HDP-Token . . . . . . . . . . . . . . . . . 15
8.2. Token by Reference: HDP-Token-Ref . . . . . . . . . . . . 15
8.3. Key Distribution: Well-Known Endpoint . . . . . . . . . . 16
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. Minimum-Disclosure Principal Fields . . . . . . . . . . . 16
Dalugoda Expires 4 February 2027 [Page 2]
Internet-Draft HDP Agentic Delegation August 2026
9.2. Data Retention and the Right to Erasure . . . . . . . . . 17
9.3. Proof of Humanity . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 18
10.2. Token Forgery . . . . . . . . . . . . . . . . . . . . . 18
10.3. Chain Tampering . . . . . . . . . . . . . . . . . . . . 18
10.4. Chain Truncation and Completeness . . . . . . . . . . . 18
10.5. Replay Attack Defense . . . . . . . . . . . . . . . . . 19
10.6. Revocation Considerations . . . . . . . . . . . . . . . 19
10.7. Prompt Injection . . . . . . . . . . . . . . . . . . . . 20
10.8. Key Management . . . . . . . . . . . . . . . . . . . . . 20
10.9. Offline Verification Guarantee . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11.1. HTTP Header Field Registration . . . . . . . . . . . . . 21
11.2. Media Type Registration . . . . . . . . . . . . . . . . 21
11.3. Well-Known URI Registration . . . . . . . . . . . . . . 22
12. Comparison with Related Work . . . . . . . . . . . . . . . . 22
12.1. IPP (draft-haberkamp-ipp-01) . . . . . . . . . . . . . . 23
12.2. OAuth 2.0 Token Exchange (RFC 8693) . . . . . . . . . . 23
12.3. JSON Web Token (RFC 7519) . . . . . . . . . . . . . . . 24
12.4. UCAN (User Controlled Authorization Networks) . . . . . 24
12.5. ZCAP-LD (Authorization Capabilities for Linked Data) . . 24
12.6. ODRL and the Verifiable Credentials Data Model . . . . . 25
13. Normative References . . . . . . . . . . . . . . . . . . . . 25
14. Informative References . . . . . . . . . . . . . . . . . . . 26
Appendix A. Complete Token Example . . . . . . . . . . . . . . . 28
Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
Autonomous AI agents are increasingly used to execute consequential
actions: sending emails, modifying files, running code, calling APIs,
and transacting on behalf of users. When a human authorizes an
orchestrator agent, which in turn delegates to sub-agents, which
further delegate to tool-execution agents, the originating human
authorization becomes disconnected from the terminal action. There
is no standard record of the authorization chain.
This gap creates accountability, auditability, and safety problems:
* Downstream agents cannot verify that the action they are being
asked to perform was actually authorized by a human.
* Post-hoc audits cannot reconstruct who approved what, and when.
Dalugoda Expires 4 February 2027 [Page 3]
Internet-Draft HDP Agentic Delegation August 2026
* Prompt injection attacks (where malicious content in the
environment instructs an agent to act) cannot be distinguished
from legitimate human delegation.
HDP addresses this by defining a token that:
* Records the human principal, their declared scope, and the session
binding at issuance.
* Accumulates a cryptographically signed hop record for each agent
that handles the token.
* Allows any recipient to verify the entire chain (root signature
plus all hop signatures) using only the issuer's Ed25519 public
key and the session identifier.
1.1. 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.2. Design Goals
HDP is designed with the following goals in order of priority:
1. *Offline verifiability.* Verification MUST require only a public
key and session ID. 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.
Dalugoda Expires 4 February 2027 [Page 4]
Internet-Draft HDP Agentic Delegation August 2026
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.3. 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.4. 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.
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
[RFC2119] and [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Dalugoda Expires 4 February 2027 [Page 5]
Internet-Draft HDP Agentic Delegation August 2026
Issuer: The system or person that creates and signs an HDP token on
behalf of a human principal.
Principal: The human who authorized the agentic task. Represented
in the token's principal object.
Agent: Any AI system, model, or automated process that receives and
acts upon an HDP token.
Hop: A single delegation event, recorded as a signed entry in the
token's chain array.
Root signature: The Ed25519 signature over the token's header,
principal, and scope, computed by the issuer at token creation
time.
Hop signature: The Ed25519 signature over the cumulative chain state
at the time of extension. In HDP v0.1 it is produced by the
issuer using the same key as the root signature.
Session: A logical unit of work identified by a session_id string,
established between the issuer and the agent framework before the
token is issued.
3. Token Structure
An HDP token is a JSON object with six top-level fields. The token
MUST conform to the following structure. All integer timestamps are
Unix milliseconds (milliseconds since 1970-01-01T00:00:00Z).
{
"hdp" : "0.1", // protocol version
"header" : { ... }, // session binding + lifecycle
"principal" : { ... }, // authorizing human
"scope" : { ... }, // authorized intent + constraints
"chain" : [ ... ], // delegation hops (append-only)
"signature" : { ... } // root Ed25519 signature
}
Figure 1: HDP Token Top-Level Structure
3.1. Header
The header object carries token lifecycle and session binding fields.
Dalugoda Expires 4 February 2027 [Page 6]
Internet-Draft HDP Agentic Delegation August 2026
{
"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. Token MUST NOT be
accepted after this time. Default lifetime is 24 hours.
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].
Dalugoda Expires 4 February 2027 [Page 7]
Internet-Draft HDP Agentic Delegation August 2026
* 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.
{
"intent" : "Analyze Q1 sales data and report.",
"authorized_tools" : ["database_read", "file_write"],
"authorized_resources" : ["db://sales/q1-2026"],
"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 human-readable authorization
statement.
authorized_tools: OPTIONAL. Array of tool identifiers the principal
has explicitly authorized. Enforcement is application-defined.
authorized_resources: OPTIONAL. Array of resource identifiers
(URIs, paths, etc.) the principal has authorized access to.
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
Dalugoda Expires 4 February 2027 [Page 8]
Internet-Draft HDP Agentic Delegation August 2026
write persistent state.
max_hops: OPTIONAL. Positive integer, chosen by the issuer,
expressing the delegation budget the human authorized for this
token. HDP defines no fixed or maximum value; an issuer MAY set
any positive integer. 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).
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.
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.
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.
action_summary: REQUIRED. Human-readable description of the action
Dalugoda Expires 4 February 2027 [Page 9]
Internet-Draft HDP Agentic Delegation August 2026
this agent intends to take.
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. Cryptographic Signing
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.
Dalugoda Expires 4 February 2027 [Page 10]
Internet-Draft HDP Agentic Delegation August 2026
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.
Dalugoda Expires 4 February 2027 [Page 11]
Internet-Draft HDP Agentic Delegation August 2026
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 has its hop signed by the
issuer, within the same trust domain. This keeps verification
dependent on a single public key (Section 10.9). Per-agent hop
signing, in which each agent signs its own hop with its own key, is a
planned extension for a future version and is not part of v0.1.
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 SHOULD be monotonically non-decreasing.
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. Verification Pipeline
A verifier MUST execute the following seven steps in order. A
failure at any step MUST cause immediate rejection with an
appropriate error. The verifier MUST NOT proceed to subsequent steps
after a failure.
1. *Version check.* The hdp field MUST contain a recognized protocol
version string. For this specification, the only recognized
value is "0.1". The header.version field MUST equal the hdp
field; a mismatch MUST cause rejection.
2. *Expiry check.* The token's header.expires_at MUST be strictly
greater than the current time. Expired tokens MUST be rejected.
3. *Root signature verification.* Reconstruct the canonical JSON
payload by removing the signature field and resetting chain to an
empty array (its value when the root signature was computed),
Dalugoda Expires 4 February 2027 [Page 12]
Internet-Draft HDP Agentic Delegation August 2026
then serializing the remaining token object per RFC 8785. Verify
that signature.alg is Ed25519, then verify the signature in
signature.value against this payload using the issuer's public
key. A failure indicates tampering with the header, principal,
or scope.
4. *Hop sequence and structure integrity.* For each hop in chain,
verify that hop.seq == (index + 1); any gap or duplication MUST
cause rejection. Verify that each hop's parent_hop references
either 0 (the root authorization) or the seq of a prior hop; an
out-of-range parent_hop MUST cause rejection (Rule 3 of
Section 4.3).
5. *Hop signature verification.* For each hop at index i:
a. Verify that hop_signature is present. Absence MUST cause
rejection.
b. Reconstruct the signing payload as described in Section 4.2,
using the hops at indices 0...(i-1) with their signatures,
plus the hop at index i without its hop_signature, prepended
by the root signature value.
c. Serialize the payload per RFC 8785 and verify the
hop_signature against the issuer's public key (the same key
used for the root signature in HDP v0.1).
6. *max_hops check.* If scope.max_hops is defined, the length of
chain MUST NOT exceed it.
7. *Session binding check.* The token's header.session_id MUST
exactly match the session_id provided by the verifying
application. This prevents token replay across sessions. See
Section 10.5.
An optional eighth step MAY be performed if the application has
registered a Proof-of-Humanity verifier: if principal.poh_credential
is present and a verifier callback is configured, the credential MUST
be validated by that callback. See Section 9.3.
Verification is fully offline. Steps 1 through 7 require only the
issuer's Ed25519 public key, the current session identifier, and the
current time (for the expiry check). No network call, registry
lookup, or third-party contact is required at any step.
Dalugoda Expires 4 February 2027 [Page 13]
Internet-Draft HDP Agentic Delegation August 2026
6. Re-Authorization
Long-running or streaming sessions may exhaust the max_hops limit,
require scope expansion, or encounter situations where a high-risk
action warrants fresh human confirmation. In these cases, the issuer
(acting on behalf of the human principal) issues a new token that
supersedes the original.
Re-authorization is indicated by setting header.parent_token_id to
the token_id of the token being superseded. This field MUST be set
before computing the root signature, so the parentage link is
cryptographically covered by the new token's root signature.
A re-authorized token:
* Has a new token_id, issued_at, and expires_at.
* Inherits session_id, principal, and scope from the original unless
explicitly overridden.
* Starts with an empty chain (delegation count resets).
* Records parent_token_id pointing to the original, creating an
auditable lineage of scope evolution.
Verifiers that require re-authorization chain traversal SHOULD retain
all tokens in a session and verify the full parent_token_id linkage.
7. Multi-Principal Delegation
HDP v0.1 supports one principal per token. Joint authorization by
multiple humans is achieved by sequential chaining: Human A issues
token T1; Human B issues token T2 with parent_token_id equal to T1's
token_id. Each token is independently signed with its issuer's key.
To verify a multi-principal chain, the verifier MUST:
1. Verify each token individually against its issuer's public key
using the standard 7-step pipeline.
2. Verify that T[i].header.parent_token_id == T[i-1].header.token_id
for all i > 0.
3. Verify that all tokens in the chain share the same session_id.
Dalugoda Expires 4 February 2027 [Page 14]
Internet-Draft HDP Agentic Delegation August 2026
This pattern provides joint authorization auditably without requiring
a threshold signature scheme. Each principal's authorization is a
distinct signed artifact. A future version of HDP (v0.2) is planned
to introduce simultaneous multi- signature primitives using threshold
signature schemes.
The parent_token_id field thus serves two distinct purposes:
supersession, where a re-authorized token replaces an earlier one
(Section 6), and joint authorization, where both the parent and child
tokens remain valid (this section). HDP v0.1 does not tag which
relationship a given parent_token_id expresses; applications MUST
determine it from context, typically by checking whether the parent
token is still within its validity period and has not been
superseded. A future version may add an explicit relationship type.
Note also that a superseded token's session_id MAY be overridden on
re-authorization, whereas the tokens in a joint-authorization chain
MUST share one session_id.
8. Transport
The HTTP header field names defined below do not use the "X-" prefix,
in accordance with [RFC6648].
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
Figure 2: HDP-Token HTTP Header Example
Implementations MUST NOT include tokens in URL query parameters, as
this exposes sensitive data in server logs and browser history.
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 by its token_id using the HDP-
Token-Ref header.
Dalugoda Expires 4 February 2027 [Page 15]
Internet-Draft HDP Agentic Delegation August 2026
POST /api/task HTTP/1.1
Host: agent.example.com
HDP-Token-Ref: 550e8400-e29b-41d4-a716-446655440000
Figure 3: HDP-Token-Ref HTTP Header Example
Implementations using token-by-reference MUST secure the token store
and use transport-layer security (TLS) for all reference resolution.
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 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. Privacy Considerations
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.
Dalugoda Expires 4 February 2027 [Page 16]
Internet-Draft HDP Agentic Delegation August 2026
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 issuer or extending agent MAY use opaque, per-
delegation identifiers for agent_id. Each delegate can still be held
accountable by the delegator that assigned its identifier, step by
step along the chain, because the opaque agent_id and its
action_summary are bound into the signed, tamper-evident chain,
without exposing a stable real-world identity to downstream
verifiers.
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.
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.
Dalugoda Expires 4 February 2027 [Page 17]
Internet-Draft HDP Agentic Delegation August 2026
10. Security Considerations
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.
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).
Applications that require completeness SHOULD establish the expected
chain length or a terminal marker out of band: for example, by
pairing HDP with an application-layer receipt or settlement step that
Dalugoda Expires 4 February 2027 [Page 18]
Internet-Draft HDP Agentic Delegation August 2026
records the final hop count, by setting scope.max_hops to the exact
expected length where it is known, or by requiring each recipient to
acknowledge the hop count it observed. A signed, monotonic chain-
length commitment is a candidate mechanism for a future version.
10.5. Replay Attack Defense
HDP provides two orthogonal replay defenses:
1. *Expiry.* Tokens are short-lived (expires_at, 24h default). 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 before it expires.
Applications with high security requirements SHOULD use short token
lifetimes (minutes, not hours).
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 Considerations
HDP does not provide mid-chain revocation. The revocation model is
deliberately coarse: a token becomes invalid when it expires
(Section 10.5) or when its session ends. There is no mechanism to
revoke authorization for a single delegate in the middle of an
otherwise valid chain without invalidating the whole token and re-
authorizing (Section 6).
A consequence is that proof that an action was authorized is not, by
itself, sufficient to determine whether that authorization is still
current. Deployments that require fine-grained, mid-chain revocation
SHOULD keep token lifetimes short and rely on re-authorization, or
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.
Dalugoda Expires 4 February 2027 [Page 19]
Internet-Draft HDP Agentic Delegation August 2026
10.7. 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.
An HDP-aware agent SHOULD refuse to extend a token's chain with an
action_summary that contradicts the token's scope.intent. However,
the protocol cannot enforce this semantically; the comparison between
action intent and token scope is application-defined.
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.8. 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 key in the verifier's registry until all
tokens signed with it have expired.
10.9. 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).
Dalugoda Expires 4 February 2027 [Page 20]
Internet-Draft HDP Agentic Delegation August 2026
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. IANA Considerations
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 the UUID token_id of an HDP token stored by
reference.
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].
Dalugoda Expires 4 February 2027 [Page 21]
Internet-Draft HDP Agentic Delegation August 2026
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. Comparison with Related Work
Dalugoda Expires 4 February 2027 [Page 22]
Internet-Draft HDP Agentic Delegation August 2026
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 requires agents to poll a central
revocation registry at a configurable endpoint before every
action, with a recommended interval of 5,000 milliseconds. If
the registry is unreachable, agents cannot safely act. HDP uses
short-lived tokens with session_id binding as the revocation
mechanism; no registry polling is required at any point.
2. *Trust anchor.* IPP tokens contain a 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 central registry, existing DID infrastructure, and
a requirement for mid-chain revocation 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.
Dalugoda Expires 4 February 2027 [Page 23]
Internet-Draft HDP Agentic Delegation August 2026
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
Dalugoda Expires 4 February 2027 [Page 24]
Internet-Draft HDP Agentic Delegation August 2026
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.
Because the chain-of-custody mechanism is payload-agnostic
(Section 1.4), 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.
13. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
Dalugoda Expires 4 February 2027 [Page 25]
Internet-Draft HDP Agentic Delegation August 2026
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/rfc/rfc9562>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
14. Informative References
[I-D.haberkamp-ipp]
Haberkamp, A., "Intent Provenance Protocol (IPP)", Work in
Progress, Internet-Draft, draft-haberkamp-ipp-01, July
2026, <https://datatracker.ietf.org/doc/html/draft-
haberkamp-ipp-01>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
Liu, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[W3C.DID] Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele,
O., and C. Allen, "Decentralized Identifiers (DIDs) v1.0",
W3C Recommendation did-core, July 2022,
<https://www.w3.org/TR/did-core/>.
[HDP-SPEC] Helixar Limited, "Human Delegation Provenance Protocol
v0.1 Specification", 2026, <https://helixar.ai/labs/hdp>.
Dalugoda Expires 4 February 2027 [Page 26]
Internet-Draft HDP Agentic Delegation August 2026
[HDP-IMPL] Helixar Limited, "HDP TypeScript Reference
Implementation", 2026,
<https://github.com/Helixar-AI/HDP>.
[W3C.ODRL] Iannella, R. and S. Villata, "ODRL Information Model 2.2",
W3C Recommendation odrl-model, February 2018,
<https://www.w3.org/TR/odrl-model/>.
[W3C.VC-DATA-MODEL-2.0]
Sporny, M., Thibodeau, T., Herman, I., Jones, M., and G.
Cohen, "Verifiable Credentials Data Model v2.0", W3C
Recommendation vc-data-model-2.0, May 2025,
<https://www.w3.org/TR/vc-data-model-2.0/>.
[W3C.ZCAP-LD]
Lemmer Webber, C. and M. Miller, "Authorization
Capabilities for Linked Data", W3C Community Group Report
zcap-ld, 2023, <https://w3c-ccg.github.io/zcap-spec/>.
[UCAN] UCAN Working Group, "User Controlled Authorization
Networks (UCAN) Specification", 2024,
<https://github.com/ucan-wg/spec>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/rfc/rfc5321>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
Structured Syntax Suffixes", RFC 6839,
DOI 10.17487/RFC6839, January 2013,
<https://www.rfc-editor.org/rfc/rfc6839>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648,
DOI 10.17487/RFC6648, June 2012,
<https://www.rfc-editor.org/rfc/rfc6648>.
Dalugoda Expires 4 February 2027 [Page 27]
Internet-Draft HDP Agentic Delegation August 2026
Appendix A. Complete Token Example
The following is a complete HDP token with a two-hop delegation
chain, for illustrative purposes. Signature values are truncated.
{
"hdp": "0.1",
"header": {
"token_id" : "550e8400-e29b-41d4-a716-446655440000",
"issued_at" : 1711483200000,
"expires_at" : 1711569600000,
"session_id" : "sess-20260326-abc123",
"version" : "0.1"
},
"principal": {
"id" : "usr_alice_opaque",
"id_type" : "opaque",
"display_name" : "Alice Chen"
},
"scope": {
"intent" : "Analyze Q1 sales data and report.",
"authorized_tools" : ["database_read", "file_write"],
"data_classification" : "confidential",
"network_egress" : false,
"persistence" : true,
"max_hops" : 10
},
"chain": [
{
"seq" : 1,
"agent_id" : "orchestrator-v2",
"agent_type" : "orchestrator",
"timestamp" : 1711483260000,
"action_summary" : "Decompose task; delegate to sub-agents.",
"parent_hop" : 0,
"hop_signature" : "base64url-sig-1..."
},
{
"seq" : 2,
"agent_id" : "sql-agent-v1",
"agent_type" : "sub-agent",
"timestamp" : 1711483320000,
"action_summary" : "Execute read query on sales database.",
"parent_hop" : 1,
"hop_signature" : "base64url-sig-2..."
}
],
"signature": {
Dalugoda Expires 4 February 2027 [Page 28]
Internet-Draft HDP Agentic Delegation August 2026
"kid" : "alice-signing-key-v1",
"alg" : "Ed25519",
"value" : "base64url-root-sig..."
}
}
Change Log
This section will be removed before publication as an RFC.
draft-helixar-hdp-agentic-delegation-01: Incorporates review
feedback from the W3C Credentials Community Group and a
specification-consistency pass. Related Work (Section 12)
expanded with ODRL, a Verifiable Credentials Data Model 2.0
termsOfUse alignment note, and ZCAP-LD; the UCAN comparison
identifies the execution audit trail as HDP's distinguishing
contribution. Added Section 1.4 (payload-agnostic chain-of-
custody with agentic delegation as the reference profile).
Corrected root signature verification to reset chain to empty
before canonicalization, matching the signing procedure, and
clarified that in v0.1 the issuer produces all root and hop
signatures with a single key. Added Section 10.4 (chain
truncation and completeness), Section 10.6 (revocation),
session_id entropy guidance, and per-hop opaque-identifier privacy
guidance (Section 9.1). The verification pipeline now also checks
header.version, signature.alg, and parent_hop validity. Completed
the IANA media-type registration template and added a Well-Known
URI registration. Added missing normative and informative
references. Renamed the HTTP header fields from X-HDP-Token and
X-HDP-Token-Ref to HDP-Token and HDP-Token-Ref ([RFC6648]).
Editorial corrections. The token wire format is unchanged and
remains HDP v0.1; the HTTP header field names changed.
draft-helixar-hdp-agentic-delegation-00: Initial submission.
Specifies HDP v0.1 token structure, signing, verification
pipeline, re-authorization, multi-principal delegation, transport,
privacy considerations, and security analysis.
Author's Address
Asiri Dalugoda
Helixar Limited
Email: protocol@helixar.ai
URI: https://helixar.ai
Dalugoda Expires 4 February 2027 [Page 29]