Re: [HDP] Agentic delegation provenance with DID principal binding

Siri,
Thank you for sharing HDP. The delegation chain model is very interesting
and useful. I've been working with similar issues and offer these
observations:

*The W3C ODRL gap*
HDP's scope object reinvents vocabulary that ODRL (W3C Recommendation)
already provides:

   -  authorized_tools → ODRL action with asset targets
   -  authorized_resources → ODRL target
   -  constraints (action_count, time_window) → ODRL constraint with
   existing operators
   -  persistence / network_egress → ODRL prohibition

The cost of not inheriting from ODRL is concrete:

   - First, vocabulary fragmentation. Systems that already understand ODRL
   (there are several, particularly in the rights management and VC ecosystem)
   cannot reason about HDP scopes without a separate parser and separate
   policy reasoning tooling. This duplicates functionality unnecessarily.
   - Second, lost composability. ODRL policies compose: you can express
   "this agent may read financial documents unless classification is
   restricted, and must log every access" in a single policy that standard
   engines evaluate consistently. HDP's constraint array is a bespoke
   constraint language that replicates this without the composability.
   - Third, the VC alignment. You note that you see "a natural alignment
   between HDP's delegation model and the VC data model" and want to formalise
   it in the next revision. The VC Data Model 2.0 already has a termsOfUse
   property (section 5.5) for expressing policies attached to a credential,
   and ODRL is an established vocabulary for populating it. If HDP's scope
   were an ODRL Policy, the VC binding would follow naturally from existing
   practice rather than requiring new formalisation.

*Recommended v0.2 change*
Replace the novel scope object with an ODRL Policy document. HDP-specific
fields with no ODRL equivalent — intent, poh_credential, max_hops — become
ODRL extensions under the x- namespace HDP already defines for
extensibility. This preserves all HDP semantics while gaining ODRL
interoperability, composability, and the VC binding the CG audience would
expect without requiring additional formalisation.

*A broader architectural observation*
Asking what remains of HDP if scope becomes an ODRL Policy document leads
somewhere interesting. What if "scope" could be any payload?

What remains of HDP if scope becomes generic: header (standard token
envelope), principal (the human anchor with DID binding and optional
proof-of-human credential), and chain[] (the hop-by-hop append-only record
with cumulative hash chaining). The genuine novelty in HDP lies in its
chain structure: each hop extends a signed record over all prior states,
gaps in sequence numbers indicate tampering evidence, and any party can
verify the entire chain offline without a registry.

Notice that the chain structure says nothing about authorisation
specifically. The scope field is a payload. There is no structural reason
that payload has to be an authorisation policy. It could equally carry:

   - Data provenance: This dataset was derived from these sources, passed
   through these transformations, and met these conditions
   - Consent delegation: This patient authorised this use of their data,
   delegated to this researcher, and then to this analysis tool
   - Content moderation: A human reviewed this content, which was then
   passed to this classifier and flagged by this tool
   - Financial instruction: This officer authorised this transaction,
   delegated it to this system, and this agent executed it.
   - Physical-world command (as your HDP-P paper already explores): This
   action was authorised by this operator, delegated to this robot, executed
   by this actuator

In every case the invariant is identical: a human principal initiates a
chain, each hop extends it with a signed record, any party can verify the
full chain offline, gaps are detectable. The chain mechanism is the
protocol. The payload is a profile.

This suggests HDP could be specified at two levels: a payload-agnostic
generic chain-of-custody protocol defining the chain structure, signing
rules, and verification procedure; and a set of named profiles, of which
ODRL-scoped agentic delegation is the first, data provenance is an obvious
second, and consent management is a third, etc.

That separation would make HDP a broadly applicable provenance
infrastructure rather than a single-purpose agentic authorisation token.
The IETF draft would be the generic protocol; the profiles would be
separate documents. The core enabling structure, the chain structure, would
clearly separate from the application-specific vocabulary.

This is a larger architectural suggestion than the ODRL point, and may be
more than you want to take on in v0.2. But it seems worth raising while the
design is still open, because retrofitting payload-agnosticism into a
protocol after it has been specified around a fixed payload type is hard.

Thanks again for an interesting spec!

bob wyman

On Mon, Mar 30, 2026 at 3:59 PM Siri Dalugoda <siri@helixar.ai> wrote:

> Hi Credentials CG Team,
>
> I'd like to share a protocol that addresses a gap in the agentic AI space
> that I believe is directly relevant to this group's work on Verifiable
> Credentials and decentralized identity.
>
> HDP (Human Delegation Provenance Protocol) defines a signed token
> chain that creates a cryptographic audit trail from an authorising human
> to every AI agent acting downstream.
> The principal identity model supports id_type: "did" natively, meaning a
> W3C DID can be used as the root authorising identity binding HDP delegation
> chains to existing decentralised identity infrastructure.
>
> IETF draft:
> https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/
> Spec:       https://helixar.ai/about/labs/hdp/
> Repository: https://github.com/Helixar-AI/HDP
>
> Key properties:
> - Ed25519 signatures over RFC 8785 canonical JSON
> - Fully offline verification, no registry or network dependency
> - DID-compatible principal binding at the root token level
> - Compact enough for HTTP header transport (X-HDP-Token)
>
> I see a natural alignment between HDP's delegation model and the VC data
> model, specifically around how an AI agent's authority could be expressed
> as a Verifiable Presentation derived from the root delegation token.
> I'm actively exploring this in the next draft revision and would welcome
> input from this group on how best to formalise that binding.
>
> Happy to answer questions or take feedback on the draft.
>
> Best regards,
> Siri
> Helixar Limited
>
>
>