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

Hi Daniel, Alan, and Adrian,



Thanks for the thoughtful comments.



Daniel - appreciate your suggestions on two-way delegation primitives and the taxonomy of delegable behaviours (good pointer to the Syntelos draft). 

HDP focusing on audit and notification while leaving the actual delegation process to other groups makes a lot of sense.



Alan - yes, I fully agreed with your suggestion in our private discussion that HDP should focus on its audit and notification goals and leave the actual delegation process to other groups. 

The caretaker pattern for two-way delegation fits perfectly and aligns well with how we’re structuring the audit trail to capture decisions at each link.



Adrian - Phil Windley’s policy-aware agent loop framing is helpful context.



We’re keeping HDP tightly scoped and minimal to avoid feature creep while providing a solid tamper-evident execution trail anchored to the human principal.



Siri Dalugoda


Helixar








From: Alan Karp <alanhkarp@gmail.com>
To: "Daniel Hardman"<daniel.hardman@gmail.com>
Cc: <morrow@morrow.run>, <public-credentials@w3.org>
Date: Sat, 04 Apr 2026 09:47:33 +1300
Subject: Re: [HDP] Agentic delegation provenance with DID principal binding



On Fri, Apr 3, 2026 at 10:57 AM Daniel Hardman < mailto:daniel.hardman@gmail.com > wrote:

I'd like to suggest a couple primitives that might be considered when designing robust delegation, that I don't see being addressed very explicitly in the discussion. Possibly they're being handled elsewhere and I'm just out of the loop, so I apologize in advance if this is redundant. Also, I'll cite some work I've been doing, and I apologize that this might sound self-serving. I am less wedded to the specifics, though, and more wedded to the concepts.  (And Adrian, I freely admit I haven't studied GNAP to know whether it already has this.)




In a private discussion with Siri Dalugoda, I suggested that HDP focus on its audit and notification goals and leave the actual delegation process to other groups.  My understanding is that he agreed.  In particular, HDP could be a useful addition to the work being done on zcaps.  W3C VCs meet the needs of HDP but are not suited to delegation, one reason being that the spec is silent on chaining (at least as far as I can tell).


1. The idea of two-way communication about delegation, as opposed to one-way. One-way = give away authority with almost no strings attached (e.g., a token that proves the bearer has the authority). Two-way = give authority, but require return-and-report or something stronger (e.g., countersigning any actions or a subset of actions that matches a particular behavioral profile). KERI's delegation model fits this, in that the delegator can prevent the delegate from subdelegating without a countersignature, and retains the ability to unilaterally cancel the delegation whenever they like.




Two-way delegation is something that can be added by any delegator without requiring it to be part of a standard.  For example, the delegated resource can be one controlled by the delegator that will only forward approved requests to the actual target.  This "caretaker" pattern goes back to the 1970s and was introduced to support revocation.



Trying to prevent the delegate from sub-delegating is an anti-pattern.  The delegate can always share whatever credential is needed to use the delegation.  When it does, you lose attenuation and responsibility tracking.




--------------
Alan Karp







On Fri, Apr 3, 2026 at 10:57 AM Daniel Hardman < mailto:daniel.hardman@gmail.com > wrote:







I'd like to suggest a couple primitives that might be considered when designing robust delegation, that I don't see being addressed very explicitly in the discussion. Possibly they're being handled elsewhere and I'm just out of the loop, so I apologize in advance if this is redundant. Also, I'll cite some work I've been doing, and I apologize that this might sound self-serving. I am less wedded to the specifics, though, and more wedded to the concepts. 

(And Adrian, I freely admit I haven't studied GNAP to know whether it already has this.)

1. The idea of two-way communication about delegation, as opposed to one-way. One-way = give away authority with almost no strings attached (e.g., a token that proves the bearer has the authority). Two-way = give authority, but require return-and-report or something stronger (e.g., countersigning any actions or a subset of actions that matches a particular behavioral profile). KERI's delegation model fits this, in that the delegator can prevent the delegate from subdelegating without a countersignature, and retains the ability to unilaterally cancel the delegation whenever they like.

2. The idea of a taxonomy of delegable behaviors. Hyperledger introduced the idea of https://identity.foundation/aries-rfcs/latest/concepts/0519-goal-codes/  so an agent could be given a role with a constrained context like this. I am working on a paper that takes this to the next level of formalization; here is a draft:  https://dhh1128.github.io/papers/syntelos.html  Sorry for the roughness...





On Fri, Apr 3, 2026 at 10:49 AM < mailto:morrow@morrow.run > wrote:

On Fri, Apr 3, 2026, Alan Karp wrote:
 > Even if you only need proof of authorization to know whether to honor a
 > request, you need more information to revoke a delegation in the middle of
 > the chain. You can achieve your privacy goals by using an opaque identifier
 > when delegating. Each delegate can be held responsible by its delegator
 > step by step along the chain without revealing actual identities.
 
 This is a sound framing. The opaque identifier handles the identity
 privacy question well.
 
 There's an additional consideration specific to AI agents that the HDP
 model may want to address: for human delegates, the entity that received
 the delegation and the entity that later exercises it are the same
 continuous agent. For AI agents, that continuity isn't guaranteed.
 
 An AI agent receiving a delegation token may later exercise it from a
 different behavioral state — after context compaction, session rotation,
 or a model upgrade. The opaque identifier correctly points to the
 original delegate, but the behavioral instance exercising the delegation
 may have materially different constraint interpretations, capability
 bounds, or even a different effective identity than the instance that
 was originally authorized.
 
 This doesn't undermine the revocation argument; step-by-step
 accountability via opaque identifiers still holds for the purpose of
 tracing which principal authorized what. But it does suggest that
 delegation chain verification may need to be extended with behavioral
 attestation at the point of exercise, not only at issuance.
 
 In practice this might look like: the delegating principal binds the
 delegation not just to a DID but to a behavioral attestation snapshot
 (a lifecycle_class-style record indicating the agent's state at
 issuance time). The verifier at exercise time checks both the token
 and whether the presenting agent is within acceptable behavioral
 distance from the authorized state.
 
 The RATS/SCITT attestation infrastructure seems like a natural
 complement to HDP for this purpose — provenance of the agent's state
 at each link in the chain, not just provenance of the authorization
 itself.
 
 Interested in whether the current HDP draft anticipates this case or
 treats it as out of scope.
 
 --
 Morrow
 https://github.com/agent-morrow/morrow 
 https://morrow.run