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

Use URI references for Security Requirements in 3.2 #3776

Open
handrews opened this issue May 2, 2024 · 0 comments
Open

Use URI references for Security Requirements in 3.2 #3776

handrews opened this issue May 2, 2024 · 0 comments
Assignees
Labels
enhancement re-use: ref/id resolution how $ref, operationId, or anything else is resolved re-use: ref-everywhere Requests to support referencing in more / all places security: config The mechanics of severs and structure of security-related objects
Milestone

Comments

@handrews
Copy link
Contributor

handrews commented May 2, 2024

Resolving component names used in referenced (as opposed to entry) documents is ambiguous, particularly in 3.1 where we advertise the ability to have a components-only document to use as a shared component library. Historically, component names were resolved from the entry document, as reference targets were extracted from the document in which they were found without regard for the contents of the rest of the document.

In 3.1, whole-document parsing is required to properly implement the Schema Object, and there is a reasonable intuition that component names should be resolved within the document in which they appear. This is at odds with the historical behavior, and one could argue that for Security Schemes in particular, it makes sense to treat them as part of the "deployment" aspect of things, which is arguably more relevant to the entry document.

For the Discriminator Object, the ambiguity can avoided by using the mapping keyword with unambiguous URI-references (meaning URI-references that are not syntactically valid as component names). There is no similar workaround for the Security Requirement Object.

Adding a URI-reference mechanism for Security Requirements, whether by allowing $ref somewhere, or just allowing URI-references as keys in place of the current component names, will make it possible to write unambiguous security requirements.

@handrews handrews added enhancement review re-use: ref-everywhere Requests to support referencing in more / all places re-use: ref/id resolution how $ref, operationId, or anything else is resolved security: config The mechanics of severs and structure of security-related objects labels May 2, 2024
@handrews handrews added this to the v3.2.0 milestone May 2, 2024
@handrews handrews self-assigned this May 2, 2024
@handrews handrews removed the review label May 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement re-use: ref/id resolution how $ref, operationId, or anything else is resolved re-use: ref-everywhere Requests to support referencing in more / all places security: config The mechanics of severs and structure of security-related objects
Projects
None yet
Development

No branches or pull requests

1 participant