v3.3: define an explicit default for the top-level "security" object - #5536
v3.3: define an explicit default for the top-level "security" object#5536karenetheridge wants to merge 1 commit into
Conversation
Similar to the "servers" default, this does not change any functionality; it only adds clarity.
mikekistler
left a comment
mikekistler
left a comment
There was a problem hiding this comment.
I have concerns about this change.
| | <a name="oas-security"></a>security | [[Security Requirement Object](#security-requirement-object)] | A declaration of which security mechanisms can be used across the API. The list of values includes alternative Security Requirement Objects that can be used. Only one of the Security Requirement Objects need to be satisfied to authorize a request. Individual operations can override this definition. | ||
| If the `security` field is not provided, or is an empty array, the default value would be an array consisting of a single Security Requirement Object with no properties (`[{}]`), which indicates that security is optional. | |
There was a problem hiding this comment.
I am uncomfortable with this change, as it seems to change the meaning of an OpenAPI description that does not have a security field in an "Open World" interpretation of OpenAPI (which I think is how we want OpenAPI descriptions to be interpreted).
From [Is OpenAPI an Open World or a Closed World Contract?](#568):
In an open world we cannot make assumptions about what is not described.
So if security is not provideed/described, we cannot make assumptions about it -- including about whether it is optional or required. It may very well be required and simply not described.
There was a problem hiding this comment.
Isn't it already described that "no security" is the default, in the absence of any security specification? That is: how would an implementation's behaviour change?
3 participants
Similar to the "servers" default, this does not change any functionality; it only adds clarity.
(I'm on the fence as to whether this should/could go into v3.2.)