Original text:
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>  7.2.  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

Reviewer comments:
Yup. Thanks. I realized I forgot to add the IANA section after I sent out the PR. I'll update it soon.
NAME Regarding your comment about wrong approach: I mentioned something along those lines as well. I personally don't think that a new token type is actually necessary. A JWT is a good fit as it can carry the necessary data, but whether it should be signed by the workload (or what additional claims and associated checks should be incorporated) could be a decision by the individual TTS/trust domain.
NAME My point is that even the JWT structure/encoding is not needed. No need to sign anything, no need to encode stuff in base64 (and either of them adds potential security issues). All the semantics we need can be carried in a simple JSON object.
I tend to agree with Yaron, that perhaps self-signed JWTs aren't the best way to express this. We can discuss this on the call tomorrow.
Given the requirement that the TTS/AS always has to authenticate the identity of the requesting workload, conveying this info in an unsigned thing (the subject token could even contain just plain JSON) would probably be okay. Though it seems like the kind of thing that might lead to mistakes in deployment and resultant security issues.
Letting the input be any kind of JSON structure feels problematic - not least because of interop. Using a JWT as the container and then putting constraints on it (i.e. a minimal set of supported claims) will help transaction token services in parsing and making some basic determinations about security. Self-signing has pros and cons - we can make it optional for those deployments that have a risk profile that would get additional assurances from it, but as Brian notes, signing is easy to get wrong.
Well, you'd put some constraints on the JSON content too. I don't see how that'd be any more problematic from an interop perspective.
As long as there are some constraints on the format and contents that everyone would expect. Why not just use a JWT at that point though (there are libraries that support it etc)?
NAME On we discussed this topic, and while there are valid opinions on both approaches, for now I am keeping the request as a self-signed JWT unless we think this approach is problematic.
Let's go ahead and merge and then file issues if there is stuff we want to change.

Revised text:
Transaction Token Service.  The exact client authentication mechanism used is outside the scope of this specification.  <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