Re: draft-helixar-hdp-agentic-delegation-01: chain-of-custody for agentic delegation (revision, seeking review)

Sorry for the delay.  Life got in the way.

I've put my comments inline below

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


On Wed, Aug 12, 2026 at 9:59 PM Brigitte Qirong LI <hello@jiaozi.io> wrote:

> Hi Siri, all,
>
> We read -01 closely — two comments on the open questions, then a pointer
> to a complementary design we would like review on.
>
> On question 1 (hop signing keys): this seems to depend on what the token
> is for. For an offline-verifiable evidence trail, the single-key default is
> coherent.
>
You appear to be making the common assumption that every entity in the
system has a well-known public key that is used to identify it.  That isn't
even always true within a single company.  For example, you might delegate
to a program you wrote.  Such a program does not have a widely known key,
and you don't want to give it your own key.  The problem is even trickier
when working across companies, where you have no direct control over how
keys are assigned to parties you may wish to delegate to.

What I'm trying to say is that the single-key default is not as coherent as
you may think.  What does work is holding your direct delegate responsible
for use of the delegation, even if the actual use came from farther down
the delegation chain.  In that case, your direct delegate will hold its
direct delegate responsible, and so on.

> For runtime authorization it seems insufficient: with one issuer key, a
> hop attests that the issuer recorded a delegation, not that the delegating
> agent cryptographically consented to it.
>
I don't understand.  The delegating agent signed with a secret key only it
knows.  Are you saying that you don't know who that agent is with per hop
keys?

> We took the other branch of your trade-off — per-hop signatures by each
> delegator's own key — and accepted losing offline verification.
>
Why does that choice lose offline verification?

> On question 2 (truncation): from the capability side, if the verifier
> requires the chain to terminate exactly at the authenticated presenter — as
> UCAN Invocation ("ending at the invoker") and ZCAP's capabilityInvocation
> proof already require — deleting trailing hops gains an attacker nothing:
> authority only narrows toward the tail, so a truncated prefix is only
> usable by the delegatee of its last remaining hop, who legitimately holds
> that authority anyway. A signed chain-length commitment may therefore be
> unnecessary for authorization; completeness stays an audit question, where
> your out-of-band suggestion looks right.
>
That sounds right.

> We have published a design (design only, no implementation yet) that is
> roughly the capability-layer complement to HDP's provenance layer: per-hop
> independent signatures, MUST-level monotonic attenuation (capabilities ⊆
> parent, caveats grow-only, expiry shrink-only, unknown caveat rejects the
> chain), chains rooted in a KYB-verified entity's attested behavior
> boundary, and revocation via 60-second-TTL status credentials — bounded
> mid-chain revocation, cf. your §10.6. Deviations from UCAN/ZCAP are
> declared per clause:
>
>
> https://github.com/jiaozi-protocol/jiaozi-app/blob/main/standards/delegation-v1/DESIGN.md
>
> Feedback is very welcome, including "use X instead".
>
I'll respond separately.

> Thanks,
>
> Brigitte Qirong LI
>
> Jiaozi Protocol
>
> https://www.jiaozi.io
>