Code change:
1. <ins> 1.1. </ins> A Verifiable Credential is an tamper-evident statement made by an Issuer about a Subject of the Verifiable Credential.  Verifiable Credentials are issued to Holders which can present Verifiable Credentials to Verifiers typically in form of Verifiable <del> Presentations. </del> <ins> Presentations which are secure envelops that contain Verifiable Credentials addressed to a specific audience. </ins> These relationships are described by the three-party-model which involves the following parties: <del> Verifiers have to trust Issuers to make trustworthy statements about the Subject and they can additionally require that the Holder provides a proof that they are the intended Holder of the Verifiable Credential which can important for security reasons.  This is only possible if an Issuer binds the Verifiable Credential to a specific Holder at the time of issuance. </del> <ins> In the three-party-model, Verifiers have to trust Issuers to make trustworthy statements about the Subject and they can additionally require that the Holder provides a proof that they are the intended Holder of the Verifiable Credential which can important for security reasons.  This is only possible if an Issuer binds the Verifiable Credential to a specific Holder at the time of issuance.  This process is referred to as Holder Binding and is further described in I-D.ietf-oauth-selective-disclosure-jwt. The three-party-model, i.e., actors, Verifiable Credentials and Verifiable Presentations, are further described in [VCDM2.0]. However, this specification focuses on a specific version of the three-party-model which can have different features but will provide a representation of the model described in [VCDM2.0]. 1.2. </ins> JSON Web Tokens (JWTs) RFC7519 can in principle be used to express Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives.  However, JWTs do not support selective disclosure, i.e., the ability to disclose only a subset of the claims contained in the JWT, in the three-party- <del> model as described above.  This is a common problem in the so-called three-party model: An Issuer creates a Verifiable Credential for some End-User (Holder), who then presents this credential to multiple Verifiers.  A credential might contain a large number of claims, but the Holder typically only wants to disclose a subset of these claims to a Verifier.  In this case, the Holder would have to receive a new JWT from the Issuer, containing only the claims that should be disclosed, for each interaction with a new Verifier.  This is inefficient, costly, and the necessary interaction with the Issuer </del> <ins> model as described above.  This is a common problem in the three- party model: An Issuer creates a Verifiable Credential for some End- User (Holder), who then can presents this credential to multiple Verifiers.  A Verifiable Credential might contain a large number of claims, but the Holder typically only wants to disclose a subset of these claims to a Verifier.  In this case, the Holder would have to receive a new JWT from the Issuer, containing only the claims that should be disclosed, for each interaction with a new Verifier.  This is inefficient, costly, and the necessary interaction with the Issuer </ins> introduces additional privacy risks. <del> SD-JWT is a specification that introduces conventions to support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer). This format is therefore perfectly suitable for Verifiable Credentials. </del> <ins> Selective Disclosure JWT (SD-JWT) [SD-JWT] is a specification that introduces conventions to support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer).  This format is therefore perfectly suitable for Verifiable Credentials and Verifiable Presentations. </ins> SD-JWT itself does not define the claims that must be used within the payload or their semantics.  This specification therefore defines how

Related discussion:
text: I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.