Code change:
I'm not sure whether we really need a comprehensive description of the issuer-holder-verifier model. I think what is needed is a description why JWT is not suitable and why SD-JWT is to motivate VC-SD-JWT. Note: we also have a duplication of term definitions between intro and terminology section
lgtm now

Related discussion:
text: Abstract <del> This specification describes data formats, validation and processing rules to express Verifiable Credentials with JSON payload based on the securing mechanisms of SD-JWT I-D.ietf-oauth-selective- disclosure-jwt. </del> <ins> This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payload based on the SD-JWT format I-D.ietf-oauth-selective-disclosure-jwt. </ins> 1. 1.1. <del> 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 Presentations which secure Verifiable Credentials addressed to a specific audience. These relationships are described by the three-party-model which involves the following parties: 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 </del> <ins> In the so-called Three-Party-Model, Issuers issue Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers.  Verifiable Credentials are tamper-evident (usually cryptographically signed) statements about a Subject, typically the Holder. Verifiers can check the authenticity of the data in the Verifiable Credentials and optionally enforce Holder Binding, i.e., ask the Holder to prove that they are the intended holder of the Verifiable Credential, for example, by proving possession of a cryptographic key referenced in the credential.  This process is further described in </ins> I-D.ietf-oauth-selective-disclosure-jwt. <ins> To support revocation of credentials, an optional fourth party can be involved, a Status Provider, who delivers revocation information to Verifiers.  (The Verifier can also serve as the Status Provider.) </ins> The three-party-model, i.e., actors, Verifiable Credentials and <del> Verifiable Presentations, is also described in VC-DATA.  However, this specification provides a specific format of Verifiable Credentials which deviates from the format described in VC-DATA to create Verifiable Credentials based on SD-JWT and JSON payloads but a translation algorithm is provided in this specification. </del> <ins> Verifiable Presentations, is also described in VC-DATA.  This specification defines Verifiable Credentials based on the SD-JWT format and JSON payloads.  A translation algorithm between the two approaches is provided in this specification. </ins> 1.2. JSON Web Tokens (JWTs) RFC7519 can in principle be used to express Verifiable Credentials in a way that is easy to understand and <del> 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, which is a requirement to implement the three-party-model efficiently. </del> <ins> process as it builds upon established web primitives.  However, JWT- based credentials do not support selective disclosure, i.e., the ability for a holder to disclose only a subset of the claims contained in the JWT, which is a requirement to implement the three- party-model efficiently. </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 <del> perfectly suitable for Verifiable Credentials and Verifiable </del> <ins> perfectly suited for Verifiable Credentials and Verifiable </ins> Presentations. SD-JWT itself does not define the claims that must be used within the payload or their semantics.  This specification therefore defines how Verifiable Credentials can be expressed using SD-JWT. <del> JWTs are used to protect the integrity of JSON payloads, which can contain claims that are registered in the IANA JWT Claim Registry, as well as public and private claims.  Private claims are not relevant for this specification due to the openness of the three-party-model. Since SD-JWTs are based on JWTs, this specification aims to express the basic Verifiable Credential data model purely through JSON payloads, using registered claims while allowing Issuers to use additional registered claims, as well as new or existing public claims, to make statements about the Subject of the Verifiable Credential. </del> <ins> JWTs (and SD-JWTs) can contain claims that are registered in the IANA JWT Claim Registry, as well as public and private claims.  Private claims are not relevant for this specification due to the openness of the three-party-model.  Since SD-JWTs are based on JWTs, this specification aims to express the basic Verifiable Credential data model purely through JWT Claim Sets, using registered claims while allowing Issuers to use additional registered claims, as well as new or existing public claims, to make statements about the Subject of the Verifiable Credential. </ins> 1.3.