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: Added privacy considerations section from SD-JWT which provides a good foundation. ,
Currently, is not one of the selectively disclosable claims. This might be ok but it might have some privacy implications if a VC has multiple types. Let's assume the following: A VC with the types: driver's-license, age-over-18. If the holder discloses only the age, then based on the current specification, the verifier would also know that the age was disclosed from a DL which is probably unnecessary context info since all the verifier needs is to trust the issuer of the VC. Note, the issuer itself might also leak some contextual info as well, so the issue might not need to be mitigated or it might not be entirely possible anyways. Should we make selectively disclosable per array entry? Is this even supported by SD-JWT?
Closing this issue since SD-JWT doesn't support selectively disclosing array elements.
We might want to add something to privacy considerations about that.
FYI: There is a discussion about Selective Disclosure for array elements. URL
suggest to close as the type is a simple string now
NAME raised an issue with me that "if the type is always disclosed, what is the point of selective disclosure because the verifier will know what claims are in the credential". I think we should consider making type selectively disclosable.
I agree with Peter and I'm in favor of sd for type
What is the value of a VC without type information? Or let me put it the other way around. If the Verifier is supposed to be able to process a VC without knowing the type (which also means it can request the VC presentation without specifying the type), why do we need the type at all?
I was wondering about that point as well - what is revealed information worth without information about credential type (and corresponding trust framework).
It becomes valuable if all the verifier wants to know is a specific claim, e.g., , and trusts an issuer which could issue other credential types as well. The credential type can also make a difference, e.g., if somebody wants to know whether somebody has a driver's license but is not interested in the details.
My current assumption is that is the primary selection criteria for credentials in a presentation request (as identifier for a pre-defined bundle of claims associated with certain policies for enrollment and issuance). Based on that assumption, the Verifier always knows the type.