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

Siri,
Thank you for the candid reply. It has, however, clarified something that I
think this community needs to consider directly.

You are presenting HDP to the IETF and to this Credentials CG. Both are
bodies whose purpose is to develop interoperability standards: general
mechanisms that serve a wide variety of requirements with minimal
complexity, and that do not privilege any particular implementation or
commercial offering.

Yet your response to suggestions that would increase HDP's generality is
that doing so falls outside the scope of your commercial platform. The
parts of the problem that HDP deliberately leaves unaddressed — policy
reasoning, enforcement, violation detection — are, by your own description,
handled by Helixar 360. Your proposed standard and your product are
designed to fit together. Your proposed standard is narrow because your
product fills the gap.

This creates a problem for both organizations you are engaging. If either
the IETF or this CG were to endorse HDP as specified, they would be lending
standards legitimacy to a mechanism whose scope has been constrained by
narrow commercial considerations rather than by general technical ones.
That endorsement would not serve the interoperability goals these bodies
exist to advance. It would, however, serve the interests of your specific
product.

I want to be clear that I am not questioning the technical quality of the
chain-of-custody mechanism in HDP, which appears genuinely good on first
reading, nor your good faith in bringing it here. But the appropriate
submission to a standards body is one of two things: a set of requirements
("we need chain-of-custody provenance for agentic delegation; here are the
properties that matter") or a general mechanism ("here is a
payload-agnostic chain-of-custody protocol with an agentic delegation
profile as the reference application"). A specific implementation whose
generality has been deliberately bounded by product strategy is a third
thing, and standards bodies are not the right venue for it.

If HDP is presented as a general chain-of-custody protocol — with
ODRL-scoped agentic delegation as one profile, and the scope object
replaced by a typed, extensible payload — it becomes a genuine candidate
for standardisation and a genuine contribution to the interoperability
goals of this community. In that form I would probably support it
enthusiastically.

If it is presented as-is, I would encourage both the IETF and this CG to
consider carefully whether endorsing it serves their members or narrows the
space of future solutions in ways that benefit a single commercial actor.

bob wyman

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

> Hi Bob,
>
> Thank you for the detailed and thoughtful feedback, this is exactly the
> high-quality review I was hoping for.
>
> On the scope object and ODRL: I appreciate the clear mapping and the
> interoperability/VC benefits (especially via termsOfUse). However, my
> intent is to keep HDP strictly as a provenance and audit-trail record. The
> scope is a lightweight signed description of intended delegation for the
> evidence trail, while enforcement, violation detection, and policy
> reasoning remain application-layer concerns, handled by enterprise agentic
> threat detection software such as Helixar 360 (the commercial platform I
> created) and similar tools.
>
> Adopting a full ODRL Policy would shift HDP toward general policy
> carriage, moving away from its narrow chain-focused provenance goal. I'll
> strengthen the related work section in v0.2 to better cover ODRL and the
> trade-offs of vocabulary reuse vs. minimal token format.
>
> Your broader idea of a payload-agnostic chain-of-custody core with
> profiles (agentic delegation, data provenance, consent, etc.) is compelling
> and the novelty really is in the tamper-evident append-only chained
> structure. Worth exploring longer-term, though likely too large for v0.2.
>
> I'd value your thoughts on keeping the scope minimal for provenance while
> improving VC alignment.
>
> Thanks again, feedback like this is incredibly valuable.
>
> Best regards,
> Siri Dalugoda
> Helixar
>
>
>
> ---- On Tue, 31 Mar 2026 10:36:55 +1300 *Bob Wyman <bob@wyman.us
> <bob@wyman.us>>* wrote ----
>
> 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
>
>
>
>
>