Kieran, all, Comments on two of your four questions, from the human-approval end of the chain.
On 4, composing a user-minted root. I would suggest -03 keeps two things separate in the root: who minted it (the user rather than the DS), and what evidence shows that a natural person actually approved it when it was minted. The second would be method and assurance only, for example using the amr and identity-verification values now being registered in OAuth, and never the underlying biometric data. A verifier away from the DS then has a fixed place to check it without needing to know how the DS works internally. draft-zagarella-verified-human-root-01 describes one way to carry that evidence. I am not suggesting Cred adopts it, only that the slot exists so that any such profile can fill it. On 2, "invalidation, not closure" reads correctly to me, and saying it plainly is a real improvement. One addition: if a delegation can be suspended and later restored, Section 7 should say what a verifier sees for actions taken while it was suspended, and whether a restored delegation is the same grant or a new one. Otherwise two verifiers holding the same tokens can reach different answers about an action taken just before restoration. A short worked example would settle it. The 1-hour cap seems a reasonable default, provided the text presents it as a bound on exposure rather than a guarantee of closure. Rob. Rob Zagarella, Violet Shores On Tue, Nov 03, 2026 01:38 AM, Kieran Sweeney <[email protected]> wrote: > 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] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
