[OAUTH-WG] Motivation for plain transform method in PKCE, and encrypted code_challenge in code

[Adam Lewis <[e-mail]>]

Hi,

I'm probably missing something here, but what is the use case for allowing
the plain transform method in PKCE?  It seems to me the entire point of
sending the hash of the code_verifier (code_challenge) rather than the
code_verifier itself is to avoid leaking the code_verifier through
the browser during the authorization request.  It seems using the plain
type would enable an attacker to intercept the code verifier and use it to
exchange the code for the AT.  If a client is really unable to compute a
S256 hash, wouldn't it just fall back to vanilla OAuth?

Also, under security considerations, it mentions that if the code challenge
is returned as part of the code, it needs to be encrypted. Not sure why
since it was sent un-encrypted, where the attacker would have already had
the opportunity to intercept/obtain it. Plus 7.3 re-enforces the point that
the code verifier has sufficient entropy to prevent brute force attacks.  I
suppose the motivation then for encrypting the code_challenge is to address
the scenario whereby 1) the plain transform method is used, and 2) a
malicious app fails to intercept the code_challenge, but then 3) gets the
code?

Just looking for some background understanding of what went into these
designs.


tx!
adam