jiebi/CodeConvo huggingface dataset:
Code change:
The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments

Related discussion:
text: 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.
Code change:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Related discussion:
text: 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
Code change:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Related discussion:
text: "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
Code change:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Related discussion:
text: 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.
Code change:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Related discussion:
text: 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
Code change:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Related discussion:
text: 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
Code change:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Related discussion:
text: 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
Code change:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Related discussion:
text: request.  The "actor_token" MUST authenticate the identity of the requesting workload. <del> 9.4. </del> <ins> 9.5. </ins> Validation of a replacement Txn-Token, as well as any Txn-Token, is critical to the security of the entire transaction invocation
Code change:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Related discussion:
text: signature be verified but also the workload identity of the workload requesting the replacement Txn-Token. <del> 9.5. </del> <ins> 9.6. </ins> The authorization model within a trust domain boundary is most often quite different from the authorization model (e.g.  OAuth scopes)
Code change:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Related discussion:
text: 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.
Code change:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Related discussion:
text: 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.
Code change:
Is there a reason why you did not use uppercase terms like MUST NOT or SHOULD? Because it's supposed to be informative?
Yes, the section is non-normative.
Currently logging guidance says "Txn-Tokens SHOULD NOT be logged if they contain Personally Identifiable Information (PII)". I have few questions on this one Risks with logging is that token is still valid for few minutes and if logs are rotated to any other central archival storage with access to broader set of people or someone has access to the server with logs, then they can reuse the token. So why not just say MUST not log token? Also how would a service know if incoming token has PII or not. They will have to validate the token, extract claims and then somehow know infer that a claim is PII or not. On similar lines, for PII , can we mention that TTS SHOULD evaluate encrypting or tokenizing PII claims rather than adding them in plaintext. Adding in plaintext is a risk because TTS isn't aware where the token flows.
Txn-Tokens already contain the subject identifier which is enough to be considered PII in some environments. Our own policy states that PII data can be logged, but the logs must be deleted after a few days (max 7) days. We forbid logging of Txn-Tokens in our integrations for security reasons, not just because they could contain PII.
Our implementation in my company, we do follow the same guidance i.e do not log tokens at all, nothing to do with PII. Tokens are pretty much considered as credentials as validating parties leverage the claims for authorizing the request.

Related discussion:
text: 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.
Code change:
See issue Question for reviewers. Do we need the final sentence on how a workload is invoked? If the sentence was not there would it change how we think about a trust domain? Do we need the second sentence as an example? Should we add more examples (e.g. trust domains can be defined as all the applications or workloads that recognise a specific issuer).
The definition of a Trust Domain feels very specific to network segmentation. Is there a industry level Trust Domain definition we can use instead? For example, should we use a definition that defines the trust domain in terms of the shared policies that apply? Something like: "A trust domain refers to a collection of systems, applications, or workloads that share a common security policy".
I'm good with this

Related discussion:
text: 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.
Code change:
Related to issue
Section 7.2 includes a "access_token", which is part of the token exchange protocol. RFC 8693 makes it clear that it des not need to be an OAuth token, but perhaps we can reference that this parameter is define in RFC 8693? Perhaps something like: "The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:" or "A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response. The Txn-Token Response is a profile of the token exchange response defined in RFC 8693. If the Transaction Token Service responds with an error, the error response is as described in Section 5.2 of RFC6749. The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:"
I'm not seeing access_token mentioned in section 7.2 other than implicitly when referencing the token types defined by 8693. Did you mean section 7.4? I'm fine with the first suggestion.
Yes, section 7.4.
I'm good with this

Related discussion:
text: 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
Code change:
Related to issue
Section 7.2 includes a "access_token", which is part of the token exchange protocol. RFC 8693 makes it clear that it des not need to be an OAuth token, but perhaps we can reference that this parameter is define in RFC 8693? Perhaps something like: "The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:" or "A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response. The Txn-Token Response is a profile of the token exchange response defined in RFC 8693. If the Transaction Token Service responds with an error, the error response is as described in Section 5.2 of RFC6749. The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:"
I'm not seeing access_token mentioned in section 7.2 other than implicitly when referencing the token types defined by 8693. Did you mean section 7.4? I'm fine with the first suggestion.
Yes, section 7.4.
I'm good with this

Related discussion:
text: 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.
Code change:
See issue
In section 2.2.1 the context that may be included in a transaction token includes "The external authorization token (e.g., the OAuth access token)". To ensure this is not interpreted to mean that an access token is included in a transaction token, I would suggest the following additions, in line with section 9.3 in Security Considerations: "A reference to the external authorization token (e.g., the OAuth access token), including scopes or claims included in the authorization token, but not the unmodified authorization token (see Security Considerations, Section 9.3)"
Pieter, in that section of the spec we are describing what needs to be sent to the Transaction token service, I think in that case the full access token should be passed. However, when generating the request context, we want to ensure that the full access token is not included. Did I get my spec sections wrong?
Maybe instead we shouldn't say "This context MAY include:" but rather ... "The information provided to the Txn-Token Service MAY include" to not confuse readers who might think this data should be included in the request context.
Agreed - I missed that this was for initial token creation. I did create a PR with your suggested text.
PR approved
Looks good.

Related discussion:
text: 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)