jiebi/CodeConvo huggingface dataset:
REQUIRED Expiry time of the Txn-Token as defined in REQUIRED A unique transaction identifier as defined in Section 2.2 <del> of RFC8417.  When used in the transaction token, it identifies the 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. </del> <ins> of RFC8417. </ins> REQUIRED A unique identifier for the subject within the context of the "aud" trust domain.  Unlike OpenID Connect, the "sub" claim is
replacement Txn-Token.  The TTS MUST ensure there is not unintentional increase in authorization scope. <ins> 9.7. A Txn-token typically represents the call-chain of workloads necessary to complete a logical function initiated by an external or internal workload.  The "txn" claim in the Txn-token provides a unique identifier that when logged by the TTS and each subsequent workload can provide both discovery and auditability of successful and failed transactions.  It is therefore strongly RECOMMENDED to use an identifier, unique within the trust domain, for the "txn" value. </ins> 10. 10.1.
10.2. <del> Txn-Tokens SHOULD NOT be logged if they contain Personally Identifiable Information (PII).  What constitutes PII depends upon the use case, but in some cases even an email address (which could be a "sub" value) can be protected PII, which should not be logged. </del> <ins> Complete Txn-Tokens must not be logged verbatim.  This is in order to prevent replay of tokens or leakage of PII or other sensitive information via log files.  A hash of the Txn-Token may be logged to allow for correlation with the log files of the Txn-Token Service that records issued tokens.  Alternatively the JWS payload of a Txn- Token may be logged after the signature has been removed.  If the Txn-Token contains PII, then care should be taken in logging the content of the Txn-Token so that the PII does not get logged. </ins> 11.
microservices, monolithic services and infrastructure services such as managed databases. <del> A virtually or physically separated network, which contains two or more workloads.  The workloads within a Trust Domain may be invoked only through published interfaces. </del> <ins> A collection of systems, applications, or workloads that share a common security policy.  In practice this may include a virtually or physically separated network, which contains two or more workloads.  The workloads within a Trust Domain may be invoked only through published interfaces. </ins> A published interface to a Trust Domain that results in the invocation of a workload within the Trust Domain.
A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response.  If the Transaction Token Service responds with an error, the error response is as described in <del> Section 5.2 of RFC6749.  The following describes required values of a Txn-Token Response: </del> <ins> Section 5.2 of RFC6749.  The following values defined in RFC8693 MUST be included in the Txn-Token Response: </ins> The "token_type" value MUST be set to "N_A" per guidance in OAuth 2.0 Token Exchange
The "issued_token_type" value MUST bet set to "urn:ietf:params:oauth:token-type:txn_token" <del> The response MUST NOT include the values "expires_in", "refresh_token" and "scope" </del> <ins> The Txn-Token Response MUST NOT include the values "expires_in", "refresh_token" and "scope" </ins> figtxtokenresponse shows a non-normative example of a Txn-Token Response.
an OAuth 2.0 Token Exchange RFC8693 to obtain a Txn-Token.  To do this, it invokes a special Token Service (the Txn-Token Service) and provides context that is sufficient for it to generate a Txn-Token. <del> This context MAY include: </del> <ins> The context information provided to the Txn-Token Service MAY include: </ins> The external authorization token (e.g., the OAuth access token)
token endpoint with the following parameters: "grant_type" REQUIRED.  The value MUST be set to <del> "urn:ietf:params:oauth:grant-type:token-exchange" </del> <ins> "urn:ietf:params:oauth:grant-type:token-exchange". </ins> <del> "audience" REQUIRED.  The value MUST be set to the Trust Domain name </del> <ins> "audience" REQUIRED.  The value MUST be set to the trust domain name. </ins> "scope" REQUIRED.  A space-delimited list of case-sensitive strings where the value(s) MUST represent the specific purpose or
7.6. <ins> A workload and Transaction Token Service MUST perform mutual authentication. </ins> A Txn-Token Service MUST ensure that it authenticates any workloads requesting Txn-Tokens.  In order to do so: <del> It MUST name a limited, pre-configured set of workloads that MAY request Txn-Tokens </del> <ins> It MUST maintain a limited, pre-configured set of authorized workloads that MAY request Txn-Tokens. It MUST authenticate the requesting workload and confirm that it is included in the list of workloads authorized to request a transaction token. </ins> <del> It MUST individually authenticate the requester as being one of the named requesters </del> <ins> It SHOULD accept workload credentials such as JWTs or X.509 certificates which MAY be provisiond using mechanisms such as SPIFFE or other provisioning protocols. </ins> <del> It SHOULD rely on mechanisms, such as SPIFFE used in conjunction with MTLS RFC8446, or some other means of performing MTLS, to securely authenticate the requester </del> <ins> It SHOULD use X.509 credentials in conjunction with MTLS RFC8446, or a JWT protected by TLS at the transport layer, to securely authenticate the requesting workload. </ins> It SHOULD NOT rely on insecure mechanisms, such as long-lived <del> shared secrets to authenticate the requesters </del> <ins> shared secrets to authenticate the requesting workloads. The requesting workload MUST ensure that it authenticates the Transaction Token Service.  In order to do so: It MUST have a pre-configured location for the Transaction Token Service. </ins> <del> The requesting workload MUST have a pre-configured location for the Transaction Token Service.  It SHOULD rely on mechanisms, such as SPIFFE, to securely authenticate the Transaction Token Service before making a Txn-Token Request. </del> <ins> It SHOULD accept Transaction Token Service credentials such as JWTs or X.509 certificates which MAY be provisiond using mechanisms such as SPIFFE or other provisioning protocols. It SHOULD use X.509 credentials in conjunction with MTLS RFC8446, or a JWT protected by TLS at the transport layer, to securely authenticate the Transaction Token Service. It SHOULD NOT rely on insecure mechanisms, such as long-lived shared secrets to authenticate the Transaction Token Service. </ins> 8.
9.4. <del> 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 Token Exchange specification, both parameters MUST be present in the request.  The "actor_token" MUST authenticate the identity of the requesting workload. </del> <ins> If using the "actor_token" and "actor_token_type" parameters of the OAuth 2.0 Token Exchange specification, both parameters MUST be present in the request.  The "actor_token" MUST authenticate the identity of the requesting workload. </ins> 9.5.
and failed transactions.  It is therefore strongly RECOMMENDED to use an identifier, unique within the trust domain, for the "txn" value. <ins> 9.8. A workload may be configured to access more than one instance of a Transaction Token Service to ensure redundency or reduce latency for transaction token requests.  The workload configuration should be protected against unauthorized addition or removal of Transaction Token Service instances.  An attacker may perform a denial of service attack or degrade the performance of a system by removing an instance of a Transaction Token Service from the workload configuration. 9.9. A workload may accidently send a transaction token request to a service that is not a Transaction Token Service, or an attacker may attempt to impersonate a Transaction Token Service in order to gain access to transaction token requests which includes senstive information like access tokens.  To minimise the risk of leaking sensitive information like access tokens that are included in the transacation token request, the workload must ensure that it authenticates the Transaction Token Service and only contact instances of the Transaction Token Service that is authorized to issue transaction tokens. </ins> 10. 10.1.
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.  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. </del> <ins> to be replaced as the value of the "subject_token" parameter and sets the "subject_token_type" parameter to the value "urn:ietf:params:oauth:token-type:txn_token".  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.
The following entry will be proposed using the IANA Media Type registration IANA.MediaTypes form. <del> Applicant Name: Atul Tulshibagwale </del> <ins> Type Name: application </ins> <del> Applicant Email: atul@sgnl.ai </del> <ins> Subtype Name: txntoken+jwt </ins> <del> Type Name: "application (RFC 2046)" </del> <ins> Change Controller: IETF </ins> <del> Subtype Name: "txntoken+jwt" </del> <ins> Required Parameters: N/A. </ins> <del> Required Parameters: "N/A." Optional Parameters: "N/A." </del> <ins> Optional Parameters: N/A. </ins> Encoding Considerations: 7-bit text
The following additional parameter MUST be present in a Txn-Token Request: <del> A parameter named "azc" , whose value is a JSON object.  This object contains any information the Transaction Token Service needs to understand the context of the incoming request. </del> <ins> A parameter named "rctx" , whose value is a JSON object.  This object contains the request context, i.e. any information the Transaction Token Service needs to understand the context of the incoming request. </ins> figtxtokenrequest shows a non-normative example of a Txn-Token Request.
9. <del> This memo includes no request to IANA. </del> <ins> This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in RFC6749, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in 9.1. Name: "txn_token" Description: JWT of type Transaction Token Additional Token Endpoint Response Parameters: none HTTP Authentication Schemes: TLS Change Controller: IESG Specification Document: Section txn-token-header of this specificaiton 9.2. Claim Name: "azc" Claim Description: The authorization context Change Controller: IESG Specification Document: Section txn-token-claims of this specification </ins> 10.
An "exp" claim, whose value is the time at which the Txn-Token expires. <del> A "txn" claim, whose value is the unique identifier of entire call chain. </del> <ins> A "txn" claim, whose value is the unique transaction identifier as defined in Section 2.2 of RFC8417.  When used in the transaction token, it identifies the entire call chain. </ins> A "sub_id" claim, whose value is the unique identifier of the user or workload on whose behalf the call chain is being executed.  The
Txn-Tokens are expected to be short-lived (order of minutes, e.g., 5 minutes), and as a result MAY be used only for the expected duration <del> of an external invocation.  If a long-running process such as an batch or offline task is involved, it can use a separate mechanism to perform the external invocation, but the resulting Txn-Token is still short-lived. </del> <ins> of an external invocation.  If the token or other credential presented to the Txn-Token service when requesting a Txn-Token has an expiration time, then the Txn-Token MUST NOT exceed the lifetime of the originally presented token or credential.  If a long-running process such as an batch or offline task is involved, it can use a separate mechanism to perform the external invocation, but the resulting Txn-Token is still short-lived. </ins> 2.4.
Because Txn-Tokens are short-lived, the Txn-Token response from the Txn-Token service does not contain the "refresh_token" field.  A Txn- <del> Token is also cannot be issued by presenting a "refresh_token". </del> <ins> Token cannot be issued by presenting a "refresh_token". </ins> The "expires_in" and "scope" fields of the OAuth 2.0 Token Exchange specification RFC8693 are also not used in Txn-Token responses.  The
format of this claim MAY be a Subject Identifier as specified in SubjectIdentifiers. <del> An "azc" claim, whose value is a JSON object that contains values </del> <ins> An "azd" claim, whose value is a JSON object that contains values </ins> that remain constant in the call chain. <del> figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token: </del> <ins> 5.2.2. The JWT body MAY have the following claims: 5.2.2.1. The Txn-Token MAY contain an "req_ctx" claim, whose value is a JSON object the describes the requester context of the transaction.  This MAY include the IP address information of the originating user, as well as information about the computational entity that requested the Txn-Token. The JSON value of the "req_ctx" claim MAY include any values the Txn- Token Service determines are interesting to downstream services that rely on the Txn-Token.  The following claims are defined so that if they are included, they have the following meaning: * "req_ip" The IP address of the requester.  This MAY be the end-user or a robotic process that requested the Transaction * "authn" The authentication method used to idenitfy the requester.  Its value is a URN that uniquely identifies the method used.  * "req_wl" The requesting workload.  A URN that uniquely identifies the computational entity that requested the Txn-Token.  This entity MUST be within the Trust Domain of the Txn-Token. 5.2.2.2. The Txn-Token MAY contain a "purp" claim, whose value specifies the purpose of the transaction.  The format of this claim is a JSON string. 5.2.3. The figure below figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token: </ins> 6.
Workloads MAY request replacement Txn-Tokens in order to change (add to, remove or modify) the asserted values within a Txn-Token. <ins> The value of the "aud" claim MUST remain unchanged in a replacement Txn-Token.  If the claim "req_ctx" is present in the original Txn- Token, then it MUST be present unchanged in the replacement Txn- Token. </ins> 7.3.1. A Txn-Token Service replacing a Txn-Token must consider that
8.2. <del> Claim Name: "azc" </del> <ins> Claim Name: "azd" </ins> <del> Claim Description: The authorization context </del> <ins> Claim Description: The authorization context details </ins> Change Controller: IESG Specification Document: Section txn-token-claims of this specification <ins> Claim Name: "req_ctx" Claim Description: The requester context Change Controller: IESG Specification Document: Section requester-context of this specification Claim Name: "purp" Claim Description: The purpose of the transaction Change Controller: IESG Specification Document: Section purpose of this specification </ins> 9. 9.1.
8. <ins> 8.1. A Txn-Token is not resistant to replay attacks.  A long-lived Txn- Token therefore represents a risk if it is stored in a file, discovered by an attacker, and then replayed.  For this reason, a Txn-Token lifetime must be kept short, not exceeding the lifetime of a call-chain.  Even for long-running "batch" jobs, a longer lived access token should be used to initiate the request to the batch endpoint.  It then obtains short-lived Txn-Tokens that may be used to authorize the call to downstream services in the call-chain. Because Txn-Tokens are short-lived, the Txn-Token response from the Txn-Token service does not contain the "refresh_token" field.  A Txn- Token cannot be issued by presenting a "refresh_token". The "expires_in" and "scope" fields of the OAuth 2.0 Token Exchange 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 omitted from the request and therefore omitted in the response. 8.2. Although Txn-Tokens are short-lived, they MAY be sender constrained as an additional layer of defence to prevent them from being re-used by a compromised or malicious workload under the control of a hostile actor. 8.3. When creating Txn-Tokens, the Txn-Token MUST NOT contain the Access Token presented to the external endpoint.  If an Access Token is included in a Txn-Token, an attacker may extract the Access Token from the Txn-Token, and replay it to any Resource Server that can accept that Access Token.  Txn-Token expiry does not protect against this attack since the Access Token may remain valid even after the Txn-Token has expired. 9. 9.1. Some "req_ctx" claims may be considered personal information in some jurisdictions and if so their values need to be obsfucated.  For example, originating IP address ("req_ip") is often considerd personal information and in that case must be protected through some obsfucation method (e.g.  SHA256). 10. </ins> This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in RFC6749, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in <del> 8.1. </del> <ins> 10.1. </ins> Name: "txn_token"
Change Controller: IESG Specification Document: Section purpose of this specification <del> 9. 9.1. A Txn-Token is not resistant to replay attacks.  A long-lived Txn- Token therefore represents a risk if it is stored in a file, discovered by an attacker, and then replayed.  For this reason, a Txn-Token lifetime must be kept short, not exceeding the lifetime of a call-chain.  Even for long-running "batch" jobs, a longer lived access token should be used to initiate the request to the batch endpoint.  It then obtains short-lived Txn-Tokens that may be used to authorize the call to downstream services in the call-chain. Because Txn-Tokens are short-lived, the Txn-Token response from the Txn-Token service does not contain the "refresh_token" field.  A Txn- Token cannot be issued by presenting a "refresh_token". The "expires_in" and "scope" fields of the OAuth 2.0 Token Exchange 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 omitted from the request and therefore omitted in the response. 9.2. Although Txn-Tokens are short-lived, they MAY be sender constrained as an additional layer of defence to prevent them from being re-used by a compromised or malicious workload under the control of a hostile actor. 9.3. When creating Txn-Tokens, the Txn-Token MUST NOT contain the Access Token presented to the external endpoint.  If an Access Token is included in a Txn-Token, an attacker may extract the Access Token from the Txn-Token, and replay it to any Resource Server that can accept that Access Token.  Txn-Token expiry does not protect against this attack since the Access Token may remain valid even after the Txn-Token has expired. </del>
to, remove or modify) the asserted values within a Txn-Token. The value of the "aud" claim MUST remain unchanged in a replacement <del> Txn-Token.  If the claim "req_ctx" is present in the original Txn- Token, then it MUST be present unchanged in the replacement Txn- Token. </del> <ins> Txn-Token.  If the claim "rctx" is present in the original Txn-Token, then it MUST be present unchanged in the replacement Txn-Token. </ins> <del> 7.3.1. </del> <ins> 7.4.1. </ins> A Txn-Token Service replacing a Txn-Token must consider that modifying previously asserted values from existing Txn-Tokens can
SHOULD NOT enable modification to asserted values that expand the scope of permitted actions <del> 7.3.2. </del> <ins> 7.4.2. </ins> To request a replacement Txn-Token, the requester makes a Txn-Token Request as described in txn-token-request but includes the Txn-Token to be replaced as the value of the "subject_token" parameter. <del> 7.3.3. </del> <ins> 7.4.3. </ins> A successful response by the Transaction Token Server to a Replacement Txn-Token Request is a Txn-Token Response as described in <del> 7.4. </del> <ins> 7.5. </ins> A Txn-Token Service MUST ensure that it authenticates any workloads requesting Txn-Tokens.  In order to do so:
this attack since the Access Token may remain valid even after the Txn-Token has expired. <ins> 8.4. 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 Token Exchange specification, both parameters MUST be present in the request.  The "actor_token" MUST autenticate the identity of the requesting workload. </ins> 9. 9.1. <del> Some "req_ctx" claims may be considered personal information in some </del> <ins> Some "rctx" claims may be considered personal information in some </ins> jurisdictions and if so their values need to be obsfucated.  For example, originating IP address ("req_ip") is often considerd personal information and in that case must be protected through some
8. <ins> Txn-Tokens need to be communicated between workloads that depend upon them to authorize the request.  Such workloads will often present HTTP RFC2616 interfaces for being invoked by other workloads.  This section specifies the HTTP header the invoking workload MUST use to communicate the Txn-Token to the invoked workload, when the invoked workload presents an HTTP interface.  Note that the standard HTTP "Authorization" header MUST NOT be used because that may be used by the workloads to communicate channel authorization. </ins> 8.1. <ins> A workload that invokes another workload using HTTP and needs to present a Txn-Token to the invoked workload MUST use the HTTP Header "Txn-Token" to communicate the Txn-Token.  The value of this header MUST be the JWT that represents the Txn-Token. 9. 9.1. </ins> A Txn-Token is not resistant to replay attacks.  A long-lived Txn- Token therefore represents a risk if it is stored in a file, discovered by an attacker, and then replayed.  For this reason, a
field, which indicates the token lifetime.  The "scope" field is omitted from the request and therefore omitted in the response. <del> 8.2. </del> <ins> 9.2. </ins> Although Txn-Tokens are short-lived, they MAY be sender constrained as an additional layer of defence to prevent them from being re-used by a compromised or malicious workload under the control of a hostile actor. <del> 8.3. </del> <ins> 9.3. </ins> When creating Txn-Tokens, the Txn-Token MUST NOT contain the Access Token presented to the external endpoint.  If an Access Token is
personal information and in that case must be protected through some obsfucation method (e.g.  SHA256). <del> 10. </del> <ins> 11. </ins> This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in RFC6749, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in <del> 10.1. </del> <ins> 11.1. </ins> Name: "txn_token"
9.2. <del> Although Txn-Tokens are short-lived, they MAY be sender constrained as an additional layer of defence to prevent them from being re-used by a compromised or malicious workload under the control of a hostile actor. 9.3. </del> When creating Txn-Tokens, the Txn-Token MUST NOT contain the Access Token presented to the external endpoint.  If an Access Token is included in a Txn-Token, an attacker may extract the Access Token