Original text:
Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn <del> Butterfield, 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>  The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Reviewer comments:
URL
I was wondering if there might be a mistake in the encoding of the address given in example 4: The documentation says: I assume this should be ? It looks like the claims where added to the list on error and there is a missing hash. I would expect to see some additional disclosure elements for postal_code, ... (each with a nonce) similar to instead.
Thanks for catching that! There is definitely a mistake in Example 4a. But it looks like the problem has to do with decoy digests in that example. The decoys listed at URL got pulled from the wrong place and so don't match up with the other example content, which includes the address claim Disclosure you've pointed. That all makes parts of that Example 4a problematic and hard to follow. I think it'd be best addressed by not including decoys in Example 4a. This is related: URL FWIW
PR aims to fix this. A preview from that PR of that example: URL and specifically the Disclosure for address: URL
Thanks for the quick response! That looks much better. I was expecting the address to be passed in a way that allows the selective disclosure of single items (e.g., only the post code). Maybe you can add an additional comment which of the three options in 5.7 every example uses (here 5.7.1). To me, having three options in 5.7 makes it unnecessarily complicated. and 5.7.3 are basically the same when you would allow having non-selectively disclosable items in this as well. If that would be the case, this could probably also handle all cases 5.7.2 would be used for.
Thanks for reporting this and NAME thanks for the quick fix! NAME The options in 5.7 are meant to show what is possible with SD-JWT and are not meant to restrict or define how can be encoded. It is up to the issuer to decide for each claim whether it should be SD or not. Options 1-3 just show some of the possible results. I'm not sure I'm following what you mean by "having non-selectively disclosable items in this as well". Could you give an example?
I created this PR to ensure that our wording around the options is clear in that the options are non-normative and not exhaustive: URL
I was wondering, if 5.7.1 would allow to have non-selectively disclosable items in the address claim: This single definition could then cover all use cases of 5.7.1,5.7.2, and 5.7.3. But i see what you are up to (thanks for ). You do want to leave a maximum flexibility. However, i am a bit concerned of "creative" uses of what is technically possible and how to make sure to be able to parse/process all possible combinations in the openid4vp context.
Yes, this mixture is possible within the current specification. With the algorithm defined in Section 6.3 there is no need (for the Holder) to be aware of all possible combinations. (In other words, such assumptions should never be hard coded.) It is just the Issuer that has to make a decision on which pattern to use.
Sure, this should never be hard coded. However you need e.g., to come up with a user friendly way of displaying that kind of information in a wallet context. It is a challenge to find an intuitive/understandable way to inform the user which information will or can be disclosed and so on. But this is becoming way to off-topic ;) Thanks for your quick response!
URL merged
I don't know why but I think we should have more examples, but not going to go against these changes.

Revised text:
Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn  <ins> 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.