Original text:
5. <del> TBD </del>  5.1. The <del> header parameter of the SD-JWT-VC MUST be present.  The </del>  <del> value MUST use the media type </del>  <del> that is registered by this specification.  This indicates that the payload of the SD-JWT-VC contains plain JSON and follows the rules as defined in this specification. </del>  The following is a non-normative example of a decoded SD-JWT-VC header:

Reviewer comments:
Added terms and definitions section; made some changes data formats based on terms and definitions section -
I think we need to define what the following "things" are. What is the Verifiable Credential based on SD-JWTs? I believe it is the JWT that contains the s. It is not any of the combined formats. This means that the Verifiable Credential MAY NOT contain any disclosable claims, e.g., . Would you agree NAME NAME Daniel? The VC based on SD-JWT will have the media type . What is the Verifiable Presentation based on SD-JWTs? It makes sense to define that since the HB JWT has some specific requirements. It also makes sense because protocol developers will need to refer to one term when they exchange presentations or verifiable presentations between issuer holder verifier. Can we call the Combined Format for Issuance AND Presentation the Presentation based on SD-JWTs, and if there is HB, then it is a Verifiable Presentation? The VP based SD-JWT will have the media type altough I'm not sure if this makes sense. Wouldn't it better to have ? Any thoughts on that?
Also it is important to note that for OIDC4VP we use Verifiable Presentations in vptoken and we use Verifiable Credentials in OIDC4VCI in the credential response. It probably has the implication that for OIDC4VCI, we will put the VC based on SD-JWT into the credential response, or we define a format identifier for something else. Keep in mind we need to send the disclosures to the client as well. In that regards is the SD-JWT itself the SD-JWT-VC without disclosures, or is the combined format including disclosures the SD-JWT-VC? Or we follow the approach above and we return a combined presentation (no HB) in the credential response and define a credential identifier for that. It probably also means that we would put the VP based on SD-JWT into the OIDC4VP vptoken.
We (IDunion) put the combined presentation (+hb jwt) in the vp_token. What else would you expect?
That makes sense, so the VP based on SD-JWT is the combined format for presentation including HB JWT. Then, there is the question what would the OIDC4VCI credential response return? And what would be a format identifier? I know that this doesn't have to be answered in this spec but it helps with answering the terminology question.
Suggest we not overcomplicate things and say: what is returned in a VP Token in OID4VP is a combined Format for presentation with HB-JWT. what is returned in Credential Response in Credential Response in VCI is combined format for issuance. credential format identifier is 'vc+sd-jwt' for both. Terminology-wise, SD-JWT in the IETF spec is defined as an issuer signed JWS without disclosures. For this profile, the payload of SD-JWT, can be mapped back to a VCDM2.0
This is potentially fixed by PR

Revised text:
5.  <ins> This specification defines the media type which describes a VC-SD-JWT with the following components: 1.  An SD- JWT to protect the integrity of the claims, to enable selective disclosure and to ensure authorship of the VC-SD-JWT.  The SD-JWT header parameters and the payload is further defined by this specification.  1.  The full set of SD-JWT Disclosures that contain the claims in plain text. This specification defines the media type which describes the VP-SD-JWT with the following components: 1.  The SD-JWT from the VC-SD-JWT.  1.  A subset of the SD-JWT Disclosures that are selectively disclosed by the Holder.  1.  An optional holder binding JWT that proves the Holder is the intended Holder of the Verifiable Credential.  Note, it is the responsibility for the Issuer to include a confirmation method in the Verifiable Credential.  This process is referred to as holder binding.  This enables the Holder to prove they are the intended Holder of the Verifiable Credential. Further note, it is up to the Verifier to require or to not require the Holder to prove posessions of the confirmation method. </ins> 5.1. The  <ins> header parameter of the SD-JWT MUST be present.  The </ins>  <ins> value MUST use </ins>  <ins> . This indicates that the payload of the SD-JWT contains plain JSON and follows the rules as defined in this specification.  It further indicates that the SD-JWT is a SD-JWT component of a VC-SD-JWT. </ins> The following is a non-normative example of a decoded SD-JWT-VC header: