All, Based on the feedback on the list, we think that the WG has decided to adopt this draft as a WG document.
Authors, Feel free to submit a new WG -00 version of the draft at your earliest convenience. Regards, Rifaat On Sun, Oct 11, 2026 at 5:44 PM Cliff Singletary <[email protected]> wrote: > Rifaat, Hannes: > > I support adoption of draft-gco-oauth-delegate-sd-jwt. > > Two things I would prefer the WG to take up after adoption (not a > condition on it) > > Section 6 ends in a binary: “If any of the steps fail then the > presentation is invalid and processing MUST be aborted.” For chain > integrity that is right; nothing in steps 1–5 is fetched. But Section 8.3 > defers revocation to “traditional mechanisms,” which do fetch. Once a > verifier consults a status source for any link, it needs to distinguish a > chain it evaluated and refused from a chain it could not evaluate because > the source did not answer, and to record which link’s status was > unavailable. Otherwise an outage reads later as a revocation of the > delegator. > > Section 8.2 lets an Issuer or Holder put constraints in “visible claims,” > but nothing in Section 6 requires the verifier to check that each Delegate > Payload stays within the constraints of the link that issued it. > Narrowing-only across the chain should be a verifier requirement rather > than a policy option, or the chain carries attribution but not bounded > authority. > Cliff > > _______________________________________________ > 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]
