Merge pull request #91 from oauthstuff/danielfett/mikes-feedback

Incorporate SECDIR feedback

Author: danielfett

A01_introduction.md

@@ -22,8 +22,8 @@ challenges can be observed:
 	  creating new challenges with respect to security. Those challenges go beyond
 	  the original scope of [@!RFC6749], [@!RFC6750], and [@!RFC6819].
 
-    OAuth initially assumed static relationships between client,
-    authorization server, and resource servers. The URLs of the servers were
+    OAuth initially assumed static relationships between clients,
+    authorization servers, and resource servers. The URLs of the servers were
     known to the client at deployment time and built an anchor for the
     trust relationships among those parties. The validation of whether the
     client is talking to a legitimate server was based on TLS server
@@ -56,8 +56,8 @@ compatible with the new requirements and following the best practices described
 this document may break interoperability. Nonetheless, it is RECOMMENDED that
 implementers upgrade their implementations and ecosystems as soon as feasible.
 
-OAuth 2.1, under developement as [@I-D.ietf-oauth-v2-1], will incorporate the
-security recommendations of this document.
+OAuth 2.1, under developement as [@I-D.ietf-oauth-v2-1], will incorporate
+security recommendations from this document.
 
 ## Structure
 

A02_recommendations.md

@@ -1,7 +1,7 @@
 # Best Practices {#recommendations}
 
 This section describes the core set of security mechanisms and measures the
-OAuth working group considers best practices at the time of writing. Details
+OAuth working group considers to be best practices at the time of writing. Details
 about these security mechanisms and measures (including detailed attack
 descriptions) and requirements for less commonly used options are provided in
 (#attacks_and_mitigations).
@@ -10,13 +10,13 @@ descriptions) and requirements for less commonly used options are provided in
 
 When comparing client redirect URIs against pre-registered URIs, authorization
 servers MUST utilize exact string matching except for port numbers in
-`localhost` redirection URIs of native apps, see (#iuv_countermeasures). This
+`localhost` redirection URIs of native apps (see #iuv_countermeasures). This
 measure contributes to the prevention of leakage of authorization codes and
 access tokens (see (#insufficient_uri_validation)). It can also help to detect
 mix-up attacks (see (#mix_up)).
 
 Clients and authorization servers MUST NOT expose URLs that forward the user's browser to
-arbitrary URIs obtained from a query parameter (open redirector) as
+arbitrary URIs obtained from a query parameter (open redirectors) as
 described in (#open_redirection). Open redirectors can enable
 exfiltration of authorization codes and access tokens.
 
@@ -122,10 +122,10 @@ access tokens in the authorization response, unless access token injection
 in the authorization response is prevented and the aforementioned token leakage
 vectors are mitigated.
 
-Clients SHOULD instead use the response type "code" (aka authorization
+Clients SHOULD instead use the response type `code` (i.e., authorization
 code grant type) as specified in (#ac) or any other response type that
 causes the authorization server to issue access tokens in the token
-response, such as the "code id\_token" response type. This allows the
+response, such as the `code id_token` response type. This allows the
 authorization server to detect replay attempts by attackers and
 generally reduces the attack surface since access tokens are not
 exposed in URLs. It also allows the authorization server to
@@ -251,5 +251,5 @@ To support browser-based clients, endpoints directly accessed by such clients
 including the Token Endpoint, Authorization Server Metadata Endpoint, `jwks_uri`
 Endpoint, and the Dynamic Client Registration Endpoint MAY support the use of
 Cross-Origin Resource Sharing (CORS, [@WHATWG.CORS]). However, CORS MUST NOT be
-supported at the Authorization Endpoint as the client does not access this
-endpoint directly, instead, the client redirects the user agent to it.
+supported at the Authorization Endpoint, as the client does not access this
+endpoint directly; instead, the client redirects the user agent to it.

A03_security-model.md

@@ -10,7 +10,7 @@ include new types of attackers and to define the attacker model more clearly.
 
 The goal of this document is to ensure that the authorization of a resource
 owner (with a user agent) at an authorization server and the subsequent usage of
-the access token at a resource server is protected, as good as practically
+the access token at a resource server is protected, as well as practically
 possible, at least against the following attackers:
 
   * (A1) Web Attackers that can set up and operate an arbitrary number of
@@ -81,7 +81,7 @@ attackers are relevant in particular:
     example, a resource server can be compromised by an attacker, an
     access token may be sent to an attacker-controlled resource server
     due to a misconfiguration, or a resource owner is social-engineered into
-    using an attacker-controlled resource server. See also (#comp_res_server).
+    using an attacker-controlled resource server. Also see (#comp_res_server).
 
 (A3), (A4) and (A5) typically occur together with either (A1) or (A2).
 Attackers can collaborate to reach a common goal.