Add info to security considerations about outdated security practices, and link in new versions

[handrews]

See PR #3584 from @AxelNennker for the background. We agreed in the TDC meeting 2024-02-22 to add info in security considerations and probably also on the learn site, and link to that and to any new RFCs in 3.0.4/3.1.1/3.2.0.

@lornajane also noted that we should replace any examples using deprecated practices with ones that are current.

[AxelNennker]

Regarding

@lornajane also noted that we should replace any examples using deprecated practices with ones that are current.

I assume that a PR replacing the implicit grant type examples by authoriztionCode grant type examples should start in v3.0.4-dev, right? Examples are non-normative and changing to another flow in an example should not break things.

https://github.com/OAI/OpenAPI-Specification/blob/v3.0.4-dev/versions/3.0.4.md

I would write that PR but I do not want doing it for the wrong version. Please advise.

[AxelNennker]

If I wrote an PR updating https://github.com/OAI/OpenAPI-Specification/blob/main/SECURITY_CONSIDERATIONS.md?plain=1 to which branch would that be?

I would recommend reading to API designers/developers the elven years old OAuth 2.0 Threat Model and Security Considerations and the new draft probably replacing it this year OAuth 2.0 Security Best Current Practice. From there I would argue that implicit flow should be replaced by authorization code flow with PKCE.

[AxelNennker]

Maybe mention FAPI 2.0 Security Profile because what is good for the Financial Industry should be considered for other APIs that e.g. handle health data, personal data, child data etc.

[handrews]

I'm not sure what's going on with the security considerations document, as I think it was a stop-gap for putting such a section in future releases. @darrelmiller can you advise?