The Oauth PKCE protocol flow is as follows, as defined in [RFC 7636](https://www.rfc-editor.org/rfc/rfc7636#section-1.1):

```
                                             +-------------------+
                                             |   Authz Server    |
   +--------+                                | +---------------+ |
   |        |--(A)- Authorization Request ---->|               | |
   |        |       + t(code_verifier), t_m  | | Authorization | |
   |        |                                | |    Endpoint   | |
   |        |<-(B)---- Authorization Code -----|               | |
   |        |                                | +---------------+ |
   | Client |                                |                   |
   |        |                                | +---------------+ |
   |        |--(C)-- Access Token Request ---->|               | |
   |        |          + code_verifier       | |    Token      | |
   |        |                                | |   Endpoint    | |
   |        |<-(D)------ Access Token ---------|               | |
   +--------+                                | +---------------+ |
                                             +-------------------+

```

My question is: why do we need to use a trapdoor like `S256` in step (A)?

According to the RFC's threat model, a malicious app cannot intercept the *outgoing* communication in (A) or (C). So why can't an app generate and temporarily store a random value in (A) and re-use it in (C)?

To elaborate: the goal of `t(code_verifier)` (ie `S256(code_verifier)`) is to later enable the app to prove to the server that it is indeed the app as it possess `code_verifier` before the transform.

However, if the app just sent `code_verifier` and later sent it again, the same guarantee is achieved: the server receives a random value that uniquely identifies the app, and receives it again. No other app can provide this value: as long as the connection isn't intercepted (and it shouldn't be - TLS), `S256` seems unnecessary.