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

3.1 Header

Why does a token have an expiration time?

3.3 Scope

I think authorization_tools and authorized_resorucess should be mandatory
but can be an empty array.

data_classification: The specified values are too general.  The value
should be up to the issuer.

persistence: I think this is too coarse grained.  For example, you might
want to let the agent write log records but nothing else

max_hops for delegation is an anti-pattern.  Here max_hops could mean that
the audit is only interested in the first few delegations.

There's too much room for ambiguity if authorized_tools,
authorized_resources, and data_classification are separate lists.  What if
the resources are both databases, and one tool is write while the other is
read.  You can't tell which goes with which.  The intent would have to be
unnecessarily complex to capture the distinction.  What you need is a
nested data structure.

3.4. Chain

Does the agent append to the chain?  Can you trust it?

What's the difference between a sub-agent and an orchestrator?

I presume "custom" is exactly that string.  Why can't it be anything the
delegator wants it to be?

action_summary: Presumably, this is provided by the agent.  Can you trust
it?  Normally this information would be provided by a trusted party, such
as a VM sidecar.

Can you detect if the chain was truncated?  Does it matter?

4.2 Hop Signature

Do you have to worry about key rotation?  Probably, not in v0.1, but what
about when you go to local signing?
5.1 Historical Audit Verification

You introduce revoked tokens, that's not defined until Section 10.6.  You
should include a forward pointer.

----------- To be continued -------------

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


On Fri, Sep 11, 2026 at 4:03 AM Siri <siri@helixar.ai> wrote:

> Hi Alan, Brigitte, and all,
>
> Following up on our August discussion, revision -02 is now available:
>
> Human Delegation Provenance Protocol draft (
> https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/)
>
> Alan, your point that the distinction needed to be explicit in the actual
> text was well taken. The revision now states early that HDP is not an
> authorization protocol, and aligns the scope descriptions, verification
> procedure, and transport discussion with that boundary.
>
> The main changes following our exchange are:
>
>    - Clarifying that issuer-signed hops record claims, rather than
>    demonstrating delegate consent.
>    - Correcting the single-key rationale: independent per-hop signatures
>    do not inherently prevent offline verification.
>    - Separating verifier-local revocation from re-authorization lineage.
>    - Addressing attribution across concurrent tokens without treating HDP
>    as the mechanism that selects or combines permissions.
>
> A further consistency pass separates historical audit from live
> acceptance, expands the truncation analysis to include same-length forks,
> and makes explicit that audit records must preserve violations rather than
> only record actions that appear permitted. The wire protocol remains HDP
> v0.1: token structure and signature payloads are unchanged, although
> validation and verifier requirements are tighter.
>
> *Alan*, if you have time for another look, I would especially value
> whether the revised non-authorization framing and attribution discussion
> now resolve the ambiguity you identified.
> *Brigitte*, I would welcome your assessment of the signature semantics
> and the completeness discussion.
>
> Thank you both; the acknowledgments describe your contributions without
> implying endorsement of the remaining design choices.
>
> Thank you,
> Siri
>
> On Sat, 29 Aug 2026 at 13:22, Alan Karp <alanhkarp@gmail.com> wrote:
>
>> I think you've got it, but the devil is in the actual text.
>>
>> --------------
>> Alan Karp
>>
>>
>> On Fri, Aug 28, 2026 at 6:01 PM Siri <siri@helixar.ai> wrote:
>>
>>> Alan,
>>>
>>> Thanks for both notes.
>>>
>>> On truncation, I’m glad that one landed, since it was the only place I
>>> found myself arguing against you and Brigitte at the same time.
>>>
>>> On the invocation point, I think the reason you keep forgetting is that
>>> the draft never tells you.
>>>
>>> I went looking for where -01 says HDP is not an authorization protocol,
>>> and it says it nowhere. The only out-of-scope line is about payload
>>> profiles. Meanwhile section 8.1 shows a POST carrying a token in a header,
>>> the scope object has fields called authorized_tools and
>>> authorized_resources, and the seven-step pipeline reads like an access
>>> control decision. Anyone defaulting to “this is an authorization token” is
>>> just reading what is in front of them.
>>>
>>> So the fix is on my side: -02 will state the non-goal early, and I will
>>> stop borrowing authorization vocabulary for things that are really records.
>>>
>>> You were right to doubt the merge as well. If I fix 3.3 properly by
>>> giving scope a per-resource permission map, so Alice’s token says foo maps
>>> to query and Carol’s says foo maps to update, both cleanly bound, Bob can
>>> still call the service passing foo twice and nothing tells you which token
>>> covers which argument. The ambiguity survives the fix, which means it was
>>> never the same defect. 3.3 is about binding inside one token, and the
>>> ambiguity is about selecting between tokens.
>>>
>>> That also takes down the section I described to you. Deciding which
>>> grant applies to which argument sits at the authorization layer, and HDP
>>> has no business there.
>>>
>>> What does belong to me is the audit version of it, and -01 misses it
>>> entirely. Nothing in the draft requires that the hop recording an action be
>>> appended to the token that authorized that action.
>>>
>>> So with two live tokens over the same resource, a hop attached to the
>>> wrong one verifies perfectly, and afterwards you cannot clear Alice or
>>> implicate Carol, which is precisely what the record exists for.
>>>
>>> Section 7 doesn’t help, since it only covers tokens linked by
>>> parent_token_id that share a session_id.
>>>
>>> In -02 this becomes a security consideration: append your hop to the
>>> token that authorized the action, and where more than one qualifies, let
>>> the application decide. It is a behavioural rule, so no wire change and
>>> existing tokens stay valid.
>>>
>>> Does that hold up, or am I still smuggling invocation in somewhere?
>>>
>>> Siri
>>>
>>>
>>> On Sat, 29 Aug 2026 at 9:47 AM, Alan Karp <alanhkarp@gmail.com> wrote:
>>>
>>>> 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
>>>>>>
>>>>>>