Open Community (TDC) Meeting, Thursday 22 February 2024

[github-actions]

NOTE: weekly meetings happen on Thursdays at 9am - 10am Pacific.

This agenda gives visibility into discussion topics for the weekly Technical Developer Community (TDC) meetings. Sharing agenda items in advance allows people to plan to attend meetings where they have an interest in specific topics.

Whether attending or not, anyone can comment on this issue prior to the meeting to suggest topics or to add comments on planned topics or proposals.

Zoom: https://zoom.us/j/975841675, dial-in passcode: 763054

Participants must abide by our Code-of-Conduct.

Topic	Owner	Decision/NextStep
Intros and governance meta-topics (5 mins)	TDC
Reports from Special Interest Groups (5 mins)	SIG members
Any other business (add comments below to suggest topics)	TDC
Approved spec PRs	TDC
New issues needing attention	@OAI/triage

/cc @OAI/tsc please suggest items for inclusion.

[handrews]

PRs:

• ALL THE SECURITY!!!! 🔒🤣
  • Added security considerations document #3488 (from @darrelmiller 's comment below)
  • OAuth2 implicit grant is not secure #3584 (can't be merged as is, seems to be open as to whether we want to do this in a patch or whether it belongs on learn? or in the security considerations doc?)
  • Proposal: Add JWT audience in security scheme #3286 (an old security PR for 3.2.0, since we seem to have a security theme at the moment 🧐 )
  • Initial proposal for New Security Schemes #2582 (a proposal with a discussion ending in a "so... what now?" comment)
• Is this "guidelines" directory still relevant, and if so is it living in the right place?
  • [cleaning] Guideline #3579

Policy issue:

• Minimum criteria for Namespace Registry #3598 (from @miqui 's comment below)

[darrelmiller]

Security considerations PR #3488

[lornajane]

Whitespace fixes PRs are rebased and ready already merged

[miqui]

adding: #3598. (OAS extensions)

[hudlow]

If possible, I'd like to follow up on #3572, but unfortunately I can only join at the bottom of the hour.

[AxelNennker]

Could we talk about #3595 in this meeting?

Some things we discussed today could be simplified if we had oauth2 metadata in openapi not only openIdConnectConfigurationUrl

[lornajane]

Recap from my notes (we have AI transcript but you might not want to read all of it)

• Very good turnout this week with 17+ people.
• Updates from SIGs: Moonwalk has good meetings and talked about deployments, both Overlays and Workflows are seeing some activity.
• TSC membership updates are expected next week.
• Added security considerations document #3488 needs some formatting/editing but got good feedback and is needed for openapi to become a media type.
• OAuth2 implicit grant is not secure #3584 concerns the modern, secure use of OAuth2. We concluded that OpenAPI is here to enable users to describe their APIs, not to judge if they are doing it right. We'll update our examples to use updated practices (@AxelNennker can you help me identify which examples those are? Ideally by opening an issue that someone can work on) and create learning resources on how it should be done. Edit: Add info to security considerations about outdated security practices, and link in new versions #3603 is the followup issue
• Proposal: Add JWT audience in security scheme #3286 proposes adding an audience field; group feedback was to add it as an x-audience extension first and show adoption/usage before proposing (should we have closed this?)
• Initial proposal for New Security Schemes #2582 is an old issue about sorting out the security schemes. This needs major work so has been moved to the Moonwalk repository. Once we settle how the security schemes will look in the 4.0 version, we'll try to adopt as much as we can for the 3.x branches but it makes no sense to invent something now and something completely different in a year.
• Clean guidelines #3580 PR to remove the old extensions stuff relating to OpenAPI 2.0 was merged.
• Minimum criteria for Namespace Registry #3598 is about fleshing out our registries for extensions and we also discussed the use of vendor namespaces. The tl;dr is that we should encourage extensions that can be used with multiple tools, but that specific things can still use a prefix. @miqui is going to work on adding some common extensions to the list.
• Formats for arrays #3572 proposes adding more array format styles, and we'd appreciate comments and thoughts on that one if anyone has any.