edit all security sections

Author: krishahn

versions/3.0.md

@@ -3343,7 +3343,7 @@ animals:
 
 #### <a name="securitySchemeObject"></a>Security Scheme Object
 
-Allows the definition of a security scheme that can be used by the operations.
+Defines a security scheme that can be used by the operations.
 Supported schemes are HTTP authentication, an API key (either as a header or as a query parameter) and OAuth2's common flows (implicit, password, application and access code).
 
 ##### Fixed Fields
@@ -3513,7 +3513,7 @@ The name used for each property MUST correspond to a security scheme declared in
 Security Requirement Objects that contain multiple schemes require that all schemes MUST be satisfied for a request to be authorized.
 This enables support for scenarios where multiple query parameters or HTTP headers are required to convey security information.
 
-When a list of Security Requirement Objects is defined on the [Open API object](#oasObject) or [Operation Object](#operationObject), only one of Security Requirement Objects in the list needs to be satisfied to authorize.  
+When a list of Security Requirement Objects is defined on the [Open API object](#oasObject) or [Operation Object](#operationObject), only one of Security Requirement Objects in the list needs to be satisfied to authorize the request.  
 
 ##### Patterned Fields
 
@@ -3566,15 +3566,15 @@ The extensions may or may not be supported by the available tooling, but those m
 
 ### <a name="securityFiltering"></a>Security Filtering
 
-Some objects in the OpenAPI Specification MAY be declared and remain empty, or completely be removed, even though they are inherently the core of the API documentation. 
+Some objects in the OpenAPI Specification MAY be declared and remain empty, or be completely removed, even though they are inherently the core of the API documentation. 
 
-The reasoning behind it is to allow an additional layer of access control over the documentation itself.
+The reasoning is to allow an additional layer of access control over the documentation.
 While not part of the specification itself, certain libraries MAY choose to allow access to parts of the documentation based on some form of authentication/authorization.
 
-Two examples for this:
+Two examples of this:
 
 1. The [Paths Object](#pathsObject) MAY be empty. It may be counterintuitive, but this may tell the viewer that they got to the right place, but can't access any documentation. They'd still have access to the [Info Object](#infoObject) which may contain additional information regarding authentication.
-2. The [Path Item Object](#pathItemObject) MAY be empty. In this case, the viewer will be aware that the path exists, but will not be able to see any of its operations or parameters. This is different than hiding the path itself from the [Paths Object](#pathsObject) so the user will not be aware of its existence. This allows the documentation provider a finer control over what the viewer can see.
+2. The [Path Item Object](#pathItemObject) MAY be empty. In this case, the viewer will be aware that the path exists, but will not be able to see any of its operations or parameters. This is different than hiding the path itself from the [Paths Object](#pathsObject), so the user will not be aware of its existence. This allows the documentation provider a finer control over what the viewer can see.
 
 ## <a name="revisionHistory"></a>Appendix A: Revision History