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]
