Stack Compare — one scenario, four stacks, eleven fields

The same agent-to-agent scenario — Agent A → Agent B → Payment Agent, intent approve-invoice — walked field by field under four trust stacks: A2A + HTTPS/OAuth, A2A + DID/VC, A2A + capability token, and A2A + RTTP/IQA. Three stacks are protocol choreography (simulated walk-throughs of real standards). The fourth executes real browser crypto: shard derivation, envelope verification, the standing read, the policy gate and fail-closed revocation — live, in this tab.

The question this page answers is the sharp one an outside reviewer asked: does RTTP + IQA add a primitive that did not exist before — or does it just rename existing primitives with new URI syntax? Run all four stacks and read the counters.

Sequel: the sharper question — delegation with attenuation (grant €10,000 → attenuate to €2,000 → delegate to a Payment Agent) — now has its own page: the same four stacks, plus the fifth experiment — Capability + RTTP/IQA composed, ten verification items each labeled cryptographically bound or application policy. → Run the Delegation Stress Test

Scenario. Agent A holds an invoice from supplier Agent B and needs Payment Agent to execute approve-invoice. Before any money moves, Agent A wants two things pinned down: what exactly is being asked (intent, addressed to whom) and what an independent trust organ currently says about that subject (standing) — with proof, not reputation.

Pick a stack, run the eleven fields

network round-trips

third parties trusted

real crypto steps

—

offline-verifiable result

pick a stack, then press Run. Fields: discovery → identity → intent → authentication → attestation → authorization → delegation → replay → revocation → audit → routing.

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: SHA-256 shard derivation and the HMAC-SHA256 sealing and verification of a demonstration envelope (published AE-128 layout), rebuilt byte for byte in this tab. The authorization gate shown for RTTP/IQA is an example application policy — the schemes deliberately leave authorization semantics open.

The full matrix

Field	A2A + HTTPS/OAuth	A2A + DID/VC	A2A + capability	A2A + RTTP/IQA
discovery	Agent Card over HTTPS (DNS+TLS)	Agent Card; identity layer switches to DIDs	as A2A	no lookup — authority names the subject; ROUTE_SHARD derives locally; delivery is the operator's job
identity	TLS cert = domain control, not agent identity	DID document, verification methods — strong, method-dependent	token bearer — possession, not identity	subject shard derived from authority + AID origin in the frame (self-certifying)
intent	free text inside the task payload	free text inside the task payload	free text inside the task payload	the URI is the intent — addressable, computable, action-independent
authentication	OAuth2 token exchange (IdP)	DIDAuth challenge–response	token MAC/signature	organ Ed25519/HMAC seal — ts and nonce inside the signature
attestation	none — server policy only	Verifiable Credential (issuer→claim→subject)	none — a capability confers authority, states nothing	AE-128 envelope: organ-relative standing, offline verifiable
authorization	server policy + OAuth scopes	policy engine consumes VCs	the token is the authorization	deliberately open — the (subject,intent,organ,standing,time,proof) tuple feeds the application's policy gate
delegation	OAuth on-behalf-of flows (complex)	capabilityInvocation / delegation ✓	capability chaining ✓	not specified in v1.3.1 — honest boundary
replay	TLS + token lifetime; task replay = app's job	VC dates; freshness = re-query issuer	token expiry; in-window replay possible	per-verdict nonce + lease + freshness window — bound in the signature
revocation	token revocation (network)	status list (network)	expiry only	Genesis state in the closed set + lease expiry — a flipped byte breaks the MAC
audit	operator-owned server logs	portable VC artifacts ✓	token receipts	the tuple (subject,intent,organ,standing,time,proof) — machine-checkable
routing	DNS + URL — address = location	DID resolution → service endpoint	DNS + URL	ROUTE_SHARD = deterministic, offline, action-independent

The verdict this page is built to test

Run all four stacks and the counters answer the reviewer's question directly. The other three stacks each depend on a trusted party at issuance or at verification time: a CA and IdP (HTTPS/OAuth), a DID method and issuer (DID/VC), and an issuer (capability — the minted token verifies offline, but carries no standing, no identity and expiry-only revocation). The RTTP/IQA column performs its derivation, authentication, attestation, revocation-relevant checks and audit emission with zero network calls and zero third parties — the standing evidence remains independently verifiable offline after issuance, while current standing is bounded by the lease. That is the primitive the other stacks do not standardize: not a new algorithm — a portable, self-contained trust state bound to a derived intent address. Whether the ecosystem adopts it is the open question this page cannot answer. Everything above the counters is checkable today.