Jijie, Ryan, Agreed on all three, including the order: check the key binding before scope or authority, so a substituted key is denied before anything else about the child is evaluated.
Two additions to the negative tests. First, the binding has to hold at every hop, not only the first, so the test set needs a three-hop chain where the substitution happens at the second hop. Second, a parent that binds no delegatee key at all should deny. Otherwise receipts minted before the fix, which carry no binding, would pass the new check by default, and the gap stays open for every receipt already in a log. Kieran On Tue, Oct 20, 2026 10:24 AM, Jijie Wei <[email protected]> wrote: > Kieran, Ryan, all, > > > the parent body names no delegatee key, so anyone holding a copy of a > > parent receipt can mint a narrower child that passes every check in 8.7. > > Agreed. I think this is a protocol-level gap, not just an implementation > issue. The missing fact is not really the agentId string; it is which key > the parent authorized to continue the delegation. > > The smallest fix is for the parent body to bind the child/delegatee key, > either as the complete public JWK or as its RFC 7638 thumbprint. After > verifying the parent signature and before checking scope or authority, a > verifier can verify the child signature under signerPublicKey, derive its > thumbprint, and compare that with the parent's binding. Any mismatch > should deny. > > This may also settle what orchestratorSignature is for. Once the child > signing key must match the parent's binding, a second signature over the > parentReceiptId/receiptId pair may be redundant. If it is kept, the text > should say what separate fact it establishes. > > One useful negative test would copy a valid parent, mint a narrower child > under an attacker key, and create a self-consistent orchestratorSignature > with that same key. The chain should still fail at the parent's key-binding > check. > > The same key-substitution check appears in draft-wei-aic-jwt-02 as > da.agent_key_binding.key_hash. I think that is worth citing as a design > reference rather than adding another general-purpose claim. > > [Drafted with AI assistance; I have checked every point and agree with it.] > > Best, > Jijie
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
