Original text:
SHOULD NOT enable modification to asserted values that expand the scope of permitted actions <del> 7.4.2. </del>  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>  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>  A Txn-Token Service MUST ensure that it authenticates any workloads requesting Txn-Tokens.  In order to do so:

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:
SHOULD NOT enable modification to asserted values that expand the scope of permitted actions  <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.  <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  <ins> 7.6. </ins> A Txn-Token Service MUST ensure that it authenticates any workloads requesting Txn-Tokens.  In order to do so: