jiebi/CodeConvo huggingface dataset:
Code change:
NAME do you know how to fix the build errors?
let's fix references later and create a new issue for that

Related discussion:
text: 5.2. SD-JWT-VCs as defined in this specification can use any claim <del> registered in the "JSON Web Token Claims" registry as defined in RFC 7519. </del> <ins> registered in the "JSON Web Token Claims" registry as defined in RFC7519. </ins> 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
Code change:
NAME do you know how to fix the build errors?
let's fix references later and create a new issue for that

Related discussion:
text: A verifier MUST validate an SD-JWT-VC as follows: <del> Additional validation rules MAY apply but their use is out-of-scope of this specification. </del> <ins> Additional validation rules MAY apply, but their use is out of the scope of this specification. </ins> 6.1. <del> Verifiers processing SD-JWT-VCs MUST verify the signature of the SD- JWT with the public key of the SD-JWT-VC issuer.  This makes sure that the SD-JWT-VC was issued by the SD-JWT-VC issuer and that it has not been tampered with since issuance. The claim in the SD-JWT-VC 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.  A verifier MAY use alternative methods to obtain the public key to verify the signature of the SD- JWT. 6.2. </del> This specification defines the JWT Issuer Metadata to retrieve the JWT Issuer Metadata configuration of the JWT Issuer of the JWT.  The JWT Issuer is identified by the
Code change:
NAME do you know how to fix the build errors?
let's fix references later and create a new issue for that

Related discussion:
text: The JWT Issuer Metadata configuration MUST be a JSON document compliant with this specification and MUST be returned using the <del> application/json content type. </del> <ins> content type. </ins> This specification defines the following JWT Issuer Metadata parameters: <ins> JWT Issuer Metadata MUST include either or in their JWT Issuer Metadata, but not both. </ins> It is RECOMMENDED that the JWT contains a JWT header parameter that can be used to lookup the public key in the
Code change:
Type identifiers MUST be collision-resistant names as defined in RFC7515 Changed the example to a URI

Related discussion:
text: value MUST be a case-sensitive (see RFC7519) value serving as an identifier for the type of the SD- <del> JWT VC.  A type defines which claims may or must appear in the Unsecured Payload of the SD-JWT VC and whether they may, must, or must not be selectively disclosable.  This specification does not define any </del> <ins> JWT VC.  The value MUST be a Collision-Resistant Name as defined in Section 2 of RFC7515. A type is associated with rules defining which claims may or must appear in the Unsecured Payload of the SD-JWT VC and whether they may, must, or must not be selectively disclosable.  This specification does not define any </ins> values; instead it is expected that ecosystems using SD-JWT VCs define such values including the semantics of the respective claims
Code change:
Type identifiers MUST be collision-resistant names as defined in RFC7515 Changed the example to a URI

Related discussion:
text: , and <del> may be used.  The type might also indicate that , , , can be selectively disclosable. </del> <ins> may be used.  The type might also indicate that any of the aforementioned claims can be selectively disclosable. </ins> 3.2.2.2.
Code change:
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.

Related discussion:
text: This specification defines the JWT claim <del> . The </del> <ins> (for verifiable credential type).  The </ins> value MUST be a case-sensitive
Code change:
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.

Related discussion:
text: is used to express a type: <del> For example, a type </del> <ins> For example, a value of </ins> can be associated with rules that define that at least the registered JWT claims
Code change:
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.

Related discussion:
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> <ins> Key Binding JWT MUST adhere to the rules defined in Section 5.10 of I-D.ietf-oauth-selective-disclosure-jwt. </ins> <del> The Key Binding JWT MAY include addtional claims which when not understood MUST be ignored. </del> <ins> The Key Binding JWT MAY include addtional claims which, when not understood, MUST be ignored by the Verifier. </ins> 5.2.
Code change:
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

Related discussion:
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> <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
Code change:
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

Related discussion:
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
Code change:
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

Related discussion:
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-
Code change:
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

Related discussion:
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> <ins> Key Binding JWT MUST adhere to the rules defined in Section 5.10 of I-D.ietf-oauth-selective-disclosure-jwt. </ins> <del> The Key Binding JWT MAY include addtional claims which when not understood MUST be ignored. </del> <ins> The Key Binding JWT MAY include addtional claims which, when not understood, MUST be ignored by the Verifier. </ins> 5.2.
Code change:
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

Related discussion:
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> <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
Code change:
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

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

Related discussion:
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> <ins> "Key Binding", and "Key Binding JWT" defined by I-D.ietf-oauth- selective-disclosure-jwt. </ins> 2.
Code change:
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.

Related discussion:
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> <ins> The Key Binding JWT MAY include additional claims which, when not </ins> understood, MUST be ignored by the Verifier. 4.2.
Code change:
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.

Related discussion:
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> <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
Code change:
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

Related discussion:
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> <ins> Metadata configuration available at the location formed by inserting the well-known string </ins> <del> to the </del> <ins> between the host component and the path component (if any) of the </ins> claim value in the JWT.  The
Code change:
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

Related discussion:
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> <ins> The following is a non-normative example of an HTTP request for the </ins> JWT VC Issuer Metadata configuration when is set to