From ac982410b94f749e8ad87d7cfc548f17fc221a43 Mon Sep 17 00:00:00 2001
From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Date: Thu, 11 Jun 2020 11:18:29 +0100
Subject: [PATCH] Apply suggestions from code review

Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
---
 proposals/2610-remove-oauth2-auth-type.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/proposals/2610-remove-oauth2-auth-type.md b/proposals/2610-remove-oauth2-auth-type.md
index e2437a48..05b5677c 100644
--- a/proposals/2610-remove-oauth2-auth-type.md
+++ b/proposals/2610-remove-oauth2-auth-type.md
@@ -15,7 +15,7 @@ The definition of
 authentication is incomplete. [OAuth2](https://oauth.net/2/) is best considered
 as a framework for implementing authentication protocols rather than a protocol
 in its own right, and this section says nothing about the grant types, flows
-and scopes which a compliant implemenation should understand.
+and scopes which a compliant implementation should understand.
 
 A better candidate for OAuth2-based authentication of matrix clients is via
 [OpenID Connect](https://openid.net/connect/), but this has already been
@@ -27,7 +27,7 @@ and redundant. It should be removed from the specification to reduce confusion.
 ## Alternatives
 
 It would be possible to extend the definition so that it is complete: as
-mentioned above, a likely implemenation would be based on OpenID
+mentioned above, a likely implementation would be based on OpenID
 Connect. Matrix clients could then follow the standardised OpenID Connect flow
 rather than the matrix-specific `m.login.sso` flow. However, this would require
 significant design work, and development in both clients and servers, which