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]
