jiebi/CodeConvo huggingface dataset:
MUST be used. <del> The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry IANA.Hash.Algorithms or a value defined in another specification and/or profile of this specification. </del> <ins> This claim value is a case-sensitive string with the hash algorithm identifier.  The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry IANA.Hash.Algorithms or a value defined in another specification and/or profile of this specification. </ins> To promote interoperability, implementations MUST support the
4.3.2. <del> The Verifier MUST ensure that the key with which it validates the signature on the Key Binding JWT is the key specified in the SD-JWT as the Holder's public key.  For example, if the SD-JWT contains a </del> <ins> Whether to require Key Binding is up to the Verifier's policy, based on the set of trust requirements such as trust frameworks it belongs to.  See key_binding_security for security considerations. If the Verifier requires Key Binding, the Verifier MUST ensure that the key with which it validates the signature on the Key Binding JWT is the key specified in the SD-JWT as the Holder's public key.  For example, if the SD-JWT contains a </ins> value with a member, the Verifier would parse the provided JWK and use it to verify the Key Binding JWT. <del> Whether to require Key Binding is up to the Verifier's policy, based on the set of trust requirements such as trust frameworks it belongs to.  See key_binding_security for security considerations. </del> <ins> Details of the Validation process are defined in verifier_verification. </ins> 5.
Holder about having received a complete set of Disclosures.  That is, for some digest values in the Issuer-signed JWT (which are not decoy digests) there may be no corresponding Disclosures, for example, if <del> the message from the Issuer was truncated. It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the End-User when needed. </del> <ins> the message from the Issuer was truncated.  It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the user when needed. </ins> 7.2.
implicitly pressure Verifiers into collusion by incentivizing participation in their larger ecosystem.  Deployers of SD-JWT must be aware of these potential power dynamics, mitigate them as much as <del> possible, and/or make the risks transparent to the End-User. </del> <ins> possible, and/or make the risks transparent to the user. </ins> Contrary to that, Issuer/Verifier unlinkability with an honest Verifier can generally be achieved.  However, a callback from the
10.2. <del> Wherever End-User data is stored, it represents a potential target for an attacker.  This target can be of particularly high value when the data is signed by a trusted authority like an official national </del> <ins> Wherever user data is stored, it represents a potential target for an attacker.  This target can be of particularly high value when the data is signed by a trusted authority like an official national </ins> identity service.  For example, in OpenID Connect OpenID.Core, signed ID Tokens can be stored by Relying Parties.  In the case of SD-JWT, Holders have to store SD-JWTs, and Issuers and Verifiers may decide to do so as well. Not surprisingly, a leak of such data risks revealing private data of <del> End-Users to third parties.  Signed End-User data, the authenticity of which can be easily verified by third parties, further exacerbates the risk.  As discussed in key_binding_security, leaked SD-JWTs may also allow attackers to impersonate Holders unless Key Binding is enforced and the attacker does not have access to the Holder's cryptographic keys.  Altogether, leaked SD-JWT credentials may have a high monetary value on black markets. </del> <ins> users to third parties.  Signed user data, the authenticity of which can be easily verified by third parties, further exacerbates the risk.  As discussed in key_binding_security, leaked SD-JWTs may also allow attackers to impersonate Holders unless Key Binding is enforced and the attacker does not have access to the Holder's cryptographic keys. </ins> Due to these risks, systems implementing SD-JWT SHOULD be designed to minimize the amount of data that is stored.  All involved parties
Holders SHOULD store SD-JWTs only in encrypted form, and, wherever possible, use hardware-backed encryption in particular for the private Key Binding key.  Decentralized storage of data, e.g., on <del> End-User devices, SHOULD be preferred for End-User credentials over </del> <ins> user devices, SHOULD be preferred for user credentials over </ins> centralized storage.  Expired SD-JWTs SHOULD be deleted as soon as possible. After Verification, Verifiers SHOULD NOT store the Issuer-signed JWT or the respective Disclosures if they contain privacy-sensitive data. It may be sufficient to store the result of the verification and any <del> End-User data that is needed for the application. </del> <ins> user data that is needed for the application. </ins> 10.3. If the SD-JWT is transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the <del> End-User's personal data or correlate the information with previous uses of the same SD-JWT. </del> <ins> user's personal data or correlate the information with previous uses of the same SD-JWT. </ins> Usually, transport protocols for issuance and presentation of credentials are designed to protect the confidentiality of the
any encryption mechanism. Implementers MUST ensure that the transport protocol provides <del> confidentiality if the privacy of End-User data or correlation attacks by passive observers are a concern. </del> <ins> confidentiality if the privacy of user data or correlation attacks by passive observers are a concern. </ins> To encrypt the SD-JWT when transmitted over an insecure channel, implementers MAY use JSON Web Encryption (JWE) RFC7516 by nesting the
the existence of particular claims) can be a side-channel disclosing information about otherwise undisclosed claims.  In particular, if a claim in an SD-JWT is present only if a certain condition is met <del> (e.g., a membership number is only contained if the End-User is a member of a group), the Issuer SHOULD add decoy digests when the condition is not met. </del> <ins> (e.g., a membership number is only contained if the user is a member of a group), the Issuer SHOULD add decoy digests when the condition is not met. </ins> Decoy digests increase the size of the SD-JWT.  The number of decoy digests (or whether to use them at all) is a trade-off between the <del> size of the SD-JWT and the privacy of the End-User's data. </del> <ins> size of the SD-JWT and the privacy of the user's data. </ins> 10.5.
case, the mechanisms defined in this document can be used for many other use cases as well. <del> Note: so far agreed to define holder binding (user's public key contained inside an SD-JWT) as an option.  It is not mandatory since holder binding is use case specific and orthogonal to the general mechanism of selective disclosure defined here. </del> <ins> This document also describes holder binding, or the concept of binding SD-JWT to a key material controlled by the subject of SD-JWT, which is optional to implement. </ins> 1.1.
4.3. <ins> Some use-cases MAY require holder binding. Information about the key material controlled by the holder MUST be communicated in SD-JWT.  How the public key is included in SD-JWT is out of scope of this document.  It can be passed by value or by reference.  Examples in this document use Claim to include raw public key by value in SD-JWT. Holder MUST sign SD-JWT-R using the private key associated with the public key included in SD-JWT. Verifier MUST verify that the signature on SD-JWT-R using the public key information in SD-JWT. 4.4. </ins> A verifier checks that The detailed algorithm is described below.
1. <del> The JSON-based content of signed JSON Web Token documents as defined in RFC7515 is secured against modification using digital signatures. A consumer of a JWT document that has checked the document's signature can safely assume that the contents of the document have not been modified.  However, anyone receiving a JWT can read all contents of the document. </del> <ins> The JSON-based claims in a signed JSON Web Token (JWT) RFC7519 document are secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT document that has checked the document's signature can safely assume that the contents of the document have not been modified.  However, anyone receiving an unencrypted JWT can read all of the claims and likewise, anyone with the decryption key receiving an encrypted JWT can also read all of the claims. </ins> A common use case is that the signed document represents a user's identity credential, created by an issuer.  The issuer includes the
7.3. <ins> The length of the randomly-generated portion of the salt MUST be at least 128 bits. 7.4. </ins> For the security of this scheme, the hash function is required to have the following property.  Given a claim value, a salt, and the resulting hash, it is hard to find a second salt value so that equals the hash. <del> 7.4. </del> <ins> Furthermore the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 revealed fundamental weaknesses and they MUST NOT be used. 7.5. </ins> TBD
deploying and publishing such requirements) is out of scope for this document. <del> Furthermore, this specification defines additional </del> <ins> Furthermore, this specification defines the following </ins> <del> auth-param values to convey the authentication requirements back to the client. </del> <ins> auth-param values for those OAuth authentication schemes to convey the authentication requirements back to the client. </ins> acr-challenge below is an example of a <ins> authentication scheme challenge with the </ins> header using the error code value to inform the client that the access token presented
to frequent prompts, hence a suboptimal user experience, if reused for routine operations.  In those scenarios, the client would be better served by keeping both the old tokens, associated with a lower <del> authentication level, and the new one- selecting the appropriate </del> <ins> authentication level, and the new one - selecting the appropriate </ins> token for each API call.  This is not a new requirement for clients, as incremental consent and least privilege principles will require similar heuristics for managing access tokens associated to different
impose requirements that are impossible for users to comply with, or leading to an undesirable user experience outcome.  The authentication prompts presented by the authorization server as a <del> result of the requirements propagation method described here might require the user to perform some specific actions such as using multiple devices, having access to devices complying with specific security requirements, and so on.  Those extra requirements, concerning more about how to comply with a particular requirement rather than indicating the identifier of the requirement itself, are out of scope for this specification. </del> <ins> result of the method of propagating authentication requirements described here might require the user to perform some specific actions such as using multiple devices, having access to devices complying with specific security requirements, and so on.  Those extra requirements, concerning more about how to comply with a particular requirement rather than indicating the identifier of the requirement itself, are out of scope for this specification. </ins> 9.
attacks.  Implementers should use care in determining what to disclose in the challenge and in what circumstances.  The logic examining the incoming access token to determine whether a challenge <del> should be returned can execute either before or after the traditional token validation logic, be it based on JWT token validation, introspection, or any other method.  The resource server MAY return a challenge without verifying the client presented a valid token. However, this approach will leak the required properties of an authorization token to an actor who has not proven they can obtain a token for this resource server. </del> <ins> should be returned can execute either before or after the conventional token validation logic, be it based on JWT token validation, introspection, or any other method.  The resource server MAY return a challenge without verifying the client presented a valid token.  However, this approach will leak the required properties of an authorization token to an actor who has not proven they can obtain a token for this resource server. </ins> As this specification provides a mechanism for the resource server to trigger user interaction, it's important for the authorization server
To request a replacement Txn-Token, the requester makes a Txn-Token Request as described in txn-token-request but includes the Txn-Token <del> to be replaced as the value of the "subject_token" parameter. </del> <ins> to be replaced as the value of the "subject_token" parameter.  The "scope" value in the replacement request, if different from that in the original Txn-Token, MUST NOT increase the authorization surface beyond that of the original Txn-Token. </ins> 7.5.3.
specification RFC8693 are also not used in Txn-Token responses.  The "expires_in" is not required since the issued token has an "exp" field, which indicates the token lifetime.  The "scope" field is <del> omitted from the request and therefore omitted in the response. </del> <ins> omitted from the response in favor of the "purp" claim in the Txn- Token. </ins> 9.2.
request.  The "actor_token" MUST authenticate the identity of the requesting workload. <ins> 9.4. Validation of a replacement Txn-Token, as well as any Txn-Token, is critical to the security of the entire transaction invocation sequence.  Only Txn-Tokens issued by a trusted Transaction Token Service may be trusted, so verification of the Txn-Token signature is required.  For replacement transaction tokens, not only must the JWT signature be verified but also the workload identity of the workload requesting the replacement Txn-Token. 9.5. The authorization model within a trust domain boundary is most often quite different from the authorization model (e.g.  OAuth scopes) used with client external to the trust domain.  This makes managing unintentional scope increase a critical aspect of the Transaction Token Service.  The TTS MUST ensure that the requested purpose ("scope") of the Txn-Token is equal or less than the scope(s) identified in the "subject_token".  This is also true of requesting a replacement Txn-Token.  The TTS MUST ensure there is not unintentional increase in authorization scope. </ins> 10. 10.1.
REQUIRED A unique transaction identifier as defined in Section 2.2 of RFC8417.  When used in the transaction token, it identifies the <del> entire call chain. </del> <ins> entire call chain.  It is strongly RECOMMENDED to provide an identifier unique within the trust domain.  If providing such an identifier is not possible, then a fixed value of "N_A" MAY be supplied. </ins> REQUIRED A unique identifier for the subject within the context of the "aud" trust domain.  Unlike OpenID Connect, the "sub" claim is
5.2.1. <ins> The "purp" claim captures the exact purpose of this particular transaction.  This is often much narrower than a scope value issued to an external client.  This is due to the fact that in most cases, the authorization model within the trust domain is quite different than the authorization model used with clients external to the trust domain.  To that end, it is intentional to separate the concept of scope (often fairly coarse-grained) used with external clients from the purpose of the transaction used within the trust domain.  How a given deployment represents the authorization model within the trust domain is out of scope for this specification. 5.2.2. </ins> The Txn-Token SHOULD contain an "rctx" claim.  This MAY include the IP address information of the originating user, as well as information about the computational entity that requested the Txn-
relating to the transaction being performed.  Most of these elements are provided by the OAuth 2.0 Token Exchange specification and the rest are defined as new parameters.  Additionally, this profile <del> defines a new token type URN "urn:ietf:params:oauth:token-type:txn- token" which is used by the requesting workload to identify that it is requesting the Txn-Token Response to contain a Txn-Token. </del> <ins> defines a new token type URN "urn:ietf:params:oauth:token- type:txn_token" which is used by the requesting workload to identify that it is requesting the Txn-Token Response to contain a Txn-Token. </ins> To request a Txn-Token the workload invokes the OAuth 2.0 RFC6749 token endpoint with the following parameters:
intent of the transaction. "requested_token_type" REQUIRED.  The value MUST be <del> "urn:ietf:params:oauth:token-type:txn-token" </del> <ins> "urn:ietf:params:oauth:token-type:txn_token" </ins> "subject_token" REQUIRED.  The value MUST represent the subject of the transaction.  This could be an inbound token received by an
The "access_token" value MUST be the Txn-Token JWT The "issued_token_type" value MUST bet set to <del> "urn:ietf:params:oauth:token-type:txn-token" </del> <ins> "urn:ietf:params:oauth:token-type:txn_token" </ins> The response MUST NOT include the values "expires_in", "refresh_token" and "scope"
"urn:ietf:params:oauth:token-type:txn_token" "subject_token" REQUIRED.  The value MUST represent the subject of <del> the transaction.  This could be an inbound token received by an API Gateway, or a self-signed JWT constructed by a workload initiating a transaction, the type of which is identified by </del> <ins> the transaction.  This MAY be: An inbound token received by an API Gateway A self-signed JWT constructed by a workload initiating a transaction An unsigned JSON object constructed by a workload initiating a transaction Any other format that is understood by the Txn-Token Service The type of the "subject_token" field is identified by </ins> "subject_token_type". "subject_token_type" REQUIRED.  The value MUST indicate the type
7.2. The "subject_token_type" parameter value MUST be a URI RFC3986.  It <del> MAY be any one of the subject token types described in Section 3 of OAuth 2.0 Token Exchange RFC8693 except the Refresh Token type (i.e., "urn:ietf:params:oauth:token-type:refresh_token"), or it MAY be a self-signed JWT, as described below, or it MAY be a custom URI agreed to between requesters and the Txn-Token Service. </del> <ins> MAY be: </ins> <del> The Txn-Token Service MAY support other token formats, which MAY be specified in the "subject_token_type" parameter.  Any value used in this parameter MUST be a URI as specified in RFC 8693 RFC8693. </del> <ins> Any one of the subject token types described in Section 3 of OAuth 2.0 Token Exchange RFC8693 except the Refresh Token type (i.e., "urn:ietf:params:oauth:token-type:refresh_token"). A URN type name when the subject token is a self-signed JWT, as described below. A URN type name when the subject token is an unsigned JSON object, as described below. A custom URN agreed to between requesters and the Txn-Token Service.  The Txn-Token Service MAY support other token formats, which MAY be specified in the "subject_token_type" parameter. </ins> 7.2.1.
The self-signed JWT MAY contain other claims. <ins> 7.2.2. A requester MAY use an unsigned JSON object as a "subject_token" value.  In that case, the requester MUST set the "subject_token_type" value to: "urn:ietf:params:oauth:token-type:unsigned_json".  The value of the "subject_token" field MUST be the BASE64URL encoded value of the JSON object as described in Section 5 of RFC6848.  The JSON object in the subject token MUST contain the following fields: "sub": The subject for whom the Txn-Token is being requested.  The Txn-Token Service SHALL use this value in determining the "sub" value in the Txn-Token issued in the response to this request. "exp": The expiration time of the unsigned JSON object, which the TTS MAY use as input to determining the lifetime of the Txn-token. The unsigned JSON object MAY contain other fields, and the Txn-Token Service MAY consider them when generating the Txn-Token. </ins> 7.3. When the Transaction Token Service receives a Txn-Token Request it
within the trust domain defined by the "aud" claim. The Transaction Token Service MUST set the "iat" claim to the time of <del> issuance of the Txn-Token.  The Transaction Token Service MUST set the "aud" claim to an identifier representing the Trust Domain of the Transaction Token Service.  If the Transaction Token Service supports multiple trust domains, then it MUST determine the correct "aud" value for this request.  The Transaction Token Service MUST set the "exp" claim to the expiry time of the Txn-Token.  The Transaction Token Service MUST set the "txn" claim to a unique ID specific to this transaction. </del> <ins> issuance of the Txn-Token. The Transaction Token Service MUST set the "aud" claim to an identifier representing the Trust Domain of the Transaction Token Service.  If the Transaction Token Service supports multiple trust domains, then it MUST determine the correct "aud" value for this request. The Transaction Token Service MUST set the "exp" claim to the expiry time of the Txn-Token.  The Txn-Token Service MAY consider any "exp" value present in the "subject_token" parameter of the Txn-Token Request in determining the "exp" value of the resulting Txn-Token. The Transaction Token Service MUST set the "txn" claim to a unique ID specific to this transaction. </ins> The Transaction Token Service MAY set the "iss" claim of the Txn- Token to a value defining the entity that signed the Txn-Token.  This <del> claim MUST be ommitted if not set. </del> <ins> claim MUST be omitted if not set. </ins> The Transaction Token Service MUST evaluate the value specified in the "scope" parameter of the request to determine the "purp" claim of
9.3. <ins> A service requesting a Txn-Token SHOULD provide an incoming token if it has one that it used itself to authorize a caller, and if it directly correlates with the downstream call chain it needs the Txn- Token for.  In the absence of an appropriate incoming token, the requesting service MAY use a self-signed JWT, an unsigned JSON object or any other format to represent the details of the requester to the Txn-Token service. 9.4. </ins> How requesting clients authenticate to the Transaction Token Service is out of scope for this specification.  However, if using the "actor_token" and "actor_token_type" parameters of the OAuth 2.0
URN: urn:ietf:params:oauth:token-type:txn_token <del> Common Name: Transaction Token </del> <ins> Common Name: Transaction Token </ins> <del> Change Controller: IESG </del> <ins> Change Controller: IESG </ins> <del> Specification Document Section txn-token-request of this specification </del> <ins> Specification Document Section txn-token-request of this specification </ins> URN: urn:ietf:params:oauth:token-type:self_signed <del> Common Name: Token type for Self-signed JWT </del> <ins> Common Name: Token type for Self-signed JWT Change Controller: IESG Specification Document: Section self-signed-subject-token-type of this specification URN: urn:ietf:params:oauth:token-type:unsigned_json </ins> <del> Change Controller: IESG </del> <ins> Common Name: Token type for Unsigned JSON Object Change Controller: IESG </ins> <del> Specification Document: Section subject-token-types of this specification </del> <ins> Specification Document: Section unsigned-json-subject-token- type of this specification </ins> 11.2.