Code change:
Provider.) 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.

Related discussion:
text: a bit of the context... this trailing ~ is the result of the decision being taken in SD-JWT spec to better align the issuance and presentation formats, (URL does it, and it has not been merged yet). One option is to keep issuance and presentation formats separate in SD-JWT (as-is) so that there is no ~ when (SD-)JWT VC is issued. but that is not that clean from a pure SD-JWT processing perspective is I think the opinion of its authors (NAME NAME so the question is really what to do with a trailing ~ when there is no SD in SD-JWT based VC.
should be good to merge once NAME takes a look and approves
I'm ok with this direction. I personally don't like the trailing tilde but we can fix that in another PR. I'll open an issue in the repository.
Merging this PR since a lot of approvals and no objections.
approving but will create an issue to address trailing tilde.I approve this approach over as, the specification is much cleaner I expect implementations to be much cleaner I don't see confusion with trailing tilde, because typ is not jwt but sd-jwt most interop profiles will require SD support anywayI prefer URL since I find its description of what we're achieving more natural / less surprising. But I can live with this description as well, provided the distracting "with JSON Claims" language is removed.