jiebi/CodeConvo huggingface dataset:
Code change:
Added terms and definitions section; made some changes data formats based on terms and definitions section -
I think we need to define what the following "things" are. What is the Verifiable Credential based on SD-JWTs? I believe it is the JWT that contains the s. It is not any of the combined formats. This means that the Verifiable Credential MAY NOT contain any disclosable claims, e.g., . Would you agree NAME NAME Daniel? The VC based on SD-JWT will have the media type . What is the Verifiable Presentation based on SD-JWTs? It makes sense to define that since the HB JWT has some specific requirements. It also makes sense because protocol developers will need to refer to one term when they exchange presentations or verifiable presentations between issuer holder verifier. Can we call the Combined Format for Issuance AND Presentation the Presentation based on SD-JWTs, and if there is HB, then it is a Verifiable Presentation? The VP based SD-JWT will have the media type altough I'm not sure if this makes sense. Wouldn't it better to have ? Any thoughts on that?
Also it is important to note that for OIDC4VP we use Verifiable Presentations in vptoken and we use Verifiable Credentials in OIDC4VCI in the credential response. It probably has the implication that for OIDC4VCI, we will put the VC based on SD-JWT into the credential response, or we define a format identifier for something else. Keep in mind we need to send the disclosures to the client as well. In that regards is the SD-JWT itself the SD-JWT-VC without disclosures, or is the combined format including disclosures the SD-JWT-VC? Or we follow the approach above and we return a combined presentation (no HB) in the credential response and define a credential identifier for that. It probably also means that we would put the VP based on SD-JWT into the OIDC4VP vptoken.
We (IDunion) put the combined presentation (+hb jwt) in the vp_token. What else would you expect?
That makes sense, so the VP based on SD-JWT is the combined format for presentation including HB JWT. Then, there is the question what would the OIDC4VCI credential response return? And what would be a format identifier? I know that this doesn't have to be answered in this spec but it helps with answering the terminology question.
Suggest we not overcomplicate things and say: what is returned in a VP Token in OID4VP is a combined Format for presentation with HB-JWT. what is returned in Credential Response in Credential Response in VCI is combined format for issuance. credential format identifier is 'vc+sd-jwt' for both. Terminology-wise, SD-JWT in the IETF spec is defined as an issuer signed JWS without disclosures. For this profile, the payload of SD-JWT, can be mapped back to a VCDM2.0
This is potentially fixed by PR

Related discussion:
text: 1.2. <del> TBD 1.3. TBD </del> 2. TBD
Code change:
This PR includes the following: [x] Add schema type metadata [x] Add full schema type metadata examples [x] Describe base document for schema validation [x] Minor editorial fixes [x] Moved type metadata retrieval section for readability purposes [x] ~IANA considerations for , and ~ See preview here: URL Fixes URL
NAME NAME Do you think it makes sense to describe the base document for schema type metadata validation? For example, a verifier receiving an SD-JWT VC with Disclosures won't be able to validate the JSON schema against it before transforming the entire SD-JWT VC with Disclosures to expanded JSON document first.
NAME NAME Should we restrict schema to specific JSON schema versions?
I'm honestly not familiar with the intricacies of JSON schema. Is/are there a stable standard version(s) that can be referenced from a prospective RFC? The current content of the PR seems to have some normative statements but no reference. I'd think that's kind of a prerequisite to discussing version restrictions/requirements. A few minutes of looking around and I found this https://json-URL which at least suggests it's a bit messy. Any idea if/how other actual standards documents utilize JSON schema?
Well, statements like "MUST validate the Verifiable Credential against the provided JSON Schema document." probably need some more clarity about what part of the VC and at what stage of transformation/processing.
I suggest that we proceed with merging this PR nonetheless and have a separate discussion on JSON Schema versions in an issue.
Update: We don't need IANA registration for schema, schemauri and schemauri#integrity since type metadata is not a JWT.
NAME NAME Can you please check the examples I added.
I believe we will need to distinguish between presentation and issuance schemas -> see
I don't really speak JSON schema but it looks ok
Thanks a lot. I updated the PR. Will merge later on the editor's call.
Merging this since all comments were addressed.
Define how schemas can be included in type metadata. Requirement is that it should allow JSON schema.
left a couple of editorial remarks, but generally this looks good to me, thank you!

Related discussion:
text: verification key for the Issuer-signed JWT as defined in issuer- signed-jwt-verification-key-validation. <ins> If Schema Type Metadata is provided, a recipient MUST validate the JSON Schema as defined in schema-type-metadata. </ins> If there are no selectively disclosable claims, there is no need to process the
Code change:
This PR includes the following: [x] Add schema type metadata [x] Add full schema type metadata examples [x] Describe base document for schema validation [x] Minor editorial fixes [x] Moved type metadata retrieval section for readability purposes [x] ~IANA considerations for , and ~ See preview here: URL Fixes URL
NAME NAME Do you think it makes sense to describe the base document for schema type metadata validation? For example, a verifier receiving an SD-JWT VC with Disclosures won't be able to validate the JSON schema against it before transforming the entire SD-JWT VC with Disclosures to expanded JSON document first.
NAME NAME Should we restrict schema to specific JSON schema versions?
I'm honestly not familiar with the intricacies of JSON schema. Is/are there a stable standard version(s) that can be referenced from a prospective RFC? The current content of the PR seems to have some normative statements but no reference. I'd think that's kind of a prerequisite to discussing version restrictions/requirements. A few minutes of looking around and I found this https://json-URL which at least suggests it's a bit messy. Any idea if/how other actual standards documents utilize JSON schema?
Well, statements like "MUST validate the Verifiable Credential against the provided JSON Schema document." probably need some more clarity about what part of the VC and at what stage of transformation/processing.
I suggest that we proceed with merging this PR nonetheless and have a separate discussion on JSON Schema versions in an issue.
Update: We don't need IANA registration for schema, schemauri and schemauri#integrity since type metadata is not a JWT.
NAME NAME Can you please check the examples I added.
I believe we will need to distinguish between presentation and issuance schemas -> see
I don't really speak JSON schema but it looks ok
Thanks a lot. I updated the PR. Will merge later on the editor's call.
Merging this since all comments were addressed.
Define how schemas can be included in type metadata. Requirement is that it should allow JSON schema.
left a couple of editorial remarks, but generally this looks good to me, thank you!

Related discussion:
text: 6.3. <del> A type can extend another type.  The extended type is identified by the URI in the property.  Consumers MUST retrieve and process Type Metadata for the extended type before processing the Type Metadata for the extending type. The extended type MAY itself extend another type.  This can be used to create a chain or hierarchy of types.  The security considerations described in circular-extends apply in order to avoid problems with circular dependencies. 6.4. 6.4.1. </del> <ins> 6.3.1. </ins> A URI in the
Code change:
The first example in Section 6.1 shows a credential, not a type metadata document, but is not labelled as such. The example in question:

Related discussion:
text: All examples in this section are non-normative. <del> Type Metadata about the value of a </del> <ins> The following is an example of an SD-JWT VC payload, containing a </ins> <del> claim value can be retrieved as described in retrieving-type- metadata. </del> <ins> claim with the value </ins> <del> Here, the type is </del> <ins> : </ins> <del> . The Type Metadata is retrieved from the URL </del> <ins> Type Metadata for the type </ins> <del> . </del> <ins> can be retrieved using various mechanisms as described in retrieving- type-metadata.  For this example, the well-known URL as defined in retrieval-from-vct-claim is used and the following Type Metadata Document is retrieved from the URL : </ins> <del> The following is an example for a Type Metadata document: </del> <ins> Note: The hash of the Type Metadata document shown in the second example must be equal to the one in the claim in the SD-JWT VC payload, . </ins> 6.2.
Code change:
for and hopefully/maybe too URL URL URL
NAME this work and URL were largely undertaken as a result of your questions/feedback
Select parts of a conversation from an encrypted messaging service copied here. Editorial liberties have been taken to extract the most relevant parts of the discussion and protect the identities of the participants. >- the first example is just user claims that are being secured >- the second example is user claims + metadata that is necessary to be added when signing the sd-jwt IMHO it would be worthwhile to expand the example in URL with some additions to URL to also show the content of the thing that needs a name.
Seems related to
I think the understanding of the spec could be further facilitated by adding an example of a SD-JWT VC after the verifier has processed the SD-JWT VC and (basically) has constructed a JWT representation for further processing in the application.
The new PID example in draft -02/-03 shows the JSON data for "further processing" after validation: URL Does that seem sufficient? Or perhaps a similar addition to the example used in the main body of the draft ()? Or something different/more?
I personally don't understand why this applies to the verifier: "has constructed a JWT representation for further processing in the application". However, NAME has this issue been addressed by the examples NAME provided? Then we can close it.

Related discussion:
text: 3.3. <del> The following is a non-normative example of an unsecured payload of an SD-JWT VC. </del> <ins> The following is a non-normative example of the user data of an unsecured payload of an SD-JWT VC. </ins> The following is a non-normative example of how the unsecured payload <del> of the SD-JWT VC above can be used in a SD-JWT where the resulting </del> <ins> of the SD-JWT VC above can be used in an SD-JWT where the resulting </ins> SD-JWT VC contains only claims about the Subject that are selectively disclosable:
Code change:
for and hopefully/maybe too URL URL URL
NAME this work and URL were largely undertaken as a result of your questions/feedback
Select parts of a conversation from an encrypted messaging service copied here. Editorial liberties have been taken to extract the most relevant parts of the discussion and protect the identities of the participants. >- the first example is just user claims that are being secured >- the second example is user claims + metadata that is necessary to be added when signing the sd-jwt IMHO it would be worthwhile to expand the example in URL with some additions to URL to also show the content of the thing that needs a name.
Seems related to
I think the understanding of the spec could be further facilitated by adding an example of a SD-JWT VC after the verifier has processed the SD-JWT VC and (basically) has constructed a JWT representation for further processing in the application.
The new PID example in draft -02/-03 shows the JSON data for "further processing" after validation: URL Does that seem sufficient? Or perhaps a similar addition to the example used in the main body of the draft ()? Or something different/more?
I personally don't understand why this applies to the verifier: "has constructed a JWT representation for further processing in the application". However, NAME has this issue been addressed by the examples NAME provided? Then we can close it.

Related discussion:
text: The SD-JWT and the Disclosures would then be serialized by the Issuer into the following format for issuance to the Holder: <ins> Examples of what presentations of SD-JWT VCs might look like are provided in presentation-examples. </ins> 3.4. The recipient (Holder or Verifier) of an SD-JWT VC MUST process and
Code change:
for and hopefully/maybe too URL URL URL
NAME this work and URL were largely undertaken as a result of your questions/feedback
Select parts of a conversation from an encrypted messaging service copied here. Editorial liberties have been taken to extract the most relevant parts of the discussion and protect the identities of the participants. >- the first example is just user claims that are being secured >- the second example is user claims + metadata that is necessary to be added when signing the sd-jwt IMHO it would be worthwhile to expand the example in URL with some additions to URL to also show the content of the thing that needs a name.
Seems related to
I think the understanding of the spec could be further facilitated by adding an example of a SD-JWT VC after the verifier has processed the SD-JWT VC and (basically) has constructed a JWT representation for further processing in the application.
The new PID example in draft -02/-03 shows the JSON data for "further processing" after validation: URL Does that seem sufficient? Or perhaps a similar addition to the example used in the main body of the draft ()? Or something different/more?
I personally don't understand why this applies to the verifier: "has constructed a JWT representation for further processing in the application". However, NAME has this issue been addressed by the examples NAME provided? Then we can close it.

Related discussion:
text: The following is a non-normative example of a presentation of the SD- JWT shown in vc-sd-jwt-example including a Key Binding JWT.  In this <del> presentation, the Holder provides only the Disclosure for the </del> <ins> presentation, the Holder provides only the Disclosures for the and claims.  Other claims are not disclosed to the Verifier. After validation, the Verifier will have the following processed SD- JWT payload available for further handling: </ins> <del> claim.  Other claims are not disclosed to the Verifier. </del> <ins> The following example shows a presentation of a (similar but different) SD-JWT without a Key Binding JWT: </ins> <del> The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT: </del> <ins> The Verifier will have the following processed SD-JWT payload after validation: </ins> 5.
Code change:
Update the anticipated media type registration request from to per the Dublin Accord (last slide of URL)

Related discussion:
text: SD-JWT VCs compliant with this specification MUST use the media type <del> as defined in application-vc-sd-jwt. </del> <ins> as defined in media-type. The base subtype name is meant to stand for "digital credential", which is a term that is emerging as a conceptual synonym for "verifiable credential". </ins> 3.2.
Code change:
Update the anticipated media type registration request from to per the Dublin Accord (last slide of URL)

Related discussion:
text: The following is a non-normative example of a decoded SD-JWT header: <ins> Note that this draft used as the value of the header from its inception in July 2023 until November 2024 when it was changed to to avoid conflict with the media type name registered by the W3C's Verifiable Credentials Data Model draft.  In order to facilitate a minimally disruptive transition, it is RECOMMENDED that Verifiers and Holders accept both and as the value of the header for a reasonable transitional period. </ins> 3.2.2. This section defines the claims that can be included in the payload
Code change:
and a few others that had gotten out of sync
Section 4.1. Key Binding JWT, says the following: But Section 5.3 does not exist in the referred spec. Instead, it should be Section 4.3
Thanks NAME A couple sections in SD-JWT were consolidated around draft 12 or 13 and other sections were renumbered as a result. We'll fix this reference and check for others that might need updating too.
see including URL

Related discussion:
text: 3.2. SD-JWT VCs MUST be encoded using the SD-JWT format defined in <del> Section 5 of I-D.ietf-oauth-selective-disclosure-jwt.  A presentation </del> <ins> Section 4 of I-D.ietf-oauth-selective-disclosure-jwt.  A presentation </ins> of an SD-JWT VC MAY contain a Key Binding JWT. Note that in some cases, an SD-JWT VC MAY have no selectively
Code change:
and a few others that had gotten out of sync
Section 4.1. Key Binding JWT, says the following: But Section 5.3 does not exist in the referred spec. Instead, it should be Section 4.3
Thanks NAME A couple sections in SD-JWT were consolidated around draft 12 or 13 and other sections were renumbered as a result. We'll fix this reference and check for others that might need updating too.
see including URL

Related discussion:
text: selective-disclosure-jwt. If Key Binding is required (refer to the security considerations in <del> Section 11.6 of I-D.ietf-oauth-selective-disclosure-jwt), the Verifier MUST verify the Key Binding JWT according to Section 8 of I- D.ietf-oauth-selective-disclosure-jwt.  To verify the Key Binding JWT, the </del> <ins> Section 9.5 of I-D.ietf-oauth-selective-disclosure-jwt), the Verifier MUST verify the Key Binding JWT according to Section 7 of I-D.ietf- oauth-selective-disclosure-jwt.  To verify the Key Binding JWT, the </ins> claim of the SD-JWT MUST be used.
Code change:
and a few others that had gotten out of sync
Section 4.1. Key Binding JWT, says the following: But Section 5.3 does not exist in the referred spec. Instead, it should be Section 4.3
Thanks NAME A couple sections in SD-JWT were consolidated around draft 12 or 13 and other sections were renumbered as a result. We'll fix this reference and check for others that might need updating too.
see including URL

Related discussion:
text: 4.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the <del> Key Binding JWT MUST adhere to the rules defined in Section 5.3 of I- </del> <ins> Key Binding JWT MUST adhere to the rules defined in Section 4.3 of I- </ins> D.ietf-oauth-selective-disclosure-jwt. The Key Binding JWT MAY include additional claims which, when not
Code change:
and a few others that had gotten out of sync
Section 4.1. Key Binding JWT, says the following: But Section 5.3 does not exist in the referred spec. Instead, it should be Section 4.3
Thanks NAME A couple sections in SD-JWT were consolidated around draft 12 or 13 and other sections were renumbered as a result. We'll fix this reference and check for others that might need updating too.
see including URL

Related discussion:
text: property is present, a Consumer MUST validate the JSON document resulting from the SD-JWT verification algorithm (as defined in <del> Section 8 of I-D.ietf-oauth-selective-disclosure-jwt) against the </del> <ins> Section 7 of I-D.ietf-oauth-selective-disclosure-jwt) against the </ins> JSON Schema document provided by the or
Code change:
and a few others that had gotten out of sync
Section 4.1. Key Binding JWT, says the following: But Section 5.3 does not exist in the referred spec. Instead, it should be Section 4.3
Thanks NAME A couple sections in SD-JWT were consolidated around draft 12 or 13 and other sections were renumbered as a result. We'll fix this reference and check for others that might need updating too.
see including URL

Related discussion:
text: 11.1. <del> The Privacy Considerations in Section 12.5 of I-D.ietf-oauth- </del> <ins> The Privacy Considerations in Section 10.1 of I-D.ietf-oauth- </ins> selective-disclosure-jwt apply especially to the claim.
Code change:
Pros: selective disclosure of types possible to increase privacy and to reduce contextual info more granular types possible issuers don't have to issue multiple credentials Cons: polymorphism always is a challenge, we that with no support in SD-JWT yet to selectively disclose array elements
After further discussions it seems that multiple types might cause difficulties with JSON schemas. If multiple types are required in the future (e.g. more implementer's feedback), we can update the specification. So, let's make a single string value.

Related discussion:
text: . The <del> claim is used to express the type or types of the JSON object that is contained in the JWT payload.  In the general case, the </del> <ins> claim is used to express the type of the JSON object that is contained in the JWT payload.  The </ins> <del> value is an array of case-sensitive strings, each containing a value.  In the special case when the SD-JWT has one credential type, the value MAY be a single case-sensitive string containing a </del> <ins> value MUST be a case-sensitive </ins> value. The following is a non-normative example of how <del> is used to express a single type: The following is a non-normative example of how is used to express multiple types: </del> <ins> is used to express a type: </ins> 5.1.2.2.
Code change:
I left some references open that will be addressed by other pull requests changing the surrounding text in order to avoid merge conflicts.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.
lgtm

Related discussion:
text: 9.1. <del> The W3C VCDM 2.0 (see TBD) defines a JSON-LD vocabulary for Verifiable Credentials and Verifiable Presentations.  To interop with the W3C VCDM 2.0 data model defined in [TBD], this specification defines mapping algorithm for VC-SD-JWT and VP-SD-JWT to the vocabulary and data model defined W3C VCDM 2.0 which is based on JSON-LD. </del> <ins> The W3C VCDM 2.0 VC-DATA defines a JSON-LD vocabulary for Verifiable Credentials and Verifiable Presentations.  To interop with the W3C VCDM 2.0 data model defined in VC-DATA, this specification defines a mapping algorithm for VC-SD-JWT and VP-SD-JWT to the vocabulary and data model defined W3C VCDM 2.0 which is based on JSON-LD. </ins> 9.1.1.
Code change:
I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.

Related discussion:
text: claims, to make statements about the Subject of the Verifiable Credential. <del> 1.1. </del> <ins> 1.3. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. <del> 1.2. </del> <ins> 1.4. </ins> 2.