Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v3.1.1(schema): update empty security array constraint #4070

Conversation

jeremyfiel
Copy link
Contributor

handrews and others added 30 commits September 28, 2023 09:36
This follows up from a discussion on the OAI slack that decided:

* redefining "document" to sometimes mean multiple documents is confusing
* "description" has more support than "definition"
This is a more natural grouping of similar types, making the data much easier to read.
…e-style

the chart in section 4.8.12.4 shows that primitive and object types are also valid for style=simple
…v3.1.1

switch the order of these styles in the tables
…ct-extra-params

extra keywords in the reference object are permitted (v3.1.1)
Co-authored-by: Ralf Handl <ralf.handl@sap.com>
Remove "redact" from wording, leaving only "obscure".

Co-authored-by: Rob Ede <robjtede@icloud.com>
Co-authored-by: Ralf Handl <ralf.handl@sap.com>
Co-authored-by: Ralf Handl <ralf.handl@sap.com>
…d-composition

merging after discussion on the TDC call today
* Sync validate-markdown workflow with main (3.1.1)

* Match latest environment from main
Generalize description of password data type
…ples-v3.1.1

whitespace and quoting fixes in json and yaml examples (v3.1.1)
Co-authored-by: Adam Altman <adam@rebilly.com>
Co-authored-by: Mike Kistler <mikekistler@microsoft.com>
@jeremyfiel jeremyfiel force-pushed the feat/update-empty-security-array-constraint-3.1.x branch from b445f55 to 43e0026 Compare September 4, 2024 20:52
@jeremyfiel jeremyfiel force-pushed the feat/update-empty-security-array-constraint-3.1.x branch from 43e0026 to c7d6fc9 Compare September 4, 2024 20:55
@handrews
Copy link
Member

handrews commented Sep 4, 2024

@jeremyfiel as with the other one this needs to go to main, but also I'm not sure why you have added this as [] is allowed.

@jeremyfiel
Copy link
Contributor Author

Doesn't your comment infer from the spec language that at minimum for an undefined security requirement, the empty object SHALL be defined?

#3938 (comment)

@jeremyfiel
Copy link
Contributor Author

I also commented in a slack discussion today that I believe the security requirement spec text is the only reference to an actual JSON structure where is recommends [{}] rather than only descriptive text.

https://open-api.slack.com/archives/C1137F8HF/p1725479409881939?thread_ts=1725473300.217419&cid=C1137F8HF

@jeremyfiel jeremyfiel changed the base branch from v3.1.1-dev to main September 5, 2024 00:52
@jeremyfiel jeremyfiel requested review from a team as code owners September 5, 2024 00:52
@handrews
Copy link
Member

handrews commented Sep 5, 2024

@jeremyfiel all of that was about defining what security: [] means, so that means it is a legal value and the schema cannot forbid it.

@jeremyfiel
Copy link
Contributor Author

I suppose the wording To remove a top-level security declaration, an empty array can be used. contradicts the recommendation To make security optional, an empty security requirement ({}) can be included in the array.

@ralfhandl
Copy link
Contributor

the wording To remove a top-level security declaration, an empty array can be used. contradicts the recommendation To make security optional, an empty security requirement ({}) can be included in the array.

No.

The top-level declaration in the OpenAPI Object is the default applying to all operations, and this may state "no authentication required" by including {} in the array.

An operation can opt out of this default in two ways:

  1. with a non-empty array listing all mechanisms this operation supports
  2. with an empty array saying "I don't tell you how to authenticate here", which probably implies that unauthenticated access allowed by the top-level default will probably not work

Should we need to elaborate this in the specification text?

@ralfhandl ralfhandl closed this Sep 5, 2024
@ralfhandl ralfhandl reopened this Sep 5, 2024
@ralfhandl ralfhandl marked this pull request as draft September 5, 2024 10:14
@lornajane
Copy link
Contributor

There are some problems with this pull request, but having discussed the proposed change (the newest commit), this isn't a useful change to make to our existing validation schemas since it is valid to have an empty security array. Please keep an eye on the project for more discussion about linting schemas in addition to our validation schemas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.