jiebi/CodeConvo huggingface dataset:
more workloads.  The workloads within an Trust Domain may be invoked only through published interfaces.  A Trust Domain must have an identifier that is used as the "aud" (audience) value in <del> Txn-Tokens.  The format of this identifier is a universal resource identifier.  Each Trust Domain has exactly one Txn-Token Service. </del> <ins> Txn-Tokens.  The format of this identifier is as defined in the JWT specification RFC7519. </ins> A published interface to an Trust Domain that results in the invocation of a workload within the Trust Domain.
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- <del> Token. </del> <ins> Token and contextual attributes of the originating request itself. </ins> The JSON value of the "rctx" claim MAY include any values the Txn- Token Service determines are interesting to downstream services that
user or a robotic process that requested the Transaction "authn" The authentication method used to idenitfy the requester. <del> 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. </del> <ins> Its value is a StringOrURI that uniquely identifies the method used. "req_wl" The requesting workload.  A StringOrURI that uniquely identifies the computational entity that requested the Txn-Token. This entity MUST be within the Trust Domain of the Txn-Token.  If a replacement Txn-Token has been requested, then this claim will be an array of StringOrURIs representing the different workloads that have requested Txn-Tokens as part of the transaction processing. 5.2.1.1. It is useful to be able to track the set of workloads that have requested a Txn-Token.  The "req_wl" claim allows for tracking this information even through requests for a replacement Txn-Token.  By default the "req_wl" is a StringOrURI representing the original workload entity that requested the Txn-Token.  However, if a workload within the path of servicing the transaction requests a replacement Txn-Token, then the Transaction Token Service will append the new requesting workload as a subsequent array element in the "req_wl" claim.  This provides a "pathing" mechanism to track which services have requested replacement Txn-Tokens.  If there is only a single value the "req_wl" will be a StringOrURI.  If there is more than a single value, then "req_wl" will be prepresented by an array of StringOrURIs. </ins> 5.2.2.
case-sensitive strings where the value(s) MUST represent the specific purpose or intent of the transaction.  * "requested_token_type" REQUIRED.  The value MUST be "urn:ietf:params:oauth:token-type:txn- <del> token" * "subject_token" REQUIRED.  The value MUST be a token representing the subject of the transaction.  This could be an OAuth access_token received by an API Gateway or a JWT assertion constructed by a workload initiating a transaction or another form of token as identified by "subject_token_type".  * "subject_token_type" REQUIRED.  The value MUST indicate the type of the token present in the "subject_token" parameter </del> <ins> token" * "subject_token" REQUIRED.  The value MUST represent the subject of the transaction.  This could be an OAuth access_token received by an API Gateway, a JWT assertion constructed by a workload initiating a transaction or a simple string value all identified by "subject_token_type".  * "subject_token_type" REQUIRED.  The value MUST indicate the type of the token or value present in the "subject_token" parameter </ins> The following additional parameters MAY be present in a Txn-Token Request:
Workloads MAY request replacement Txn-Tokens in order to change (add to, remove or modify) the asserted values within a Txn-Token. <del> The value of the "aud" claim MUST remain unchanged in a replacement Txn-Token.  If the claim "rctx" is present in the original Txn-Token, then it MUST be present unchanged in the replacement Txn-Token. </del> <ins> The values of the "sub" and "aud" claims MUST remain unchanged in a replacement Txn-Token.  If the claim "rctx" is present in the original Txn-Token, then it MUST be present and unchanged in the replacement Txn-Token except for the "req_wl" claim which MUST be updated to include the requesting workload identifier. </ins> 7.4.1.
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 <del> obsfucation method (e.g.  SHA256). </del> <ins> obsfucation method (e.g. salted SHA256). 10.2. 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. </ins> 11.
7.5.1. <del> A Txn-Token Service replacing a Txn-Token must consider that modifying previously asserted values from existing Txn-Tokens can completely negate the benefits of Txn-Tokens.  When issuing replacement Txn-Tokens, a Transaction Token Server therefore: </del> <ins> When issuing replacement Txn-Tokens, a Txn-Token Service: </ins> MAY enable modifications to asserted values that reduce the scope of permitted actions
SHOULD NOT enable modification to asserted values that expand the scope of permitted actions <ins> MUST NOT modify "sub" and "aud" values of the Txn-Token in the request MUST NOT remove any of the existing requesting workload identifiers from the "req_wl" field in the "rctx" claim of the Txn-Token </ins> 7.5.2. To request a replacement Txn-Token, the requester makes a Txn-Token
to authorize its calls to subsequent workloads.  Subsequent workloads may obtain Txn-Tokens of their own. <ins> If the requesting service does not have an inbound token that it can use in its request to the Txn-Token Service, it generates a self- signed JWT and passes that in the request in place of the external authorization token. </ins> 2.2.2. A service within a call chain may choose to replace the Txn-Token.
"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 OAuth access_token received by an API Gateway, a JWT assertion constructed by a workload initiating a transaction or a simple string value all identified by "subject_token_type". </del> <ins> 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 "subject_token_type". </ins> "subject_token_type" REQUIRED.  The value MUST indicate the type of the token or value present in the "subject_token" parameter
Transaction Token Service.  The exact client authentication mechanism used is outside the scope of this specification. <del> figtxtokenrequest shows a non-normative example of a Txn-Token Request. </del> <ins> The figure below figtxtokenrequest shows a non-normative example of a Txn-Token Request. </ins> 7.2. <ins> The "subject_token_type" parameter value MUST be a URI RFC3986.  It 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. 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. 7.2.1. A requester MAY use a self-signed JWT as a "subject_token" value.  In that case, the requester MUST set the "subject_token_type" value to: "urn:ietf:params:oauth:token-type:self_signed".  This self-signed JWT MUST contain the following claims: "iss": The unique identifier of the requesting workload.  The Txn- Token Service SHALL use this value in determiining the "req_wl" value in the Txn-Token issued in response to this request. "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. "iat": The time at which the self-signed JWT was created.  Note that the Txn-Token Service may reject self-signed tokens with an "iat" value that is unreasonably far in the past. The self-signed JWT MAY contain other claims. 7.3. </ins> When the Transaction Token Service receives a Txn-Token Request it MUST validate the requesting workload client authentication and determine if that workload is authorized to obtain the Txn-Tokens
SHOULD NOT enable modification to asserted values that expand the scope of permitted actions <del> 7.4.2. </del> <ins> 7.5.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.4.3. </del> <ins> 7.5.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.5. </del> <ins> 7.6. </ins> A Txn-Token Service MUST ensure that it authenticates any workloads requesting Txn-Tokens.  In order to do so:
This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in <del> RFC6749, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in </del> <ins> RFC6749, the following claim in Section subject-token-types to the "OAuth URI" subregistry of the "OAuth Parameters" IANA.OAuth.Parameters registry, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in </ins> 11.1.
that have requested Txn-Tokens as part of the transaction processing. <del> 5.2.1.1. </del> <ins> 5.2.2. The Txn-Token SHOULD contain an "azd" claim.  The value of this claim is a JSON object that contains name/value pairs (wherein the value could itself be an object), which together assert the details that remain immutable through the call-chain where this Txn-Token is used. Txn-Tokens are primarily used to assure identity and context for a transaction, and the content of this field is a critical part of that context. Whereas the "rctx" field contains environmental values related to the request, the "azd" field contains the actual authorizaiton details that are determined by the TTS.  These values are used by services using the Txn-Token to reliably obtain specific parameters needed to perform their work.  The content of the "azd" field is determined by the Txn-Token Service and they may be computed internally or from parameters it receives from the service that requests the Txn-Token. The following is a non-normative example of an "azd" claim: 5.2.2.1. </ins> It is useful to be able to track the set of workloads that have requested a Txn-Token.  The "req_wl" claim allows for tracking this
1.3.3. The client credentials or other forms of client authentication (e.g. <del> a "client_secret" or a private key used to sign a JWT) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server.  Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server. </del> <ins> a private key used to sign a JWT, as described in RFC7523) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server.  Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server. </ins> 1.4.
the process of issuance/registration and distribution of the underlying credentials ensures their confidentiality. <del> If the client is confidential or credentialed, the authorization server MAY accept any form of client authentication meeting its security requirements (e.g., password, public/private key pair). </del> <ins> If the client is confidential, the authorization server MAY accept any form of client authentication meeting its security requirements (e.g., password, public/private key pair). </ins> It is RECOMMENDED to use asymmetric (public-key based) methods for client authentication such as mTLS RFC8705 or "private_key_jwt"
supported by the token request.  The details of those grant types are defined below. <del> Confidential or credentialed clients MUST authenticate with the authorization server as described in token-endpoint-client- authentication. </del> <ins> Confidential clients MUST authenticate with the authorization server as described in token-endpoint-client-authentication. </ins> For example, the client makes the following HTTP request (with extra line breaks for display purposes only): The authorization server MUST: <del> require client authentication for confidential and credentialed clients (or clients with other authentication requirements), </del> <ins> require client authentication for confidential clients (or clients with other authentication requirements), </ins> authenticate the client if client authentication is included
Because refresh tokens are typically long-lasting credentials used to request additional access tokens, the refresh token is bound to the <del> client to which it was issued.  Confidential or credentialed clients MUST authenticate with the authorization server as described in token-endpoint-client-authentication. </del> <ins> client to which it was issued.  Confidential clients MUST authenticate with the authorization server as described in token- endpoint-client-authentication. </ins> For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes
2.3.1. Authorization servers MUST require clients to register their complete <del> redirect URI (including the path component) and reject authorization requests that specify a redirect URI that doesn't exactly match one that was registered; the exception is loopback redirects, where an exact match is required except for the port URI component. </del> <ins> redirect URI (including the path component).  Authorization servers MUST reject authorization requests that specify a redirect URI that doesn't exactly match one that was registered, with an exception for loopback redirects, where an exact match is required except for the port URI component. </ins> The authorization server MAY allow the client to register multiple redirect URIs. <ins> Registration may happen out of band, such as a manual step of configuring the client information at the authorization server, or may happen at runtime, such as in the initial POST in Pushed Authorization Requests RFC9126. </ins> For private-use URI scheme-based redirect URIs, authorization servers SHOULD enforce the requirement in private-use-uri-scheme that clients use schemes that are reverse domain name based.  At a minimum, any
token and client identity whenever the client identity can be authenticated.  When client authentication is not possible, the authorization server SHOULD issue sender-constrained refresh tokens <del> or use refresh token rotation as described in (#refresh-token- endpoint-extension). </del> <ins> or use refresh token rotation as described in refresh-token-endpoint- extension. </ins> The authorization server MUST ensure that refresh tokens cannot be generated, modified, or guessed to produce valid refresh tokens by
2.3.4. <del> In order to prevent mix-up attacks, clients MUST only process redirect responses of the authorization server they sent the respective request to and from the same user agent this authorization request was initiated with.  Clients MUST store the authorization server they sent an authorization request to and bind this information to the user agent and check that the authorization response was received from the correct authorization server.  Clients MUST ensure that the subsequent access token request, if applicable, is sent to the same authorization server.  Clients SHOULD use distinct redirect URIs for each authorization server as a means to identify the authorization server a particular response came from. </del> <ins> When an OAuth client can only interact with one authorization server, a mix-up defense is not required.  In scenarios where an OAuth client interacts with two or more authorization servers, however, clients MUST prevent mix-up attacks.  In order to prevent mix-up attacks, clients MUST only process redirect responses of the issuer they sent the respective request to and from the same user agent this authorization request was initiated with. See mixupcountermeasures for a detailed description of two different defenses against mix-up attacks. </ins> 2.3.5.
authorization request.  The exact value received from the client. OPTIONAL.  The identifier of the authorization server which the <del> client can use to prevent mixup attacks, if the client interacts with more than one authorization server.  See RFC9207 for additional details on when this parameter is necessary, and how the client can use it to prevent mixup attacks. </del> <ins> client can use to prevent mix-up attacks, if the client interacts with more than one authorization server.  See mix-up and RFC9207 for additional details on when this parameter is necessary, and how the client can use it to prevent mix-up attacks. </ins> For example, the authorization server redirects the user agent by sending the following HTTP response:
REQUIRED.  The type of the access token issued as described in access-tokens.  Value is case insensitive. <del> RECOMMENDED.  The lifetime in seconds of the access token.  For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated.  If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value. </del> <ins> RECOMMENDED.  A JSON number that represents the lifetime in seconds of the access token.  For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated.  If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value. </ins> RECOMMENDED, if identical to the scope requested by the client; otherwise, REQUIRED.  The scope of the access token as described
authentication, integrity and confidentiality such as Transport-Layer Security RFC8446, to protect the exchange of clear-text credentials and tokens either in the content or in header fields from <del> eavesdropping, tampering, and message forgery (eg. see client-secret, authorization_codes, token-endpoint, and bearer-tokens). </del> <ins> eavesdropping, tampering, and message forgery (e.g., see client- secret, authorization_codes, token-endpoint, and bearer-tokens). </ins> OAuth URLs MUST use the "https" scheme except for loopback interface redirect URIs, which MAY use the "http" scheme.  When using "https",
an HTML document response, processed by the user agent.  If the HTML response is served directly as the result of the redirection request, any script included in the HTML document will execute with full <del> access to the redirect URI and the artifacts (e.g. authorization </del> <ins> access to the redirect URI and the artifacts (e.g., authorization </ins> code) it contains.  Additionally, the request URL containing the authorization code may be sent in the HTTP Referer header to any embedded images, stylesheets and other elements loaded in the page.
_Sender-constrained refresh tokens:_ the authorization server cryptographically binds the refresh token to a certain client <del> instance, e.g. by utilizing DPoP RFC9449 or mTLS RFC8705. </del> <ins> instance, e.g., by utilizing DPoP RFC9449 or mTLS RFC8705. </ins> _Refresh token rotation:_ the authorization server issues a new refresh token with every access token refresh response.  The
9. <del> Browser-based apps are are clients that run in a web browser, typically written in JavaScript, also known as "single-page apps". These types of apps have particular security considerations similar to native apps. </del> <ins> Browser-based apps are clients that run in a web browser, typically written in JavaScript, also known as "single-page apps".  These types of apps have particular security considerations similar to native apps. </ins> TODO: Bring in the normative text of the browser-based apps BCP when it is finalized.
authorization server during the client registration process. The redirect URI MUST be an absolute URI as defined by RFC3986 <del> Section 4.3.  The redirect URI MAY include an "application/x-www- form-urlencoded" formatted query component (WHATWG.URL), which MUST be retained when adding additional query parameters.  The redirect URI MUST NOT include a fragment component. </del> <ins> Section 4.3.  The redirect URI MAY include an query string component (query-string-serialization), which MUST be retained when adding additional query parameters.  The redirect URI MUST NOT include a fragment component. </ins> 2.3.1.
the authorization server's metadata document (RFC8414). The authorization endpoint URL MUST NOT include a fragment component, <del> and MAY include an "application/x-www-form-urlencoded" formatted query component WHATWG.URL, which MUST be retained when adding additional query parameters. </del> <ins> and MAY include a query string component query-string-serialization, which MUST be retained when adding additional query parameters. </ins> The authorization server MUST support the use of the HTTP "GET" method Section 9.3.1 of RFC9110 for the authorization endpoint and
3.2.2. The client makes a request to the token endpoint by sending the <del> following parameters using the "application/x-www-form-urlencoded" format per application-x-www-form-urlencoded with a character encoding of UTF-8 in the HTTP request content: </del> <ins> following parameters using the form-encoded serialization format per form-serialization with a character encoding of UTF-8 in the HTTP request content: </ins> REQUIRED.  Identifier of the grant type the client uses with the particular token request.  This specification defines the values
%x5D-7E. The parameters are included in the content of the HTTP response using <del> the "application/json" media type as defined by RFC7159.  The parameters are serialized into a JSON structure by adding each parameter at the highest structure level.  Parameter names and string values are included as JSON strings.  Numerical values are included as JSON numbers.  The order of parameters does not matter and can vary. </del> <ins> the "application/json" media type as defined in json-serialization. </ins> For example:
If the resource owner grants the access request, the authorization server issues an authorization code and delivers it to the client by adding the following parameters to the query component of the <del> redirect URI using the "application/x-www-form-urlencoded" format, per application-x-www-form-urlencoded: </del> <ins> redirect URI using the query string serialization described by query- string-serialization, unless specified otherwise by an extension: </ins> REQUIRED.  The authorization code is generated by the authorization server and opaque to the client.  The authorization