[WIMSE] Re: [OAUTH-WG] draft-sweeney-wimse-credential-delegation-02

[Kieran Sweeney <[e-mail]>]

Caleb, Rob,

Thanks both.

Caleb, on 1, 4 and 6: the remap for a user-issued token, the depth-0 values
and "user-issued" all read right to me. On 2, Rafael and I still need to
agree how a user-issued root composes with the chain format, and your
jti-as-root shape is a concrete proposal for that. On 3, a mode marker per
cumulative key is what I proposed for -03 in my post on -02. One caution on
the delegate-held tally: a cumulative budget needs a single writer that
sees every exercise, so a tally held at each verifier bounds the total per
verifier, not across them. Section 5.5 already says that separate verifiers
that each see only some of the exercises do not between them hold the
total. On 5, -02 names no status mechanism for a token the DS did not
issue; Section 7 says only that an offline verifier learns of a revocation
through whatever status mechanism it consults.

Rob, keeping who issued the root separate from evidence that a person
approved it is a useful distinction. On suspension and restoration, -02
Section 7 covers revocation only and says nothing about either. Agreed that
the 1-hour cap bounds exposure and is not closure.

Kieran

On Fri, Nov 06, 2026 07:49 PM, Rob Zagarella <[e-mail]> wrote:

> 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