Summary

  • Azat Davliatshin's 2 November independent report built a verifier and modeled two individual agent-delegation drafts. It found a precise fork beneath their common chain rules: who signs a child token.
  • AAT revision 01 requires the parent token's holder key to sign the child. The report reads Asor revision 02 as allowing a verifier-configured issuer key to sign it without the parent's holder taking part.
  • In the report's model, possession of one accepted signing key can extend an honest Asor chain. A leaf DPoP proof then proves possession of the new leaf key, not consent from the original parent holder. This is a modeled key-compromise case, not a reported breach.

The chain looks orderly until the next signer arrives

The two proposals have reassuringly similar furniture. A root grants authority. Each child points cryptographically to its parent, carries a narrower permission set and obeys depth and expiry limits. At the last hop, the presenting agent proves it holds the leaf key. A reader could skim that list and mistake the designs for interchangeable ways to do the same job.

The second signature is where the office politics begin. In Niki Aimable Niyikiza's AAT -01, invariant I1 ties a new link to the key named by its parent. The party holding that parent key is the one able to extend the chain. In Rafael Asor's -02, as read and implemented by Davliatshin, a link can be signed by a key in the verifier's accepted configuration. The parent holder's key is present as a binding, but the verifier's signature step does not demand that key for the child.

Davliatshin put the distinction through a formal model. Given control of one key the Asor verifier accepts, an attacker in that model can add a link below an honest token and put the attacker's own key in the new leaf. A DPoP proof for that leaf then passes the presentation check. DPoP answers “who is presenting this leaf?” It cannot retrospectively answer “did the parent holder authorize this child?” The reported result depends on the model's configured-key trust assumption; it is not evidence that a deployed system was compromised.

The report tested a different reading too. When it altered the Asor model so that the parent's holder key had to sign the child, that particular difference disappeared. The test is informative precisely because the rule is absent from Asor -02. It identifies a governance choice hidden inside what otherwise looks like signature plumbing: does the agent holding a grant control its onward delegation, or does every accepted issuer share that power?

Asor published -03 on 27 October, before the report appeared. Its verifier still checks each signature using keys and algorithms from local configuration, and its separate holder-binding step checks the leaf presenter. The report's model and numerical comparison cover -02; the -03 text remains a distinct, later record. No source here documents a production deployment or exploit. The next decisive document is a revision that states exactly which key must sign a child link.

Official sources