Conversation
This commit is an exact copy of the Security Scheme Object, OAuth Flows Object, and OAuth FLow Object sections of the OAS as they appear on the v3.3 branch in the OpenAPI-Specification repository (commit 22026f5a876674d0fbe5f5d1f9d9a1380587a4be).
| - $ref: '#/$defs/security-scheme/$defs/type-apikey' | ||
| - $ref: '#/$defs/security-scheme/$defs/type-http' | ||
| - $ref: '#/$defs/security-scheme/$defs/type-http-bearer' | ||
| - $ref: '#/$defs/security-scheme/$defs/type-oauth2' | ||
| - $ref: '#/$defs/security-scheme/$defs/type-oidc' |
There was a problem hiding this comment.
I think of the security scheme object as a "discriminated union", with the type field being the "discriminator". I think the natural way to think of discriminated unions is as a "oneOf". Is there some advantage or benefit to expressing it as an "allOf" here? Not that I think the current description is "wrong" -- it just doesn't match my intuition. And I think an "allOf" description might be less verbose -- avoiding the "if / then / else" construction in the subschemas.
mkistler
left a comment
There was a problem hiding this comment.
This looks fine to me, but please look at my comments as I think there may be some small corrections needed before merging.
| @@ -10,6 +10,126 @@ | |||
|
|
|||
| TODO: Define the Security Specification. | |||
There was a problem hiding this comment.
Should this line be deleted now that the Specification section has been added?
| specification-extensions: | ||
| $comment: https://spec.openapis.org/oas/v3.3#specification-extensions | ||
| patternProperties: | ||
| '^x-': true | ||
|
|
||
| additionalProperties: | ||
| $ref: '#/$defs/example-or-reference' |
There was a problem hiding this comment.
Something looks not quite right here. Looking a the 3.2 schema, I think the "additionalProperties" came from the "examples" def, so it probably shouldn't be here.
This just moves things over so we can iterate on any necessary changes.
The schema approach in particular should not be taken too seriously, as noted in the README. I just want the schema to stay in the same repository rather than be separated while we figure out how to structure it.