Songbo, Caleb, Rafael,
Thanks for the reviews. Answers in one place, since -02 takes all of them.
Songbo, both points are right, and both are defects in -01.
Section 4.4. The MAY that lets a deployment carry the WAG identity as iss
and sub inside act contradicts Section 5.1, and the paragraph contradicts
itself: it says act.sub remains the Agent DID, then permits replacing it. A
token built under that MAY has act.sub naming a platform-scoped identifier
while client_id names the DID, which Section 5.1 calls malformed. -02
removes the MAY. WAG identity travels only as receipt evidence under
Section 5.4, with the issuer and registration context Section 4.4 already
requires. A verifier that needs the WAG identity reads it from a DS-signed
receipt bound to the hop, not from a token claim whose meaning depends on a
mapping the verifier may not hold.
client_id. RFC 8693 Section 4.3 defines it as the client that requested the
token, and RFC 9068 Section 2.2 imports that definition. -01 never says who
requests a child, and the natural reading of Section 5.4 is that the
delegating agent does. Under that reading A requests the token and
client_id names B, which is wrong. The fix is to make B the requester:
1. A holds T1 (sub=user, client_id=A, act={"sub":A}). It calls the DS with
T1, a DPoP proof, B's DID and the narrowed capabilities. The DS runs the
Section 5.4 checks, signs receipt R2 naming A and B, and returns a
single-use grant bound to B's DID.
2. B authenticates as itself per Section 4.2 and sends a token exchange
request with that grant as subject_token, its own RFC 7523 assertion as
actor_token, and a DPoP proof under its own key.
3. The DS issues T2: sub=user, client_id=B, act={"sub":B,"act":{"sub":A}},
cnf bound to B's key, prf=[R2].
client_id is now the authenticated requester, act.sub agrees with it
because both name B, and A appears only in nested act as attribution. The
grant is useless to anyone without B's key. -02 adds this exchange as
Section 5.4.1.
Caleb, on the three questions:
Rank ordering: agreed, in the token. Rafael's -02 carries it as an "order"
member on the rank constraint (his Section 4.2 and Appendix C), least to
most permissive, with a child's order required to equal its parent's. -02
of my draft adopts that and drops the rule that the Delegation Server hold
a registered ordering.
client_id and act.sub: agreed, keep both. client_id is what an RFC 9068
resource server and AIMS Section 10.3 read; act carries prior actors. Once
the receiving agent is the requester the two cannot legitimately differ,
and the agreement rule becomes the cheap consistency check you describe.
WAG identity: agreed, receipt evidence only, as above.
On the user-minted shape: it's real, and the two shapes need to compose.
-02 takes a first step. For tokens meant to be chain-verifiable it adopts
the agent_delegation detail from Rafael's draft, so a custody server can at
least read and check the authority carried by a user-minted chain token in
the same vocabulary it uses itself. Full composition, a custody server
accepting a user-minted token as the root of its own chain and the reverse,
is work for -03. I'd welcome the use-case write-up.
Rafael, thanks, that settles Section 5.3 as above. One related point from
Cliff's thread on your -02: where a server in the call path holds the
Principal's deposited grant, it learns at use time whether that grant still
stands, because the upstream call fails once it is withdrawn. That covers a
withdrawn grant, not role loss inside the Principal's own organization.
-02 goes up before the 2 November cutoff.
Kieran
On Tue, Oct 13, 2026 11:17 PM, Songbo Bu <[email protected]> wrote:
> Hi Kieran,
>
> Two wire-level clarifications on -01:
>
> Section 4.4 keeps act.sub as the Agent DID, but its optional WAG iss/sub
> encoding appears to replace that value with a platform-scoped identifier.
> How should this satisfy Section 5.1's client_id/act.sub agreement rule?
> Receipt evidence seems the simpler default unless the alternate encoding
> specifies how the existing trusted mapping affects that comparison.
>
> Also, RFC 9068 Section 2.2 imports client_id from RFC 8693 Section 4.3,
> which identifies the token-requesting OAuth client. If A requests a child
> token for B, must B instead be the authenticated requester, or can
> client_id and act.sub differ? A concrete exchange example would help settle
> the redundancy question.
>
> Best,
> Songbo
>
>
> On Tue, 13 Oct 2026 16:56:49 -0400, Kieran Sweeney <[email protected]>
> wrote:
>
> All, I have posted -01 of draft-sweeney-wimse-credential-delegation and I
> am asking both groups to review it. -00 went up in July without an
> introduction or a request for comments. -01 is the revision I want read.
> https://www.google.com/url?q=https://datatracker.ietf.org/
> doc/draft-sweeney-wimse-credential-delegation/&source=
> gmail&ust=1792011408928000&sa=E What it is. A profile for one deployment
> shape: a Delegation Server holds credentials that users have deposited, and
> AI agents exercise them through that server without ever receiving them. It
> composes RFC 8693, RFC 9449, RFC 9396 and CIBA and defines no new
> cryptography. It covers what that shape adds: custody and exercise by
> proxy, synchronous cascading revocation, and signed receipts that tie each
> hop back to the user's consent. For constraint ceilings it adopts the
> vocabulary and subsumption rules of Rafael Asor's
> draft-asor-wimse-agent-delegation-chain
> rather than defining its own, and it is written to compose with that draft,
> the Workload Authorization Grant, and Delegate SD-JWT. Where I most want
> eyes: 1. Delegation Token claims (Section 5.1). sub stays the delegated
> principal. The acting agent is named in client_id, per RFC 9068 and AIMS
> Section 10.3, and in act.sub, per RFC 8693, which also carries prior
> actors. The two MUST agree. 2. Constraint ceilings (Section 5.3). A
> constraints claim in the shape of Asor Section 4.2 (max, min, one_of,
> not_one_of, prefix, rank) with Section 4.3 subsumption, fail-closed
> parsing, and inherit-on-omit. Per-exercise ceilings are checked offline
> from the chain; lifetime aggregates stay with the Delegation Server as the
> single writer. 3. Chain integrity (Section 5.4). Each hop produces a
> DS-signed receipt referenced from prf. The DS re-verifies the parent chain,
> current authority and revocation state at every hop, authority only
> narrows, and nested act is attribution only, attested per hop with its
> as-of time. 4. Workload Authorization Grant composition (Section 4.4). A
> WAG-provisioned workload still authenticates as an Agent. Its WAG identity
> is recorded as receipt evidence, scoped to the matched platform
> registration, and is never treated as consent or as proof of possession.
> Three questions I would like answered: Section 5.3: rank labels carry no
> ordering on the wire. Should the ordering for a key live in the
> constraint-types registry entry or in the token? Until that is settled, -01
> requires the DS to hold an ordering for every label it mints and requires
> verifiers to fail closed on a label they cannot order. Section 5.1: is
> naming the acting agent in both client_id and act.sub worth the redundancy,
> or should one of them go? Section 4.4: should WAG identity travel only as
> receipt evidence, or is carrying it as iss and sub inside act, which RFC
> 8693 Section 4.1 allows, the better default? Implementation status (Section
> 9). An open source implementation ( https://www.google.com/url?q=
> https://github.com/cred-ninja/sdk&source=gmail&ust=1792011408928000&sa=E,
> Apache-2.0) follows the architecture but not yet the wire formats. It
> implements did:key agent identity, version negotiation, exercise by proxy,
> attenuated sub-delegation with all six constraint types, signed per-hop
> receipts with offline chain verification, and an ancestor revocation check
> before each sub-delegation. It does not yet implement RFC 8693 token
> exchange, DPoP, RAR, RFC 7523 agent authentication or CIBA; Section 9 lists
> those gaps. Its scope grammar, constraint subsumption and strict JSON
> decoding pass Asor's published v0.9.0 vectors (20 of 20) and 4 of 4
> proposed scope vectors. Those vectors use Asor's token format, so they do
> not test this document's formats. Comments on the list are best; issues at
> https://www.google.com/url?q=https://github.com/cred-ninja/
> protocol&source=gmail&ust=1792011408928000&sa=E also work. Kieran Sweeney
>
>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
