Closed murthygorty closed 11 months ago
@murthygorty : The RFC7636 mentions that the server can perform the proof of possession of the "code verifier" by the client. Plz feel free to get your proposed changes added to the RFC and we can then piggyback it here.
As per last WG call discussion (29/11), from Telefónica's point of view the PR #89 is ok as the changes are in line with the standard (RFC7636) and it has enough approvals. PR is a candidate for merging. @murthygorty @gmuratk Could you just double-check if you guys are ok with the changes applied to the documentation.
I don't have the access to close it myself, but we can close it. cc: @mengan
Problem description Hi, our current docs under AuthN Concepts expresses the view that PKCE is a form of Proof of Possession. In my view, PKCE is verifies possession of the verifier and doesn't meet the bar of Proof of Possession sufficiently - see DPOP rfc for a flavor of proof of possession. PKCE enables applications such as SPAs, it doesn't prevent the key attack vectors possible with OAuth2, like DPOP.
As we are discussing use of DPOP as part of CAMARA this language is causing confusion.
Expected action Recommend simple rewording: Instead of
Proof Key for Code Exchange (PKCE is specified in RFC 7636) is a kind of proof of possession. It is an extension to the authorization code flow to prevent CSRF and authorization code injection attacks.
suggest sayingProof Key for Code Exchange (PKCE is specified in RFC 7636) is an extension to the authorization code flow to prevent CSRF and authorization code injection attacks.
Additional context DPOP: https://www.rfc-editor.org/rfc/rfc9449
@shilpa-padgaonkar , @gmuratk @mengan