Ryan, I read -14. Two technical points, then the charter question.
First, sub-receipt holder binding. Sections 4.4 and 8.7 verify orchestratorSignature against the sub-receipt's own signerPublicKey. That key also signs the sub-receipt body, so the check shows only that one key signed twice. The parent body names no delegatee key (agentId is a string), so anyone holding a copy of a parent receipt can mint a narrower child that passes every check in 8.7. Receipts are bearer and get logged, so copies exist. The fix is to put the delegatee's public key or its thumbprint in the parent body and require the child's signerPublicKey to match it. orchestratorSignature then adds nothing and can go. Second, Section 10 makes the reference gate's check list, ordering, gate signing and audit logging normative for a conformance profile, along with a known deviation. Conformance should be the semantics of Sections 4 to 9. Check plumbing belongs to implementations. On charter fit: the problem is in scope. As written, the receipt touches no OAuth message. It defines no claim and no authorization_details type, and it says nothing about token exchange or the actor drafts you cited. A binding is what the WG can evaluate: for example, an authorization_details type or token claim carrying receiptId and the delegatee key, so an AS or RS can tie an access token to the receipt that authorized it. On where it fits next to the AS: Jeff's point on the WIMSE thread holds for the first hop. When an AS is involved, its consent event is already the attributable authorization. Receipts earn a place for the hops after that, which the AS does not see. And a principal-signed root adds something only if the signing key is user-held, non-exportable and gated on user verification. -14 does not yet say where the key lives. One data point. draft-sweeney-wimse-credential-delegation-01 Section 5.4 has a server sign each hop, binding the parent and child token identifiers, both actors and the subject, with the child sender-constrained. A principal-signed root and server-signed hops answer different questions and compose. A shared attenuation vocabulary would let one verifier check both. Kieran On Sat, Oct 10, 2026 03:27 PM, Ryan Nelson <[email protected]> wrote: > Chairs, list, > > I am writing to ask whether an individual draft I authored fits the > OAuth WG's charter, and if so, what you would want to see before > adoption could be considered. > > The draft is draft-nelson-agent-delegation-receipts, titled > "Delegation Receipt Protocol for AI Agent Authorization", now at > revision -11 (active on the datatracker through 12 April 2027; the -00 > dates to 28 April 2026). It defines signed receipts for AI-agent > authorization: who delegated what authority to which agent, under what > scope and time window. The signature profile is JWS (RFC 7515) over > JCS-canonicalized JSON (RFC 8785) with ES256, and there is a > COSE_Sign1 alternative. It maps itself against related industry work > such as Google AP2's signed mandates, Decagon PACT, ERC-8004, and > UCANs. > > I will be upfront about where it stands: > > - There is exactly one reference implementation ("receipt-interop" > 0.1.0, Apache-2.0 TypeScript), which verifies the draft's JWS profile > plus UCANs and agent-passport Action Receipts. It has 116 tests, but > it is mine, so treat this as single-implementer status. > - The draft states its own limitations: the verifier is a same-process > verifier, and it offers no control against a malicious operator of the > agent host. It does not claim to solve those problems. > - It is an individual Internet-Draft with no IETF standing. > > Two things I want to name explicitly rather than have the list discover > them: > > First, the neighboring work. The draft-mcguinness-oauth-actor-* family > (actor receipts, actor proofs, actor profile; the receipts -00 dates > to 4 July 2026) is the closest overlap I know of, and it is > OAuth-native in a way mine is not: issuer-signed per-hop provenance > receipts carried as JWTs inside token-exchange flows. My draft is a > standalone, user-signed authorization artifact — scope, boundaries, > instruction hash, attenuation, cascade revocation — not bound to OAuth > flows. I read these as different layers (provenance of hops vs. > authorization content; the actor-receipts draft explicitly does not > attest scope, audience, or lifetime, which is exactly what mine > covers). If the WG ever consolidates this space, I would rather > converge with that work than collide with it, and my verifier library > is built to add new formats rather than defend one. > > Second, one open question I am carrying into the next revision: > whether verifiers must ignore unknown body fields or reject them. The > -11 text says ignore; the reference implementation currently rejects. > I have not settled it, and I would welcome the list's view — including > how sibling drafts handle extension claims. > > My questions: > > 1. Does this look like work the WG could take on under the current charter? > 2. If it is close but not ready, what would you need to see first? > More implementations? A narrower scope? Alignment with the > transaction-tokens or SD-JWT VC milestones? > 3. On the unknown-fields question: is there a house view, or is this > genuinely per-draft? > > Happy to continue entirely on the list. No call requested. > > Ryan Nelson > _______________________________________________ > 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]
