jiebi/CodeConvo huggingface dataset:
3.5. <del> A recipient of an SD-JWT VC MUST apply the following rules to obtain the public verification key for the Issuer-signed JWT: </del> <ins> A recipient of an SD-JWT VC MUST apply the following rules to validate that the public verification key for the Issuer-signed JWT corresponds to the value: </ins> Separate specifications or ecosystem regulations MAY define rules complementing the rules defined above, but such rules are out of scope of this specification.  See ecosystem-verification-rules for security considerations. <ins> If a recipient cannot validate that the public verification key corresponds to the value of the Issuer-signed JWT, the SD-JWT VC MUST be rejected. </ins> 4. This specification defines the JWT Issuer Metadata to retrieve the
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
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
5. <del> TBD </del> <ins> This specification defines the media type which describes a VC-SD-JWT with the following components: 1.  An SD- JWT to protect the integrity of the claims, to enable selective disclosure and to ensure authorship of the VC-SD-JWT.  The SD-JWT header parameters and the payload is further defined by this specification.  1.  The full set of SD-JWT Disclosures that contain the claims in plain text. This specification defines the media type which describes the VP-SD-JWT with the following components: 1.  The SD-JWT from the VC-SD-JWT.  1.  A subset of the SD-JWT Disclosures that are selectively disclosed by the Holder.  1.  An optional holder binding JWT that proves the Holder is the intended Holder of the Verifiable Credential.  Note, it is the responsibility for the Issuer to include a confirmation method in the Verifiable Credential.  This process is referred to as holder binding.  This enables the Holder to prove they are the intended Holder of the Verifiable Credential. Further note, it is up to the Verifier to require or to not require the Holder to prove posessions of the confirmation method. </ins> 5.1. The <del> header parameter of the SD-JWT-VC MUST be present.  The </del> <ins> header parameter of the SD-JWT MUST be present.  The </ins> <del> value MUST use the media type </del> <ins> value MUST use </ins> <del> that is registered by this specification.  This indicates that the payload of the SD-JWT-VC contains plain JSON and follows the rules as defined in this specification. </del> <ins> . This indicates that the payload of the SD-JWT contains plain JSON and follows the rules as defined in this specification.  It further indicates that the SD-JWT is a SD-JWT component of a VC-SD-JWT. </ins> The following is a non-normative example of a decoded SD-JWT-VC header:
8. <del> TBD </del> <ins> This specification defines validation and processing rules for verifiable credentials using JSON payloads and secured by SD-JWT I- D.ietf-oauth-selective-disclosure-jwt.  Other specifications exist that define their own verifiable credential formats, which can be used independently of each other.  For example, W3C Verifiable Credential Data Model (VCDM) 2.0 W3C.VCDM defines a data model for verifiable credentials encoded as JSON-LD, and ISO/IEC 18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. </ins>
8. <del> TBD </del> <ins> This specification defines validation and processing rules for verifiable credentials using JSON payloads and secured by SD-JWT I- D.ietf-oauth-selective-disclosure-jwt.  Other specifications exist that define their own verifiable credential formats; for example, W3C Verifiable Credential Data Model (VCDM) 2.0 W3C.VCDM defines a data model for verifiable credentials encoded as JSON-LD, and ISO/IEC 18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. </ins>
4.2. The following is a non-normative example of a presentation of the SD- <del> JWT shown above including a Key Binding JWT: </del> <ins> JWT shown in vc-sd-jwt-example including a Key Binding JWT.  In this presentation, the Holder provides only the Disclosure for the </ins> <del> In this presentation, the Holder provides only the Disclosure for the claim . Other claims are not disclosed to the Verifier. </del> <ins> claim.  Other claims are not disclosed to the Verifier. </ins> The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT:
attacker to potentially manipulate the verification result to their advantage. <del> 7. </del> <ins> 8.3. A type MUST NOT extend another type that extends (either directly or with steps in-between) the first type.  This would result in a circular dependency that could lead to infinite recursion when retrieving and processing the metadata. Consumers MUST detect such circular dependencies and reject the credential. 8.4. In retrieving-type-metadata, various methods for distributing and retrieving metadata are described.  Methods relying on a network connection may fail due to network issues or unavailability of a network connection due to offline usage of credentials, temporary server outages, or denial of service attacks on the metadata server. Consumers SHOULD therefore implement a local cache as described in retrieval-from-local-cache if possible.  Such a cache MAY be populated with metadata before the credential is used. Issuers MAY provide glue documents as described in glue-documents to provide metadata directly with the credential and avoid the need for network requests. These measures allow the Consumders to continue to function even if the metadata server is temporarily unavailable and avoid privacy issues as described in privacy-preserving-retrieval-of-type-metadata. 9. </ins> The Privacy Considerations in the SD-JWT specification I-D.ietf- oauth-selective-disclosure-jwt apply to this specification. Additionally, the following privacy considerations need to be taken into account when using SD-JWT VCs. <del> 7.1. </del> <ins> 9.1. </ins> The Privacy Considerations in Section 12.5 of I-D.ietf-oauth- selective-disclosure-jwt apply especially to the claim. <del> 7.2. </del> <ins> 9.2. </ins> Issuers and Holders have to be aware that while this specification supports selective disclosure of claims of a given SD-JWT VC, the
18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. <ins> 10.1. In retrieving-type-metadata, various methods for distributing and retrieving Type Metadata are described.  For methods which rely on a network connection to a URL (e.g., provided by an Issuer), third parties (like the Issuer) may be able to track the usage of a credential by observing requests to the Type Metadata URL. Consumers SHOULD prefer methods for retrieving Type Metadata that do not leak information about the usage of a credential to third parties.  The recommendations in robust-retrieval apply. </ins>
In the so-called Issuer-Holder-Verifier Model, Issuers issue so- called Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers.  Verifiable Credentials are <del> cryptographically signed statements about a Subject, typically the </del> <ins> cryptographically secured statements about a Subject, typically the </ins> Holder. Verifiers can check the authenticity of the data in the Verifiable
claim of the SD-JWT MUST be used. <del> 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. </del> <ins> Furthermore, the recipient of the SD-JWT VC MUST validate 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
6. <del> A type is associated with metadata defining, for example, information about the type, a schema defining which claims MAY or MUST appear in the SD-JWT VC, and how they can be displayed. </del> <ins> A SD-JWT VC type, i.e., the value, is associated with Type Metadata defining, for example, information about the type or a Schema defining (see schema- definition) which claims MAY or MUST appear in the SD-JWT VC. </ins> This section defines Type Metadata that can be associated with a type <del> of a SD-JWT VC as well as a method for retrieving the Type Metadata </del> <ins> of a SD-JWT VC, as well as a method for retrieving the Type Metadata </ins> and processing rules.  This Type Metadata is intended to be used, among other things, for the following purposes: <del> Applications using Type Metadata defined in this specification are called "Consumers" in the following.  This typically includes Issuers, Verifiers, and Wallets. </del> <ins> Type Metadata can be retrieved as described in retrieving-type- metadata. </ins> 6.1. All examples in this section are non-normative. <del> Type Metadata about the value of a claim value can be retrieved as described in retrieving-type- metadata. </del> Here, the type is . The Type Metadata is retrieved from the URL
6.3. <del> A type can extend another type.  The extended type is identified by the URI in the property.  Consumers MUST retrieve and process Type Metadata for the extended type before processing the Type Metadata for the extending type. The extended type MAY itself extend another type.  This can be used to create a chain or hierarchy of types.  The security considerations described in circular-extends apply in order to avoid problems with circular dependencies. 6.4. 6.4.1. </del> <ins> 6.3.1. </ins> A URI in the
MUST be an "integrity metadata" string as defined in Section document-integrity. <del> 6.4.2. </del> <ins> 6.3.2. </ins> <del> A Consumer MAY use a registry to retrieve Type Metadata for a 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> A Consumer MAY use a registry to retrieve Type Metadata for a SD-JWT 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. </ins> The registry MUST provide the Type Metadata in the same format as described in type-metadata-format. <del> 6.4.3. </del> <ins> 6.3.3. </ins> Ecosystems MAY define additional methods for retrieving Type Metadata.  For example, a standardization body or a community MAY
claim. <del> 6.4.4. </del> <ins> 6.3.4. </ins> <del> A Consumer MAY cache Type metadata for a type.  If a hash for integrity protection is present in the Type Metadata as defined in document-integrity, the Consumer MAY assume that the Type Metadata is static and can be cached indefinitely.  Otherwise, the Consumer MUST use the </del> <ins> A Consumer MAY cache Type Metadata for a SD-JWT VC type.  If a hash for integrity protection is present in the Type Metadata as defined in document-integrity, the Consumer MAY assume that the Type Metadata is static and can be cached indefinitely.  Otherwise, the Consumer MUST use the </ins> header of the HTTP response to determine how long the metadata can be cached. <del> 6.4.5. </del> <ins> 6.3.5. </ins> Credentials MAY encode Type Metadata directly, providing it as "glue <del> information" to the consumer. </del> <ins> information" to the Consumer. </ins> For JSON-serialized JWS-based credentials, such Type Metadata documents MAY be included in the unprotected header of the JWS.  In
array instead of retrieving the respective Type Metadata elsewhere as follows: <ins> 6.4. An SD-JWT VC type can extend another type.  The extended type is identified by the URI in the property.  Consumers MUST retrieve and process Type Metadata for the extended type before processing the Type Metadata for the extending type. The extended type MAY itself extend another type.  This can be used to create a chain or hierarchy of types.  The security considerations described in circular-extends apply in order to avoid problems with circular dependencies. 6.5. 6.5.1. Schemas for Verifiable Credentials are contained in the or retrieved via the Type Metadata parameters (as defined in type-metadata-format).  A Schema MUST be represented by a JSON Schema document according to draft version 2020-12 JSON.SCHEMA.2020-12, or above. The Schema of a Verifiable Credential MUST include all properties that are required by this specification and MUST NOT override their cardinality, JSON data type, or semantic intent. The following is a non-normative example of a JSON Schema document for the example in vc-sd-jwt-example requiring the presence of the claim in an SD-JWT VC presentation: Note, that and are always required by this specification. 6.5.2. If a or property is present, a Consumer MUST validate the JSON document resulting from the SD-JWT verification algorithm (as outlined in Section 8 of I-D.ietf-oauth-selective-disclosure-jwt) against the JSON Schema document provided by the or property. If an property is present, the Schema Type Metadata of the extended type MUST also be validated in the same manner.  This process includes validating all subsequent extended types recursively until a type is encountered that does not contain an property in its Type Metadata.  Each Schema Type Metadata in this chain MUST be evaluated for a specific Verifiable Credential. If the Schema Type Metadata validation fails for any of the types in the chain, the Consumer MUST reject the Verifiable Credential. The following is a non-normative example of a result JSON document after executing the SD-JWT verification algorithm that is validated against the JSON Schema document in the example provided in schema- definition: Note, the example above does not contain any , , or claims. </ins> 7. Both the <del> claim in the SD-JWT VC and various URIs in the metadata document MAY </del> <ins> claim in the SD-JWT VC and the various URIs in the Type Metadata MAY </ins> be accompanied by a respective claim suffixed with , in particular:
All examples in this section are non-normative. <del> Type Metadata about the value of a </del> <ins> The following is an example of an SD-JWT VC payload, containing a </ins> <del> claim value can be retrieved as described in retrieving-type- metadata. </del> <ins> claim with the value </ins> <del> Here, the type is </del> <ins> : </ins> <del> . The Type Metadata is retrieved from the URL </del> <ins> Type Metadata for the type </ins> <del> . </del> <ins> can be retrieved using various mechanisms as described in retrieving- type-metadata.  For this example, the well-known URL as defined in retrieval-from-vct-claim is used and the following Type Metadata Document is retrieved from the URL : </ins> <del> The following is an example for a Type Metadata document: </del> <ins> Note: The hash of the Type Metadata document shown in the second example must be equal to the one in the claim in the SD-JWT VC payload, . </ins> 6.2.
6. <del> A type is associated with metadata defining, for example, information about the type, a schema defining which claims MAY or MUST appear in the SD-JWT VC, and how they can be displayed. </del> <ins> A SD-JWT VC type, i.e., the value, is associated with Type Metadata defining, for example, information about the type or a schema defining (see schema- definition) which claims MAY or MUST appear in the SD-JWT VC. </ins> This section defines Type Metadata that can be associated with a type <del> of a SD-JWT VC as well as a method for retrieving the Type Metadata </del> <ins> of a SD-JWT VC, as well as a method for retrieving the Type Metadata </ins> and processing rules.  This Type Metadata is intended to be used, among other things, for the following purposes: <del> Applications using Type Metadata defined in this specification are called "Consumers" in the following.  This typically includes Issuers, Verifiers, and Wallets. </del> <ins> Type Metadata can be retrieved as described in retrieving-type- metadata. </ins> 6.1. All examples in this section are non-normative. <del> Type Metadata about the value of a </del> <ins> The following is an example of an SD-JWT VC payload, containing a </ins> <del> claim value can be retrieved as described in retrieving-type- metadata. </del> <ins> claim with the value </ins> <del> Here, the type is </del> <ins> : </ins> <del> . The Type Metadata is retrieved from the URL </del> <ins> Type Metadata for the type </ins> <del> . </del> <ins> can be retrieved using various mechanisms as described in retrieving- type-metadata.  For this example, the well-known URL as defined in retrieval-from-vct-claim is used and the following Type Metadata Document is retrieved from the URL : Note: The hash of the Type Metadata document shown in the second example must be equal to the one in the </ins> <del> The following is an example for a Type Metadata document: </del> <ins> claim in the SD-JWT VC payload, . </ins> 6.2.
array instead of retrieving the respective Type Metadata elsewhere as follows: <ins> 6.4. An SD-JWT VC type can extend another type.  The extended type is identified by the URI in the property.  Consumers MUST retrieve and process Type Metadata for the extended type before processing the Type Metadata for the extending type. The extended type MAY itself extend another type.  This can be used to create a chain or hierarchy of types.  The security considerations described in circular-extends apply in order to avoid problems with circular dependencies. 6.5. 6.5.1. Schemas for Verifiable Credentials are contained in the or retrieved via the Type Metadata parameters (as defined in type-metadata-format).  A schema MUST be represented by a JSON Schema document according to draft version 2020-12 JSON.SCHEMA.2020-12 or above. The schema of a Verifiable Credential MUST include all properties that are required by this specification and MUST NOT override their cardinality, JSON data type, or semantic intent. The following is a non-normative example of a JSON Schema document for the example in vc-sd-jwt-example requiring the presence of the claim in an SD-JWT VC presentation: Note that and are always required by this specification. 6.5.2. If a or property is present, a Consumer MUST validate the JSON document resulting from the SD-JWT verification algorithm (as defined in Section 8 of I-D.ietf-oauth-selective-disclosure-jwt) against the JSON Schema document provided by the or property. If an property is present, the schema of the extended type MUST also be validated in the same manner.  This process includes validating all subsequent extended types recursively until a type is encountered that does not contain an property in its Type Metadata.  Each schema in this chain MUST be evaluated for a specific Verifiable Credential. If the schema validation fails for any of the types in the chain, the Consumer MUST reject the Verifiable Credential. The following is a non-normative example of a result JSON document after executing the SD-JWT verification algorithm that is validated against the JSON Schema document in the example provided in schema- definition: Note, the example above does not contain any , , or claims. </ins> 7. Both the <del> claim in the SD-JWT VC and various URIs in the metadata document MAY </del> <ins> claim in the SD-JWT VC and the various URIs in the Type Metadata MAY </ins> be accompanied by a respective claim suffixed with , in particular:
3.3. <del> The following is a non-normative example of an unsecured payload of an SD-JWT VC. </del> <ins> The following is a non-normative example of the user data of an unsecured payload of an SD-JWT VC. </ins> The following is a non-normative example of how the unsecured payload <del> of the SD-JWT VC above can be used in a SD-JWT where the resulting </del> <ins> of the SD-JWT VC above can be used in an SD-JWT where the resulting </ins> SD-JWT VC contains only claims about the Subject that are selectively disclosable:
The following is a non-normative example of a presentation of the SD- JWT shown in vc-sd-jwt-example including a Key Binding JWT.  In this <del> presentation, the Holder provides only the Disclosure for the </del> <ins> presentation, the Holder provides only the Disclosures for the and claims.  Other claims are not disclosed to the Verifier. After validation, the Verifier will have the following processed SD- JWT payload available for further handling: </ins> <del> claim.  Other claims are not disclosed to the Verifier. </del> <ins> The following example shows a presentation of a (similar but different) SD-JWT without a Key Binding JWT: </ins> <del> The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT: </del> <ins> The Verifier will have the following processed SD-JWT payload after validation: </ins> 5.
The following is a non-normative example of a decoded SD-JWT header: <ins> Note that this draft used as the value of the header from its inception in July 2023 until November 2024 when it was changed to to avoid conflict with the media type name registered by the W3C's Verifiable Credentials Data Model draft.  In order to facilitate a minimally disruptive transition, it is RECOMMENDED that Verifiers and Holders accept both and as the value of the header for a reasonable transitional period. </ins> 3.2.2. This section defines the claims that can be included in the payload
3.2. SD-JWT VCs MUST be encoded using the SD-JWT format defined in <del> Section 5 of I-D.ietf-oauth-selective-disclosure-jwt.  A presentation </del> <ins> Section 4 of I-D.ietf-oauth-selective-disclosure-jwt.  A presentation </ins> of an SD-JWT VC MAY contain a Key Binding JWT. Note that in some cases, an SD-JWT VC MAY have no selectively
selective-disclosure-jwt. If Key Binding is required (refer to the security considerations in <del> Section 11.6 of I-D.ietf-oauth-selective-disclosure-jwt), the Verifier MUST verify the Key Binding JWT according to Section 8 of I- D.ietf-oauth-selective-disclosure-jwt.  To verify the Key Binding JWT, the </del> <ins> Section 9.5 of I-D.ietf-oauth-selective-disclosure-jwt), the Verifier MUST verify the Key Binding JWT according to Section 7 of I-D.ietf- oauth-selective-disclosure-jwt.  To verify the Key Binding JWT, the </ins> claim of the SD-JWT MUST be used.
4.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the <del> Key Binding JWT MUST adhere to the rules defined in Section 5.3 of I- </del> <ins> Key Binding JWT MUST adhere to the rules defined in Section 4.3 of I- </ins> D.ietf-oauth-selective-disclosure-jwt. The Key Binding JWT MAY include additional claims which, when not
Type Metadata for the type can be retrieved using various mechanisms as described in retrieving- <del> type-metadata.  For this example, the well-known URL as defined in retrieval-from-vct-claim is used and the following Type Metadata Document is retrieved from the URL </del> <ins> type-metadata.  For this example, the </ins> <del> : </del> <ins> value is a URL as defined in retrieval-from-vct-claim and the following Type Metadata Document is retrieved from it: </ins> This example is shortened for presentation, a full Type Metadata example can be found in ExampleTypeMetadata.