Code change:
alternative to based on NAME 's comment "I can't help but wonder if it'd make sense to have the spec be only about SD-JWT VCs and treat the plain JWT VC as just a special case of an SD-JWT with no selectively disclosable claims." no changes to the basic structure. simple clarifications what to do when there are no selectively disclosable claims ie no claim and no Disclosures. Might need some more details but this is how it might look like. (cc NAME NAME linked to rendered preview
Generally, I really like this approach! Some examples could be useful for key binding with JWT (no disclosures)
I'd expect the typ for both to have +jwt if that were really the case. There is another draft up for multiple suffixes. URL Is it simple enough to support now?
should this be titled ? I think this should be changed as well as the title before merging to make sure we are calling out that this covering SD-JWTs and JWTs
Yes. Will make a change once we have a decision whether PR or this one is the way to go…
What is the position of this specification? From my understanding it defines a VC with JWT claims it defines a profile for the JWT claims it defines a profile for securing the VC There's an open discussion between the sd-jwt and JWS protection. Relevant discussion has been started URL - sd-jwt introduces an encoding that becomes incompatible with JWS in the limit where selective disclosure is not used. In other words, it introduces a first-order phase transition. Let's see how this topic resolves. IMO, the data model and securing mechanisms should support both sd-jwt and JWS.
I do like this approach, but I am a bit concerned that even in the 'no disclosures' case, we'll have the trailing tilde in the issuance and presentation (when no KB is present). A JWT is not a special case of an SD-JWT for this reason.
I agree with the concern.
IMHO keeping the trailing tilde is preferable as it keeps the model consistent.
from what I am sensing, there seems to be a lot of preference towards the approach in this PR over , partially because it is simpler and gives one credential format and not two (consolidation, yay!), with one major discussion point being a ~ after a JWT VC when it is issued. 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.

Related discussion:
text: 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.