Original text:
8. <del> TBD </del> 

Reviewer comments:
This PR: adds relationship to other docs section - preview here: URL
One little nit on the text but otherwise looks okay (after the couple iterations by NAME and NAME thanks for those).
NAME pls approve if you are happy with the latest language, then we will merge the PR.
Data model in this document resembles to the ID Token data model as defined in OIDC (with the addition of cnf). On the other hand, the data model is trying to follow the W3C VC data model. What is the benefit of this data model over the W3C VC data model (except that the claim names are different and iss can be a URI, and not an object and that JSON-LD is not supported by the data model, which basically excludes some significant use cases such as Europass that are leveraging JSON-LD for internationalization, for example)?
It is simple, leverages all predefined JWT claims (including eKYC), and can be used by people familiar with the JWT model to also implement VCs - with SD-JWT also with selective disclosure capabilities. So it clearly gives an easy migration path from the federated to the issuer-holder-verifier model. We tested the idea with some projects and communities and it seems a lot of implementers like that. Regarding Europass and other JSON-LD-based credential schemes. There could be another spec defining how SD-JWT could be used with JSON-LD.
eKCY defines its own data model same as for ID Token. eKYC can be easily mapped to VCs. The only real difference is the name of the metadata claims (iss vs issuer, iat vs validFrom, etc.) But SD-JWT can be used with W3C VCs (bot as SD-JWT is and W3C VCs as they are).
eKYC defines an extension that can be used in any JWTish environment. Doesn't work with W3C VCs due to the split between subject related data (credentialSubject) and metadata (evidence). Ask Mark Haine. not sure what you mean. can you please explain.
We did some mapping in the past (it was some time ago, and I don't remember how far we got): Evidence in VCs is optional and the model and use of evidence for eKYC doesn't make a lot of sense since eKYC already defines the full data model. eKYC can be nicely modelled within the credential subject. There were discussions around re-using the model of eKYC for expressing different levels of verifications. Essentially it was something like: verifiable-attestation-URL is the VC data model e-kyc-verifiedclaims-2022-URL - is the JSON schema of the eKYC
Just had a chat with Alen about typing and want to share the conclusion. We think typing happens on the following levels: Payload of a (HTTPS) response - here, a processor needs to know how to process the object (blob). So on this level, the media types or should be used. JOSE header - on that level, the determines how the payload of the JWS shall be processed. fits on that level. It governs the format (SD-JWT, which implies JSON) and what claims MUST be present (e.g. and ). Those claims are related to security of and trust in the credential. They are not related to the further domain specific structure of the credential. In SD-JWT VC, we use the claim to determine the structure/schema beyond the basic structure determined by the JOSE header. A university credential, for example, will have different rules for the schema of the payload than a drivers license. NAME NAME NAME NAME NAME NAME NAME Please let us know, whether we are on the same page. If so, it might be beneficial to add some text along those lines to the draft.
on point 1, I think that is ruled by the underlying protocol - OID4VP/OID4VP define those ( and ) I do not think sd-jwt vc draft should say anything about that. on points 2 and 3, i think i agree
to answer the original question raised in the issue, the way VCDM 2.0 is going, it requires data model to be JSON-LD and processed according to JSON-LD rules, so things like will not be conformant. the value of VCDM IMO is defining the concept of a credential in a three party model: issued credential must contain the issuer, the subject, claims about the subject, metadata about the issuance of that credential (iat, exp, etc.) and optionally a cryptographic key. that's it. How to map it to the JWT claims is not the expertise of w3c vc wg nor is well-defined in the documents produced by that group. VCDM itself is silent about how to sign/process the I would absolutely not equate ID Token data model to a VC data model. VC data model needs one step to get to the ID Token usability which is defining how the concepts defined in VCDM are mapped to the JWT claims and how to sign/process that JWT claimset, which is what this sd-jwt vc draft attempts to do.
NAME I think we need to at least scope the media type definition in the spec as those definitions are related to the only, not request payload.
why it can't be left to the protocol? why it can't be ? just for example: URL
NAME the way VCDM 2.0 is going, it requires data model to be JSON-LD and processed according to JSON-LD rules, so things like NAME is in the payload, we put it to be conformant, but are not processing it will not be conformant. Please check the discussion in URL since the conclusion is different. NAME What do you understand under LD processing? (LD processing with VCs is used only by: data integrity proofs, selective disclosure that's been just defined, internationalisation, identity matching, some advanced querying) Since JWS is not using any of that, JWS protection mechanism is not affected by the -LD part. However, it enable use cases, that want to use the -LD (e.g., ELM v3) for internationalisation etc., to use it. When VCs are secured with JWS, LD processing is not performed. It MAY be performed, if use case requires it, in the post-processing (after the validation) or rendering phase. the value of VCDM IMO is defining the concept of a credential in a three party model: issued credential must contain the issuer, the subject, claims about the subject, metadata about the issuance of that credential (iat, exp, etc.) and optionally a cryptographic key. that's it. How to map it to the JWT claims is not the expertise of w3c vc wg nor is well-defined in the documents produced by that group. That's perfectly fine. W3C VCDM is focusing on the VCDM data model. Note that the current VCDM v2.0, without any JWT claim, is a valid JWT. VCDM itself is silent about how to sign/process the data model I think this is a good approach of the specification, since it defines a data model. Securing mechanism should be defined by specifications like JAdES which defines a profile for JSON-based AdES.
Reason is simple and it is following the basic architecture/design principles. Signature (e.g., JWS) defines the serialisation and with it the resulting type. JWS specification cannot and should not know anything about the protocol that will use it. When a protocol defines a profile or a set of supported elements, the protocol needs to ensure that the media type that's defined consistent with the elements it selected.
NAME Perhaps I did not explain well. This is the media type definition from the spec. It does not describe the context where the media type shall be used. So people might think this is a media type that should be used as content type of an HTTP response. I think we agree this is not the case. All I'm suggesting is to document the intended use in the JOSE header (and as format identifier in credential exchange protocols). Would you agree?
I don't agree that it is a good idea to take VCDM claims and use all of those to secure JWTs, because there are existing claims from JWT claims registry and existing implementations depend on those
NAME thank you for your feedback and I fully understand your concern. We need to put things into a context: most of those cases operate within closed systems where everything is well defined - data models, verification rules, etc. Within this context, I fully agree with you. Securing JSON-LD can be done today by JAdES (pure JWS, no JWT). I believe it is worth to read and reflect on it URL From my experience, the NAME is really processed (in most cases) outside of the verification scope/process. There are signatures that rely on the context, however, that's not relevant for JWS and this discussion. (In a brute-force scenario context can be embedded/inline and problem solved - size is the price to pay - not in the scope of this discussion) Since JWT specifies that all claims are optional, libraries should be able to process JWT tokens without any JWT claims (I know how it sounds). From experience, JWS/JWT libraries verify the signature, other verifications are performed manually. People could also argue that VCs are used. This direction won't lead to a solution. ID Token and eKYC define rules for the JWT claims when they are secured with JWS. I believe there are many other use cases that define profiles, rules, etc. In an open multi-use case system, there are additional challenges and we had a good discussion with Torsten on the topic where we identified several points that should be considered. It is worth reflecting on the designs of JWS JAdES linked data proofs VCDM v2 on their data model and serialisation. Back to my question: What is the real benefit of this data model over the W3C VC data model by looking at the situation objectively? (I'm also trying to find an answer to the question) With Torsten we had a very fruitful discussion. We need to reflect on several elements. Have a nice weekend!
NAME , I missed one point. Can you please elaborate on "take VCDM to secure JWT"? If my understanding is correct (sometimes is, sometimes isn't), it is JWS the one secures the payload (and it can be any JSON). JWT claims define contextual information: who, validity, about who, for whom. We should reflect on sigTst from JAdES. I'm personally not proposing to use VCDM to protect a JWT. VCDM and JWT are both protected by JWS.
As an example, iss and cnf are registered claim names for JWTs that are used to secure the VC. Existing RFCs are using those. Therefore it doesn't make sense to overwrite those by the w3c data model in my opinion
Thank you NAME I understand your view. If VC claims were registered, what would be the benefit of the data model over VCDM? Since I’m involved in projects that use VCDM (in JSON and JSON-LD) and also JWT I would really like to understand the objective benefits od the data model.
To resolve this issue, we will add a section on relationship to other documents and include a chapter on "VCDM".
This issue is ready for a PR.
Approved with a minor proposed improvment.

Revised text:
8.  <ins> This specification defines validation and processing rules for verifiable credentials using JSON payloads and secured by SD-JWT I- D.ietf-oauth-selective-disclosure-jwt.  Other specifications exist that define their own verifiable credential formats, which can be used independently of each other.  For example, W3C Verifiable Credential Data Model (VCDM) 2.0 W3C.VCDM defines a data model for verifiable credentials encoded as JSON-LD, and ISO/IEC 18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. </ins>