Interop: APS delegation chains with HDP provenance tokens as root authority

[aeoess]

Context

Agent Passport System and HDP independently converged on the same cryptographic primitives for delegation provenance: Ed25519 signing, append-only chains, offline verification, human-to-agent authority binding. The convergence is striking enough that it suggests the architecture is natural, not accidental.

I build APS — 103 modules covering identity, delegation, enforcement, commerce, coordination, and governance. Ed25519 keypairs, scoped delegation chains with monotonic narrowing, 3-signature action chain (intent → policy evaluation → receipt), Merkle-committed settlements. Published on npm (agent-passport-system), PyPI, and as an MCP server. IETF Internet-Draft: draft-pidlisnyi-aps-00.

After reading the HDP paper and the IETF draft, I think these protocols are complementary rather than overlapping. Here's how I see the boundary:

Where HDP and APS sit

Concern	HDP	APS
Core question	"Was this action authorized by a human?"	"What is this agent allowed to do, and did it do it correctly?"
Token model	Single token with append-only hop chain	Signed delegation chain with cascading scope narrowing
Scope enforcement	Declared scope in token	scopeAuthorizes() evaluation at each action — gateway enforces structurally
Revocation	Short-lived tokens (session-bound, no registry)	Cascade revocation — revoking parent invalidates all children
Audit	Token carries full provenance	3-signature receipt chain, Merkle-committed into settlements
Commerce	Not in scope	4-gate commerce pipeline (passport, scope, spend limit, merchant allowlist)

HDP answers "did a human authorize this chain?" APS answers "was each action within the authorized scope, and here's the signed receipt proving it." Both are needed for a complete accountability story.

Concrete interop surface

An APS delegation chain could carry an HDP token as the root authority evidence. The HDP token proves human authorization. The APS chain proves that each subsequent delegation narrowed scope correctly and every action produced a signed receipt.

HDP Token (human → session → Agent A)
  └─ APS Delegation (Agent A → Agent B, scope: data:read)
       └─ APS Action Receipt (Agent B reads data, signed by B + policy engine)

The HDP token is the root of trust. APS is the enforcement layer that tracks what happened after the human authorized.

Proposal

Would you be interested in defining a shared test vector set? Specifically:

1. An HDP token that serves as the root authority for an APS delegation chain
2. A multi-hop scenario where the HDP provenance and APS scope narrowing compose
3. Adversarial cases: expired HDP token with live APS delegation, scope escalation attempt through the boundary

This is working group material, not competition. Three independent IETF drafts (HDP, APS, DAAP) all solving adjacent slices of the same problem suggests it's time to coordinate.

• APS SDK: https://github.com/aeoess/agent-passport-system
• IETF draft: draft-pidlisnyi-aps-00
• Paper: "The Agent Social Contract" — DOI: 10.5281/zenodo.18749779

[asiridalugoda]

@aeoess Thanks for the excellent breakdown and proposal. this is high-signal interop work.

I fully agree with your framing:

• HDP as root human authorization + session binding
• APS as scoped delegation + enforcement + signed receipts

The combined model makes a lot of sense:

HDP Token (Human → Session → Agent A)
└─ APS Delegation (narrowed scope)
└─ APS Action Receipts

I'm fully supportive and would love to collaborate on this.

Let's define shared test vectors together:

• HDP token as root authority for APS delegation
• Multi-hop scenarios with scope narrowing
• Adversarial cases (expired HDP, scope escalation, tampering)

I'll add an interop/aps/ folder with HDP examples shortly. Happy to align on embedding (full token vs reference) and co-maintain the fixtures with your SDK.

Agree that this feels like natural working-group material alongside APS and DAAP. Let's make the interop clean and strong.

Looking forward to building this with you.

[aeoess]

@asiridalugoda — accepting the interop/aps/ folder offer. Co-maintained fixtures is the right shape here.

Proposing the following test vector set as a starting point, matching the composition you described (HDP Token as root → APS delegation narrowing → APS action receipts):

Happy path:

1. HDP Token issued (human → session → agent A)
2. APS delegation issued from agent A to agent B with scope narrower than the HDP token's authority envelope
3. APS action receipt from agent B succeeds, references both the HDP token root and the APS delegation

Adversarial:
4. Expired HDP token — APS delegation signed under an expired root should fail verification at the enforcement gate
5. Scope escalation — APS delegation attempting to grant authority the HDP token didn't carry should fail at issuance time (monotonic narrowing blocks it) and again at enforcement time (defense in depth)
6. Tampered HDP token — signature check fails before APS even evaluates scope
7. Tampered APS delegation under valid HDP token — APS signature check fails independently of HDP validation
8. Multi-hop with scope narrowing — HDP → APS A→B → APS B→C, where each hop narrows further, and the final action receipt traces back through both narrowing steps to the original HDP root

Embedding question — my preference is by reference. Full-token embedding is cheaper for offline verifiers (single blob, no network fetch) but fails the delegation-chain size test at scale once chains go 3+ hops. Reference-style with JWKS resolution matches how both APS and HDP already do their own identity lookups, so the pattern composes. Open to your read if there's an HDP-side constraint I'm missing.

I can open a draft PR with skeleton fixture files (JSON objects with scenario, hdp_token, aps_chain, action_receipt, expected) if that accelerates the shape. Or if you'd rather draft the first fixture and I respond, either works.

On the working-group framing — agreed this sits alongside DAAP. Sanjeev Kumar (DAAP author) and I have been trading notes on the delegation invariants; there's room to make this a three-way alignment rather than two parallel bilateral specs.