Original text:
expired or revoked keys for signature verification using reasonable and appropriate means for the given key-distribution method.  9. The privacy principles of ISO.29100 should be adhered to.

Reviewer comments:
To fix Issue , I found that removing Example 2b is the best way to go. I tried to fixate the nonces used in the examples despite decoys being generated in one of the examples, but that got quite messy and introduces a lot of unsafe code paths into the python code. An alternative would be to manage the example manually, but that is a source for errors, so let's not do that.
The decoy concept is intuitive enough that a separate example isn't needed, I think. And per the separate example that has a completely different set of digests might cause confusion. So removing 2b seems like a good course of action. The change is larger than I'd have expected. Are all the other file changes due to regenerating examples? I think so but it caught my attention. And it seems like and this will be difficult to resolve. But maybe you've already considered that.
Why remove an entire example, if we can add a text clarifying that "Example 2b uses the same data as 2a, but because even for the same claim values, different nonces are used, not just the decoys but all digests are different from those in 2a"?
That was my initial approach, but with that change there's really not that much value to the example: It just shows a bunch of digests, where the number of digests is higher than it was previously. The fact that the digests are different can be confusing for readers at worst and the example is not very helpful at best.
So instead of showing the decoy digests in the examples you propose to list them seperately and not show a complete example with decoy digests?
We agreed on our call to generate a snippet of markdown code to explicitly list the decoy digests to improve the explanation.
I updated the python script and the spec to show the decoy digests: URL
Other than the little nit about the the text that says the decoys in the example are about the address, this looks pretty good.
Do you want to mention something in the doc history?
Good point, done!
NAME Can you please review this?
states that it was created using data from , but adding decoy values. I'd expect its param to be a superset of example 2a's, but it's not the case. Am I missing something?
Example 2b includes different nonces than Example 2a. We try to use deterministic random numbers to generate the examples, but in this case, due to the order in which the decoys and regular salts are created, this approach does not produce the same nonces for the same "real" disclosures.
PR was merged

Revised text:
expired or revoked keys for signature verification using reasonable and appropriate means for the given key-distribution method. <ins> 8.9. When Holder Binding is not enforced, any entity in possession of a Combined Format for Presentation can forward the contents to third parties.  When doing so, that entity may remove Disclosures such that the receiver learns only a subset of the claims contained in the original Combined Format for Presentation. For example, a device manufacturer might produce an SD-JWT containing information about upstream and downstream supply chain contributors. Each supply chain party can verify only the claims that were selectively disclosed to them by an upstream party, and they can choose to further reduce the disclosed claims when presenting to a downstream party. In some scenarios this behavior could be desirable, but if it is not, Issuers need to support and Verifiers need to enforce Holder Binding. </ins> 9. The privacy principles of ISO.29100 should be adhered to.