jiebi/CodeConvo huggingface dataset:
. 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
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.
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.
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:
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.
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
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.
7. <del> TBD: Holder provided nonce via </del> <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. </ins> <del> . </del> <ins> 7.1. The Privacy Considerations in Section 10.5 of I-D.ietf-oauth- selective-disclosure-jwt apply especially to the claim. 7.2. Issuers and Holders have to be aware that while this specification supports selective disclosure of claims of a given SD-JWT VC, the claim is not selectively disclosable.  In certain situations this could lead to unwanted leakage of additional context information. In general, Issuers are advised to choose values following data minimization principles.  For example, government Issuers issuing an SD-JWT VC to their citizens to enable them to prove their age, have to avoid putting information into the value that allows third-parties to infer additional personal information about the Holder, e.g., country of residency, citizenship etc.  A better approach is to have more generalized types, for example an age-proof SD-JWT VC type. Additionally, Holders have to be informed that besides the actual requested claims what information is shared with the Verifier. 7.3. A malicious Issuer can choose the Issuer identifier of the SD-JWT VC to enable tracking the usage behavior of the Holder if the Issuer identifier is Holder-specific and if the resolution of the key material to verify the Issuer-signed JWT requires the Verifier to phone home to the Issuer. For example, a malicious Issuer could generate a unique value for the Issuer identifier per Holder, e.g., and host the JWT Issuer Metadata.  The Verifier would create a HTTPS GET request to the Holder-specific well-known URI when the SD-JWT VC is verified.  This would allow the malicious Issuer to keep track where and how oftehn the SD-JWT VC was used. Verifiers are advised to establish trust in an SD-JWT VC by pining specific Issuer identifiers and should monitor suspicious behaviour such as frequently rotating Issuer identifiers.  If such behaviour was detected, Verifiers are advised to reject SD-JWT VCs issued by such Issuers. Holders are advised to reject SD-JWT VCs if they contain easiliy correlateable information in the Issuer identifier. </ins> 8.
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.
A verifier MUST validate an SD-JWT-VC as follows: <del> Additional validation rules MAY apply but their use is out-of-scope of this specification. </del> <ins> Additional validation rules MAY apply, but their use is out of the scope of this specification. </ins> 6.1. <del> Verifiers processing SD-JWT-VCs MUST verify the signature of the SD- JWT with the public key of the SD-JWT-VC issuer.  This makes sure that the SD-JWT-VC was issued by the SD-JWT-VC issuer and that it has not been tampered with since issuance. The claim in the SD-JWT-VC MAY be used to retrieve the public key from the JWT Issuer Metadata configuration (as defined in {#jwt-issuer- metadata}) of the SD-JWT-VC issuer.  A verifier MAY use alternative methods to obtain the public key to verify the signature of the SD- JWT. 6.2. </del> This specification defines the JWT Issuer Metadata to retrieve the JWT Issuer Metadata configuration of the JWT Issuer of the JWT.  The JWT Issuer is identified by the
The JWT Issuer Metadata configuration MUST be a JSON document compliant with this specification and MUST be returned using the <del> application/json content type. </del> <ins> content type. </ins> This specification defines the following JWT Issuer Metadata parameters: <ins> JWT Issuer Metadata MUST include either or in their JWT Issuer Metadata, but not both. </ins> It is RECOMMENDED that the JWT contains a JWT header parameter that can be used to lookup the public key in the
value MUST be a case-sensitive (see RFC7519) value serving as an identifier for the type of the SD- <del> JWT VC.  A type defines which claims may or must appear in the Unsecured Payload of the SD-JWT VC and whether they may, must, or must not be selectively disclosable.  This specification does not define any </del> <ins> JWT VC.  The value MUST be a Collision-Resistant Name as defined in Section 2 of RFC7515. A type is associated with rules defining which claims may or must appear in the Unsecured Payload of the SD-JWT VC and whether they may, must, or must not be selectively disclosable.  This specification does not define any </ins> values; instead it is expected that ecosystems using SD-JWT VCs define such values including the semantics of the respective claims
5.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the <del> following claims are used within the Key Binding JWT: </del> <ins> Key Binding JWT MUST adhere to the rules defined in Section 5.10 of I-D.ietf-oauth-selective-disclosure-jwt. </ins> <del> The Key Binding JWT MAY include addtional claims which when not understood MUST be ignored. </del> <ins> The Key Binding JWT MAY include addtional claims which, when not understood, MUST be ignored by the Verifier. </ins> 5.2.
claim of the SD-JWT MUST be used. <del> For the verification, the claim in the SD-JWT MAY be used to retrieve the public key from the JWT Issuer Metadata configuration (as defined in jwt-issuer-metadata) of the SD-JWT VC issuer.  Alternative methods MAY be used to obtain the public key to verify the signature of the SD-JWT. </del> <ins> Furthermore, the recipient of the SD-JWT VC MUST verify that the public key used for verification of the Issuer-signed JWT belongs to the Issuer of the Issuer-signed JWT, as defined in public-key-for- issuer-signed-jwts-verification. </ins> If there are no selectively disclosable claims, there is no need to process the
Additional validation rules MAY apply, but their use is out of the scope of this specification. <ins> 3.5. A recipient of the SD-JWT VC MUST apply the following rules to verify the Issuer-signed JWT corresponds to the Issuer: - JWT Issuer Metadata: If the value contains a HTTPS URI, the recipient MUST obtain the public key using JWT Issuer Metadata as defined in jwt-issuer-metadata.  - DID Document Resolution: If the value contains a DID, the recipient MUST retrieve the public key from the DID Document resolved from the DID in the value.  If the JWT header parameter is present, the MUST be a relative or absolute DID URL of the DID in the value, identifying the public key.  - X.509 Certificates: The recipient MUST obtain the public key from the leaf X.509 certificate defined by the , , or JWT header parameters of the Issuer-signed JWT and validate the X.509 certificate chain in the following cases: - If the value contains a DNS name encoded as a URI using the DNS URI scheme RFC4501.  The DNS name MUST matche a Subject Alternative Name (SAN) RFC5280 entry of the leaf certificate. - If the value contains a URN using the URN URI scheme RFC2141.  The URN MUST match a SAN entry of the leaf certificate. Additional rules for verifying the public key belongs to the Issuer MAY be used but are out of scope of this specification. </ins> 4. This specification defines the JWT Issuer Metadata to retrieve the
Additional considerations can be found in OWASP_SSRF. <ins> 6.2. When defining ecosystem-specific rules for the verification of the public key, as outlined in verifying-public-key-for-issuer-signed- jwts, it is critical that those rules maintain the integrity of the relationship between the value within the Issuer-signed JWT and the public keys of the Issuer. In situations where an attacker tampers with an SD-JWT VC, it is paramount to ensure that they cannot exert influence over the verification process while employing the same value. </ins> 7. The Privacy Considerations in the SD-JWT specification I-D.ietf-
claim of the SD-JWT MUST be used. <del> Furthermore, the recipient of the SD-JWT VC MUST obtain the public verification key for the Issuer-signed JWT as defined in public-key- discovery-for-issuer-signed-jwts. </del> <ins> Furthermore, the recipient of the SD-JWT VC MUST validate that the public verification key for the Issuer-signed JWT as defined in issuer-signed-jwt-verification-key-validation. </ins> If there are no selectively disclosable claims, there is no need to process the
6.2. When defining ecosystem-specific rules for the verification of the <del> public key, as outlined in public-key-discovery-for-issuer-signed- jwts, it is critical that those rules maintain the integrity of the relationship between the </del> <ins> public key, as outlined in issuer-signed-jwt-verification-key- validation, it is critical that those rules maintain the integrity of the relationship between the </ins> value within the Issuer-signed JWT and the public keys of the Issuer.
4. <del> This specification defines the JWT Issuer Metadata to retrieve the JWT Issuer Metadata configuration of the JWT Issuer of the JWT.  The JWT Issuer is identified by the </del> <ins> This section defines encoding, validation and processing rules for presentations of SD-JWT VCs. 4.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the Key Binding JWT MUST adhere to the rules defined in Section 5.3 of I- D.ietf-oauth-selective-disclosure-jwt. </ins> <del> claim in the JWT.  Use of the JWT Issuer Metadata is OPTIONAL. </del> <ins> The Key Binding JWT MAY include addtional claims which, when not understood, MUST be ignored by the Verifier. 4.2. The following is a non-normative example of a presentation of the SD- JWT shown above including a Key Binding JWT: </ins> <del> JWT Issuers publishing JWT Issuer Metadata MUST make a JWT Issuer </del> <ins> In this presentation, the Holder provides only the Disclosure for the claim . Other claims are not disclosed to the Verifier. The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT: 5. This specification defines the JWT VC Issuer Metadata to retrieve the JWT VC Issuer Metadata configuration of the Issuer of the SD-JWT VC. The Issuer is identified by the 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 </ins> Metadata configuration available at the path formed by concatenating the string
scheme, host and, optionally, port number and path components, but no query or fragment components. <del> 4.1. </del> <ins> 5.1. </ins> <del> A JWT Issuer Metadata configuration MUST be queried using an HTTP </del> <ins> A JWT VC Issuer Metadata configuration MUST be queried using an HTTP </ins> <del> request at the path defined in jwt-issuer-metadata. </del> <ins> request at the path defined in jwt-vc-issuer-metadata. </ins> The following is a non-normative example of a HTTP request for the <del> JWT Issuer Metadata configuration when </del> <ins> JWT VC Issuer Metadata configuration when </ins> is set to
component. The following is a non-normative example of a HTTP request for the <del> JWT Issuer Metadata configuration when </del> <ins> JWT VC Issuer Metadata configuration when </ins> is set to : <del> 4.2. </del> <ins> 5.2. </ins> A successful response MUST use the <del> and return the JWT Issuer Metadata configuration using the </del> <ins> and return the JWT VC Issuer Metadata configuration using the </ins> content type. An error response uses the applicable HTTP status code value. <del> This specification defines the following JWT Issuer Metadata </del> <ins> This specification defines the following JWT VC Issuer Metadata </ins> configuration parameters: <del> JWT Issuer Metadata MUST include either </del> <ins> JWT VC Issuer Metadata MUST include either </ins> or <del> in their JWT Issuer Metadata, but not both. </del> <ins> in their JWT VC Issuer Metadata, but not both. </ins> It is RECOMMENDED that the JWT contains a JWT header parameter that can be used to lookup the public key in the <del> JWK Set included by value or referenced in the JWT Issuer Metadata. </del> <ins> JWK Set included by value or referenced in the JWT VC Issuer Metadata. </ins> <del> The following is a non-normative example of a JWT Issuer Metadata </del> <ins> The following is a non-normative example of a JWT VC Issuer Metadata </ins> configuration including : <del> The following is a non-normative example of a JWT Issuer Metadata </del> <ins> The following is a non-normative example of a JWT VC Issuer Metadata </ins> configuration including : <del> Additional JWT Issuer Metadata configuration parameters MAY also be used. </del> <ins> Additional JWT VC Issuer Metadata configuration parameters MAY also be used. </ins> <del> 4.3. </del> <ins> 5.3. </ins> The
value of the JWT.  If these values are not identical, the data contained in the response MUST NOT be used. <del> 5. This section defines encoding, validation and processing rules for presentations of SD-JWT VCs. 5.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the Key Binding JWT MUST adhere to the rules defined in Section 5.3 of I- D.ietf-oauth-selective-disclosure-jwt. The Key Binding JWT MAY include addtional claims which, when not understood, MUST be ignored by the Verifier. 5.2. The following is a non-normative example of a presentation of the SD- JWT shown above including a Key Binding JWT: In this presentation, the Holder provides only the Disclosure for the claim . Other claims are not disclosed to the Verifier. The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT: </del> 6. The Security Considerations in the SD-JWT specification I-D.ietf-
6.1. <del> The JWT Issuer Metadata configuration is retrieved from the JWT </del> <ins> The JWT VC Issuer Metadata configuration is retrieved from the JWT VC </ins> 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. <del> Before making a request to the JWT Issuer Metadata endpoint, the </del> <ins> Before making a request to the JWT VC Issuer Metadata endpoint, the </ins> 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
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 <del> that the response is a valid JWT Issuer Metadata configuration </del> <ins> that the response is a valid JWT VC Issuer Metadata configuration </ins> document before processing it. Additional considerations can be found in OWASP_SSRF.
For example, a malicious Issuer could generate a unique value for the Issuer identifier per Holder, e.g., <del> and host the JWT Issuer Metadata.  The Verifier would create a HTTPS GET request to the Holder-specific well-known URI when the SD-JWT VC is verified.  This would allow the malicious Issuer to keep track where and how often the SD-JWT VC was used. </del> <ins> and host the JWT VC Issuer Metadata.  The Verifier would create a HTTPS GET request to the Holder-specific well-known URI when the SD- JWT VC is verified.  This would allow the malicious Issuer to keep track where and how often the SD-JWT VC was used. </ins> Verifiers are advised to establish trust in an SD-JWT VC by pinning specific Issuer identifiers and should monitor suspicious behaviour