Add example resolution of Security Requirement

Author: handrews

versions/3.1.1.md

@@ -225,6 +225,9 @@ The interface approach can also work for Discriminator Objects and Schema Object
 There are no URI-based alternatives for the Security Requirement Object or for the Operation Object's `tags` field.
 These limitations are expected to be addressed in a future release.
 
+See [Security Requirement in a Referenced Document](#security-requirement-in-a-referenced-document) for an example of the possible resolutions, including which one is recommended by this section.
+The behavior for Discrimator Object non-URI mappings and for the Operation Object's `tags` field operate on the same principles.
+
 Note that no aspect of implicit connection resolution changes how [URIs are resolved](#relativeReferencesURI), or restricts their possible targets.
 
 ### <a name="dataTypes"></a>Data Types
@@ -3826,6 +3829,41 @@ security:
     - read:pets
 ```
 
+###### Security Requirement in a Referenced Document
+
+See [Resolving Implicit Connections](#resolvingImplicitConnections) for more information.
+
+Entry document `openapi.yaml`:
+
+```YAML
+components:
+  securitySchemes:
+    MySecurity:
+      type: http
+      scheme: bearer
+      bearerFormat: JWT
+paths:
+  /foo:
+    $ref: "other.yaml#/components/pathItems/Foo"
+```
+
+Referenced document `other.yaml`:
+
+```YAML
+components:
+  securitySchemes:
+    MySecurity:
+      type: http
+      scheme: basic
+  pathItems:
+    Foo:
+      get:
+        security:
+        - MySecurity: []
+```
+
+In this example, it is implementation-defined whether the Security Requirement for "MySecurity" in `other.yaml` resolves to `other.yaml#/components/securitySchemes/MySecurity` or the RECOMMENDED resolved ___location of `openapi.yaml#/components/securitySchemes/MySecurity`.
+
 ### <a name="specificationExtensions"></a>Specification Extensions
 
 While the OpenAPI Specification tries to accommodate most use cases, additional data can be added to extend the specification at certain points.