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

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

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. 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].¶
• 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 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 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.1. Root Signature

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

The signing procedure is:¶

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

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

4.2. Hop Signature

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

The hop signing procedure is:¶

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

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

In HDP v0.1, all signatures (the root signature and every hop signature) are produced by the issuer using a single key. An extending agent that is not the issuer 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.¶

8.1. HTTP Header: HDP-Token

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

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

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

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

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

Implementations using token-by-reference MUST secure the token store and use transport-layer security (TLS) for all reference resolution.¶

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

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

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).¶

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

11.1. HTTP Header Field Registration

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

Header Field Name:

HDP-Token¶

Status:

provisional¶

Reference:

This document, Section 8.1¶

Comments:

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

Header Field Name:

HDP-Token-Ref¶

Status:

provisional¶

Reference:

This document, Section 8.2¶

Comments:

Carries 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].¶

Security considerations:

See Section 10 of this document.¶

Interoperability considerations:

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

Published specification:

This document.¶

Applications that use this media type:

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

Fragment identifier considerations:

N/A¶

Additional information:

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

Person & email address to contact for further information:

Asiri Dalugoda <protocol@helixar.ai>¶

Intended usage:

COMMON¶

Restrictions on usage:

None¶

Author:

Asiri Dalugoda¶

Change controller:

IETF¶

11.3. Well-Known URI Registration

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

URI suffix:

hdp-keys.json¶

Change controller:

IETF¶

Specification document:

This document, Section 8.3¶

Status:

provisional¶

Related information:

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

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

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

1. Revocation model. IPP 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.¶

12.3. JSON Web Token (RFC 7519)

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

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

12.4. UCAN (User Controlled Authorization Networks)

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

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

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

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

12.6. ODRL and the Verifiable Credentials Data Model

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

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

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