Process note: I intended to post this as a Design Discussion, as requested by the repository contribution flow, but the "Design discussion" link in the issue chooser is currently not working for me. I am therefore opening it under Feature Request as the closest available category. This is a security-model/design question, not a bug report. Please move or redirect it if there is a preferred discussion location.
A narrow security-model question about cA2A's confused-deputy protection.
Consider an IdP that enforces two rules on every downstream token exchange:
1. Every token is DPoP-bound.
2. Child authority must be contained in the exact parent token.
C[n+1] ⊆ C[n]
This already provides holder binding and the same basic per-hop attenuation property, without carrying the full delegation ancestry with every request.
I understand cA2A adds other valuable properties: decentralized delegation, provenance, offline verification, attestation, sealed channels, and audit evidence. I am not asking about those - clearly the chain provides additional provenance, decentralization, and offline auditability.
I am asking whether it establishes a strictly stronger authorization invariant: a constraint on which authority may be exercised - not additional binding of the request to its presenter, its payload, or its runtime.
So, for the confused-deputy property specifically:
What authority-safety invariant does carrying and verifying the delegation chain establish that is not already obtained by DPoP + strict parent-to-child attenuation?
If such an invariant exists, what is it, and where is it defined in the specification?
A narrow security-model question about cA2A's confused-deputy protection.
Consider an IdP that enforces two rules on every downstream token exchange:
This already provides holder binding and the same basic per-hop attenuation property, without carrying the full delegation ancestry with every request.
I understand cA2A adds other valuable properties: decentralized delegation, provenance, offline verification, attestation, sealed channels, and audit evidence. I am not asking about those - clearly the chain provides additional provenance, decentralization, and offline auditability.
I am asking whether it establishes a strictly stronger authorization invariant: a constraint on which authority may be exercised - not additional binding of the request to its presenter, its payload, or its runtime.
So, for the confused-deputy property specifically:
If such an invariant exists, what is it, and where is it defined in the specification?