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

[Yasha Khandelwal <[e-mail]>]

Siri, all,

Two parts of -03 map directly onto a test method I maintain, and I'd like to offer a measurement rather than an opinion.

The completeness gap in 10.4, an intermediate agent deleting the hops after its own, and the hash-linked snapshots in 8.3 are the cases draft-khandelwal-bmwg-agent-memory-integrity calls tail truncation and whole-store rollback. It applies nine storage-level edits to a record store behind its own API, then asks the store's own verifier what it serves back, recording refused on read, reported on audit, or served as genuine. Across sixteen stores measured so far, the pattern on exactly those two edits is consistent: a chain that is self-consistent after the cut verifies, and only a head held somewhere the attacker cannot reach catches it. That is the 8.3 question in measured form.

The token-by-reference store in 8.2 is a measurable target. If useful, I'll run the TypeScript reference's store through the method, with the chain seeded through HDP's own API and the edits applied to the store underneath, and report the per-edit result on the list before anything is published. Method and results: http://datatracker.ietf.org/doc/draft-khandelwal-bmwg-agent-memory-integrity  and agentmemoryintegrity.org.

Yasha Khandelwal







From: Siri <siri=[e-mail]>
To: "public-credentials"<[e-mail]>, <[e-mail]>
Cc: "Brigitte Qirong LI"<[e-mail]>, "Alan Karp"<[e-mail]>
Date: Tue, 06 Oct 2026 16:23:11 +0530
Subject: [Rats] Re: draft-helixar-hdp-agentic-delegation-01: chain-of-custody for agentic delegation (revision, seeking review)



Hi all,

Revision -03 is up:
https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/ 

It answers Alan's section-by-section review of -02 (2026 Sep/0030 and 0031). Most of it does what my reply of September 23 said it would. Three things don't, and I owe the list an explanation of each.

1. Live use is cut, not gathered into one section. I said -03 would name two readers, one who relies on the token before acting and an auditor, and gather everything serving the first into one section. Alan pointed out that this adds a second access control mechanism, a well-known hazard: the extra check is an independent way to attack the system, and its denials can look to the base mechanism like failures it wasn't built to handle. So -03 cuts it. An HDP token MUST NOT be an input to any access decision (1.1). Expiry checks, session binding, replay defense and revocation are gone, along with "acceptance." expires_at and session_id stay in the v0.1 wire format as record metadata.

2. max_hops is kept, not deprecated. The case I made against it was that a hop budget pushes agents to delegate without appending hops. That only holds while something acts on the token. With live use gone, a full chain blocks nothing, and max_hops becomes what Alan first read it as in his note on 3.3: "the audit is only interested in the first few delegations". It is now the number of hops the record holds, and the agent at the last recorded hop answers for anything delegated beyond it (10.5).

3. The forward pointer I promised from 5.1 to 10.6 isn't needed, because 10.6 (Revocation) is gone.

Two additions. Section 11 carries HDP content, the human's request and each hop's reading of it, in UCAN meta and in zcap, for deployments that already have capability chains; the standalone token is for those that don't. The zcap form is still open: 11.2 asks whether zcap implementations would accept an extra property on a delegated capability, and where an invoking agent's content would go. Review from anyone running zcap is welcome. And 8.3 specifies the hash-linked snapshots I raised under 8.2.

The rest of that reply is in as described: the nested scope structure (planned for the next token version, since it changes the wire format), recording by a component outside the agent such as a sidecar, a free-form agent_type, renamed sections 6 and 7, privacy as the reason for the query-parameter ban, "no longer verifiable" for stripped tokens, "secret key", the certificate paragraph in 10.4, the new example in 10.8 (now 10.6), and the prompt-injection wording. The wire format is still HDP v0.1.

Section numbers: 1 to 9 and 10.1 to 10.4 are unchanged. With 10.5 and 10.6 gone, the old 10.7 to 10.11 are now 10.5 to 10.9. The TypeScript reference implementation still makes the -02 checks and will be updated to match.

Thanks again, Alan. Your warning changed this revision more than anything else in the review.

Siri


On Wed, 23 Sept 2026 at 19:12, Siri < mailto:[e-mail] > wrote:

Alan,



Thank you for reading all of it, it was a mammoth effort. I've answered both parts below, and most of it goes into -03. Feel free to correct me if I'm off track or need any adjustments, 



One comment sits under a lot of your notes, so I'll take it first. Expiry (3.1), "acceptance" (5.1), the "MAY use as input" line (8.1), replay (10.5) and revocation (10.6) all read like authorization machinery, and you're asking why an audit record needs any of it. -02 has a second reader it never names. Section 1.1 mentions an approver who inspects the chain before letting a task continue, and the introduction talks about downstream agents checking that a task came from a human. That reader relies on the record before an action takes place. Expiry, session binding and revocation exist for that reader. The auditor needs none of them.



I don't think that makes the token a capability. Holding one is never enough to do anything; at most a service can require one as evidence that a human asked for the task, much as an OIDC ID token gets used without being an access token. But the draft spreads that reliance across several sections without ever saying so, and each one reads like authorization smuggled back in. In -03 I'll name the two readers in 1.1 and gather everything that serves the before-the-action reader into one clearly marked section, so the rest reads as the record it is. If that section still looks like authorization once it stands on its own, I'd like to hear that before -03 goes out.



Part 1



3.1 Expiry. Same answer. For audit it means nothing, and 5.1 already verifies expired tokens. It's there for the reader who relies on the token before acting.



3.3 Scope. Agreed on all of it. The fixed values for data_classification, network_egress and persistence are too coarse, and your log-writing example shows why. The separate lists create exactly the ambiguity you describe; -02 admits it in 3.3 and plans a per-resource permission map. -03 specifies that nested structure, required but allowed to be empty, so "declared nothing" can be told apart from "said nothing". It changes the wire format, so it belongs to the next token version rather than a patch to v0.1.



On max_hops, 10.7 already argues against it, because a hop budget pushes agents to delegate off the record. Your reading is a second reason. -03 deprecates it, and the next token version drops it.



3.4 Chain. In v0.1 the agent submits its hop and the issuer signs it, so the signature says the issuer recorded the claim and nothing more. No, you can't trust the agent's action_summary, which is why the draft only calls it a declaration. Your sidecar point is the one that changes the draft. Where it exists, a component outside the agent's control, such as a VM sidecar, tool gateway or MCP proxy, should record the hop, and the record should say which one did. -03 adds that.



Nothing normative separates orchestrator from sub-agent; they're descriptive labels. "custom" is the literal string, which is inconsistent with id_type accepting any x- value. -03 either makes agent_type free-form or drops it.



Truncation can't be detected from the token, and it matters, because the attacker is an intermediate agent hiding what its sub-agents did (10.4). More under 10.4 below.



4.2 Key rotation. Issuer keys rotate by kid (10.10). With per-agent signing, the plan is a fresh key for each delegation, signed into the chain by the delegator, so an agent key lasts no longer than its task and rotation mostly comes down to the issuer's key. A key compromised mid-task still has to be handled, and the extension will have to say how.



5.1 Forward pointer to 10.6: will add.



Part 2



5.1 "Acceptance" means a verifier would treat the token as current right now: in session, unexpired and unrevoked. Your question shows the word carries authorization baggage. -03 renames it and moves it into the before-the-action section.



6 Re-Authorization. Agreed, it's framed as authorization. The part that belongs to HDP is the link between a record and the one it supersedes, and -03 rewrites the section around that link.



7 Multi-Principal Delegation. This isn't delegation by several principals. It records two humans approving the same task, as under a two-person rule, and the title misleads; -03 renames it. On the untagged parent_token_id you're right that it's a weakness, and no, an audit can't always determine the relationship. -02 has auditors report "unknown" when trusted context is missing, but that's a workaround. The fix is a signed relationship type in the header, in the next token version.



8.1 Query parameters. The token isn't a bearer secret. The concern is privacy: it carries the principal and the task description, and URLs end up in logs and browser histories. -03 will give that reason instead. For "MAY use as input", see the top of this email.



8.1 Replay. For audit, no. A duplicate record harms nothing. It only matters to a reader who relies on the token before acting, and even then an HDP token isn't bound to a request, which is why 10.5 leaves replay within a session to the application.



8.2 Token by reference. The store holds the complete token, with the whole chain to that point inline. There's no pointer to a parent snapshot. Each extension produces a new snapshot under a new content-addressed reference, so storage repeats the prefix every time. A hash-linked form, where each snapshot holds the new hop plus the digest of the previous one, would be cheaper. I'd welcome a view on whether it's worth specifying.



9.1 Delegator-meaningful identifiers were your point from August, and 9.1 now adopts them for agent_id. On stripped tokens, you're right that "audit-only" is the wrong phrase. What it means is "no longer verifiable", and -03 will say that.



10.2 Will switch to "secret key".



10.4 I think you're right wherever certificates exist. On a zcap or UCAN deployment, the certificates presented at the resource are a better record of exercised authority than anything HDP carries, because the resource sees each one and no intermediate agent can remove them from its log. HDP shouldn't duplicate that. What it can add is the part that never produces a certificate: what the human asked for and how each hop read it. On such a deployment that could travel in the certificates' own metadata. -03 will say so.



10.5 and 10.6. See the top: these serve the reader who relies on the token before acting, and -03 moves them into that section.



10.7 This one I'd defend as audit, since the argument is about recording, not authority: a hop budget in the token pushes agents to delegate without appending hops. The reasons you couldn't articulate may be cost and privacy, since a long chain exposes an organisation's internal structure. The draft puts that limit at the verifier, where it can change without reissuing tokens.



10.8 Also audit. It came out of our August exchange about which token a hop is recorded against. Your point about the example is right, though. An update recorded under Alice's read-only token gives itself away. The harmful case is an action both scopes cover: if both tokens allow the update, Carol's update recorded under Alice's token is invisible, and it implicates Alice. -03 changes the example to that.



10.9 Agreed. Whether a use of a permission violated the user's intent is a hard question, and answering it isn't HDP's job. -03 drops the "detect and block" and "mitigates" language: HDP records every use, including attempted and blocked ones, and leaves the judgement to the user.



Thank you.



Siri





On Wed, 23 Sept 2026 at 11:46, Alan Karp < mailto:[e-mail] > wrote:

Continuing from where I left off.



5.1 Historical Audit Verification



What does "acceptance" mean in this section?



6. Re-Authorization



This section appears to be talking about authorization, not audit.



7. Multi-Principal Delegation



I don't know of a capability system that supports multi-principal delegation.  



You said, "HDP v0.1 does not tag which relationship a given parent_token_id expresses." That sounds like a weakness.  Are you sure an audit can always determine the relationship?



8.1 HTTP Header: HDP Token



What sensitive data might be exposed if the token is in the query parameter?  It's not like a bearer token.



You say the receiving service MAY use the HDP token as input to the authorization decision.  That sounds a lot like the token can be used as if it were a zcap, but you said HDP was only for audit.  



Question: An invocation token needs replay protection.  Does an HDP token?



Token-by-reference: It's clear that the reference goes in the HTTP header, but what goes into the token at the reference.  Does what's stored include the delegation chain to that point, or does the stored token have a reference to its parent?



9.1 Minimum-disclosure Principal Fields



One of our systems allowed opaque identifiers meaningful only to the delegator.



You say, "stripped tokens MUST be clearly marked as audit-only" I thought HDP was for audit only, whether stripped or not.



10.2 Token Forgery



Cryptographers have recently changed their terminology.  Instead of public/private keys they use public/secret keys because it simplifies the notation in their equations.



10.4 Chain Truncation



It seems to me that this weakness is a reason to use the actual delegation certificates for audit.



10.5 Replay Attack Defense



This whole section sounds like you're talking about authorization tokens, not audit tokens.



10.6 Revocation



Ditto



10.7 Delegation Budgets



Ditto, but you may want to limit the depth of the audit trail for reasons I can't articulate.



10.8 Attribution



Ditto



"an update performed in Carol's task but recorded under Alice's token"  Can't happen, since Alice's token is only for read.  You can change the example to make this possible.



10.9 Prompt Injection



Knowing if the use of a permission violates the user's policy is a hard problem.  I think the best HDP can do is report all uses and leave it to the user to decide if the permission was abused.



Whew!!!  Done. 




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







On Fri, Sep 11, 2026 at 4:03 AM Siri < mailto:[e-mail] > 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 < mailto:[e-mail] > 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 < mailto:[e-mail] > 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 < mailto:[e-mail] > 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 < mailto:[e-mail] > 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 < mailto:[e-mail] > 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 < mailto:[e-mail] >

发送时间：2026年8月28日(周五) 00:42

收件人：hello< mailto:[e-mail] >

主　题：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 < mailto:[e-mail] > 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 < mailto:[e-mail] >

发送时间：2026年8月18日(周二) 06:11

收件人：hello< mailto:[e-mail] >

抄　送："public-credentials"< mailto:[e-mail] >

主　题：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 < mailto:[e-mail] > 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 


































_______________________________________________

RATS mailing list -- mailto:[e-mail]  

To unsubscribe send an email to mailto:[e-mail]  






YASHA KHANDELWAL

Co-founder, Director & CEO

​

 



Mobile: [phone]

mailto:[e-mail]?subject=Hello Yasha 
http://www.tech4bizsolutions.com 
 Office Locations:
Headquarters:
#1207/343/1, 9th Main, Above HDFC Bank, Sector 7, HSR Layout, Bengaluru 560102
Surat
A602, Pragati IT park, near Utran Power House, Mota Varachha, Surat, Gujarat 394101
USA
10685B Hazelhurst Dr, Houston, TX 77043, United States
https://www.facebook.com/profile.php?id=61558189034099/  https://x.com/Tech4bizContact/  https://www.linkedin.com/company/tech4biz-solutions-private-limited/  https://www.youtube.com/@Tech4bizz/  https://www.instagram.com/tech4bizz/ 











The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.