Hi Gareth, Thanks a lot for taking the time to walk through the two cases. I hadn't really thought about sd_hash vs issuer_jwt_hash as a choice the holder makes per link, and that’s exactly what I was missing for the delegation part.
I'll rebuild it on top of Delegate SD-JWT for -01 and send it your way before posting, if you don't mind having a look. I'll also keep an eye on the issues and chime in if anything from the invoicing side seems useful. Cheers, Carlos > El 4 nov 2026, a las 21:11, Gareth Oliver <[email protected]> escribió: > > carlos: Yup! Publis > (https://datatracker.ietf.org/doc/draft-ietf-oauth-delegate-sd-jwt/) and > working on an updated version (will present a roadmap at ietf, but you can > see the issues opened here: > https://github.com/oauth-wg/oauth-delegate-sd-jwt/issues. > > @Blake: The idea of issuer_jwt_hash is for cases where the Holder wishes the > Delegate Holder to be able to change what is disclosed from the preceding > SD-JWT. > > So if you wanted to do a chain that looked like: (Base SD-JWT) Invoice -> > (Delegate 1 KB-SD-JWT) narrowed invoice -> (Delegate 2 KB-SD-JWT) further > narrowed invoice you'd want to use issuer_jwt_hash for Delegate 1, so that > way when Delegate Holder 1 further delegates they can remove the claims from > both the Delegate 1 SD-JWT *and* the base SD-JWT. > > A case where you might not want to do it would be if the base SD-JWT was some > sort of User Credential. So you have User Credential -> (Delegate 1 > KB-SD-JWT) Invoice -> (Delegate 2 KB-SD-JWT) narrowed Invoice. > > Here Delegate 1 could have the sd_hash claim, to forbid the Delegate Holder > from removing the disclosures as it moves downstream (if you, as the Holder > always want Verifiers be able to identify that it was 'this user' who made > the delegation). > > I have an open question if we want to be able to partially do this (e.g. > allow the Holder to require certain disclosures are always disclosed by the > Delegate Holder, in a generic policy way) but I don't really have the > implementation or use case experience to say that complexity is necessary. > > cheers, > Gareth > > On Mon, Nov 2, 2026 at 4:38 PM Blake Morrison <[email protected] > <mailto:[email protected]>> wrote: >> Hi Carlos, Gareth, >> >> > I'll rework the delegation part on top of it for -01. >> >> Section 4.1 of Delegate SD-JWT is worth a look for that as a delegate >> can only leave the parent mandate's disclosures out of what a >> counterparty sees if the holder put issuer_jwt_hash in the KB-JWT >> instead of sd_hash. Otherwise every invoice carries the purchasing >> policy along with it. >> >> Gareth, is issuer_jwt_hash the one you'd expect a buyer's wallet to >> use by default? >> >> Blake
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
