Code change:
We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, <del> Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: The use of "correct" is indeed awkward and that whole bit of text could be improved. There's room for a lot of improvement there. I've always understood text like "referenced in the Issuer-signed JWT" as intending to mean included directly in that JWT but also included recursively. But being more explicit is probably worthwhile. I think it'd be sufficient to say somewhere something like "all disclosures must correspond to a hash value that appears (either directly or recursively) in the Issuer-signed JWT". That somewhere could be in place of the "all Disclosures are correct" text and/or a step in the validation steps near . To you earlier point - it's not a difficult property to enforce. Even with the recursion. A validating party needs to compute the lists of (1) hashes of the disclosure objects and has to look at (2) all disclosure hashes in the Issuer JWT (including by recursive inclusion). The only additional step is still just to check that (1) is a subset of (2). Which is basically just checking that there were no unused disclosures at the end of processing.
Agreed, if we can update the algorithm to reject if any hashes are left over, then that would fix this issue.
Great, I think we can update the the algorithm to reject if any disclosures are left over. It'd probably go near the check to ensure that no digest value is repeated in the whole of the SD-JWT - either in the payload directly or recursively in any disclosure (that check about duplicate digests needs a bit of improvement too). Also we should tidy up that text with "correct".
From the mailing list Hi Jacob, the intention was to cover the first case you listed. We should clarify this. -Daniel Am 20.10.23 um 15:02 schrieb Jacob Ward:
my 2 cents at/from URL
Also... um, wouldn't "More than one Disclosure have[ing] the same digest" imply a collision in the hash function? And therefore infeasible to actually happen. Agree that it should be clarified. Being precise with language around this stuff is tricky. But my understanding of the intent was to ensure that no digest value is repeated in the whole of the SD-JWT - either in the payload directly or recursively in any Disclosure.