jiebi/CodeConvo huggingface dataset:
Code change:
I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.

Related discussion:
text: 4. <del> This specification defines the media type which describes a VC-SD-JWT with the following components: </del> <ins> This section defines encoding, validation and processing rules for VC-SD-JWTs. </ins> 4.1. <del> 4.1.1. </del> <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
Code change:
I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.

Related discussion:
text: 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> <ins> 4.2.2. </ins> <del> VC-SD-JWTs and VP-SD-JWTs MAY contain additional registered or public claims depending on the application. </del> <ins> This section defines the claims that can be included in the payload of SD-JWTs and Diclosures belonging to VC-SD-JWTs. </ins> <del> 4.1.2.1. </del> <ins> 4.2.2.1. </ins> This specification defines the JWT claim
Code change:
I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.

Related discussion:
text: is used to express a type: <del> 4.1.2.2. </del> <ins> 4.2.2.2. </ins> <del> The following are non-selectively disclosable registered JWT claims that SD-JWTs of VC-SD-JWTs contain for specific purposes: </del> <ins> VC-SD-JWTs MAY use any claim registered in the "JSON Web Token Claims" registry as defined in RFC7519. </ins> <del> The following are selectively disclosable registered JWT claims that SD-JWTs of VC-SD-JWTs contain for specific purposes: </del> <ins> If present, the following registered JWT claims MUST be included in the SD-JWT and MUST NOT be included in the Disclosures, i.e. cannot be selectively disclosed: </ins> <del> 4.2. </del> <ins> The following registered JWT claims MAY be contained in the SD-JWT or in the Disclosures and MAY be selectively disclosed: 4.2.2.3. Additional public claims MAY be used in the SD-JWT or in the Disclosures depending on the application. 4.3. </ins> The following is a non-normative example of a Credential acting as the input for the VC-SD-JWT:
Code change:
I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.

Related discussion:
text: TBD: add other disclosures. <del> 4.3. </del> <ins> 4.4. The recipient of the VC-SD-JWT MUST process and verify an VC-SD-JWT as follows: </ins> <del> A Verifier MUST validate an VC-SD-JWT as follows: </del> <ins> Any claims used that are not understood MUST be ignored. </ins> Additional validation rules MAY apply, but their use is out of the scope of this specification.
Code change:
I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.

Related discussion:
text: 6. <del> This specification defines the media type which describes the VP-SD-JWT with the following components: </del> <ins> This section defines encoding, validation and processing rules for VP-SD-JWTs. </ins> 6.1. <del> The following is a non-normative example of a VP-SD-JWT without holder binding: </del> <ins> VP-SD-JWTs compliant with this specification MUST use the media type </ins> <del> The following is a non-normative example of a VP-SD-JWT with holder binding: </del> <ins> as defined in {#application-vp-sd-jwt}. </ins> 6.2. <del> TBD: same as VC-SD-JWT (-> refer to SD-JWT) + Holder Binding </del> <ins> VP-SD-JWTs MUST be encoded using the SD-JWT Combined Format for Presentation as defined in I-D.ietf-oauth-selective-disclosure-jwt. VP-SD-JWTs MAY contain a Holder Binding JWT as described in I-D.ietf- oauth-selective-disclosure-jwt. 6.2.1. If the VP-SD-JWT includes a Holder Binding JWT, the following claims are used within the Holder Binding JWT: The Holder Binding JWT MAY include addtional claims which when not understood MUST be ignored. 6.3. The following is a non-normative example of a VP-SD-JWT without Holder Binding: The following is a non-normative example of a VP-SD-JWT with Holder Binding: 6.4. The Verifier MUST process and verify an VP-SD-JWT as follows: </ins> 7. <del> TBD </del> <ins> TBD: Verifier provided . </ins> 8. <del> TBD </del> <ins> TBD: Holder provided nonce via . </ins> 9.
Code change:
Fixed VCDM transformation algo,
omitting claim in Presentation and treating it as a default value
We will do the following: Instead of pseudo code, we will use algorithmic description Add algorithms for VPs and VCs.

Related discussion:
text: Issuer about a Subject of the Verifiable Credential.  Verifiable Credentials are issued to Holders which can present Verifiable Credentials to Verifiers typically in form of Verifiable <del> Presentations which are secure Verifiable Credentials addressed to a </del> <ins> Presentations which secure Verifiable Credentials addressed to a </ins> specific audience. These relationships are described by the three-party-model which
Code change:
Fixed VCDM transformation algo,
omitting claim in Presentation and treating it as a default value
We will do the following: Instead of pseudo code, we will use algorithmic description Add algorithms for VPs and VCs.

Related discussion:
text: I-D.ietf-oauth-selective-disclosure-jwt. The three-party-model, i.e., actors, Verifiable Credentials and <del> Verifiable Presentations, are further described in [VCDM2.0]. However, this specification focuses on a specific version of the three-party-model which can have different features but will provide a representation of the model described in [VCDM2.0]. </del> <ins> Verifiable Presentations, are further described in VC-DATA.  However, this specification focuses on a specific version of the three-party- model which can have different features but will provide a representation of the model described in VC-DATA. </ins> 1.2.
Code change:
Fixed VCDM transformation algo,
omitting claim in Presentation and treating it as a default value
We will do the following: Instead of pseudo code, we will use algorithmic description Add algorithms for VPs and VCs.

Related discussion:
text: This specification registers the media type <del> in the W3C Verifiable Credentials (VC) Directory. </del> <ins> in the W3C Verifiable Credentials (VC) Directory VC-DIR. </ins> 9.1.2. The following is a uni-directional transformation algorithm that takes in a VC-SD-JWT conformant to this specification and maps it to <del> the corresponding properties in the W3C VCDM 2.0 [VCDM2.0] which is </del> <ins> the corresponding properties in the W3C VCDM 2.0 VC-DATA which is </ins> based on a JSON-LD vocabulary.  It includes specific handling for JWT claims used in this specification.  The function returns a Verifiable Credential object in the W3C VCDM 2.0 format. <del> The following is a uni-directional transformation algorithm from a VP-SD-JWT onto W3C Verifiable Presentations in pseudo-code: </del> <ins> Procedure: 1.  Let </ins> <del> #### </del> <ins> be the unsecured payload of the VC-SD-JWT reconstructed from the SD- JWT and Disclosures.  1.  Let be an empty JSON object that represents the transformed Verifiable Credential: - Set the property of to .  1.  If the payload contains the property: - Convert the value of from epoch time to an ISO datetime format.  - Assign the converted value to the property of .  - Remove the claim from the payload.  1.  If the payload contains the property: - Convert the value of from epoch time to an ISO datetime format.  - Assign the converted value to the property of .  - Remove the claim from the payload.  1.  If the payload contains the property: - Assign the value of to the property of .  - Remove the claim from the payload.  1.  Set the property of to the value of the property in the payload.  - Remove the claim from the payload.  1.  Set the property of to a String array and set the first array element to . Add the value of the property in the payload as the second array element.  - Remove the claim from the payload.  1.  If the payload contains the property: - Assign the value of as the property of the object in .  - Remove the claim from the payload.  1.  Else if the payload does not have a property, create an empty object.  1.  Add all remaining claims in the payload to the object of and ignore claims that do not have a corresponding representation. 1.  Output which contains the resulting Verifiable Credential. The following is a non-normative example of a pseudocode algorithm: </ins>
Code change:
In the rendered HTML, the entire algo appears in one paragraph. The mmark is probably broken and has to be fixed.
lgtm, thank you!

Related discussion:
text: claims used in this specification.  The function returns a Verifiable Credential object in the W3C VCDM 2.0 format. <del> Procedure: 1.  Let be the unsecured payload of the SD-JWT VC reconstructed from the SD- JWT and Disclosures.  1.  Let be an empty JSON object that represents the transformed Verifiable Credential: - Set the property of to .  1.  If contains the property: - Convert the value of from epoch time to an ISO datetime format.  - Assign the converted value to the property of .  - Remove the claim from .  1.  If contains the property: - Convert the value of from epoch time to an ISO datetime format.  - Assign the converted value to the property of .  - Remove the claim from .  1.  If contains the property: - Assign the value of to the property of .  - Remove the claim from .  1.  Set the property of to the value of the property in .  - Remove the claim from .  1.  Set the property of to a String array and set the first array element to . Add the value of the property in as the second array element.  - Remove the claim from .  1.  If contains the property: - Assign the value of as the property of the object in .  - Remove the claim from .  1.  Else if does not have a property, create an empty object.  1.  Add all remaining claims in to the object of and ignore claims that do not have a corresponding representation. 1.  Output which contains the resulting Verifiable Credential. </del> <ins> Procedure: </ins> The following is a non-normative example of a pseudocode algorithm:
Code change:
As agreed on the editor's call (5/23), the following ... should become ...
I'm still confused why we need this text at all. What people will basically get is "this spec deviates from the VCDM 2.0".

Related discussion:
text: I-D.ietf-oauth-selective-disclosure-jwt. The three-party-model, i.e., actors, Verifiable Credentials and <del> Verifiable Presentations, are further described in VC-DATA.  However, this specification focuses on a specific version of the three-party- model which can have different features but will provide a representation of the model described in VC-DATA. </del> <ins> Verifiable Presentations, is also described in VC-DATA.  However, this specification provides a specific format of Verifiable Credentials which deviates from the format described in VC-DATA to create Verifiable Credentials based on SD-JWT and JSON payloads but a translation algorithm is provided in this specification. </ins> 1.2.
Code change:
fix:
in the three-party model: An Issuer creates a Verifiable Credential for some End-User (Holder), who then presents this credential to multiple Verifiers. A Verifiable Credential might contain a large number of claims, but the Holder We should short this as suggested by NAME Originally posted by NAME in URL
Relates to

Related discussion:
text: 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 <del> only a subset of the claims contained in the JWT, in the three-party- model as described above.  This is a common problem in the three- party model: An Issuer creates a Verifiable Credential for some End- User (Holder), who then can presents this credential to multiple Verifiers.  A Verifiable 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 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. </del> <ins> only a subset of the claims contained in the JWT, which is a requirement to implement the three-party-model efficiently. </ins> Selective Disclosure JWT (SD-JWT) [SD-JWT] is a specification that introduces conventions to support selective disclosure for JWTs: For
Code change:
The rules for obtaining the issuer metadata needs to be extended to cope with paths as well. I suggest to use the text from URL
The following example is already supported ... NAME is this what you had in mind, or is there anything missing? In that case, we could add an example that makes it more visible that this use case is supported.
URL needs to be URL have a look at URL
Ok, makes sense. Will create a PR to fix that.

Related discussion:
text: scheme, host and, optionally, port number and path components, but no query or fragment components. <del> The following is a non-normative example of the URL of the JWT Issuer Metadata configuration when </del> <ins> 5.1. A JWT Issuer Metadata configuration MUST be queried using an HTTP request at the path defined in jwt-issuer-metadata. The following is a non-normative example of a HTTP request for the JWT Issuer Metadata configuration when </ins> is set to : <del> The following is a non-normative example of the URL of the JWT Issuer Metadata configuration when </del> <ins> If the value contains a path component, any terminating MUST be removed before inserting and the well-known URI suffix between the host component and the path component. The following is a non-normative example of a HTTP request for the JWT Issuer Metadata configuration when </ins> is set to : <del> The JWT Issuer Metadata configuration MUST be a JSON document compliant with this specification and MUST be returned using the </del> <ins> 5.2. A successful response MUST use the and return the JWT Issuer Metadata configuration using the </ins> content type. <ins> An error response uses the applicable HTTP status code value. </ins> This specification defines the following JWT Issuer Metadata <del> parameters: </del> <ins> configuration parameters: </ins> JWT Issuer Metadata MUST include either
Code change:
The rules for obtaining the issuer metadata needs to be extended to cope with paths as well. I suggest to use the text from URL
The following example is already supported ... NAME is this what you had in mind, or is there anything missing? In that case, we could add an example that makes it more visible that this use case is supported.
URL needs to be URL have a look at URL
Ok, makes sense. Will create a PR to fix that.

Related discussion:
text: JWK Set included by value or referenced in the JWT Issuer Metadata. The following is a non-normative example of a JWT Issuer Metadata <del> including </del> <ins> configuration including </ins> : The following is a non-normative example of a JWT Issuer Metadata <del> including </del> <ins> configuration including </ins> : <ins> Additional JWT Issuer Metadata configuration parameters MAY also be used. 5.3. The value returned MUST be identical to the value of the JWT.  If these values are not identical, the data contained in the response MUST NOT be used. </ins> 6. This section defines encoding, validation and processing rules for
Code change:
NAME can we merge this now?
Try to find a new term.
Introduce and use the term "unsecured payload" instead of payload or credential to refer to the input JSON document. We cannot use payload because it would lead to confusion since the payload of the SD-JWT might not even contain all the claims and only the hashes.

Related discussion:
text: 4.3. <del> The following is a non-normative example of an unsecured input payload of an SD-JWT VC. </del> <ins> The following is a non-normative example of an unsecured payload of an SD-JWT VC. </ins> <del> The following is a non-normative example of how the Credential above can be used in a SD-JWT where the resulting SD-JWT VC contains only claims about the Subject that are selectively disclosable: </del> <ins> The following is a non-normative example of how the unsecured payload of the SD-JWT VC above can be used in a SD-JWT where the resulting SD-JWT VC contains only claims about the Subject that are selectively disclosable: </ins> Note that a
Code change:
This just fixes typos and references.
This just fixes typos and references. No review required at this stage.

Related discussion:
text: contained in the JWT, which is a requirement to implement the three- party-model efficiently. <del> Selective Disclosure JWT (SD-JWT) [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 suited for Verifiable Credentials and Verifiable Presentations. </del> <ins> Selective Disclosure JWT (SD-JWT) I-D.ietf-oauth-selective- disclosure-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 suited for Verifiable Credentials and Verifiable Presentations. </ins> SD-JWT itself does not define the claims that must be used within the payload or their semantics.  This specification therefore defines how
Code change:
Only minor editorial changes such as typos.
Only minor editorial changes such as typos -> no peer-review required at this stage.

Related discussion:
text: 4.2. SD-JWT VCs MUST be encoded using the SD-JWT Combined Format for <del> Issuance as defined in I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> Issuance as defined in Section 5.3. of I-D.ietf-oauth-selective- disclosure-jwt. </ins> SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT <del> component except for Decoy Digests as per section 5.1.1.3. of I- </del> <ins> component except for Decoy Digests as per Section 5.1.1.3. of I- </ins> D.ietf-oauth-selective-disclosure-jwt. 4.2.1.
Code change:
Only minor editorial changes such as typos.
Only minor editorial changes such as typos -> no peer-review required at this stage.

Related discussion:
text: 6.1. SD-JWT VPs MUST be encoded using the SD-JWT Combined Format for <del> Presentation as defined in I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> Presentation as defined in Section 5.4. of I-D.ietf-oauth-selective- disclosure-jwt. </ins> <del> SD-JWT VPs MAY contain a Holder Binding JWT as described in I-D.ietf- oauth-selective-disclosure-jwt. </del> <ins> SD-JWT VPs MAY contain a Holder Binding JWT as described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure-jwt. </ins> 6.1.1.