diff --git a/draft-saxe-wimse-token-exchange-and-translation.md b/draft-saxe-wimse-token-exchange-and-translation.md
index fdb3e36..2d03e2f 100644
--- a/draft-saxe-wimse-token-exchange-and-translation.md
+++ b/draft-saxe-wimse-token-exchange-and-translation.md
@@ -159,17 +159,17 @@ The Workloads possessing X.509 Certificate Identity Credentials may operate in a
    - the first subject alternative name (SAN) of type DNS name
    - the first subject alternative name (SAN) of type URI
 
-Compatible OAuth 2.0 Authorization Servers supporting this token exchange profile MUST supports mTLS. After the relying party has registered an X.509 Certificate federation profile with the OAuth 2.0 authorization server, in order to obtain access tokens, Workloads MUST present their X.509 Certificates during mTLS handshakes to establish a connection to the OAuth 2.0 Authorization Server.  Workloads MUST then send a request to token endpoint, in the manner described in [[RFC8693](https://datatracker.ietf.org/doc/html/rfc8693)]. The access token request is sent with the following properties:
+Compatible OAuth 2.0 Authorization Servers supporting this token exchange profile MUST support mTLS. After the relying party has registered an X.509 Certificate federation profile with the OAuth 2.0 authorization server, in order to obtain access tokens, Workloads MUST present their X.509 Certificates during mTLS handshakes to establish a connection to the OAuth 2.0 Authorization Server.  Workloads MUST then send a request to token endpoint, in the manner described in [[RFC8693](https://datatracker.ietf.org/doc/html/rfc8693)]. The access token request is sent with the following properties:
 
 * grant_type: REQUIRED. The value `urn:ietf:params:oauth:grant-type:token-exchange` indicates that a token exchange is being performed.
 * resource: OPTIONAL. A URI that indicates the target service or resource where the client intends to use the requested security token.
 * audience: REQUIRED for this Profile. A URI or other unique identifier for the relying party, assigned by the OAuth 2.0 Authorization Server.
 * scope: OPTIONAL. A list of space-delimited, case-sensitive strings, as defined in [Section 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) of [[RFC6749](https://datatracker.ietf.org/doc/html/rfc6749)], that allow the client to specify the desired scope of the requested security token in the context of the service or resource where the token will be used.
-* requested_token_type: `urn:ietf:params:oauth:token-type:access_token`
-* subject_token: TBD. While this field is listed as REQUIRED for token exchange in [Section 2.1](https://datatracker.ietf.org/doc/html/rfc8693#name-request) of [[RFC8693](https://datatracker.ietf.org/doc/html/rfc8693)], in this case supplying the subject token again may be redundant, since it was already conveyed during the mTLS handshake. It is unclear whether repeating it here adds additional value. If supplied, it introduces the possibility that the client sends the wrong value, complicating client integration. It adds network overhead of a few KB, which could grow larger for longer certificate chains. It might be best to mark this as: OPTIONAL. The Workload's X.509 Certificate chain. The X.509 Certificate chain MUST chain to a previously-configured Trust Anchor certificate for the relying party, either directly or through one of the previously-configured Intermediate CA path-building certificates. This field MUST be expressed as a PEM-encoded certificate chain with newline characters removed.
-* subject_token_type: `urn:ietf:params:oauth:token-type:mtls`
+* requested_token_type: MUST be `urn:ietf:params:oauth:token-type:access_token` for this token exchange profile.
+* subject_token: REQUIRED. The fixed string `mtls_client_certificate` instructs the Authorization Server to obtain the subject token from the client's mTLS Certificate message, as defined in [Section 2](https://datatracker.ietf.org/doc/html/rfc8446#section-2) of [[RFC8446](https://datatracker.ietf.org/doc/html/rfc8446)]. The X.509 Certificate chain MUST chain to a previously-configured Trust Anchor certificate for the relying party, either directly or through one of the previously-configured Intermediate CA path-building certificates.
+* subject_token_type: MUST be `urn:ietf:params:oauth:token-type:mtls` for this token exchange profile.
 
-The request MAY ONLY be accepted if the X.509 Certificate used during mTLS chain to a previously-configured Trust Anchor via a certificate path that may include previously-configured intermediate CA certificates. The previously-configured subject claim selector must be provide a non-blank string from the certificate. The previously-configured conditions must accept the X.509 Certificate.
+The request MUST ONLY be accepted if the X.509 Certificate used during mTLS chain to a previously-configured Trust Anchor via a certificate path that may include previously-configured intermediate CA certificates. The previously-configured subject claim selector MUST select a non-blank string from the certificate. The previously-configured conditions MUST accept the X.509 Certificate.
 
 The response document contains the following properties (per [[RFC8693](https://datatracker.ietf.org/doc/html/rfc8693)]):