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]
