OpenAPI-Specification
OpenAPI-Specification copied to clipboard
OAI
Extensible Security Scheme Object
There are a number of issues regarding support for security controls which do not fall neatly under the "apiKey", "http", "oauth2", "openIdConnect" taxonomy. This suggests that we need a more extensible form of the Security Scheme Object. One that makes it easy to add security schemes to OpenAPI. I propose that we create a new branch to work this issue. Guiding principles are:
- Do no harm. The extensible security schemes should be backwards compatible with the current version.
- Use a registry approach. This allows new schemes to be added without requiring a change to OpenAPI. More to come.
http is an extensible scheme. And it has a registry https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml
Yes, http has made a good start. But is it sufficient? There are authentication schemes which are not tied to HTTP. It should be quick and easy to identify if any of these are in use. In addition, there are other types of security control; integrity, confidentiality, non-repudiation, access control, etc. What does a user need to know about these controls? How do we provide them with that information? Keeping in mind that the user is likely to be a software analytic (no wetware involved).
@cmheazel We have a number of conversations going on at the moment around security. We have an item on the meeting agenda #1512 this week to talk about a proposal for payload encryption.
However, our interest is in security issues that are related to HTTP, as that is what OpenAPI is all about, describing HTTP APIs. It is true that there are other types of APIs with other security capabilities and requirements, but that is currently out of scope for us.
The problem is that OpenAPI has become very popular. It has become a de-facto standard for large scale distributed processing. Wide acceptance brings more requirements. I'm working with an industry consortium to try to get ahead of those requirements. Security is one of the low hanging fruit. It is possible that OpenAPI is not the answer. I hope that is not the case so we should at least have the conversation.
I'm on travel this week and will not be able to attend the TSC. That's unfortunate since payload encryption is on my wish list.
@cmheazel hopefully the security proposal section of the TSC meeting will be recorded.
