Code change:
Merging this since this is an improvement and PR might not be merged as is.
NAME can you pls resolve merge conflicts, then we can merge this PR.
Merging PR since a lot of approvals.
lgtm, since we have merged PR and might not merge PR , we should merge this.

Related discussion:
text: referenced in the credential.  This process is further described in I-D.ietf-oauth-selective-disclosure-jwt. <del> To support revocation of Verifiable 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.) </del> <ins> To support revocation of Verifiable Credentials, revocation information can optionally be retrieved from a Status Provider.  The role of a Status Provider can be fulfilled by either a fourth party or by the Issuer. </ins> This specification defines Verifiable Credentials based on the SD-JWT <del> format with a JWT Claim Set. </del> <ins> format with a JWT Claim Set. It can be used when there are no selective disclosable claims, too. </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.  While JWT- based credentials enable selective disclosure, i.e., the ability for a Holder to disclose only a subset of the contained claims, in an Identity Provider ecosystem by issuing new JWTs to the Verifier for every presentation, this approach does not work in the three-party- model. </del> <ins> process as it builds upon established web primitives. </ins> Selective Disclosure JWT (SD-JWT) I-D.ietf-oauth-selective- disclosure-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 <del> the Issuer).  This format is therefore perfectly suited for Verifiable Credentials. 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. JWTs (and SD-JWTs) can contain claims that are registered in "JSON Web Token Claims" registry as defined in RFC7519, 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. </del> <ins> the Issuer). SD-JWT is a superset of JWT as it can also be used when there are no selectively disclosable claims and also supports JWS JSON serialization, which is useful for long term archiving and multi signatures.  However, SD-JWT itself does not define the claims that must be used within the payload or their semantics. This specification therefore uses SD-JWT and the well-established JWT content rules and extensibility model as basis for representing Verifiable Credentials with JSON payload.  Those Verifiable Credentials are called SD-JWT VCs. SD-JWTs VC can contain claims that are registered in "JSON Web Token Claims" registry as defined in RFC7519, as well as public and private claims. </ins> 1.3.