Code change:
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. 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.
We should add something to the privacy considerations section that explains the risk of leaking more context info from the type in certain use cases.

Related discussion:
text: 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.