Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-Custody for Agentic AI Systems
draft-helixar-hdp-agentic-delegation-02
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-09-11 | ||
| 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-02
Network Working Group A. Dalugoda
Internet-Draft Helixar Limited
Intended status: Informational 11 September 2026
Expires: 15 March 2027
Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-
Custody for Agentic AI Systems
draft-helixar-hdp-agentic-delegation-02
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.
HDP is not an authorization protocol. An HDP token confers no
authority and its presentation entitles the presenter to nothing. It
is a record of who authorized a task and of what each agent declared
it did with that authorization, carried with the task and read at
audit.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Dalugoda Expires 15 March 2027 [Page 1]
Internet-Draft HDP Agentic Delegation September 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 15 March 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. What HDP Is Not . . . . . . . . . . . . . . . . . . . . . 4
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Relationship to IPP (draft-haberkamp-ipp-01) . . . . . . 6
1.5. Generality of the Chain-of-Custody Mechanism . . . . . . 6
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6
3. Token Structure . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Principal . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Chain . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Cryptographic Signing . . . . . . . . . . . . . . . . . . . . 12
4.1. Root Signature . . . . . . . . . . . . . . . . . . . . . 12
4.2. Hop Signature . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Chain Integrity Rules . . . . . . . . . . . . . . . . . . 14
5. Verification Pipeline . . . . . . . . . . . . . . . . . . . . 15
5.1. Historical Audit Verification . . . . . . . . . . . . . . 17
6. Re-Authorization . . . . . . . . . . . . . . . . . . . . . . 18
Dalugoda Expires 15 March 2027 [Page 2]
Internet-Draft HDP Agentic Delegation September 2026
7. Multi-Principal Delegation . . . . . . . . . . . . . . . . . 19
8. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. HTTP Header: HDP-Token . . . . . . . . . . . . . . . . . 20
8.2. Token by Reference: HDP-Token-Ref . . . . . . . . . . . . 21
8.3. Key Distribution: Well-Known Endpoint . . . . . . . . . . 22
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
9.1. Minimum-Disclosure Principal Fields . . . . . . . . . . . 23
9.2. Data Retention and the Right to Erasure . . . . . . . . . 24
9.3. Proof of Humanity . . . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 25
10.2. Token Forgery . . . . . . . . . . . . . . . . . . . . . 25
10.3. Chain Tampering . . . . . . . . . . . . . . . . . . . . 25
10.4. Chain Truncation and Completeness . . . . . . . . . . . 25
10.5. Replay Attack Defense . . . . . . . . . . . . . . . . . 27
10.6. Revocation . . . . . . . . . . . . . . . . . . . . . . . 28
10.7. Delegation Budgets and Off-Record Delegation . . . . . . 29
10.8. Attribution Across Concurrent Tokens . . . . . . . . . . 29
10.9. Prompt Injection . . . . . . . . . . . . . . . . . . . . 30
10.10. Key Management . . . . . . . . . . . . . . . . . . . . . 31
10.11. Offline Verification Guarantee . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
11.1. HTTP Header Field Registration . . . . . . . . . . . . . 32
11.2. Media Type Registration . . . . . . . . . . . . . . . . 32
11.3. Well-Known URI Registration . . . . . . . . . . . . . . 33
12. Comparison with Related Work . . . . . . . . . . . . . . . . 33
12.1. IPP (draft-haberkamp-ipp-01) . . . . . . . . . . . . . . 34
12.2. OAuth 2.0 Token Exchange (RFC 8693) . . . . . . . . . . 34
12.3. JSON Web Token (RFC 7519) . . . . . . . . . . . . . . . 35
12.4. UCAN (User Controlled Authorization Networks) . . . . . 35
12.5. ZCAP-LD (Authorization Capabilities for Linked Data) . . 36
12.6. ODRL and the Verifiable Credentials Data Model . . . . . 36
13. Normative References . . . . . . . . . . . . . . . . . . . . 37
14. Informative References . . . . . . . . . . . . . . . . . . . 37
Appendix A. Complete Token Example . . . . . . . . . . . . . . . 39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
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.
Dalugoda Expires 15 March 2027 [Page 3]
Internet-Draft HDP Agentic Delegation September 2026
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.
* 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. 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
Dalugoda Expires 15 March 2027 [Page 4]
Internet-Draft HDP Agentic Delegation September 2026
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.
Dalugoda Expires 15 March 2027 [Page 5]
Internet-Draft HDP Agentic Delegation September 2026
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.
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.
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.
Dalugoda Expires 15 March 2027 [Page 6]
Internet-Draft HDP Agentic Delegation September 2026
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.
Verifier: Any party that checks an HDP token: an agent receiving a
task uses the live acceptance pipeline (Section 5); an audit
system or human reviewer's tooling uses historical audit
verification (Section 5.1).
Presenter: The agent that transmits a token to a verifier. In a
complete chain the presenter is the agent that appended the final
hop.
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).
Before signing or verifying a token, implementations MUST validate
its JSON representation and all REQUIRED fields, types, and
constraints defined in this section. The input MUST satisfy the
I-JSON requirements of RFC 8785, including rejection of duplicate
object member names, invalid Unicode strings, and non-finite numbers.
Duplicate names MUST be detected before parsing discards them.
Values MUST NOT be coerced from strings or booleans to satisfy a
numeric field's type.
The integer fields header.issued_at, header.expires_at, and each
hop's timestamp and parent_hop MUST be in the inclusive range 0
through 9007199254740991 (2^53 - 1). Each hop's seq and
scope.max_hops, when present, MUST be in the inclusive range 1
through 9007199254740991. These are JSON numbers, not strings.
Implementations MUST check their numeric values before any lossy
conversion and MUST reject fractional or out-of-range values rather
than round them. The bounds ensure exact integer representation in
the IEEE 754 double-precision model used by RFC 8785. They are
Dalugoda Expires 15 March 2027 [Page 7]
Internet-Draft HDP Agentic Delegation September 2026
representation bounds, not an operational delegation budget. Other
numeric values, such as numbers inside principal.metadata, remain
subject to RFC 8785.
{
"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.
{
"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
Dalugoda Expires 15 March 2027 [Page 8]
Internet-Draft HDP Agentic Delegation September 2026
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).
Dalugoda Expires 15 March 2027 [Page 9]
Internet-Draft HDP Agentic Delegation September 2026
{
"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.
Dalugoda Expires 15 March 2027 [Page 10]
Internet-Draft HDP Agentic Delegation September 2026
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.
Dalugoda Expires 15 March 2027 [Page 11]
Internet-Draft HDP Agentic Delegation September 2026
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. 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:
Dalugoda Expires 15 March 2027 [Page 12]
Internet-Draft HDP Agentic Delegation September 2026
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.
Dalugoda Expires 15 March 2027 [Page 13]
Internet-Draft HDP Agentic Delegation September 2026
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.
Dalugoda Expires 15 March 2027 [Page 14]
Internet-Draft HDP Agentic Delegation September 2026
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. Verification Pipeline
For live acceptance, a verifier MUST first validate the input as
specified in Section 3, then execute the following seven steps in
order. A failure at any step MUST cause immediate rejection for live
use with an appropriate error; the live acceptance pipeline MUST NOT
proceed to subsequent steps. Historical audit is a separate
procedure defined in Section 5.1. Rejecting live use does not
prohibit that procedure from examining the same record.
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. A verifier MAY reject a
version it no longer supports.
2. *Lifecycle check.* The current time MUST be greater than or equal
to header.issued_at and strictly less than header.expires_at. A
token outside that interval MUST be rejected for live use. The
verifier MUST also consult its local revocation state
(Section 10.6) and MUST reject live use if header.token_id is
present there.
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),
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.
Dalugoda Expires 15 March 2027 [Page 15]
Internet-Draft HDP Agentic Delegation September 2026
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). Verify that each hop's timestamp is greater than
or equal to that of the hop before it; a decrease MUST cause
rejection (Rule 5 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. The callback runs
last because it is application-defined and may be remote, costly, or
side-effecting. Ordering it after Steps 1 through 7 keeps those
steps offline and ensures that no external verifier is invoked for a
token that fails its cryptographic checks.
Verification is fully offline. Steps 1 through 7 require only the
issuer's Ed25519 public key, the current session identifier, the
current time (for the expiry check), and the verifier's own
revocation state (for the lifecycle check). No network call,
registry lookup, or third-party contact is required at any step.
Dalugoda Expires 15 March 2027 [Page 16]
Internet-Draft HDP Agentic Delegation September 2026
A token that passes all seven steps is authentic and intact: its
header, principal, and scope are as the issuer signed them, and every
recorded hop is as the issuer recorded it. Passing verification
establishes nothing about whether the presenter may perform any
action. That determination is made by the application's own
authorization mechanism, to which the verified token is an input
(Section 1.1).
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
Dalugoda Expires 15 March 2027 [Page 17]
Internet-Draft HDP Agentic Delegation September 2026
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.
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.
Dalugoda Expires 15 March 2027 [Page 18]
Internet-Draft HDP Agentic Delegation September 2026
Re-authorization is a lineage mechanism, not a revocation mechanism.
Issuing a superseding token does not invalidate the token it
supersedes: the original remains eligible for live acceptance until
its expires_at unless revoked, and verifiers are not notified that it
has been superseded. Both records remain available for historical
integrity verification (Section 5.1). An issuer that requires the
superseded token to stop being honoured MUST revoke its token_id at
the verifiers concerned (Section 10.6), in addition to issuing the
replacement.
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 live acceptance pipeline, or historical audit
verification when examining past records.
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.
4. Obtain trusted application context that identifies each parent-
child relationship as joint authorization, as described below.
Without that context, report linked records with an unknown
relationship, not established joint authorization.
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.
An alternative to chaining is composition: each principal issues an
independent token, and the verifier's policy requires that both be
presented. Composition is more general and composes further
downstream, and a verifier MAY adopt it. Chaining is specified here
because T2 signs a reference to T1, making the linkage part of the
record. The link alone does not state that the authorizations were
conjunctive or approved the same action; that meaning requires the
application context below. Composition can also provide auditable
evidence when an authenticated receipt binds both token digests to
Dalugoda Expires 15 March 2027 [Page 19]
Internet-Draft HDP Agentic Delegation September 2026
the request and the policy requiring them. Without such retained
context, neither a bare parent link nor two independent tokens
establishes joint approval.
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
obtain its meaning from trusted, explicit context, such as an
authenticated issuance record identifying the parent, child, and
relationship type. Expiry, revocation, principal equality, and
session equality alone MUST NOT be used to infer that meaning: a
superseded token can remain valid, and a joint-authorization token
can later expire or be revoked. Applications requiring audit MUST
retain this context, with integrity protection and a binding to each
token's issuer public key and root signature, alongside the tokens.
This binding remains stable as the chains are extended. In its
absence, auditors MUST report the relationship as unknown. 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.
Dalugoda Expires 15 March 2027 [Page 20]
Internet-Draft HDP Agentic Delegation September 2026
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
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.
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
Dalugoda Expires 15 March 2027 [Page 21]
Internet-Draft HDP Agentic Delegation September 2026
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.
Dalugoda Expires 15 March 2027 [Page 22]
Internet-Draft HDP Agentic Delegation September 2026
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.
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.
Dalugoda Expires 15 March 2027 [Page 23]
Internet-Draft HDP Agentic Delegation September 2026
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.
Dalugoda Expires 15 March 2027 [Page 24]
Internet-Draft HDP Agentic Delegation September 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. 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).
Dalugoda Expires 15 March 2027 [Page 25]
Internet-Draft HDP Agentic Delegation September 2026
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
Dalugoda Expires 15 March 2027 [Page 26]
Internet-Draft HDP Agentic Delegation September 2026
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.
Dalugoda Expires 15 March 2027 [Page 27]
Internet-Draft HDP Agentic Delegation September 2026
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.
Dalugoda Expires 15 March 2027 [Page 28]
Internet-Draft HDP Agentic Delegation September 2026
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.
Dalugoda Expires 15 March 2027 [Page 29]
Internet-Draft HDP Agentic Delegation September 2026
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.
Dalugoda Expires 15 March 2027 [Page 30]
Internet-Draft HDP Agentic Delegation September 2026
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.
Dalugoda Expires 15 March 2027 [Page 31]
Internet-Draft HDP Agentic Delegation September 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 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
Dalugoda Expires 15 March 2027 [Page 32]
Internet-Draft HDP Agentic Delegation September 2026
[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. Comparison with Related Work
Dalugoda Expires 15 March 2027 [Page 33]
Internet-Draft HDP Agentic Delegation September 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 -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.
Dalugoda Expires 15 March 2027 [Page 34]
Internet-Draft HDP Agentic Delegation September 2026
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.
Dalugoda Expires 15 March 2027 [Page 35]
Internet-Draft HDP Agentic Delegation September 2026
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.
Dalugoda Expires 15 March 2027 [Page 36]
Internet-Draft HDP Agentic Delegation September 2026
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>.
[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>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/rfc/rfc6234>.
[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
Dalugoda Expires 15 March 2027 [Page 37]
Internet-Draft HDP Agentic Delegation September 2026
[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/about/labs/hdp/>.
[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>.
Dalugoda Expires 15 March 2027 [Page 38]
Internet-Draft HDP Agentic Delegation September 2026
[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>.
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.
The scope lists a resource for each tool that acts on one, and each
hop names the resource it declares acting on; Section 3.3 explains
why v0.1 cannot bind tools to resources structurally.
{
"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"],
Dalugoda Expires 15 March 2027 [Page 39]
Internet-Draft HDP Agentic Delegation September 2026
"authorized_resources": ["db://sales/q1-2026",
"file://reports/"],
"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 db://sales/q1-2026.",
"parent_hop" : 1,
"hop_signature" : "base64url-sig-2..."
}
],
"signature": {
"kid" : "alice-signing-key-v1",
"alg" : "Ed25519",
"value" : "base64url-root-sig..."
}
}
Acknowledgments
Alan Karp reviewed successive revisions of this document in detail.
The verifier-local revocation model (Section 10.6), the treatment of
delegation budgets (Section 10.7), the recursive accountability
argument and the guidance on delegate identifiers (Section 9.1), the
correction to the stated cost of single-key signing (Section 4.2),
and the insistence that this document say plainly what HDP is not
(Section 1.1) all result from those reviews.
Brigitte Qirong LI supplied the characterization of a single-key hop
signature as recording a delegation rather than evidencing consent to
it (Section 4.2), and the exchange on the W3C Credentials Community
Group list sharpened the analysis of chain truncation (Section 10.4).
Dalugoda Expires 15 March 2027 [Page 40]
Internet-Draft HDP Agentic Delegation September 2026
Bob Wyman and sankarshan mukhopadhyay reviewed the initial revision
on the same list; their comments shaped Section 1.5 and Section 12.6.
Change Log
This section will be removed before publication as an RFC.
draft-helixar-hdp-agentic-delegation-02: Incorporates a further
round of review. Added Section 1.1, stating that HDP is not an
authorization protocol, and aligned the abstract, the scope field
descriptions, the verification pipeline, and the transport text
with it. Revocation is now normative: a verifier MUST support
verifier-local revocation by token_id, checked at Step 2
(Section 10.6); re-authorization is described as lineage rather
than revocation (Section 6); the 24-hour default lifetime is
removed (Section 10.5). Corrected the stated cost of single-key
hop signing and described what a v0.1 hop signature does and does
not attest (Section 4.2). Hop timestamp monotonicity is now a
MUST (Section 4.3). Added Section 10.7 (delegation budgets and
off-record delegation), Section 10.8 (attribution across
concurrent tokens), a presenter check and a completeness analysis
in Section 10.4, recursive accountability and delegate-identifier
guidance in Section 9.1, a content-addressed token-by-reference
option with a write-once requirement (Section 8.2), a composition-
versus- chaining rationale (Section 7), and an attenuation
limitation (Section 12.6). Noted that authorized_tools and
authorized_resources are unbound lists (Section 3.3) and corrected
the Appendix A example accordingly. Retargeted [HDP-SPEC]. Added
an Acknowledgments section. A subsequent consistency review added
historical audit verification distinct from live acceptance;
explicit recording of out-of-scope attempts and observed
violations; issuer serialization and digest-bound receipt guidance
for forks; mandatory reference integrity checks and immutable UUID
snapshots; explicit retained context for parent-link meaning;
exact integer bounds and input validation; and corrections to the
IPP revocation comparison. The token structure and signature
payloads are unchanged and remain HDP v0.1; input constraints and
verifier requirements have been tightened.
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.5 (payload-agnostic chain-of-
custody with agentic delegation as the reference profile).
Corrected root signature verification to reset chain to empty
Dalugoda Expires 15 March 2027 [Page 41]
Internet-Draft HDP Agentic Delegation September 2026
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 15 March 2027 [Page 42]