Open Community (TDC) Meeting, Thursday 22 May 2025

[github-actions]

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.

Meetings take place over Zoom: https://zoom.us/j/975841675, dial-in passcode: 763054

Accessibility & Etiquette

• Participants must abide by our Code-of-Conduct.

• Meetings are recorded for future reference, and for those who are not able to attend in-person.

• We invite you to feel comfortable to challenge any language or behaviour that is harmful or not inclusive during this meeting.

• We look forward to your participation, but please consider these acts of etiquette:

  • Remain on mute when not speaking to prevent interruptions.
  • Blur your background to reduce visual distractions.
  • Use the Zoom meeting "Raise Hand" feature to notify the group when you wish to speak.

Blur My Background	Raise Hand

Agenda Structure

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	@OAI/tsc
Active Projects	@OAI/openapi-maintainers
New issues needing attention	@OAI/triage

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

[lornajane]

I'd like to discuss a few items:

• Enhancing specification to describe token presentation mechanisms for OAuth 2.0 #3612 has a long proposal about improving how we describe how to OAuth2 against an API. My question is: at a high level, could this be a useful addition?
• There's a running (but currently very unhelpful because it's super basic so far) list of changes in Draft release notes for 3.2.0 and 3.1.2 #4600 in case anyone wants to get a sneak preview of what might be in 3.2.

[handrews]

@lornajane if you're going to look at security things, please consider:

• Representation of Client-Initiated Backchannel Authentication (CIBA) in 3.2.0 #4106 (comment) (Generalized OpenID Connect authorization support)

@SensibleWood has some ideas in there that might let us just add a more-or-less empty object to let folks experiment with using OpenID Connect information, which would be a better way to implement CIBA (which a contributor added but we later removed to discuss this). I feel like if we can just give folks a place to try this out we'll get some good engagement with low mandatory implementation cost. But I can't figure out where @SensibleWood 's proposal fits.

[handrews]

I will not be on the call today. I'm in favor of considering the above two security things for inclusion.

PRs that could probably be resolved on the call:

• v3.1.2: Provide guidance on null in XML. #4612 (3.1.2 null in XML) This has 2 approvals (one was cleared for a trivial fix), but is admittedly a bit weird. It would be great to get this over the finish line so I can incorporate it into the 3.2 XML PR still under review
• v3.1.2: Allow xml field/keyword in any schema as a MAY #4613 (3.1.2 allow xml in any schema as a MAY) Should be a straightfoward yes or no- it's very simple, just a question of whether we're OK adding this MAY in a patch release. Doing so would highlight forward-compatibility for 3.2.
• v3.2: Allow allowReserved everywhere #4593 (allowReserved everywhere) Another with 2 reviews (one cleared on a technicality) that would be good to get done as it's pretty straightforward
• v3.2: Support summary alongside every description #4610 (support summary consistently alongside description) It would be good to make a call on this. So far 2 TSC members are pro, 1 wants to only do it in some places, I personally think it's easier if it's consistent but I mostly just want a decision for both the PR and the issue that motivated it.

Just needs one more approval, @lornajane did my answer to your question make sense? If you want me to add more clarity around $id, perhaps that could be a follow-on PR as the behavior there is not new?

• v3.2: $self field (Alternative Approach) #4556 ($self)

Questions that are stalemated and need a definitive answer (I do not care what the answer is on either of these, just that we communicate an answer to the intersted parties rather than leaving it hanging):

• 3.2: allow `openapi` field to just specify MAJOR.MINOR and omit the PATCH number #4233 ("3.2", "3.2.0", or allow both?)
• Support API-wide version information #4212 (API-wide version) it looks like we're not doing this, but someone should let Erik know through the issue as we've been talking about it as part of 3.2 for a while- if we're not doing it, then we should close the issue as rejected

PRs that need someone to engage more deeply:

• v3.2: Support ordered multipart including streaming #4589 (ordered multipart, including streaming) Please try to at least designate who on the TSC will review this so we can start to make progress
• v3.2: Add in: "querystring" parameter location treating the entire query string as one chunk of content #4590 (in: querystring) Thanks to @lornajane for the review and approval, can we designate a second TSC reviewer to get this over the finish line?
• v3.2: Support all common XML node types (element, attribute, text, cdata) #4592 (broader XML support) Thanks to @ralfhandl for the reviews so far — how can we get this over the line? Do we need to go post on LinkedIn to solicit some XML expertise? Does anyone have any contacts with relevant knowledge they could recruit?