jiebi/TextFlow huggingface dataset:
Original 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>  A URI in the

Reviewer comments:
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!

Revised text:
6.3.  <ins> 6.3.1. </ins> A URI in the
Original text:
All examples in this section are non-normative. <del> Type Metadata about the value of a </del>  <del> claim value can be retrieved as described in retrieving-type- metadata. </del>  <del> Here, the type is </del>  <del> . The Type Metadata is retrieved from the URL </del>  <del> . </del>  <del> The following is an example for a Type Metadata document: </del>  6.2.

Reviewer comments:
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:

Revised text:
All examples in this section are non-normative.  <ins> The following is an example of an SD-JWT VC payload, containing a </ins>  <ins> claim with the value </ins>  <ins> : </ins>  <ins> Type Metadata for the type </ins>  <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>  <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.
Original text:
3.3. <del> The following is a non-normative example of an unsecured payload of an SD-JWT VC. </del>  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>  SD-JWT VC contains only claims about the Subject that are selectively disclosable:

Reviewer comments:
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.

Revised text:
3.3.  <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  <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:
Original text:
The SD-JWT and the Disclosures would then be serialized by the Issuer into the following format for issuance to the Holder:  3.4. The recipient (Holder or Verifier) of an SD-JWT VC MUST process and

Reviewer comments:
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.

Revised 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
Original 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>  <del> claim.  Other claims are not disclosed to the Verifier. </del>  <del> The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT: </del>  5.

Reviewer comments:
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.

Revised 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  <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>  <ins> The following example shows a presentation of a (similar but different) SD-JWT without a Key Binding JWT: </ins>  <ins> The Verifier will have the following processed SD-JWT payload after validation: </ins> 5.
Original text:
SD-JWT VCs compliant with this specification MUST use the media type <del> as defined in application-vc-sd-jwt. </del>  3.2.

Reviewer comments:
Update the anticipated media type registration request from to per the Dublin Accord (last slide of URL)

Revised text:
SD-JWT VCs compliant with this specification MUST use the media type  <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.
Original text:
The following is a non-normative example of a decoded SD-JWT header:  3.2.2. This section defines the claims that can be included in the payload

Reviewer comments:
Update the anticipated media type registration request from to per the Dublin Accord (last slide of URL)

Revised 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
Original 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>  of an SD-JWT VC MAY contain a Key Binding JWT. Note that in some cases, an SD-JWT VC MAY have no selectively

Reviewer comments:
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

Revised text:
3.2. SD-JWT VCs MUST be encoded using the SD-JWT format defined in  <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
Original 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>  claim of the SD-JWT MUST be used.

Reviewer comments:
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

Revised text:
selective-disclosure-jwt. If Key Binding is required (refer to the security considerations in  <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.
Original 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>  D.ietf-oauth-selective-disclosure-jwt. The Key Binding JWT MAY include additional claims which, when not

Reviewer comments:
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

Revised text:
4.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the  <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
Original 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>  JSON Schema document provided by the or

Reviewer comments:
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

Revised text:
property is present, a Consumer MUST validate the JSON document resulting from the SD-JWT verification algorithm (as defined in  <ins> Section 7 of I-D.ietf-oauth-selective-disclosure-jwt) against the </ins> JSON Schema document provided by the or
Original text:
11.1. <del> The Privacy Considerations in Section 12.5 of I-D.ietf-oauth- </del>  selective-disclosure-jwt apply especially to the claim.

Reviewer comments:
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

Revised text:
11.1.  <ins> The Privacy Considerations in Section 10.1 of I-D.ietf-oauth- </ins> selective-disclosure-jwt apply especially to the claim.
Original 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>  <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>  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>  5.1.2.2.

Reviewer comments:
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.

Revised text:
. The  <ins> claim is used to express the type of the JSON object that is contained in the JWT payload.  The </ins>  <ins> value MUST be a case-sensitive </ins> value. The following is a non-normative example of how  <ins> is used to express a type: </ins> 5.1.2.2.
Original 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>  9.1.1.

Reviewer comments:
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

Revised text:
9.1.  <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.
Original text:
claims, to make statements about the Subject of the Verifiable Credential. <del> 1.1. </del>  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>  2.

Reviewer comments:
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.

Revised text:
claims, to make statements about the Subject of the Verifiable Credential.  <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.  <ins> 1.4. </ins> 2.
Original text:
4. <del> This specification defines the media type which describes a VC-SD-JWT with the following components: </del>  4.1. <del> 4.1.1. </del>  The

Reviewer comments:
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.

Revised text:
4.  <ins> This section defines encoding, validation and processing rules for VC-SD-JWTs. </ins> 4.1.  <ins> VC-SD-JWTs compliant with this specification MUST use the media type as defined in {#application-vc-sd-jwt}. 4.2. VC-SD-JWTs MUST be encoded using the SD-JWT Combined Format for Issuance as defined in I-D.ietf-oauth-selective-disclosure-jwt. VC-SD-JWTs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per [@!I-D.ietf-oauth- selective-disclosure-jwt, section 5.1.1.3.]. 4.2.1. This section defines JWT header parameters for the SD-JWT component of the VC-SD-JWT. </ins> The
Original text:
The following is a non-normative example of a decoded SD-JWT header: <del> 4.1.2. VC-SD-JWTs and VP-SD-JWTs can use any claim registered in the "JSON Web Token Claims" registry as defined in RFC7519. Some of the claims in a VC MUST NOT be selectively disclosed as they are always required for processing on the verifier side.  All other claims can be made selectively disclosable by the issuer when issuing the respective VC-SD-JWT. </del>  <del> VC-SD-JWTs and VP-SD-JWTs MAY contain additional registered or public claims depending on the application. </del>  <del> 4.1.2.1. </del>  This specification defines the JWT claim

Reviewer comments:
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.

Revised text:
The following is a non-normative example of a decoded SD-JWT header:  <ins> 4.2.2. </ins>  <ins> This section defines the claims that can be included in the payload of SD-JWTs and Diclosures belonging to VC-SD-JWTs. </ins>  <ins> 4.2.2.1. </ins> This specification defines the JWT claim