Security descriptions alignment with OpenAPI 3.0

[egekorkan]

Disclaimer: Automatically adding Defer to TD 2.0 since I do not see a way to include them in a backwards compatible way.

OpenAPI 3.0 has a list of changes regarding security descriptions. I am copy pasting them below:

• securityDefinitions were renamed to securitySchemes and moved inside components.
• type: basic was replaced with type: http and scheme: basic.
  • The new type: http is an umbrella type for all HTTP security schemes, including Basic, Bearer and other, and the scheme keyword indicates the scheme type.
• API keys can now be sent in: cookie.
• Added support for OpenID Connect Discovery (type: openIdConnect).
• OAuth 2 security schemes can now define multiple flows.
  • OAuth 2 flows were renamed to match the OAuth 2 Specification: accessCode is now authorizationCode, and application is now clientCredentials.

I find the first two ones rather important for TD 2.0 if we want to be always aligned with OpenAPI. At the same time, adding a term like type that contains the protocol name is rather concerning

[JKRhb]

At the same time, adding a term like type that contains the protocol name is rather concerning

I think this raises a general question if Security Schemes can really be described in a "protocol agnostic" way. While Schemes like the BasicSecurityScheme[^1] or the PskSecurityScheme[^2] can be applied to other protocols, most of the currently specified Security Schemes seem to be very HTTP-specific. Security Schemes like OSCORE or EDHOC, which might be considered for TD 2.0, on the other hand are very CoAP-specific.

Therefore, I think you might even argue that SecuritySchemes (in TD 2.0) should be specified in Protocol Binding documents instead of the main document (which is of course not possible at the moment due to their informative status) or the adaption to a specific protocol should at least be described in more detail (e. g. using basic security with MQTT). I guess in this context it could also be reconsidered specifying all possible schemes in the main TD document even though they might only be applied to a specific protocol (like OAuth 2 and HTTP for example).

[^1]: Which can be, for example, applied to MQTT in a way that does not correspond to RFC 7617 (which prescribes Base64 encoding and the inclusion in an HTTP header, for example). [^2]: Which can be used for CoAPS.