Ryan, Thanks, -15 does what I asked. The delegateeKey thumbprint check closes the holder-binding gap, Section 4.6 now plainly states that custody is attested by the deployment and cannot be shown from the receipt bytes, and Section 13 provides an OAuth binding to discuss. I read your new negative vector (scope-valid, window-valid child under a stranger's key, denied on thumbprint alone) as the copied-parent case Jijie proposed; if that is right, holder binding is covered.
On registration: neither route yet. RFC 9396 creates no IANA registry for authorization_details type values; Section 12 registers only the parameter, claim, metadata and error code, and Section 2 recommends a collision-resistant namespace for type values. A URI-form type is the fit, the same direction draft-asor-wimse-agent-delegation-chain took when it withdrew its IANA request for a type value. Whether the binding later lands in a WG document is for the chairs after an adoption call. On composition: agreed, principal-signed root plus server-signed hops with one verifier checking both. The shared attenuation vocabulary already exists: draft-asor and my draft use the same typed constraint ceilings, so the offer is concrete. One verifier, one subsumption rule. Kieran On Thu, Oct 22, 2026 10:03 AM, Ryan Nelson <[email protected]> wrote: > 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] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
