jiebi/CodeConvo huggingface dataset:
Code change:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Related discussion:
text: instance: A user is known at domain A by "johndoe@a.org" but in domain B by "doe.john@b.org".  The mapping from one identifier to the other MAY either happen in the token exchange step and the <del> updated identifier is reflected in returned authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </del> <ins> updated identifier is reflected in returned JWT authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </ins>
Code change:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Related discussion:
text: : The authorization server performing the assertion flow MAY <del> leverage claims from the presented authorization grant and include them in the returned access token.  The populated claims SHOULD be namespaced or validated to prevent the injection of invalid claims. </del> <ins> leverage claims from the presented JWT authorization grant and include them in the returned access token.  The populated claims SHOULD be namespaced or validated to prevent the injection of invalid claims. </ins> The representation of transcribed claims and their format is not defined in this specification.
Code change:
Issue
Can you give an example where this is relevant? With excluding private claims we make sure all claims are uniquely identifiable across all parties of the three-party-model.
claims we make sure all claims are uniquely identifiable across all parties of the three-party-model. I dont believe this PR discourages public claims it simply reflects that there are bunch of scenarios where VC ecosystems what to interoperate on claims that are perhaps not general enough to register as public claims.
Please merge

Related discussion:
text: JWTs (and SD-JWTs) can contain claims that are registered in "JSON Web Token Claims" registry as defined in RFC7519, as well as public <del> and private claims.  Private claims are not relevant for this specification due to the openness of the three-party-model.  Since SD-JWTs are based on JWTs, this specification aims to express the basic Verifiable Credential data model purely through JWT Claim Sets, using registered claims while allowing Issuers to use additional registered claims, as well as new or existing public claims, to make statements about the Subject of the Verifiable Credential. </del> <ins> and private claims.  This specification aims to express metadata of the properties of the Verifiable Credentials utilizing registered JWT claims, while allowing Issuers to use other registered, public, or private claims to make statements about the Subject of the Verifiable Credential. </ins> 1.3.
Code change:
Status Provider should be either 4th party or issuer (not verifier).
Merging this since multiple approvals.
lgtm, thank you!

Related discussion:
text: referenced in the credential.  This process is further described in I-D.ietf-oauth-selective-disclosure-jwt. <del> To support revocation of Verifiable Credentials, an optional fourth party can be involved, a Status Provider, who delivers revocation information to Verifiers.  (The Verifier can also serve as the Status Provider.) </del> <ins> To support revocation of Verifiable Credentials, revocation information can optionally be retrieved from a Status Provider.  The role of a Status Provider can be fulfilled by either a fourth party or by the Issuer. </ins> This specification defines Verifiable Credentials based on the SD-JWT format with a JWT Claim Set.
Code change:
Merging this since this is an improvement and PR might not be merged as is.
NAME can you pls resolve merge conflicts, then we can merge this PR.
Merging PR since a lot of approvals.
lgtm, since we have merged PR and might not merge PR , we should merge this.

Related discussion:
text: SD-JWT-based Verifiable Credentials with JSON payloads (SD-JWT VC) <del> draft-terbu-sd-jwt-vc-latest </del> <ins> draft-terbu-oauth-sd-jwt-vc-latest </ins> Abstract This specification describes data formats as well as validation and <del> processing rules to express Verifiable Credentials with JSON payload based on the SD-JWT format I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> processing rules to express Verifiable Credentials with JSON payloads based on the Selective Disclosure for JWTs (SD-JWT) I-D.ietf-oauth- selective-disclosure-jwt format.  It can be used when there are no selective disclosable claims, too. </ins> 1.
Code change:
Merging this since this is an improvement and PR might not be merged as is.
NAME can you pls resolve merge conflicts, then we can merge this PR.
Merging PR since a lot of approvals.
lgtm, since we have merged PR and might not merge PR , we should merge this.

Related discussion:
text: Issuance as defined in Section 5.3. of I-D.ietf-oauth-selective- disclosure-jwt. <del> SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of I- D.ietf-oauth-selective-disclosure-jwt. </del> <ins> When there are selectively disclosable claims, SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of I-D.ietf-oauth- selective-disclosure-jwt. </ins> 4.2.1.
Code change:
Merging this since this is an improvement and PR might not be merged as is.
NAME can you pls resolve merge conflicts, then we can merge this PR.
Merging PR since a lot of approvals.
lgtm, since we have merged PR and might not merge PR , we should merge this.

Related discussion:
text: Additional public claims MAY be used in SD-JWT VCs depending on the application. <ins> 4.2.2.4. An SD-JWT VC MAY have no selectively disclosable claims.  In that case, the SD-JWT VC MUST NOT contain the claim in the JWT body.  It also MUST NOT have any Disclosures. </ins> 4.3. The following is a non-normative example of an unsecured payload of
Code change:
Merging this since this is an improvement and PR might not be merged as is.
NAME can you pls resolve merge conflicts, then we can merge this PR.
Merging PR since a lot of approvals.
lgtm, since we have merged PR and might not merge PR , we should merge this.

Related discussion:
text: described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure- jwt. <ins> When there are no selectively disclosable claims, a presentation of SD-JWT VC does not contain any Disclosures. </ins> 6.1.1. If the presentation of the SD-JWT VC includes a Holder Binding JWT,
Code change:
Replace "Three-Party-Model" with "Issuer-Holder-Verifier Model"
There are lots of things that could be described as a three-party model (including classic OAuth where this work is aspiring for adoption). The use of "Three-Party-Model" in this document strikes me as somewhat presumptuous and potentially misleading or confusing. Could we instead use "Issuer-Holder-Verifier Model"?
I agree, since there must be always a trusted third party in the model, like a trust anchor or its intermediate
I typically refer to this model as "decentralized identity" or "verifiable credentials applications/solutions/ecosystems", I would be fine with "digital credentials applications/solutions/ecosystems".
I'm suggesting only to replace the 5 or 6 usages of "Three-Party-Model" with "Issuer-Holder-Verifier Model".
That would work for me and I understand that Three-Party-Model is confusing since other architectures also involve 3 parties.
I'm ok with using "Issuer-Holder-Verifier Model".
It seems that this issue is ready for a PR.
is that PR
thanks, lgtm

Related discussion:
text: 1.1. <del> In the so-called Three-Party-Model, Issuers issue Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers.  Verifiable Credentials are </del> <ins> In the so-called Issuer-Holder-Verifier Model, Issuers issue Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers.  Verifiable Credentials are </ins> cryptographically signed statements about a Subject, typically the Holder.
Code change:
Replace "Three-Party-Model" with "Issuer-Holder-Verifier Model"
There are lots of things that could be described as a three-party model (including classic OAuth where this work is aspiring for adoption). The use of "Three-Party-Model" in this document strikes me as somewhat presumptuous and potentially misleading or confusing. Could we instead use "Issuer-Holder-Verifier Model"?
I agree, since there must be always a trusted third party in the model, like a trust anchor or its intermediate
I typically refer to this model as "decentralized identity" or "verifiable credentials applications/solutions/ecosystems", I would be fine with "digital credentials applications/solutions/ecosystems".
I'm suggesting only to replace the 5 or 6 usages of "Three-Party-Model" with "Issuer-Holder-Verifier Model".
That would work for me and I understand that Three-Party-Model is confusing since other architectures also involve 3 parties.
I'm ok with using "Issuer-Holder-Verifier Model".
It seems that this issue is ready for a PR.
is that PR
thanks, lgtm

Related discussion:
text: 3. <del> TBD: explain use cases of the three-party-model. </del> <ins> TBD: explain use cases of the Issuer-Holder-Verifier Model. </ins> TBD: conventional crypt, hardware security, hsm, mobile secure area, compliance with FIPS
Code change:
As NAME has aptly pointed out, 'the "with JSON payloads" wording is clunky and redundant.'
lgtmI see no reason to have the "with JSON payloads" in the title

Related discussion:
text: <del> SD-JWT-based Verifiable Credentials with JSON payloads (SD-JWT VC) </del> <ins> SD-JWT-based Verifiable Credentials (SD-JWT VC) </ins> draft-terbu-oauth-sd-jwt-vc-latest Abstract
Code change:
I worry about collisions and confusion with (and with ) - those of us that work with this stuff will likely understand the difference, but there is probably a better descriptor we could use than for this reason. Maybe specifying "schema" or "schemaName" or "sn" (for nice short form) would be more useful here
NAME there is a conversation on renaming type claim in Issue URL which should be a separate PR if we agree on an alternative claim name..
lgtm after we applied NAME suggestion

Related discussion:
text: . The <del> claim is used to express the type of the JSON object that is secured by the JWT.  The </del> value MUST be a case-sensitive <del> value. </del> <ins> value serving as an identifier for the type of the SD-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 values; instead it is expected that ecosystems using SD-JWT VCs define such values including the semantics of the respective claims and associated rules (e.g., policies for issuing and validating credentials beyond what is defined in this specification). </ins> The following is a non-normative example of how is used to express a type: <ins> For example, a type can be defined such that at least the registered JWT claims , , , and must appear in the Unsecured Payload.  Additionally, the registered JWT claims and , and the private claims , , and may be used.  The type might also indicate that , , , can be selectively disclosable. </ins> 4.2.2.2. SD-JWT VCs MAY use any claim registered in the "JSON Web Token
Code change:
I removed the subsection numbers where appropriate to be less dependent on changes in the SD-JWT spec. I also removed references to the issuance/presentation format, as this was unified in SD-JWT. This also meant that the section on the data formats for issuance and presentation in our spec can now be just one section, as there are no big differences any longer.
There are a number of references to specific section numbers in SD-JWT that are now out of sync and point to the wrong sections or non-existent sections. And some lingering use of terms like "Combined Format for XXXXX" that are no longer used in SD-JWT.
And there may well be other changes coming to the section layout URL so it might be prudent to avoid specific section number references (for the time being anyway).
lgtm

Related discussion:
text: This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads based on the Selective Disclosure for JWTs (SD-JWT) I-D.ietf-oauth- <del> selective-disclosure-jwt format.  It can be used when there are no </del> <ins> selective-disclosure-jwt format.  It can be used without any </ins> selective disclosable claims, too. 1.
Code change:
I removed the subsection numbers where appropriate to be less dependent on changes in the SD-JWT spec. I also removed references to the issuance/presentation format, as this was unified in SD-JWT. This also meant that the section on the data formats for issuance and presentation in our spec can now be just one section, as there are no big differences any longer.
There are a number of references to specific section numbers in SD-JWT that are now out of sync and point to the wrong sections or non-existent sections. And some lingering use of terms like "Combined Format for XXXXX" that are no longer used in SD-JWT.
And there may well be other changes coming to the section layout URL so it might be prudent to avoid specific section number references (for the time being anyway).
lgtm

Related discussion:
text: 1.4. This specification uses the terms "Holder", "Issuer", "Verifier", <del> defined by I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> "Key Binding JWT" defined by I-D.ietf-oauth-selective-disclosure-jwt. </ins> 2.
Code change:
I removed the subsection numbers where appropriate to be less dependent on changes in the SD-JWT spec. I also removed references to the issuance/presentation format, as this was unified in SD-JWT. This also meant that the section on the data formats for issuance and presentation in our spec can now be just one section, as there are no big differences any longer.
There are a number of references to specific section numbers in SD-JWT that are now out of sync and point to the wrong sections or non-existent sections. And some lingering use of terms like "Combined Format for XXXXX" that are no longer used in SD-JWT.
And there may well be other changes coming to the section layout URL so it might be prudent to avoid specific section number references (for the time being anyway).
lgtm

Related discussion:
text: 4.2. <del> SD-JWT VCs MUST be encoded using the SD-JWT Combined Format for Issuance as defined in Section 5.3. of I-D.ietf-oauth-selective- disclosure-jwt. </del> <ins> SD-JWT VCs MUST be encoded using the SD-JWT format defined in Section 5 of I-D.ietf-oauth-selective-disclosure-jwt.  A presentation of an SD-JWT VC MAY contain a Key Binding JWT. </ins> <del> When there are selectively disclosable claims, SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of I-D.ietf-oauth- selective-disclosure-jwt. </del> <ins> Note that in some cases, an SD-JWT VC MAY have no selectively disclosable claims, and therefore the encoded SD-JWT will not contain any Disclosures. </ins> 4.2.1.
Code change:
I removed the subsection numbers where appropriate to be less dependent on changes in the SD-JWT spec. I also removed references to the issuance/presentation format, as this was unified in SD-JWT. This also meant that the section on the data formats for issuance and presentation in our spec can now be just one section, as there are no big differences any longer.
There are a number of references to specific section numbers in SD-JWT that are now out of sync and point to the wrong sections or non-existent sections. And some lingering use of terms like "Combined Format for XXXXX" that are no longer used in SD-JWT.
And there may well be other changes coming to the section layout URL so it might be prudent to avoid specific section number references (for the time being anyway).
lgtm

Related discussion:
text: 6.1. <del> A presentation of an SD-JWT VC MUST be encoded using the SD-JWT Combined Format for Presentation as defined in Section 5.4. of I- D.ietf-oauth-selective-disclosure-jwt. A presentation of an SD-JWT VC MAY contain a Key Binding JWT as described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure- jwt. When there are no selectively disclosable claims, a presentation of SD-JWT VC does not contain any Disclosures. 6.1.1. </del> If the presentation of the SD-JWT VC includes a Key Binding JWT, the following claims are used within the Key Binding JWT:
Code change:
We currently have two section describing verification by Verifiers. This commit consolidates both sections. Importantly, this commit fixes the description of the key binding check to ensure that removing a KB JWT from the presentation does not allow circumventing KB.
thank you! great improvement.

Related discussion:
text: 4.4. <del> The recipient of the SD-JWT VC MUST process and verify an SD-JWT VC as follows: </del> <ins> The recipient (Holder or Verifier) of an SD-JWT VC MUST process and verify an SD-JWT VC as described in Section 6 of I-D.ietf-oauth- selective-disclosure-jwt. If Key Binding is required (refer to the security considerations in Section 9.6 of I-D.ietf-oauth-selective-disclosure-jwt), the Verifier MUST verify the Key Binding JWT according to Section 6 of I-D.ietf- oauth-selective-disclosure-jwt.  To verify the Key Binding JWT, the claim of the SD-JWT MUST be used. 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. If there are no selectively disclosable claims, there is no need to process the claim nor any Disclosures. If is present in the verified payload of the SD-JWT, the status SHOULD be checked.  It depends on the Verifier policy to reject or accept a presentation of a SD-JWT VC based on the status of the Verifiable Credential. </ins> Any claims used that are not understood MUST be ignored.
Code change:
We currently have two section describing verification by Verifiers. This commit consolidates both sections. Importantly, this commit fixes the description of the key binding check to ensure that removing a KB JWT from the presentation does not allow circumventing KB.
thank you! great improvement.

Related discussion:
text: The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT: <del> 6.3. The Verifier MUST process and verify a presentation of SD-JWT VC as follows: </del> 7. TBD: Verifier provided
Code change:
URL
I found several minor issues here: The spec has the following headlines: 4.2.2 Claims Comparing this to RFC7519 JWT these should be: JOSE Header JWT Claims Set Also, in 4.2.2.1 type claim is never explained. This should be added to the Terminology. Its also missing a link to the Annex A.1.
Additionally, headline 4.2.2.1 would better fit saying "New JWT Claims"?

Related discussion:
text: 3.2.2.1. <ins> 3.2.2.1.1. </ins> This specification defines the JWT claim . The value MUST be a case-sensitive <del> value serving as an identifier for the type of the SD-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> (see RFC7519) value serving as an identifier for the type of the SD- 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 </ins> values; instead it is expected that ecosystems using SD-JWT VCs define such values including the semantics of the respective claims
Code change:
Add reference to Security Considerations in SD-JWT
E.g.: SSRF with Issuer URI

Related discussion:
text: 6. <del> TBD: Verifier provided . </del> <ins> The Security Considerations in the SD-JWT specification I-D.ietf- oauth-selective-disclosure-jwt apply to this specification. Additionally, the following security considerations need to be taken into account when using SD-JWT VCs: 6.1. The JWT Issuer Metadata configuration is retrieved from the JWT Issuer by the Holder or Verifier.  Similar to other metadata endpoints, the URL for the retrieval MUST be considered an untrusted value and could be a vector for Server-Side Request Forgery (SSRF) attacks. Before making a request to the JWT Issuer Metadata endpoint, the Holder or Verifier MUST validate the URL to ensure that it is a valid HTTPS URL and that it does not point to internal resources.  This requires, in particular, ensuring that the host part of the URL does not address an internal service (by IP address or an internal host name) and that, if an external DNS name is used, the resolved DNS name does not point to an internal IPv4 or IPv6 address. When retrieving the metadata, the Holder or Verifier MUST ensure that the request is made in a time-bound and size-bound manner to prevent denial of service attacks.  The Holder or Verifier MUST also ensure that the response is a valid JWT Issuer Metadata configuration document before processing it. Additional considerations can be found in OWASP_SSRF. </ins> 7.
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: Abstract <del> This document specifies Verifiable Credentials based on Selective Disclosure JSON Web Tokens (SD-JWT) with JSON payloads. </del> <ins> This specification describes data formats, validation and processing rules to express Verifiable Credentials based on the SD-JWT format (TBD: see oauth-selective-disclosure-jwt) using JSON payloads. </ins> 1. <del> TBD: why? - simplicity - JWTs are well-known, popular but doesn't work best with three-party-model - Also no selective disclosure, which impacts costs and security. This specification describes data formats, validation and processing rules for SD-JWT expresing Verifiable Credentials. </del> <ins> Todo: Discuss VCs, introduce terminology. Signed JSON Web Tokens (JWTs) RFC7519 can in principle be used to express Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives.  However, JWTs do not support selective disclosure, i.e., the ability to disclose only a subset of the claims contained in the JWT.  This is a common problem in the so-called three-party model: An Issuer creates a Verifiable Credential for some End-User (Holder), who then presents this credential to multiple Verifiers.  A credential might contain a large number of claims, but the Holder typically only wants to disclose a subset of these claims to a Verifier.  In this case, the Holder would have to receive a new signed JWT from the Issuer, containing only the claims that should be disclosed, for each interaction with a new Verifier.  This is inefficient, costly, and the necessary interaction with the Issuer introduces additional privacy risks. SD-JWT is a specification that introduces conventions to support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer). This format is therefore perfectly suitable for Verifiable Credentials. SD-JWT itself does not define the claims that must be used within the payload of the token or their semantics.  This specification therefore defines how Verifiable Credentials can be expressed using SD-JWT. Todo: Explain the 'plain JSON' part </ins> 1.1.