Original 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 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>  "subject_token_type" REQUIRED.  The value MUST indicate the type of the token or value present in the "subject_token" parameter

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:
"urn:ietf:params:oauth:token-type:txn-token" "subject_token" REQUIRED.  The value MUST represent the subject of  <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