Hi all, I posted draft-sweeney-wimse-credential-delegation-02 on 2026-10-30. Thanks to everyone who reviewed -01 on list and off list. Much of -02 is a direct response to that review. https://datatracker.ietf.org/doc/draft-sweeney-wimse-credential-delegation/ <https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-sweeney-wimse-credential-delegation/&source=gmail&ust=1793715884595000&sa=E>
Diff from -01: https://author-tools.ietf.org/iddiff?url1%3Ddraft-sweeney-wimse-credential-delegation-01 <https://www.google.com/url?q=https://author-tools.ietf.org/iddiff?url1%3Ddraft-sweeney-wimse-credential-delegation-01%26url2%3Ddraft-sweeney-wimse-credential-delegation-02&source=gmail&ust=1793715884595000&sa=E> What it is, briefly: a Delegation Server holds credentials a user deposits, and agents exercise them by proxy under a delegation token. It is a profile of RFC 8693, 9449, 9396, CIBA, RFC 7523 and RFC 9068. The agent never holds the upstream credential. Main changes from -01: 1. Sub-delegation exchange (Section 5.4.1). client_id and act.sub both name the receiving agent, who is also the token requester, in a two-step exchange. act is attribution only and never authority. 2. Rank order is carried in the token, so a verifier does not depend on out-of-band ordering. 3. Cumulative bounds. A delegation_constraints claim carries max_lifetime and max_subtree, with the DS as single writer of the running total. 4. Chain-verifiable profile (Section 5.5). For tokens verified away from the DS, -02 adopts the agent_delegation format from draft-asor-wimse-agent-delegation-chain unchanged, including the shared scope grammar and constraint vocabulary. Composition with a user-minted root is deferred to -03. 5. Revocation (Section 7). revoked_count is invalidation, not closure. Exchanged and offline tokens are only partially revoked until they expire. Cross-DS and cross-domain revocation is out of scope. The 1-hour token cap bounds admission after revocation. 6. Trust and evidence. Section 10.9 states plainly that the DS is trusted with deposited credentials. Section 10.8 covers long-term evidence anchoring. WAG identity appears only as receipt evidence. ML-DSA is now permitted. Credit: Rafael Asor, Caleb Dayton, Songbo and Deonte Watts shaped the constraint, revocation and chain-profile text, and Thaha is credited for the -01 comments. Please tell me if I got any attribution wrong. Where I most want eyes: 1. The cumulative-bound design. Caleb has argued for a delegate-held tally instead of a DS ledger. I plan to add a mode marker per cumulative key in -03 so both can be expressed. Does that work, or is one mode enough? 2. Section 7. Is "invalidation, not closure" the right framing, and is the 1-hour cap the right place to bound admission? I would like to align the wording with the S+L revocation-admission bound discussion on the AIMS thread. 3. Section 5.5 and the depth boundary. AAT J.10.f and the Asor -03 text differ by one hop on del_max_depth. I would like one meaning across the drafts. 4. User-minted root composition for -03. Rafael and I need to agree on how a root minted by the user rather than the DS composes with the chain format. Implementation status (Section 9): the reference implementation and test vectors are at https://github.com/cred-ninja/protocol <https://www.google.com/url?q=https://github.com/cred-ninja/protocol&source=gmail&ust=1793715884595000&sa=E>. The Cred SDK 2.0.0 (https://github.com/cred-ninja/sdk <https://www.google.com/url?q=https://github.com/cred-ninja/sdk&source=gmail&ust=1793715884595000&sa=E>) tracks the 2.0 server. Brokered delegation now requires an agent signing identity, and the SDK creates a request-bound DPoP proof, so a delegation id alone no longer authorizes exercise. Comments here or as GitHub issues at https://github.com/cred-ninja/protocol <https://www.google.com/url?q=https://github.com/cred-ninja/protocol&source=gmail&ust=1793715884595000&sa=E> are both fine. Kieran Sweeney
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
