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

You're right about truncation.  I just keep forgetting that HDP is not for
invocation.

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


On Thu, Aug 27, 2026 at 6:09 PM Siri <siri@helixar.ai> wrote:

> Brigitte, Alan,
>
> Three things from this thread would land in HDP -02, one of them as a
> disagreement.
>
> Recorded, not consented. Adopting this, and crediting you for the phrasing
> in -02's Acknowledgments. It is a sharper statement of what a v0.1 hop
> signature means than anything in -01: with a single issuer key, a hop
> attests that the issuer recorded a delegation claim and nothing more. The
> draft says "declared", which gestures at this without naming the mechanism
> that makes it so.
>
> Offline verification. Your retraction matches the correction Alan sent me
> on the same point, so the same fix goes into -02: per-hop signing costs
> nothing offline once each hop carries its delegate's key, and my rationale
> for single-key signing in section 4.2 was wrong about this. Worth saying on
> the list, since -01 is published with that reasoning. I am also borrowing
> your separation of the two costs: chain integrity is offline, revocation
> freshness is what goes online, and that is a property of wanting bounded
> revocation rather than of per-hop signatures.
>
> Truncation, where I disagree. Your analysis is correct for a capability
> chain, and I think Alan is right to endorse it there, but it does not
> transfer to HDP. It rests on attenuation: authority narrows toward the
> tail, so a truncated prefix is only usable by the delegatee of its last
> remaining hop, who holds that authority legitimately. HDP hops record
> actions, not grants, so there is no attenuation and a truncated chain still
> carries the full original scope. The attacker is different too: it is an
> intermediate agent deleting the hops after its own to hide what its
> sub-agents did, and terminating at the authenticated presenter does not
> stop that, because after truncation that agent genuinely is the presenter.
>
> So I am taking the recommendation and declining the conclusion. -02 will
> recommend terminating the chain at the authenticated presenter, which is
> cheap, aligns with UCAN Invocation and ZCAP's capability Invocation proof,
> and closes third-party replay of a shorter copy. It will also say plainly
> that this leaves HDP's completeness gap open, which is the audit question
> you identify. What your analysis does settle for me is that a signed
> chain-length commitment is not worth a wire-format change.
>
> On revocation, Alan's distinction is the one I would draw: yours is an
> issuer-signed freshness assertion the verifier fetches, buying a bounded
> window at the cost of issuer availability; mine will be verifier-local
> state with no fetch.
> Same trade, priced differently.
>
> I owe you a proper read of the design doc rather than a reaction, and will
> come back on section 6 separately.
>
> Siri
>
> On Fri, Aug 28, 2026 at 9:01 AM Brigitte Qirong LI <hello@jiaozi.io>
> wrote:
>
>> Hi Alan,
>>
>> Good question — it is the pressure point of the all-enrolled design, so
>> here is the honest shape of it.
>>
>> In v1, every principal on a chain is enrolled, including agents. What
>> makes that tolerable is that enrollment is not an out-of-band ceremony:
>> issuance is API-first and automated at the software tier — an agent can
>> procure its own credential in seconds, unattended. So "agents that start
>> agents" works today as: the parent (or the child itself, at startup)
>> registers the child via API, and the child becomes a delegatable principal
>> with its own key and its own revocable status. For genuinely short-lived
>> workers there are two v1 patterns: issue the child a short-expiry
>> credential — expiry does the cleanup, and the 60-second status freshness
>> bounds any revocation race — or keep the authority at the parent and have
>> the parent invoke on the child's behalf, so nothing needs enrolling.
>>
>> Where we think you are pointing, though, is the case where even automated
>> enrollment is too much — a process that lives for one task. For that we
>> have an identified phase-2 extension, directly shaped by your comments: a
>> bare-public-key *tail* delegatee. The guardrails we would insist on:
>> tail position only (no further re-delegation); the direct delegator of a
>> bare key must be an enrolled, accountable principal — your
>> recursive-accountability model, made a MUST; revoking that hop means
>> revoking the upstream delegation edge, not a subject; and short TTLs so
>> natural expiry, not revocation, is the primary lifecycle. It is not settled
>> for v1, because it punches a hole in per-principal revocation freshness,
>> but it is written down and waiting for a real workload to justify it.
>>
>> On your revocation-list remark: agreed, and the distinction is fair —
>> yours is local to the resource's verifier; ours is an issuer-signed
>> freshness assertion the verifier fetches, which trades verifier-local state
>> for issuer availability (mitigated by a mirrored second anchor, and
>> fail-closed if all anchors are down).
>>
>> The -02 revision, including the new invocation section (§6: mandatory
>> resource designation, fail-closed; canonical resource identifiers; the
>> confused-deputy reclassification; and the "resources passed as arguments
>> must be delegated" rule), is now up at the same URL:
>> https://github.com/jiaozi-protocol/jiaozi-app/blob/main/standards/delegation-v1/DESIGN.md
>> — details matter, as you say, so §6 is exactly where an early objection
>> would save us the most. A summary of what changed and what we adopted from
>> your two rounds is in the revision history at the bottom.
>>
>> Best regards,
>>
>> Brigitte Qirong LI
>>
>> Jiaozi Protocol
>>
>> https://www.jiaozi.io
>>
>>
>> ------------------------------------------------------------------
>> 发件人：Alan Karp <alanhkarp@gmail.com>
>> 发送时间：2026年8月28日(周五) 00:42
>> 收件人：hello<hello@jiaozi.io>
>> 主 题：Re: draft-helixar-hdp-agentic-delegation-01: chain-of-custody for
>> agentic delegation (revision, seeking review)
>>
>> Thanks for the detailed response.  I do have one question.
>>
>> How do you deal with agents with your single credential system? I wonder
>> especially about short-lived ones and agents that start agents,
>>
>> --------------
>> Alan Karp
>>
>>
>> On Tue, Aug 25, 2026 at 10:47 PM Brigitte Qirong LI <hello@jiaozi.io>
>> wrote:
>>
>> Hi Alan,
>>
>> Thanks for the careful read. Taking your points in order.
>>
>> On well-known keys: you are right, and our claim needed scoping.
>> delegation-v1 operates inside a single credential system: the chain root is
>> an attestation issued to a KYB-verified operator, and every delegator and
>> delegatee on a chain holds a credential whose key is registered with the
>> issuer at issuance. So "every principal has a resolvable key" holds by
>> construction within that domain — but only there. For delegation across
>> organizations, or to a program nobody else knows a key for, your model —
>> hold your direct delegate responsible for use of the delegation,
>> recursively down the chain — is the more general answer. We see that
>> accountability chain as complementary to the signature chain rather than
>> competing with it; v1 explicitly scopes out cross-issuer chains and does
>> not attempt the case you describe.
>> How do you deal with short-lived agents?
>>
>> On losing offline verification: you caught an over-compression. Per-hop
>> signatures lose nothing offline: given the principals' public keys, chain
>> integrity — signatures, principal alignment, monotonic attenuation —
>> verifies entirely offline. What is online in our design is revocation
>> freshness: we require a fresh status credential (60-second TTL) for each
>> principal on the chain, instead of revocation lists or delivered revocation
>> tokens. That cost comes from wanting bounded revocation, which any
>> revocable system pays in some form; it is not a cost of per-hop signing.
>> The sentence should have read "accepted requiring online status checks for
>> revocation freshness."
>> When people say "revocation lists," they often mean something
>> centralized.  In this case, the list is local to the resource's verifier.
>>
>>
>> Glad the truncation analysis holds up.
>>
>> Your detailed comments on the design doc arrived separately — thank you.
>> We are working through them and will respond to you directly, and fold the
>> results into the next revision.
>>
>> Brigitte Qirong LI
>>
>> Jiaozi Protocol
>>
>> https://www.jiaozi.io
>>
>>
>>
>> ------------------------------------------------------------------
>> 发件人：Alan Karp <alanhkarp@gmail.com>
>> 发送时间：2026年8月18日(周二) 06:11
>> 收件人：hello<hello@jiaozi.io>
>> 抄 送："public-credentials"<public-credentials@w3.org>
>> 主 题：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
>>
>>