From 6eda0990347b2ad9bcb6fc235b52ab0810ffcc4b Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Thu, 12 Sep 2024 09:30:41 -0700 Subject: [PATCH] Move complex Sec Req example to appendix F The extended example with a multi-document OAD and a Security Requirement in the referenced document did to fit well where it was, and there wasn't room in the Resolving Implicit Connections area. So this moves it to an Appendix linked from both locations. --- versions/3.0.4.md | 196 +++++++++++++++++++++++----------------------- 1 file changed, 99 insertions(+), 97 deletions(-) diff --git a/versions/3.0.4.md b/versions/3.0.4.md index 1b1610048a..f4f3f8c379 100644 --- a/versions/3.0.4.md +++ b/versions/3.0.4.md @@ -171,7 +171,7 @@ 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. +See [Appendix F: Resolving Security Requirements in a Referenced Document](#appendix-f-resolving-security-requirements-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 [URLs are resolved](#relative-references-in-urls) or restricts their possible targets. @@ -3739,6 +3739,8 @@ When a list of Security Requirement Objects is defined on the [OpenAPI Object](# ##### Security Requirement Object Examples +See also [Appendix F: Resolving Security Requirements in a Referenced Document](#appendix-f-resolving-security-requirements-in-a-referenced-document) for an example using Security Requirement Objects in multi-document OpenAPI Descriptions. + ###### Non-OAuth2 Security Requirement ```json @@ -3788,102 +3790,6 @@ security: - read:pets ``` -###### Security Requirement in a Referenced Document - -See [Resolving Implicit Connections](#resolving-implicit-connections) for more information. - -First, the [entry document](#openapi-description-structure) is where parsing begins. It defines the `MySecurity` security scheme to be JWT-based, and it defines a Path Item as a reference to a component in another document: - -```HTTP -GET /api/description/openapi HTTP/1.1 -Host: www.example.com -Accept: application/openapi+json -``` - -```json -"components": { - "securitySchemes": { - "MySecurity": { - "type": "http", - "scheme": "bearer", - "bearerFormat": "JWT" - } - } -}, -"paths": { - "/foo": { - "$ref": "other#/components/pathItems/Foo" - } -} -``` - -```HTTP -GET /api/description/openapi HTTP/1.1 -Host: www.example.com -Accept: application/openapi+yaml -``` - -```yaml -components: - securitySchemes: - MySecurity: - type: http - scheme: bearer - bearerFormat: JWT -paths: - /foo: - $ref: 'other#/components/pathItems/Foo' -``` - -This entry document references another document, `other`, without using a file extension. This gives the client the flexibility to choose an acceptable format on a resource-by-resource basis, assuming both representations are available: - -```HTTP -GET /api/description/other HTTP/1.1 -Host: www.example.com -Accept: application/openapi+json -``` - -```json -"components": { - "securitySchemes": { - "MySecurity": { - "type": "http", - "scheme": "basic" - } - }, - "pathItems": { - "Foo": { - "get": { - "security": [ - "MySecurity": [] - ] - } - } - } -} -``` - -```HTTP -GET /api/description/other HTTP/1.1 -Host: www.example.com -Accept: application/openapi+yaml -``` - -```yaml -components: - securitySchemes: - MySecurity: - type: http - scheme: basic - pathItems: - Foo: - get: - security: - - MySecurity: [] -``` - -In the `other` document, the referenced path item has a Security Requirement for a Security Scheme, `MySecurity`. The same Security Scheme exists in the original entry document. As outlined in [Resolving Implicit Connections](#resolving-implicit-connections), `MySecurity` is resolved with an [implementation-defined behavior](#undefined-and-implementation-defined-behavior). However, documented in that section, it is RECOMMENDED that tools resolve component names from the [entry document](#openapi-description-structure). As with all implementation-defined behavior, it is important to check tool documentation to determine which behavior is supported. - ### Specification Extensions While the OpenAPI Specification tries to accommodate most use cases, additional data can be added to extend the specification at certain points. @@ -4347,3 +4253,99 @@ Code that relies on leaving these delimiters unencoded, while using regular perc For maximum interoperability, it is RECOMMENDED to either define and document an additional escape convention while percent-encoding the delimiters for these styles, or to avoid these styles entirely. The exact method of additional encoding/escaping is left to the API designer, and is expected to be performed before serialization and encoding described in this specification, and reversed after this specification's encoding and serialization steps are reversed. This keeps it outside of the processes governed by this specification. + +## Appendix F: Resolving Security Requirements in a Referenced Document + +This appendix shows how to retrieve an HTTP-accessible multi-document OpenAPI Description (OAD) and resolve a [Security Requirement Object](#security-requirement-object) in the referenced (non-entry) document. See [Resolving Implicit Connections](#resolving-implicit-connections) for more information. + +First, the [entry document](#openapi-description-structure) is where parsing begins. It defines the `MySecurity` security scheme to be JWT-based, and it defines a Path Item as a reference to a component in another document: + +```HTTP +GET /api/description/openapi HTTP/1.1 +Host: www.example.com +Accept: application/openapi+json +``` + +```json +"components": { + "securitySchemes": { + "MySecurity": { + "type": "http", + "scheme": "bearer", + "bearerFormat": "JWT" + } + } +}, +"paths": { + "/foo": { + "$ref": "other#/components/pathItems/Foo" + } +} +``` + +```HTTP +GET /api/description/openapi HTTP/1.1 +Host: www.example.com +Accept: application/openapi+yaml +``` + +```yaml +components: + securitySchemes: + MySecurity: + type: http + scheme: bearer + bearerFormat: JWT +paths: + /foo: + $ref: 'other#/components/pathItems/Foo' +``` + +This entry document references another document, `other`, without using a file extension. This gives the client the flexibility to choose an acceptable format on a resource-by-resource basis, assuming both representations are available: + +```HTTP +GET /api/description/other HTTP/1.1 +Host: www.example.com +Accept: application/openapi+json +``` + +```json +"components": { + "securitySchemes": { + "MySecurity": { + "type": "http", + "scheme": "basic" + } + }, + "pathItems": { + "Foo": { + "get": { + "security": [ + "MySecurity": [] + ] + } + } + } +} +``` + +```HTTP +GET /api/description/other HTTP/1.1 +Host: www.example.com +Accept: application/openapi+yaml +``` + +```yaml +components: + securitySchemes: + MySecurity: + type: http + scheme: basic + pathItems: + Foo: + get: + security: + - MySecurity: [] +``` + +In the `other` document, the referenced path item has a Security Requirement for a Security Scheme, `MySecurity`. The same Security Scheme exists in the original entry document. As outlined in [Resolving Implicit Connections](#resolving-implicit-connections), `MySecurity` is resolved with an [implementation-defined behavior](#undefined-and-implementation-defined-behavior). However, documented in that section, it is RECOMMENDED that tools resolve component names from the [entry document](#openapi-description-structure). As with all implementation-defined behavior, it is important to check tool documentation to determine which behavior is supported.