Kieran, -15 is live (https://datatracker.ietf.org/doc/draft-nelson-agent-delegation-receipts/). Your review drove most of it; the custody section came out of parallel review from Jeff and Caleb Dayton.
Holder binding. Parent carries OPTIONAL "delegateeKey"; child's "signerPublicKey" must match by RFC 7638 thumbprint; no "delegateeKey" means terminal; "orchestratorSignature" deprecated. The bearer-copy case has a dedicated negative vector now: scope-valid, window-valid child minted under a stranger's key, denied on the thumbprint mismatch alone. Key custody. Section 4.6 states it normatively now: non-exportable, user verification required per signing operation, FIDO2/WebAuthn platform authenticators RECOMMENDED as the mechanism. It also says plainly what the format cannot do, which is prove custody from the receipt bytes. Custody is attested by the deployment and obtained out of band, not demonstrated by the signature. Section 10 rescoped the way you asked: the profile requires the Sections 4-9 semantics; check ordering, gate signing, and audit logging are profile requirements only, not requirements of the receipt format. Section 13 sketches the authorization_details binding (receiptId plus delegatee key thumbprint) with deliberately unregistered names. That is the opening move rather than the finished thing; the evaluable version is a registered "delegation_receipt" type. What form would the WG want that in, expert review or folded into a WG document? On composition, yes, explicitly. Principal-signed root plus server-signed hops, one shared attenuation vocabulary, one verifier checking both. Same interop shape as the EMILIA work. Happy to work it through wherever is useful. Ryan _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
