jiebi/TextFlow huggingface dataset:
Original text:
5.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the <del> following claims are used within the Key Binding JWT: </del>  <del> The Key Binding JWT MAY include addtional claims which when not understood MUST be ignored. </del>  5.2.

Reviewer comments:
This PR renames the claim to , as per the discussion in
I oppose against this change. I suggest to use 'vct' instead.
I'm good with . For the record, I think it's important to move away from , because URL uses the claim name, but with a different syntax. Keeping the naming conflict will inevitably lead to grief.
Naming is hard. Regarding dct: isn't it obvious for an internet standard that we refer to digital credentials?
Neither dct nor vct are intuitive for me, so I am pretty unsure. But between dct and vct, I would prefer dct. A term Verifiable credentials got enough feedback that it has strong too strong of an association to W3C VC-DATA-MODEL. And Digital credentials seems to be a term that is acceptable to generalize.
Why is "Verifiable Credential Type" (vct) not intuitive to you? This would match the current definition of . Isn't this what this claim is about? That is why I'm actually in favor of over , .
I meant that abbreviations are not intuitive to me. And "type" is a pretty JSON-LD specific construct AFAIK so I was hoping we could have a deeper discussion on whether it should be called "claimset" or something. If we are to move away from "type" claim name. on dct and vct, as I explained, I prefer something that is not associated to W3C VCDM and digital credentials seems to be pretty well understood.
If the color of the bikeshed is still open for debate, how about just for credential type?
I like 3-letter-names more than 2-letter-names for some reason. Also, is more accurate since the spec is about SD-JWT VCs => Verifiable Credentials. I'd be still in favor of for that reason.
is fine for me. Updated the PR accordingly.
is fine for me too. was just an off-hand idea
Merging this PR since a lot of approvals. We will have a larger conversation on what is inferred by the value in a separate issue.
I suggest to use 'vct'.LGTM. We should address NAME concern in a separate issue.This is an improvement.

Revised text:
5.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 5.10 of I-D.ietf-oauth-selective-disclosure-jwt. </ins>  <ins> The Key Binding JWT MAY include addtional claims which, when not understood, MUST be ignored by the Verifier. </ins> 5.2.
Original text:
claim of the SD-JWT MUST be used. <del> For the verification, the claim in the SD-JWT MAY be used to retrieve the public key from the JWT Issuer Metadata configuration (as defined in jwt-issuer-metadata) of the SD-JWT VC issuer.  Alternative methods MAY be used to obtain the public key to verify the signature of the SD-JWT. </del>  If there are no selectively disclosable claims, there is no need to process the

Reviewer comments:
This PR does the following: make verification that the public key of the Issuer-signed JWT belongs to the Issuer mandatory introduce methods to perform this verification based on JWT Issuer Metadata, X.509 Certificates and DIDs Potentially . Partially Out-of-scope: Renaming and moving JWT Issuer Metadata Section
Addressed all suggestions, please review again NAME
I had to rename the section. I think now it is more precise.
Show possible options like JWT Issuer Metadata, being a DID URL etc.
We introduced a new section that talks about different key discovery methods during the verification process in PR

Revised text:
claim of the SD-JWT MUST be used.  <ins> Furthermore, the recipient of the SD-JWT VC MUST verify that the public key used for verification of the Issuer-signed JWT belongs to the Issuer of the Issuer-signed JWT, as defined in public-key-for- issuer-signed-jwts-verification. </ins> If there are no selectively disclosable claims, there is no need to process the
Original text:
Additional validation rules MAY apply, but their use is out of the scope of this specification.  4. This specification defines the JWT Issuer Metadata to retrieve the

Reviewer comments:
This PR does the following: make verification that the public key of the Issuer-signed JWT belongs to the Issuer mandatory introduce methods to perform this verification based on JWT Issuer Metadata, X.509 Certificates and DIDs Potentially . Partially Out-of-scope: Renaming and moving JWT Issuer Metadata Section
Addressed all suggestions, please review again NAME
I had to rename the section. I think now it is more precise.
Show possible options like JWT Issuer Metadata, being a DID URL etc.
We introduced a new section that talks about different key discovery methods during the verification process in PR

Revised text:
Additional validation rules MAY apply, but their use is out of the scope of this specification. <ins> 3.5. A recipient of the SD-JWT VC MUST apply the following rules to verify the Issuer-signed JWT corresponds to the Issuer: - JWT Issuer Metadata: If the value contains a HTTPS URI, the recipient MUST obtain the public key using JWT Issuer Metadata as defined in jwt-issuer-metadata.  - DID Document Resolution: If the value contains a DID, the recipient MUST retrieve the public key from the DID Document resolved from the DID in the value.  If the JWT header parameter is present, the MUST be a relative or absolute DID URL of the DID in the value, identifying the public key.  - X.509 Certificates: The recipient MUST obtain the public key from the leaf X.509 certificate defined by the , , or JWT header parameters of the Issuer-signed JWT and validate the X.509 certificate chain in the following cases: - If the value contains a DNS name encoded as a URI using the DNS URI scheme RFC4501.  The DNS name MUST matche a Subject Alternative Name (SAN) RFC5280 entry of the leaf certificate. - If the value contains a URN using the URN URI scheme RFC2141.  The URN MUST match a SAN entry of the leaf certificate. Additional rules for verifying the public key belongs to the Issuer MAY be used but are out of scope of this specification. </ins> 4. This specification defines the JWT Issuer Metadata to retrieve the
Original text:
Additional considerations can be found in OWASP_SSRF.  7. The Privacy Considerations in the SD-JWT specification I-D.ietf-

Reviewer comments:
This PR does the following: make verification that the public key of the Issuer-signed JWT belongs to the Issuer mandatory introduce methods to perform this verification based on JWT Issuer Metadata, X.509 Certificates and DIDs Potentially . Partially Out-of-scope: Renaming and moving JWT Issuer Metadata Section
Addressed all suggestions, please review again NAME
I had to rename the section. I think now it is more precise.
Show possible options like JWT Issuer Metadata, being a DID URL etc.
We introduced a new section that talks about different key discovery methods during the verification process in PR

Revised text:
Additional considerations can be found in OWASP_SSRF. <ins> 6.2. When defining ecosystem-specific rules for the verification of the public key, as outlined in verifying-public-key-for-issuer-signed- jwts, it is critical that those rules maintain the integrity of the relationship between the value within the Issuer-signed JWT and the public keys of the Issuer. In situations where an attacker tampers with an SD-JWT VC, it is paramount to ensure that they cannot exert influence over the verification process while employing the same value. </ins> 7. The Privacy Considerations in the SD-JWT specification I-D.ietf-
Original text:
5.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the <del> following claims are used within the Key Binding JWT: </del>  <del> The Key Binding JWT MAY include addtional claims which when not understood MUST be ignored. </del>  5.2.

Reviewer comments:
This fixes Issue . Note that this removed the "exp" claim which I think we don't need to mention explicitly.
SD-JWT defines the KB-JWT header, SD-JWT-VC only refers to the claims. Is it necessary to reference to the SD-JWT spec for this?
We do refer to the Key Binding JWT: URL Is there anything else missing?
Closing this issue since got merged.
LGTM

Revised text:
5.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 5.10 of I-D.ietf-oauth-selective-disclosure-jwt. </ins>  <ins> The Key Binding JWT MAY include addtional claims which, when not understood, MUST be ignored by the Verifier. </ins> 5.2.
Original text:
claim of the SD-JWT MUST be used. <del> Furthermore, the recipient of the SD-JWT VC MUST obtain the public verification key for the Issuer-signed JWT as defined in public-key- discovery-for-issuer-signed-jwts. </del>  If there are no selectively disclosable claims, there is no need to process the

Reviewer comments:
This PR introduces the following changes: - - Fixed SAN Extension rule Removed all options for X509 except
NAME pls review again.
Fixed merge conflicts and reconciled with PR . Nothing new should have been introduced than what has been approved already. If NAME or NAME can approve again, then we can merge imo.
The section should be renamed to "Issuer-signed JWT verification key validation" since the section is about checking that the value corresponds to the key that signed the JWT. The process of obtaining it via different means is just the first step. We should also fix the language in the "Verification and Processing" section to say: instead of
Fixed by
The rules to obtain the verification key from X.509 should be changed to use the from the SAN extension instead of the (which does not exist). Furthermore, since can potentially start with a https scheme, the JWT Issuer Metadata rule should only be enforced if no x5* JWT header was set.
We also need to add JWT header.
Fixed by

Revised text:
claim of the SD-JWT MUST be used.  <ins> Furthermore, the recipient of the SD-JWT VC MUST validate that the public verification key for the Issuer-signed JWT as defined in issuer-signed-jwt-verification-key-validation. </ins> If there are no selectively disclosable claims, there is no need to process the
Original text:
6.2. When defining ecosystem-specific rules for the verification of the <del> public key, as outlined in public-key-discovery-for-issuer-signed- jwts, it is critical that those rules maintain the integrity of the relationship between the </del>  value within the Issuer-signed JWT and the public keys of the Issuer.

Reviewer comments:
This PR introduces the following changes: - - Fixed SAN Extension rule Removed all options for X509 except
NAME pls review again.
Fixed merge conflicts and reconciled with PR . Nothing new should have been introduced than what has been approved already. If NAME or NAME can approve again, then we can merge imo.
The section should be renamed to "Issuer-signed JWT verification key validation" since the section is about checking that the value corresponds to the key that signed the JWT. The process of obtaining it via different means is just the first step. We should also fix the language in the "Verification and Processing" section to say: instead of
Fixed by
The rules to obtain the verification key from X.509 should be changed to use the from the SAN extension instead of the (which does not exist). Furthermore, since can potentially start with a https scheme, the JWT Issuer Metadata rule should only be enforced if no x5* JWT header was set.
We also need to add JWT header.
Fixed by

Revised text:
6.2. When defining ecosystem-specific rules for the verification of the  <ins> public key, as outlined in issuer-signed-jwt-verification-key- validation, it is critical that those rules maintain the integrity of the relationship between the </ins> value within the Issuer-signed JWT and the public keys of the Issuer.
Original text:
1.4. This specification uses the terms "Holder", "Issuer", "Verifier", <del> "Key Binding JWT" defined by I-D.ietf-oauth-selective-disclosure-jwt. </del>  2.

Reviewer comments:
also fix a typo or two for Issue
URL has "Combined Format for Presentation", which isn't used in SD-JWT anymore.
I assigned you NAME since you are one of the SD-JWT editor's.
Gotta start somewhere... hopefully I can handle this one. PR has proposed changes.

Revised text:
1.4. This specification uses the terms "Holder", "Issuer", "Verifier",  <ins> "Key Binding", and "Key Binding JWT" defined by I-D.ietf-oauth- selective-disclosure-jwt. </ins> 2.
Original text:
Key Binding JWT MUST adhere to the rules defined in Section 5.3 of I- D.ietf-oauth-selective-disclosure-jwt. <del> The Key Binding JWT MAY include addtional claims which, when not </del>  understood, MUST be ignored by the Verifier. 4.2.

Reviewer comments:
also fix a typo or two for Issue
URL has "Combined Format for Presentation", which isn't used in SD-JWT anymore.
I assigned you NAME since you are one of the SD-JWT editor's.
Gotta start somewhere... hopefully I can handle this one. PR has proposed changes.

Revised text:
Key Binding JWT MUST adhere to the rules defined in Section 5.3 of I- D.ietf-oauth-selective-disclosure-jwt.  <ins> The Key Binding JWT MAY include additional claims which, when not </ins> understood, MUST be ignored by the Verifier. 4.2.
Original text:
It is RECOMMENDED that the JWT contains a <del> JWT header parameter that can be used to lookup the public key in the JWK Set included by value or referenced in the JWT VC Issuer </del>  Metadata. The following is a non-normative example of a JWT VC Issuer Metadata

Reviewer comments:
also fix a typo or two for Issue
URL has "Combined Format for Presentation", which isn't used in SD-JWT anymore.
I assigned you NAME since you are one of the SD-JWT editor's.
Gotta start somewhere... hopefully I can handle this one. PR has proposed changes.

Revised text:
It is RECOMMENDED that the JWT contains a  <ins> JWT header parameter that can be used to look up the public key in the JWK Set included by value or referenced in the JWT VC Issuer </ins> Metadata. The following is a non-normative example of a JWT VC Issuer Metadata
Original text:
claim in the JWT.  Use of the JWT VC Issuer Metadata is OPTIONAL. Issuers publishing JWT VC Issuer Metadata MUST make a JWT VC Issuer <del> Metadata configuration available at the path formed by concatenating the string </del>  <del> to the </del>  claim value in the JWT.  The

Reviewer comments:
also add associated IANA registration request and fix up formatting etc in other IANA bits see it live URL
There are 2 parts of the draft discussing the path to issuer metadata: and I do believe the latter is the currently intended /.well-known mechanism, whereas the first section was probably not updated and would result in to resolve metadata. I guess this was an oversight in ?
Thanks for catching the inconsistency NAME and I believe you are correct that the latter is currently the intended mechanism for .well-known.
We might also want to use something other than "user" in the example path. It's not wrong exactly but maybe unnecessarily misleading or confusing.
endeavors to fix this (and a few other little things)
lgtm

Revised text:
claim in the JWT.  Use of the JWT VC Issuer Metadata is OPTIONAL. Issuers publishing JWT VC Issuer Metadata MUST make a JWT VC Issuer  <ins> Metadata configuration available at the location formed by inserting the well-known string </ins>  <ins> between the host component and the path component (if any) of the </ins> claim value in the JWT.  The
Original text:
request at the path defined in jwt-vc-issuer-metadata. <del> The following is a non-normative example of a HTTP request for the </del>  JWT VC Issuer Metadata configuration when is set to

Reviewer comments:
also add associated IANA registration request and fix up formatting etc in other IANA bits see it live URL
There are 2 parts of the draft discussing the path to issuer metadata: and I do believe the latter is the currently intended /.well-known mechanism, whereas the first section was probably not updated and would result in to resolve metadata. I guess this was an oversight in ?
Thanks for catching the inconsistency NAME and I believe you are correct that the latter is currently the intended mechanism for .well-known.
We might also want to use something other than "user" in the example path. It's not wrong exactly but maybe unnecessarily misleading or confusing.
endeavors to fix this (and a few other little things)
lgtm

Revised text:
request at the path defined in jwt-vc-issuer-metadata.  <ins> The following is a non-normative example of an HTTP request for the </ins> JWT VC Issuer Metadata configuration when is set to
Original text:
1.2. <del> TBD 1.3. TBD </del> 2. TBD

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

Revised text:
1.2.  2. TBD
Original text:
verification key for the Issuer-signed JWT as defined in issuer- signed-jwt-verification-key-validation.  If there are no selectively disclosable claims, there is no need to process 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:
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