Code change:
7. <del> TBD: Holder provided nonce via </del> <ins> The Privacy Considerations in the SD-JWT specification I-D.ietf- oauth-selective-disclosure-jwt apply to this specification. Additionally, the following privacy considerations need to be taken into account when using SD-JWT VCs. </ins> <del> . </del> <ins> 7.1. The Privacy Considerations in Section 10.5 of I-D.ietf-oauth- selective-disclosure-jwt apply especially to the claim. 7.2. Issuers and Holders have to be aware that while this specification supports selective disclosure of claims of a given SD-JWT VC, the claim is not selectively disclosable.  In certain situations this could lead to unwanted leakage of additional context information. In general, Issuers are advised to choose values following data minimization principles.  For example, government Issuers issuing an SD-JWT VC to their citizens to enable them to prove their age, have to avoid putting information into the value that allows third-parties to infer additional personal information about the Holder, e.g., country of residency, citizenship etc.  A better approach is to have more generalized types, for example an age-proof SD-JWT VC type. Additionally, Holders have to be informed that besides the actual requested claims what information is shared with the Verifier. 7.3. A malicious Issuer can choose the Issuer identifier of the SD-JWT VC to enable tracking the usage behavior of the Holder if the Issuer identifier is Holder-specific and if the resolution of the key material to verify the Issuer-signed JWT requires the Verifier to phone home to the Issuer. For example, a malicious Issuer could generate a unique value for the Issuer identifier per Holder, e.g., and host the JWT Issuer Metadata.  The Verifier would create a HTTPS GET request to the Holder-specific well-known URI when the SD-JWT VC is verified.  This would allow the malicious Issuer to keep track where and how oftehn the SD-JWT VC was used. Verifiers are advised to establish trust in an SD-JWT VC by pining specific Issuer identifiers and should monitor suspicious behaviour such as frequently rotating Issuer identifiers.  If such behaviour was detected, Verifiers are advised to reject SD-JWT VCs issued by such Issuers. Holders are advised to reject SD-JWT VCs if they contain easiliy correlateable information in the Issuer identifier. </ins> 8.

Related discussion:
text: So what would be the scenario to request a VC without knowing its type?
Having the type disclosable does not mean the user never shares it. If a verifier requests the type then the user can disclose it, no? The issues with both the and the is that they reveal what claims the user has, which is more than what is strictly required for a service. The privacy requirements from the Parliament, Council, and the Commission are strict. However, I cannot think of a scenario to justify type being disclosable. Arguments for: As NAME mentions, the verifier may require only a particular claim, e.g., age over 18, and should reasonable accept these from any trusted issuer without having to know what exact attestation type it came from. Some issuers may have multiple types that all contain the same attribute. And there are strong demands that the user should reveal only what is required for the service and absolutely nothing else (to the point where I am actively having to fight against people who want to put ZKP everywhere). Not revealing claim values is great; also hiding what claims you have is more privacy preserving. Arguments against: Beside from those already mentioned, you could question the privacy benefits. As long as the individual Issuer's signature is included, it is likely not that hard to guess what the particular attestation may contain, particularly if the Issuer only issues few attestations. In conclusion, given how there are no technical challenges to making type disclosable, and how the Verifier may just request a type and refuse to process a presented claim without type disclosed, I would argue for that the type MAY be disclosed.
The field is always disclosed, hence not revealing the only offers privacy if the same issuer with the same key offers multiple VCs that share the same claim name that is being requested. It seems like an unrealistic scenario that this is a privacy benefit. It seems to me the usecase would be merely a fillout help, where the verifier does not care about the origin of claims and handles those as self-attested
Let's create a PR and see how the spec will change and continue the discussion there.
Currently, the spec gives the following function: Given that, I don't think it can be selectively disclosed. We should close this issue.