Delegation Stress Test — one chain, five stacks
Stack Compare asked whether RTTP/IQA adds a primitive. This page asks the sharper question an
outside reviewer raised: delegation with attenuation. Agent A grants Agent B the authority to
approve-invoice up to €10,000; Agent B attenuates that grant to €2,000 and
further delegates it to a Payment Agent. Nine delegation fields per stack — grant, attenuation,
further delegation, chain verification, subject binding, standing, replay, revocation, audit.
Pick a stack, run the delegation fields
Honesty note: stacks A2A+HTTPS/OAuth, A2A+DID/VC and A2A+capability are real standards — their walk here is protocol choreography (illustrative, not a benchmark). The RTTP/IQA run executes genuine WebCrypto against the published AE-128 layout. Where v1.3.1 does not specify something — delegation chief among them — the run says so and shows the gap live; the compositions offered are application-layer work, clearly labeled, not specification. The fifth stack’s macaroon uses a shared demo HMAC key to show the chaining mechanics; real deployments use issuer public-key signatures — the discipline is identical.
The delegation scorecard
| Question | A2A + HTTPS/OAuth | A2A + DID/VC | A2A + capability | A2A + RTTP/IQA | 5 · Cap + RTTP/IQA |
|---|---|---|---|---|---|
| ≤ €2,000 in the credential? | only as custom IdP claims — not native, admin-configured | chained VC; B becomes issuer-of-record — semantics murky | ✓ native — a first-class caveat on the macaroon | ✗ not in the frame — the 128 bytes carry standing, not amounts (shown live below) | ✓ now a chained caveat (crypto), IQA tuple embedded |
| further delegation native? | on-behalf-of token exchange, provider-specific | ✓ chained credentials | ✓ native — third-party caveats | ✗ not specified in v1.3.1 — organ re-attestation shown as composition | ✓ third-party caveat names the derived shard |
| chain provable offline? | ✗ introspection at the IdP | signatures yes · freshness needs the status list | ✓ fully offline | ✓ both envelopes verify offline | ✓ macaroon chain + both envelopes, all offline |
| standing travels with the grant? | ✗ no trust statement exists | ▲ via the issuing VC, cached | ✗ authority without context | ✓ organ-relative standing in the frame, byte-verifiable | ✓ embedded IQA tuple rides with the attenuated grant |
| tamper-evident artifact? | ✗ server logs | ✓ signed VCs | ✓ MACed chain | ✓ whole-frame HMAC — flip one byte, it dies | ✓✓ two independent MACs must both hold |
| delegation root | the IdP | issuer B | the issuer | the organ (application-layer composition) | issuer + organ — dual anchor, composed |
The verdict this page is built to test
The run confirms the prediction in both directions. The capability stack wins attenuation outright: “≤ €2,000” is a one-line caveat, chained and offline-verifiable — no other stack makes delegation this natural. RTTP/IQA wins the other chain: it is the only stack where the standing of the subject — what an independent organ currently says, not what a bearer possesses — travels inside a tamper-evident artifact and survives offline forever. And v1.3.1 does not pretend otherwise: the frame has no amount field, and delegation is simply not specified. The honest composition is to run both: a capability macaroon for attenuation, whose root caveat embeds the RTTP/IQA audit tuple so the standing context travels with the attenuated grant. That composition is application-layer work — this page mints and verifies every byte of it live, and labels it as work, not as spec.
The fifth stack below runs exactly that composition — macaroon caveats for authority and attenuation, both AE-128 envelopes for intent, addressing and standing — with each of its ten verification items labeled cryptographically bound or application policy. The reviewer’s question — competing primitives, or orthogonal ones? — gets a direct, runnable answer: orthogonal and composable, offline end to end.