jiebi/CodeConvo huggingface dataset:
A URI in the claim can be used to express a type.  If the type is a URL using the <del> HTTPS scheme, Type Metadata can be retrieved from the URL , i.e., by inserting after the authority part of the URL. </del> <ins> HTTPS scheme, Type Metadata MAY be retrieved from it. </ins> The Type Metadata is retrieved using the HTTP GET method.  The response MUST be a JSON object as defined in type-metadata-format.
6.3.2. A Consumer MAY use a registry to retrieve Type Metadata for a SD-JWT <del> VC type, e.g., if the type is not a HTTPS URL or if the Consumer does not have access to the URL.  The registry MUST be a trusted registry, i.e., the Consumer MUST trust the registry to provide correct Type Metadata for the type. </del> <ins> VC type, e.g., if the type is not an HTTPS URL or if the Consumer does not have access to the URL.  The registry MUST be a trusted registry, i.e., the Consumer MUST trust the registry to provide correct Type Metadata for the type. </ins> The registry MUST provide the Type Metadata in the same format as described in type-metadata-format.
. The <del> claim is used to express the type or types of the JSON object that is contained in the JWT payload.  In the general case, the </del> <ins> claim is used to express the type of the JSON object that is contained in the JWT payload.  The </ins> <del> value is an array of case-sensitive strings, each containing a value.  In the special case when the SD-JWT has one credential type, the value MAY be a single case-sensitive string containing a </del> <ins> value MUST be a case-sensitive </ins> value. The following is a non-normative example of how <del> is used to express a single type: The following is a non-normative example of how is used to express multiple types: </del> <ins> is used to express a type: </ins> 5.1.2.2.
9.1. <del> The W3C VCDM 2.0 (see TBD) defines a JSON-LD vocabulary for Verifiable Credentials and Verifiable Presentations.  To interop with the W3C VCDM 2.0 data model defined in [TBD], this specification defines mapping algorithm for VC-SD-JWT and VP-SD-JWT to the vocabulary and data model defined W3C VCDM 2.0 which is based on JSON-LD. </del> <ins> The W3C VCDM 2.0 VC-DATA defines a JSON-LD vocabulary for Verifiable Credentials and Verifiable Presentations.  To interop with the W3C VCDM 2.0 data model defined in VC-DATA, this specification defines a mapping algorithm for VC-SD-JWT and VP-SD-JWT to the vocabulary and data model defined W3C VCDM 2.0 which is based on JSON-LD. </ins> 9.1.1.
claims, to make statements about the Subject of the Verifiable Credential. <del> 1.1. </del> <ins> 1.3. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. <del> 1.2. </del> <ins> 1.4. </ins> 2.
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
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
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:
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.
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.
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.
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>
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:
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.
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
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
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
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
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
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.
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.
referenced in the credential.  This process is further described in I-D.ietf-oauth-selective-disclosure-jwt. <del> To support revocation of 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, 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.) </ins> <del> The three-party-model, i.e., actors, Verifiable Credentials and Verifiable Presentations, is also described in VC-DATA.  This specification defines Verifiable Credentials based on the SD-JWT format and JSON payloads.  A translation algorithm between the two approaches is provided in this specification. </del> <ins> The three-party-model, i.e., actors, Verifiable Credentials, is also described in VC-DATA.  This specification defines Verifiable Credentials based on the SD-JWT format and JWT Claim Sets with JSON payloads.  A translation algorithm between the two approaches is provided in this specification. </ins> 1.2.
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 <del> Verifiable Credentials and Verifiable Presentations. </del> <ins> Verifiable Credentials. </ins> SD-JWT itself does not define the claims that must be used within the payload or their semantics.  This specification therefore defines how Verifiable Credentials can be expressed using SD-JWT. <del> JWTs (and SD-JWTs) can contain claims that are registered in the IANA JWT Claim Registry, as well as public 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> JWTs (and SD-JWTs) can contain claims that are registered in "JSON Web Token Claims" registry as defined in RFC7519, as well as public 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. </ins> 1.3.
6. This section defines encoding, validation and processing rules for <del> SD-JWT VPs. </del> <ins> presentations of SD-JWT VCs. </ins> 6.1. <del> SD-JWT VPs 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. </del> <ins> 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. </ins> <del> SD-JWT VPs MAY contain a Holder Binding JWT as described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> A presentation of an SD-JWT VC 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. <del> If the SD-JWT VP includes a Holder Binding JWT, the following claims are used within the Holder Binding JWT: </del> <ins> If the presentation of the SD-JWT VC includes a Holder Binding JWT, the following claims are used within the Holder Binding JWT: </ins> The Holder Binding JWT MAY include addtional claims which when not understood MUST be ignored.