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: Clarify validation around no duplicate digests in the payload (directly or recursively) and no unused disclosures at the end of processing (to & )
SD-JWT validation processes should require that the validating party (Holder or Verifier) validate that the hash of each disclosure object appears in the Issuer JWT claims. If this validation is not performed, then the SD-JWT format is malleable, in the sense that arbitrary additional disclosure objects can be added beyond those that the issuer intended. This creates the opportunity for mischief, from bugs to covert channels. This is not a difficult property to enforce. The already has the validating party compute the lists of (1) hashes of disclosure objects and (2) disclosure hashes in the Issuer JWT. So the only additional step required is to check that (1) is a subset of (2).
That requirement that the hash of each disclosure must appear in the Issuer-singed JWT is in the current draft text - near the top of has "a Holder or a Verifier MUST ensure that ... all Disclosures are correct, i.e., their digests are referenced in the Issuer-signed JWT". Seems it could be made more explicit or clear? But it is there.
Ah, thanks, I had missed that. Even given that though: I would not call this property "correct". The only other place that property appears is in 11.2, so maybe it can just be dropped, and we can just say directly "All disclosures correspond to a hash value that appears in the Issuer JWT" Given recursive disclosure, though, even that's not really sufficient. A recursively disclosed claim does not in fact appear in the Issuer JWT -- you basically need to verify that it hash-chains into the Issuer JWT via a series of disclosures If we're going to eliminate recursive disclosure, I think the current text probably suffices (modulo "correct"). But if we're going to keep it, we need to elaborate the algorithm. Maybe it can be folded into the existing recursive algorithm as a termination condition. If you're adding the hashes inside disclosed values as you restore them, then if you get to the point where none of the claim hashes are in the set of disclosure hashes, then if the set of disclosure hashes is non-empty, the object is invalid.
Assuming here in this ticket at least that we are not going to eliminate recursive disclosure.