Skip to content

v3.3: First pass at explaining SAFs - #5447

Open
handrews wants to merge 1 commit into
OAI:v3.3-devfrom
handrews:safs
Open

v3.3: First pass at explaining SAFs#5447
handrews wants to merge 1 commit into
OAI:v3.3-devfrom
handrews:safs

Conversation

@handrews

@handrews handrews commented Jul 25, 2026

Copy link
Copy Markdown
Member

This PR is to get conversation started on how we want to explain SAFs in the OAS. I'm not particularly attached to it, but as we get the SIG/SAF repositories up and running, we should figure out how to explain this to readers.

  • schema changes are included in this pull request

3huss99-ui
3huss99-ui previously approved these changes Jul 25, 2026
@karenetheridge
karenetheridge dismissed 3huss99-ui’s stale review July 26, 2026 01:50

This user appears to be farming participation events, possibly for future spamming or attempts to inject vulnerabilities into tooling or content.

@handrews
handrews marked this pull request as ready for review August 9, 2026 19:34
@handrews
handrews requested review from a team as code owners August 9, 2026 19:34
@handrews

handrews commented Aug 9, 2026

Copy link
Copy Markdown
Member Author

Clean rebase force-push, no changes to commits. This is ready for review.

@miqui miqui left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me. Perhaps a few more examples?

Comment thread src/oas.md
| Field Name | Type | Description |
| ---- | :----: | ---- |
| <a name="oas-version"></a>openapi | `string` | **REQUIRED**. This string MUST be the [version number](#versions-and-deprecation) of the OpenAPI Specification that the OpenAPI document uses. The `openapi` field SHOULD be used by tooling to interpret the OpenAPI document. This is _not_ related to the [`info.version`](#info-version) string, which describes the OpenAPI document's version. |
| <a name="using-features"></a>usingFeatures | Map[`string`, `string`] | A map of [SAF](#standardized-api-features) names, as defined in various companion specifications, to a valid version string for the named SAF. Implementations MUST apply the SAF's rules, such as treating header parameters that are managed by the SAF as illegal in Parameter Objects, while processing the current document. The default is `{"legacySecurity": "3.3.0"}`. |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this default value mean, and where is that meaning described?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ralfhandl oh, I don't think I meant to include this yet as it references something we have not decided, but the idea is:

  • We should move the existing Security Scheme, OAuth Flows, and OAuth Flow Objects to the SIG-Security specification and treat them as a SAF, which I was calling legacySecurity
  • For compatibility with OAS 3.2, if you don't explicitly set usingFeatures it assumes you are using the legacy security, as otherwise everyone's OAS 3.2 (or 3.1)-style security would break.
  • The 3.3.0 was me thinking that since the legacy security was coming from the original OAS specification revision stream, it should keep that numbering (implicitly, the security in past OAS versions could be considered a SAF with the matching version... why we'd want to do that idk, I'm just explaining my thought process).
  • The Security Requirement Object probably stays in the main OAS, although I think that will become clear one way or another as we work with stuff.

I am also happy to take this part (and anything else that suggests we've made a decision on security compatibility) out of this PR. We can add it back when we make a decision there.

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.

4 participants